Audible

Week Thirty-one

(or Can You Hear Mech Now?)

Last weekend I made several new sounds for AIM<. The game is far enough along that I can look at what will actually be in our game play and focus on just the sounds we need instead of guessing. Chloe Terry got some of the audio in last weekend and Patrick Oudemans has been working on getting the rest done this week. I've got a few more to do this weekend and all the final sound will be implemented throughout the next week in time for the SGX debut.

The last time I talked about sound was four months ago, where I mentioned that general power-up audio, drone jet engines, and a couple more tracks were mastered. This set of sounds and the audio featured in AIM< Audio II and III further down this post were created by an auxiliary team I lead from a Fall 2016 digital sound studio. The contributing members of that team are as follows: Shane Yach, Hannah Bragelman, Derek Sirp, and Daniel Mike. Take a listen to the first set of tracks!



The team and I made this first set of audio for the areas I thought would be the most important at the time. Some of the mechanics have changed since then and a couple of the sounds are not as critical as they once were but are still being used in some form or fashion.

Next came the audio for picking up power-ups, swapping power-ups, firing projectiles, launching drones, and an alarm for nearby danger. Out of all of these, the projectile sound was the most difficult. Field recordings of firearms contain a lot of reverb (kind of like echo) even if they are recorded in a small room. The presence of reverb causes the audio sound like it's happening in very specific environments. Removing the reverb is necessary so the engine can control audio "size" based on how the levels are designed. Here's the audio!



I really enjoy the physicality of  the swap power-up track created by Hannah Bragelman. It's going to be used for menu sounds and when players swap ammo types with the "ammo cards". As I mentioned in my UI post, portions of the UI were inspired by trading card games so this track emphasizes the physical inspiration quite well.

The last of the audio created with the auxiliary team features explosions, alerted enemy sounds, and an impact sound. Click play!

Shane Yach was responsible for the hilarious drone alert sounds. All of the sounds he synthesized have a lot of personality and are very dynamic breathing welcome life into the AIM< world.

The explosion sounds were challenging. Any field recordings of explosions face the same problems as firearm sounds. Once reverb is removed, the recordings tend to feel flat and unsatisfying. There are a couple tricks to bring back some depth. A rumbling low end can be made by slowing down a lion or other big cat roar. Layer that with a kettle drum and the depth is returned without too much reverb.

Audio, like any other art, is about trying to find what to exaggerated to create the feeling, world, character, or other elements one desires to create. It's not always beneficial to try to mimic reality exactly since the fantasy of what something is is almost always better than the reality. I'll elaborate on this thought a bit more in my next post when I cover the most recent audio I've made.

I know I said this last week but be sure to keep checking the AIM< Facebook page! Mark May 4th on your calendar and stop by to play the game if you're in the area! Have a great weekend!

Mines

Week Thirty

(or Mine? Mine!? Mine?!?)

The other members of Violent Traversal and I have been ramping up work for the public demo of AIM< at Stout's game expo, SGX. Several members of the team have been working steadily on a level and squashing bugs while Chloe Terry and I finish the UI and pull together sounds. The UI is looking really polished now so my focus is starting to narrow in on sounds. I've got many more more to make this week/weekend, which I'll talk about in a bit more detail in an upcoming post.

In a past post, I showed a concept for some mines and shared some brief details. They are now fully realized in-engine with 3D models and textures! There are two versions; one is a mine that lays on the ground and the other floats in the sky, inspired by sea mines.

Both versions serve as hazardous obstacles and encourage players to pay attention to their surroundings while moving through the environment. The mines explode on contact and emit a beeping sound when players get too close. I'm hoping to get some time to add in more "personalized" sounds to both, such as a jet sound for the hovering mines. Check out the full screenshots in the gallery below.

That's it for this week. Have a great Easter weekend!

Be sure to check out the AIM< Facebook page! Mark May 4th on your calendar and stop by to play the game!

Mine Concepts by Aram Wahler

AIM< Air Mines by Violent Traversal

AIM< Ground Mines by Violent Traversal

Rift

Week Twenty-nine

(or Shift to Balance)

This week I planned on detailing the other power up in AIM< called "Rift". As the week progressed however, I had a couple conversations with one of the team members working on level design. We decided that the Rift concept created problems requiring more time than we have remaining to address. With only about 2 weeks and a couple days left to the deadline, we've had to make some tough decisions as to where to spend our precious resources. For now, "Rift" has been shelved in favor of making sure that the other power-up, "Rocket", receives the amount of polish and dedicated level design it deserves in order to shine.

I'm learning that balance is an important word for game design. Most obvious perhaps is the realization that balance can refer to the distribution of power each element is allowed to have during game play. I've learned this week balance is also needed in making sure that all the parts of a game are treated with the attention and resources that they need in order to pave the way for fun.

