The End

Week Thirty-seven

(or The End Is Nigh) 

The AIM< website is now updated with the game, process book, and game design document. Enjoy!

I spent this week thinking about what I would post to wrap up my thoughts and reflect what I learned during AIM<’s development. While compiling the materials for the AIM< process book, I wrote a post-mortem with input from the rest of Violent Traversal.

After reading through the post-mortem again, I’ve decided that it nicely sums up the development process and leaves nothing out that I could concisely elaborate. So, this will be my last post for my AIM< dev blog. Thank you very much for taking the time to read the posts. I hope that my trials, errors, and successes can encourage you in any of your creative endeavors.

If you’re interested in any of my future dev blogs or projects, check out my homepage and blog page. I will be working on new projects soon. Until next time, enjoy the post-mortem!

“AIM< is the culmination of two semesters worth of teamwork amongst individuals with a passion for learning game design and development. The development cycle reflects the many trials, errors, and successes experienced while learning new skills and disciplines. Our goal was to develop a fun game that was markedly different from a majority of readily available games.

From the beginning, the playful and abstract concept of “cannon shooting cannons” took a great deal of time to explore. The initial concept met our goal of being different from other games but also brought the challenge of trying to find enough common ground with games we had experienced to know where to begin.

We saw the gameplay as being comprised of three genres; puzzle, platform, shooter, and some exploration. While these genres have been combined in other games, our goal was to reject some conventions by featuring shooting as the primary means of moving and interacting with the environment.

A copious of time passed before a mission statement was finalized. This contributed to the development and persistence of a gameplay identity crisis throughout a majority of the design process. The identity crisis caused many difficulties, including setting task goals and establishing scope. Scope grew out of control. When we realized the issue, we were forced to start cutting features and content to have a cohesive project by the deadline. Our struggle to manage scope was compounded by a lack of experience with anticipating the amount of time required to augment existing skills or learn new ones.

Level design proved to be a particularly important skill that no one on the team had much experience with. We started this process very late in development and discovered a pipeline was needed for producing levels. Developing such a pipeline was a process that should have been addressed much earlier due to the amount of time required. Had level design been started sooner, the game’s identity crisis may not have persisted as long since we would have discovered which proposed mechanics worked through the level design process.

In spite of difficulty with scope, we found that establishing consistent modes of communication early on helped us through many of the challenges we faced. Our team established strong internal communication from the onset, which promoted a healthy teamwork environment. Communication and teamwork continued to be strong throughout AIM<’s development cycle, eroding only slightly towards the end due to external pressure from other coursework.

Another portion of the development  that we consider successful is the realization of AIM<’s characters. By offering two unique characters, we offered players different gameplay experiences. The Mech and Drone were designed to reflect gameplay differences through their size difference, changes in mobility, varying levels of durability, and differing functionality.

As the development cycle for AIM< comes to a close, we believe that we have overcome the challenges we faced and gained valuable experience designing a complete game. We look forward to sharing AIM< with an audience of family, friends, and our fellow students.”

Thanks for reading!

Design Doc

Week Thirty-six

(or Is There A Doc In The House?)

As I promised in my last post, I spent part of this past week merging external documents into the main document to create a complete design doc. The final version of the AIM< design doc is finished and can be viewed here. A link to the document can be easily accessed from the AIM< homepage as well.

Part of the process involved highlighting all the parts of the design that did not make it into the finalized build. I’ll talk about the specific features cut in a bit more detail over the next couple of posts. Getting the final document put together was a bittersweet experience as I had a chance to review past builds, early concepts, and examine how the design document evolved over the development process.

I realized this week that I haven’t really talked much about my process in creating the design document. As I explained in my very first post, the game design document is like a game’s rule book. I completely understand if this doesn’t elicit excited squeals. The document is important, though, as it ideally functions to keep development on track and serves as a place where the teams agreed upon design is kept. Anyone can look at the doc anytime and get a sense for what each aspect of the game looks like.

