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!