Each dev team has to decide for themselves what the balance looks like. Violent Traversal decided that we would rather have a polished portion of game play demonstrating the essential components of AIM< than an amalgamation of disparate parts. I think a good goal is to show the potential of our game's design than leave the audience wondering what we were trying to accomplish. I'm confident that AIM< will be a fun and polished experience on release day.

More topics are on the way in upcoming weeks so make sure to check back for more AIM<! Have a great Spring weekend!

Rift Concept Ver 1 by Aram Wahler

Rift Concept Ver 1.2 (back) by Aram Wahler

Rift Concept Ver 2 by Aram Wahler

Switches

Week Twenty-eight

(or Switch On, Switch Off)

Well, as I said last week, this post is about switches. I'll explain what they are in AIM< and how they work, show the concept art, 3D models, and HUD icon throughout the post and in the gallery at the end.

Switches are another mechanic that we tested in a build that I mentioned a couple weeks ago. I had gotten some feedback some weeks back from our producer/professor Jay Little that we needed to implement a mechanic that gave players some tangible feedback for progress during game play.

I started doing some research and discovered a Gamasutra article written by Orcun Nisli that nicely covered general elements that are found in platforming games. In "The Path to Monochroma: Platformer Design Elements", Nisli talks about the idea of "locks and keys". Players find keys while playing through levels to unlock closed portions of levels and progress through the game. The purpose of this design is twofold. Players want to explore, being motivated by the goal of finding keys. Also, when doors are unlocked the previously closed off level sections are opened giving the player a sense of measurable progress.

A while back, Sihneng Thao, one of the modelers on the team, told me an idea he had for using the AIM< drones as batteries during game play. I merged Sihneng's idea with the "lock and key" concept to create the switch mechanic for AIM<.

The concept for the mechanic is that there are "switch" devices all around in AIM<, which are essentially battery bays. Once a drone is piloted into a bay, it charges the device, switching on dynamic level elements such as moving platforms and doors. Players will now be able to measure some of their progress through the level via the switch devices.

I drew two different switch concepts; one closed and one open. The closed switch is a bit like a garage. Once the drone enters the bay, a door closes keeping the drone safe and the device powered. A drawback is that this switch can only be entered one way; through the open door.

The open switch can be entered from the top and sides but once the drone interfaces with the device, it's left vulnerable to enemy fire. Players will have to make sure to clear the area of enemies before using or else risk losing their drone.

For both switches, once a drone activates the device, a light beam shoots out towards the sky so that players can see a powered switch from most places in the level. I also just finished making a HUD icon to show players where they are in relation to a nearby switch.

Sihneng Thao and Jon Worman just got the models finished for both switches this week. Check them out in the gallery below!

That's all for this post. Check back in a week or so for more AIM< developments! Have an awesome weekend!

Closed Switch Concept by Aram Wahler

Closed Switch Model by Jon Worman

Open Switch Concept by Aram Wahler

Open Switch Model by Sihneng Thao. Drone Model by Daniel Bodunov.

Rocket

Week Twenty-seven