“Ideally” is the key word. For the document to work as intended, the team needs to read the sections that pertain to the work they are doing. Leads should probably read the whole thing, at least when major updates are implemented.

For everyone to want to read the document, the formatting needs to be very readable. The document makes for some dry reading already (unless you’re me and like that sort of thing) and can be bogged down by poor structure or formatting. I had to make a lot of changes before I found something that started to work well for the team.

The “Mech Powers” build version of the document was where readability was really improved. I discovered that dispersing main portions of the document into their own separate documents was easier to update. Separate documents can be linked from the main document for easy access to connected areas of the game’s design. Team members had an easier time keeping up-to-date with changes since all they had to do was read the portions they needed by clicking on the links or checking the separate document.

Separating the largest portions of the game doc also allowed me to create more concise sections. I wrote very brief summaries and descriptions for each section. Any details I tried to limit to a handful of bullet points. My intent was for everyone to be able to get a general overview and quickly decide whether they needed to read the more detailed linked document.

Commenting worked far better with separate documents as well. Previously, if too many comments were made, it was a chore to read through each area due to the unwieldy size of the document. Separated, I could focus on individual sections and quickly get in touch with certain team members about specific comments and design decisions.

Some of my research into game documentation lead me to consider wikis and proprietary software. Google docs is free, though, and I think the system that I worked out is viable for future projects.

I didn’t have much time to experiment with the current document before AIM< was finalized. The change-log has not been updated since the “Mech Powers” build and some last-minute design decisions have not been documented. Violent Traversal doesn’t have any plans to re-visit AIM< in the current iteration so my time would be better spent by writing a couple retrospectives.

If you’re interested in some of the ideas Violent Traversal had in store for AIM<, please check out the doc. It contains a wealth of content I’ve not had time to write about here, including a pretty sweet narrative written by Daniel Bodunov and myself.

Have a beautiful weekend! 

Work

Week Thirty-five

(or Work, Work)

I’m still working on finalizing the documentation for the game and should have everything completed in not too long. Some personal matters needed attended to this past week that have been put off over the last month of the semester. Expect to see my retrospective blogging soon.

Until then, download AIM<, give it a spin, and have a great weekend!

Release Day

Week Thirty-four

(or Finally!)

Development on AIM< is now finished! This week I wrapped up some loose ends with and (just today actually) got the finalized version uploaded to itch.io for everyone to download. Check out the game here!

I still have a little work to do making sure the game design documentation is updated to show what was finished and what features were shelved. That work should be completed within a week or so. I may have another blog post or two to write as I get the documentation done.

Enjoy the game and have an awesome weekend!

Graphic Design & PR

Week Thirty-three

(or We are here, we are here, we are here!)

[UPDATED 6/2/17] The AIM< process book is now online! You can access it here or on the website.

[UPDATED 5/5/17] I learned an important lesson in blog writing. I had been copying the format from post to post just using copy and paste to unify all the posts. Well, I accidentally copied over this post. Blogger doesn’t have a “revert” function so the post was lost. From now on, I’ll be writing the posts in Word or Google Docs and pasting in the text so I don’t have to re-write posts. Lesson learned. I’ll try to re-write this the best I can.

Last weekend and this week have been all about making promo materials, making a website, and creating a process book.

The process book took a while to make.  I prioritize organization while I work and had been gathering materials throughout the development process. However, I still had to look through everything and decide how to best present the body of work. I also wrote several paragraphs to accompany the artifacts of development, except for the coding section. Marcus Tolbert wrote several paragraphs explaining the features and challenges from a coding perspective.

Once I gathered everything, I assembled the document in InDesign using a template from a 3D Game Art and Engines class I was taking this semester. I’ve not figured out how to embed PDFs online in a satisfactory manner, but once I do, the book will be available on the AIM< website.