(or Up, Up, and Don't Die!)

I intended to write and publish this post last week but time flew by before I knew it. So, anyway. This post will finally reveal some information and art for the power-up we tested in our last build. The art featured in the post is pretty recent. I drew the concept a couple weeks ago and Jon Worman just put finishing touches on the model in the past couple days.

The power-up is called "Rocket". Once player's pick this up at the end of one of the levels, the mech is able to make Rocket Drones and Rocket Ammo. Rocket Drones have a lot of control in the air and are able to boost themselves vertically to greater heights than other drones. Players will be able to use them to reach out-of-reach places and when aerial maneuvers are needed. Rocket Drones can also self-destruct, dealing damage to nearby enemies. They will explode if too much damage is received.

Power-ups have come a long way from the initial concept. The last time I posted some art for them was November last year. At that point, I was planning on having players pick up finite power-ups and manage when and where they would be used. Now that sort of resource management is met by the current scrap/energy resource mechanic and players keep the power-up once it's acquired.

Not only did power-ups in general go through big conceptual changes, specific power-ups like Rocket changed quite a bit as well. Initially, I wrote Rocket to be all about vertical movement and very little aerial control. Another power-up called "Glider" would be about horizontal movement. The reason behind splitting all of this functionality up was to have a number of large rewards that could be given to players when they beat levels or game-play challenges.

The fragmentation turned out to be a bit clunky and overlapped too much in testing. We decided to combine the horizontal control with Rocket and make it a more functional power-up. Rocket now feels really great to use and I think we will have some fun challenges in store for players.

We're getting further and further along in development, which means I'll have some new stuff to show next post.

Have a great rest of the weekend!

Rocket Concept Art by Aram Wahler

Rocket Model by Jon Worman. Drone Model by Daniel Bodunov.

Wing Power-up Concept by Aram Wahler

Progress

Week Twenty-five

(or Build 3ish?)

Violent Traversal just completed our "Mech Powers" build of AIM< with the goal of testing...surprise! The mech model and a power-up. We haven't put power-ups in a map since last October, where we tested out our initial power-up designs. So this build was a pretty big deal.

It turned out to be quite successful! We didn't have as many hands test this build as the two previous versions, but our producer (and professor), Jay Little, was pleased with the progress and we got great feedback from everyone that played.

The past couple weeks I've talked about the design decisions and process behind building the UI for AIM<. One of our programmers, Chloe Terry, worked very hard to get the UI implemented for the current build and make any changes that needed to be made. It looks and functions awesomely so far! More tweaks and adjustments will continue to be made but it works very well and is tremendously helpful in testing and playing. We were able to understand much better what was happening during game play and feel less disoriented. A working UI really helps understand what's working and what needs fixed.

As you can see from the screenshot, an updated mech model made it into this build! Dan Bodunov has been hard at work turning the mech concepts into a final model for our game. Soon, he will have the animations completed and move onto texturing the completed model, creating the final, massive juggernaut that you will be able to control when the game is released.

This mech model is now correct size and replaces the placeholder being used previously. Now we are better able to understand the scale and proportion between the mech, drone(s), and level geometry, allowing for more accurate white-boxing of levels.

Speaking of levels; Steven Lindbloom designed and white-boxed the level shown in the screenshots. He used geometry created by Jon Worman and switch objects programmed by Marcus Tolbert (also used in the last build) to design a fun and engaging level focused on showcasing a power-up. Construction of the level also served as a test for a modular pipeline we are adopting to create the rest of the levels for AIM<.

The level is a lot of fun to play. Steven plans to continue working on it and refining it. I'll record some game-play footage of the next version for a future blog post.

I've mentioned a few of the developers from Violent Traversal involved in creating the "Mech Powers" build, but everyone on the team has in some way or another had a hand in creating what you see in the screenshots. Take a look at the facebook page to see blog posts by the other members and see what they're up too. Each member of the team plays an integral and irreplaceable role in creating AIM<.

Next post, I'll be talking about the power-up tested in the "Mech Powers" build. A near-future post will cover the "switch" objects and collaboration between modelers Jon Worman, Sihneng Thao, and I.

Check back soon and have a great weekend!

AIM<: Mech Powers Build Screenshots Featuring work by everyone at Violent Traversal.

Shapes

Week Twenty-four

(or UI II)

I hope you've had a great week! I thought I would talk a little bit more about the UI since I'm still working on certain aspects and continuing to develop artwork. I decided to show some of my sketch pages this week in the gallery below. Both pages show my UI ideation process on paper.

Last week I laid out the fundamental concepts behind the UI I'm designing for AIM<. This week I'll go into a little more detail regarding one of the most enjoyable parts to develop; the artwork.

The artwork is primarily icons. This decision is largely influenced by design conventions already established by shooters and further enhanced by the TCG (trading card game) influence I mentioned near the end of my blog post last week.

Beginning with the earliest shooters, specific iconography is developed to quickly communicate to players vital information, like health and ammo, at a glance during frenzied action sequences. Many shooters have their own iconography. Shape language is typically quickly established early in the game so that later, during more difficult levels, players can quickly identify important pickups, power-ups, avatar status, etc.

In AIM<, players will be able to see at a glance where resources and threats are and quickly make decisions. I designed the icons with high contrast to stand out from the  environment. Also, each icon uses shape language that varies greatly from one another to avoid confusion. The final color schemes for the UI will further enhance recognition.

TCG cards use a similar logic for iconography as shooters but take the concept a little further. It's common for TCGs to sum up complex functions with a single icon. Icons are even able to be strung together to form even more complex function statements. Iconography is key to card designs since space (or real estate) is often limited to a very small area. Important information must be able to be communicated at a glance without competing too much with illustrations, or breaking aesthetic uniformity and consistency.

I created a couple variations for many of the elements featured on the "cards" in AIM<, seeking to establish a uniform aesthetic among the different icons. All of them need to look like they fit in the same game. I also had to be sure that each icon could be resized and used at different locations consistently, without having to change any of the elements that compose the icon. Some basic graphic design knowledge has been very helpful when making these decisions.

Game design, I've learned, really is a multi-disciplinary exercise. Every course I've taken has been influential in some form or fashion.

I look forward to sharing more with about the design process behind AIM< next week! Have an awesome weekend!

AIM< UI Concept Sketches Page 1 by Aram Wahler

AIM< UI Concept Sketches Page 2 by Aram Wahler