Speaking of the website, once I had completed the process book, I was able to focus on building a web presence for our game. The process was a bit easier than the book as I could use all the files already gathered together to construct the site. Look at the site here!

Last, I created the PR materials: a poster, business card, table card, and a sell sheet. The poster design I made for SGX.16 was successful so I updated it with the new mech model for SGX.17. I used elements from the poster and some screenshots to create the rest of the PR materials.

SGX.17 is only 6 days away! Violent Traversal will be there debuting AIM<. Hope to see you there! Have a beautiful spring weekend!

AIM< Orthos by Aram Wahler. Featuring work by Violent Traversal.

Poster by Aram Wahler

Sell Sheet by Aram Wahler

Business Card by Aram Wahler

Table Card by Aram Wahler

SGX.17

I'm breaking my typical weekly blog posting routine as a reminder that AIM< debuts this week at SGX.17!

Check out the gameplay trailer and new website!

Audible II

Week Thirty-two

(or Biff! Bang! Pow!)

Before I get to the audio I've been making, I'll talk a little about the music w're using in AIM<. AIM< isn't being made for profit so our studio is going to be using Creative Commons tracks. Unique music would be ideal but I've not had the time to compose any during development.

The menu track is "Prologue" by Alex Mason from an album called "Return" and is licensed under creative commons (CC BY-NC 4.0). Give it a listen!



"Prologue" fits AIM< well and plays after the game starts while players navigate menus. There is also an awesome in-engine scene that plays out in the background in time to the music.

Game play music is "A Moment" by Scott Gratton and is also licensed under creative commons (CC BY-NC 4.0). Here it is!



At first, I had picked something a bit more percussive and slightly more high energy, a track called "Overflow of Time" by Artofescapism (also CC. BY-NC 4.0) But as awesome as the track was, the music overwhelmed the gameplay audio and just didn't sit right as we play-tested with it. Here's the track for comparison.



"A Moment" works far better with the game play in AIM< establishing some good ambiance without overpowering the other audio.

Besides researching music, I made more sounds. The first set I'll share is audio created to give feedback with player/environment interaction and a walk sounds for the mech. Click the play button to hear them!



 When I started this particular set of sounds, I thought the impact audio would be the easiest but quickly found I was mistaken. The difficulty in creating believable, satisfying impact comes back to what I mentioned last week about reality vs fantasy. I found that what I expected to sound like impact was quite flat and lacked character. I discovered that layering the "swoosh" and impact of bamboo pole impact with other foley audio created the sounds I was looking for.

I made only one impact sound per material for now since to create more to cycle through and vary the sound takes time and I had more audio to make before creating alternates.

The mech walk loop features some interesting foley, layering drills, miniature servos, drums, and other sounds to convey weight and large, mechanized movement. it took a few passes to make something I was happy with and felt would be convincing.

The last set of audio I made for the game elaborated on the player/environment interaction, a couple ambient loops, enemy shooting, and near miss feedback. Give it a listen!



Creating looping audio that doesn't sound too repetitious was challenging. I mixed up small audio segments, randomly dispersing them so the loop would be less noticeable for both tracks. Avoiding any sounds that are too rhythmic helps trick the ear into missing the repetition, a lot like working with textures. The less patterns, the less obvious the looping will be.

For the enemy laser sound, I drew inspiration from unusual weapons fire sounds like the WWII German nebelwerfer artillery. The enemy fire had to be distinct and evoke a similar fear response in the player as my sources of inspiration. I also needed the audio to stand out over player weapon fire but not get too annoying when multiple enemies fired simultaneously.

The other tracks were created in a similar manner as other tracks I talked about here and last week.

I hope you enjoyed using some different senses to interact with the past couple blogs. Future posts will most likely return to visuals.

Next week on May 4th is the premier of AIM<! Click on the link for event details and come check out the game if you're in the area.

Have a great weekend and I hope to see you next week!

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.