Welcome to the general overview of my time on A.V. from start up to now. Here I will cover the production/development of A.V. from its conception in school up to our current state. Some areas will lack specific detail for now, but I will dive into the details in further posts. My personal blog and hopefully at some point, Doug’s blog also, will also cover the blanks from the commercial era. To start off here are the links to the “living” game design document from our design phase and also the development blog, which started losing steam as we shifted from the academic to commercial development phase.
· Old Development Blog - http://devblog.avthegame.com/
· Game Design Document/Wiki - http://avgame.wikidot.com/
· A.V. Main Site – http://avthegame.com
A.V. had humble roots as a student project. It was the brain child of Doug and my interests. Our main intention was to experiment with concepts that we were interested in while producing an experience worthy of finishing our degrees. At the start there were only two of us graduate students focused on the project as others had teamed up to go a different route with a custom mobile engine. We had no idea what resources would be available at the time. This will come into play later when we start to scope and structure the project.
The university gave us slightly more than a week to brainstorm ideas to present in class. That time sure was needed as it seemed we had very little overlapping game passions. Doug had interest in making a puzzle game and wanted to avoid the shooter prospective. He was also interested in adventure and RPG elements as well. I always had interest in a combat heavy game and really wanted to push the limits on audio. Fortunately we found some common ground with the desire to have an open world space and some quick paced action. I came up with the "Sound to Light" (STL - not to be confused with the C++ library!) concept a few days in, but set it aside as we explored other avenues. There was a brief period where we thought that there was not enough common ground between us to continue. Of course this was extremely concerning not only to ourselves but to faculty. We technically were allowed to split again but the university urged us not too. Doug and I knew that a further split would be like shooting ourselves in the foot. We would lack the personnel and talent needed to create something of professional caliber. On top of this we risked falling flat on our faces and not even completing our degrees.
Fortunately we were not to headstrong to waste the opportunity presented to us. We spent another day just throwing ideas at the board so to speak, without committing to anything specific. We made a list of plausible mechanics venture on to along with a few potential match ups. We slept on the ideas overnight so we could weigh in on things in a cool and collected mindset the next day.
Doug and I realized the multitude of compelling gameplay we could implement in this open-world, audio design, puzzles, stealth, combat… well you get the idea. We had of potential and were trying to keep the obvious scoping issues on the back burner. Doug continued to flesh out the game mechanics as well as drawing up a world map of sorts. Even though we were heavily leaning towards using Unity, I also researched other potential options for prototyping and full development. Right around this time we found out that we would be able to use a multi-disciplined team of student contributors to help crank through some of the work. Knowing that our lives were about to get even more chaotic with the search and management of these contributors, we outlined our own roles in the project to help define the project structure.
Officially I am credited with being the Executive Producer, Technical Director/Scripting Lead, Audio Director, Zone 1 Music Assets & Various Sound FX, Community Manager, and Design Assistant. Doug was credited with Creative Director, Lead Designer/Level Designer, 3D Modeler & Animator, Writing & Narrative Design, 2D Art & Animation, Video Editing, Voice Acting, General Scripter, and Audio Assistant. As one can tell, there are several areas that we both dabbled in heavily, but we still had clearly defined leads. Some areas, like audio and art assets, had extensive help from contributors, while others, like design and programming, were more closed off to us. Doug and I wanted to try to keep direct control of the project evenly split among the two of us while also being flexible to outside feedback as needed. We wanted to keep communication between the two of us as open as possible in order to make most decisions as a pair. Anything that wasn’t declared in the document and was deemed critical to the game should be decided as a pair. Lesser decisions could be left up to the ‘lead’ of that particular area. (e.g. Doug could make an executive decision about the color of a particular light, where as I could make a judgement call an audio.) Going down the chain of command here, we also wanted to extend the same sense of creative freedom to our contributors in an effort to tap the maximum potential. We would dump the technical requirements on contributors while being somewhat vague on the creative details. If there was confusion then we would add constraints as needed to help guide. Mostly we were interested in other takes for the art style and audio.
To finalize the managing structure we realize that we needed a way to break potential ties on team decisions. While we could go to the department with any potential concerns, we knew that someone on the team should really have the final word if needed. I was already taking on the Executive Producer role so I “stepped up and took the Iron Throne”, so to speak. I was already familiar with production and the RIT ways along too, so taking the lead felt natural.
· Old Development Blog - http://devblog.avthegame.com/
· Game Design Document/Wiki - http://avgame.wikidot.com/
· A.V. Main Site – http://avthegame.com
A.V. had humble roots as a student project. It was the brain child of Doug and my interests. Our main intention was to experiment with concepts that we were interested in while producing an experience worthy of finishing our degrees. At the start there were only two of us graduate students focused on the project as others had teamed up to go a different route with a custom mobile engine. We had no idea what resources would be available at the time. This will come into play later when we start to scope and structure the project.
The university gave us slightly more than a week to brainstorm ideas to present in class. That time sure was needed as it seemed we had very little overlapping game passions. Doug had interest in making a puzzle game and wanted to avoid the shooter prospective. He was also interested in adventure and RPG elements as well. I always had interest in a combat heavy game and really wanted to push the limits on audio. Fortunately we found some common ground with the desire to have an open world space and some quick paced action. I came up with the "Sound to Light" (STL - not to be confused with the C++ library!) concept a few days in, but set it aside as we explored other avenues. There was a brief period where we thought that there was not enough common ground between us to continue. Of course this was extremely concerning not only to ourselves but to faculty. We technically were allowed to split again but the university urged us not too. Doug and I knew that a further split would be like shooting ourselves in the foot. We would lack the personnel and talent needed to create something of professional caliber. On top of this we risked falling flat on our faces and not even completing our degrees.
Fortunately we were not to headstrong to waste the opportunity presented to us. We spent another day just throwing ideas at the board so to speak, without committing to anything specific. We made a list of plausible mechanics venture on to along with a few potential match ups. We slept on the ideas overnight so we could weigh in on things in a cool and collected mindset the next day.
Doug and I realized the multitude of compelling gameplay we could implement in this open-world, audio design, puzzles, stealth, combat… well you get the idea. We had of potential and were trying to keep the obvious scoping issues on the back burner. Doug continued to flesh out the game mechanics as well as drawing up a world map of sorts. Even though we were heavily leaning towards using Unity, I also researched other potential options for prototyping and full development. Right around this time we found out that we would be able to use a multi-disciplined team of student contributors to help crank through some of the work. Knowing that our lives were about to get even more chaotic with the search and management of these contributors, we outlined our own roles in the project to help define the project structure.
Officially I am credited with being the Executive Producer, Technical Director/Scripting Lead, Audio Director, Zone 1 Music Assets & Various Sound FX, Community Manager, and Design Assistant. Doug was credited with Creative Director, Lead Designer/Level Designer, 3D Modeler & Animator, Writing & Narrative Design, 2D Art & Animation, Video Editing, Voice Acting, General Scripter, and Audio Assistant. As one can tell, there are several areas that we both dabbled in heavily, but we still had clearly defined leads. Some areas, like audio and art assets, had extensive help from contributors, while others, like design and programming, were more closed off to us. Doug and I wanted to try to keep direct control of the project evenly split among the two of us while also being flexible to outside feedback as needed. We wanted to keep communication between the two of us as open as possible in order to make most decisions as a pair. Anything that wasn’t declared in the document and was deemed critical to the game should be decided as a pair. Lesser decisions could be left up to the ‘lead’ of that particular area. (e.g. Doug could make an executive decision about the color of a particular light, where as I could make a judgement call an audio.) Going down the chain of command here, we also wanted to extend the same sense of creative freedom to our contributors in an effort to tap the maximum potential. We would dump the technical requirements on contributors while being somewhat vague on the creative details. If there was confusion then we would add constraints as needed to help guide. Mostly we were interested in other takes for the art style and audio.
To finalize the managing structure we realize that we needed a way to break potential ties on team decisions. While we could go to the department with any potential concerns, we knew that someone on the team should really have the final word if needed. I was already taking on the Executive Producer role so I “stepped up and took the Iron Throne”, so to speak. I was already familiar with production and the RIT ways along too, so taking the lead felt natural.
Clearly I didn’t just turn into Joffrey and run everything into the ground. I did want the chance to lead from start to finish for once and was extremely excited about the opportunity, but extremely cautious as well. I knew that Doug and I had a shaky start to begin with, and I had no desire to start overruling his thoughts. I needed his talent and vision too in order to succeed. Fortunately I never had to use my “master veto” on anything. Every decision that we shared different opinions on was thoroughly dissected and in the end we would come to terms before hitting the cut off time when something had to be decided. There were very few cases where we even disagreed greatly. Most of the indecisiveness came when thinking up the details of how to implement a decision. The one great debate that comes to mind between Doug and I were the use of the monologues for player direction. It is important to note that this topic got dealt with further down the line when we had switched over from prototyping and had most monologue assets made. We knew the voice overs were extremely long and most people tend to skip these things. I wanted to push the audio theme and felt that the monologues help advance the audio design. Clearly we also had a lot of work with the assets done and didn’t want to abandon that work. We debated fiercely about the proper path and went over different alternatives. One solution was to use symbols that had musical STL’s to try and prompt the player. I did like it, but this doesn’t add much for the narrative where the monologues gave A.V. himself a bit of character. This discussion went on for about a day when I insisted that the alternatives were too much cost for too little game reward. We came to an agreement as the tensions were starting to mount. The monologues were a key element of the game, and for better or for worse, were to remain the main way of communicating details back to the player. We agreed to shorten the monologues down to the absolute key points and give more detail about instruments and puzzle elements as text in a menu. This menu was in the original design as it was, but now we fleshed it with more detail… aka walls of text ahoy. Not the best end case, but one that worked and was feasible. I still go the audio props and Doug was able to convey his designer’s message still.
Prototyping Phase
Stepping back into the proper flow of the timeline now, it is late October 2013. Doug and I are having trouble communicating the glory of A.V. to RIT. Of course as the creators of this game idea we had a very good grasp on what A.V. was, although we will find out later that even our own imaginations had different things in mind. We gave formal presentations around this time so that the faculty could check how things were going. The faculty liked the “Sound To Light” concepts but had concerns about the actual puzzle gameplay, difficulty/annoyance of the darkness, and the immense scope of the game.
We were going to prototype the game anyway, but the faculty confusion only upped the timeline. No matter, we took the prototype a week class for a reason, right? We had already decided on using the Unity engine for the prototyping and the final game. This naturally led to evolutionary prototyping structure and as a follow up we followed a very Agile like style of development. Many of the core systems made in the prototype would be recycled into the main game. This helped speed up production significantly, but also opened up the road to some nasty code bugs later on. This method also assured that we got locked into the monologues as discussed before, since the system was so entrenched in the design and code already. Doug had recently cooked up some EXTREMELY detailed maps of possible puzzles which may have added to the facility confusion, and my sanity, but it was still a great place to get ideas for the prototype.
As we were scouring over the maps we came to the decision that was also urged onto us by RIT. Drop the combat aspect. The ability to destroy everything in your path along with having good puzzle and stealth aspect was not feasible. The amount of work would prevent us from getting to far. The quality of the game would also suffer since we couldn’t focus on one or the other. It pained me quite a bit to ditch this aspect, but I knew it was for the best. We took a one third slice of what will become known as “Zone 1” (aka level one or act one) of the game and began to model that for the prototype.
We demonstrated the first prototype to the faculty, who started seeing the full picture of the game now. We quickly made a second iteration with improved HUD elements, ping time changes, and other minor factors. The second iteration was the one that we wanted to get some student feedback on, so after much drama with the faculty about play testing, we arranged a ‘free demo’ to fellow game development friends in the labs. This test confirmed that even veteran gamers had a hard struggle with navigating the map and moving while in complete darkness. We wanted to avoid re-teaching the generic first person movement controls as much as possible as our target audience would be people that were already familiar with this movement. While the first person movement thing was concerning, the fact the people were mostly walking into walls was the pressing issue. Thankfully those who did play liked the sensory overload and understood the general idea we were shooting for. The concept of the game was confirmed enjoyable and we got wonderful feedback… success!
We were going to prototype the game anyway, but the faculty confusion only upped the timeline. No matter, we took the prototype a week class for a reason, right? We had already decided on using the Unity engine for the prototyping and the final game. This naturally led to evolutionary prototyping structure and as a follow up we followed a very Agile like style of development. Many of the core systems made in the prototype would be recycled into the main game. This helped speed up production significantly, but also opened up the road to some nasty code bugs later on. This method also assured that we got locked into the monologues as discussed before, since the system was so entrenched in the design and code already. Doug had recently cooked up some EXTREMELY detailed maps of possible puzzles which may have added to the facility confusion, and my sanity, but it was still a great place to get ideas for the prototype.
As we were scouring over the maps we came to the decision that was also urged onto us by RIT. Drop the combat aspect. The ability to destroy everything in your path along with having good puzzle and stealth aspect was not feasible. The amount of work would prevent us from getting to far. The quality of the game would also suffer since we couldn’t focus on one or the other. It pained me quite a bit to ditch this aspect, but I knew it was for the best. We took a one third slice of what will become known as “Zone 1” (aka level one or act one) of the game and began to model that for the prototype.
We demonstrated the first prototype to the faculty, who started seeing the full picture of the game now. We quickly made a second iteration with improved HUD elements, ping time changes, and other minor factors. The second iteration was the one that we wanted to get some student feedback on, so after much drama with the faculty about play testing, we arranged a ‘free demo’ to fellow game development friends in the labs. This test confirmed that even veteran gamers had a hard struggle with navigating the map and moving while in complete darkness. We wanted to avoid re-teaching the generic first person movement controls as much as possible as our target audience would be people that were already familiar with this movement. While the first person movement thing was concerning, the fact the people were mostly walking into walls was the pressing issue. Thankfully those who did play liked the sensory overload and understood the general idea we were shooting for. The concept of the game was confirmed enjoyable and we got wonderful feedback… success!
After the initial playtest we took the UI in a different direction based on Doug’s lead. This image is from near A.V.'s release. Colored Blotches (upper piece) showed if you were just running up against something. In this case the player is running into geometry in the back right. The lower bar was an inverted vertical indicator. In this case the player is looking up a bit. The upper left piece is one of the four corners of the “Frame HUD”. This moved around in an inverted as the player moved to show that the player character was truly moving. This sort of UI sway is becoming more common in shooter games with similar interfaces. (e.g. Borderlands 2 & Pre-Sequel)
Even with Doug and I reducing the scope of A.V. over time, we knew there was still too much work to be done, even if we just strived for a bare minimal progress to graduate. We wanted a lot more out of this than that as it was, so we inquired more about getting help. Clearly we weren’t able to pay hourly, but we didn’t want anyone to feel like we used them. We used the school and personal connections along with some social media to get the word out that we were looking for help. Terms were negotiable per contributor, but many were fine doing it for just class credit or even volunteer work. The future was still very unsure for A.V. so for people coming on early I worked out contracts that stated they were volunteering their time and work for acknowledgement, and where it applied, class or co-op credit. We had the right to boot them off the project if we deemed the work was poor or the schedule could not be kept. If the game went commercial then we would work out additional terms when that time came. Of course those commercial contracts became a real thing, but I will touch on that more soon.
Production was starting to go fairly smoothly as the new year came. Officially the “Capstone Design” class was over and “Capstone Development” was starting. The design document (wiki) was finalized and we were almost 4 iterations in on the prototype. During the “winter break” we cleaned up the code base and assets so we could shift from prototyping to full development. We were gunning for the Alpha stage at the time. If you are unfamiliar, this is the “version featuring the preliminary layout of the full game structure from beginning to end. Levels are boxed or filled with placeholder art. Core mechanics are in place, along with any features necessary for completion of the game.” Doug said this in an old development blog post over a year ago when the Kickstarter was going. Our production process, as you may have guessed, were not quite as optimal with all the school requirements, uncertainty about commercial development, and our own personal lives seeping into the mix. Reading over Doug’s brief post about this process is extremely insightful as I will not be getting into detail in this post and his thoughts cover it well. I will add my own two cents in my production focused post.
As the official development phase opened up we had 7 contributors. I will detail our interview process in another post. Each had a greatly varying workload which was agreed to beforehand. Amanda quickly became the right-hand woman, leading the charge on the big bulk of 2D art assets we required in game and out. (Business cards and game posters are critical!) She was also a great go to for thoughts on design and other issues that arose. Brockton made the initial charge on the AI. Jake became my assistant scripter and helped complete things that Doug and I could not get too. Nik was the principle 3D modeler and texture guy. Although Doug did do a part of modeling himself, including the level geometries, Nik provided a lot of additional takes on many models. Hunter was another modeler and close friend of Nik’s that helped him along the way. Keith was my friend who had his music theory and composition down. Keith helped refine my synth sounds into actual melodies. Matt was another audio guy that Doug knew. Since Matt was out of town he didn’t have a lot of direct influence on the project but still provided valuable input. Each of the members had a similar agreement as mentioned above that their assets were made voluntarily for educational/non-profit use.
With the added team members production continued cranking along. We still had major UI and navigation issues to tackle, but things were getting better as we continued testing and developing. We were warned that we would have to public show off the game rather soon by RIT. We had decided to show off Zone 1 in its entirety. Zone 1 and Zone 3 were our goals for completing the academic portion of A.V. and seeing as how we started with Zone 1, it was the most complete feeling. At this point we were still missing a critical feature though, check pointing. When the player died the game started fresh from the beginning. The check pointing system was on the schedule, but was planned further down the road since we had been dealing in short play tests where progress really didn’t matter. The sudden public reveal pushed it to the front. I teamed up with our programming contributor Jake to work on a solution. Originally I wanted to cook something up totally in house. Unfortunately, there was not enough time to do the appropriate background research on serialization in Unity and then implement it. We ended up picking an Unity Asset Store plugin by whydoidoit. The initial setup was quite quick and worked well enough. We missed a few minor things like enemies or receptors not always resetting on a reload, but overall the system worked and could be refined. Down the road we will realize we misunderstood the setup along with finding some bugs that prevented proper IDs from being generated. For now though, we had a system to reload the scene, the nightmares could be dealt with soon.
Production was starting to go fairly smoothly as the new year came. Officially the “Capstone Design” class was over and “Capstone Development” was starting. The design document (wiki) was finalized and we were almost 4 iterations in on the prototype. During the “winter break” we cleaned up the code base and assets so we could shift from prototyping to full development. We were gunning for the Alpha stage at the time. If you are unfamiliar, this is the “version featuring the preliminary layout of the full game structure from beginning to end. Levels are boxed or filled with placeholder art. Core mechanics are in place, along with any features necessary for completion of the game.” Doug said this in an old development blog post over a year ago when the Kickstarter was going. Our production process, as you may have guessed, were not quite as optimal with all the school requirements, uncertainty about commercial development, and our own personal lives seeping into the mix. Reading over Doug’s brief post about this process is extremely insightful as I will not be getting into detail in this post and his thoughts cover it well. I will add my own two cents in my production focused post.
As the official development phase opened up we had 7 contributors. I will detail our interview process in another post. Each had a greatly varying workload which was agreed to beforehand. Amanda quickly became the right-hand woman, leading the charge on the big bulk of 2D art assets we required in game and out. (Business cards and game posters are critical!) She was also a great go to for thoughts on design and other issues that arose. Brockton made the initial charge on the AI. Jake became my assistant scripter and helped complete things that Doug and I could not get too. Nik was the principle 3D modeler and texture guy. Although Doug did do a part of modeling himself, including the level geometries, Nik provided a lot of additional takes on many models. Hunter was another modeler and close friend of Nik’s that helped him along the way. Keith was my friend who had his music theory and composition down. Keith helped refine my synth sounds into actual melodies. Matt was another audio guy that Doug knew. Since Matt was out of town he didn’t have a lot of direct influence on the project but still provided valuable input. Each of the members had a similar agreement as mentioned above that their assets were made voluntarily for educational/non-profit use.
With the added team members production continued cranking along. We still had major UI and navigation issues to tackle, but things were getting better as we continued testing and developing. We were warned that we would have to public show off the game rather soon by RIT. We had decided to show off Zone 1 in its entirety. Zone 1 and Zone 3 were our goals for completing the academic portion of A.V. and seeing as how we started with Zone 1, it was the most complete feeling. At this point we were still missing a critical feature though, check pointing. When the player died the game started fresh from the beginning. The check pointing system was on the schedule, but was planned further down the road since we had been dealing in short play tests where progress really didn’t matter. The sudden public reveal pushed it to the front. I teamed up with our programming contributor Jake to work on a solution. Originally I wanted to cook something up totally in house. Unfortunately, there was not enough time to do the appropriate background research on serialization in Unity and then implement it. We ended up picking an Unity Asset Store plugin by whydoidoit. The initial setup was quite quick and worked well enough. We missed a few minor things like enemies or receptors not always resetting on a reload, but overall the system worked and could be refined. Down the road we will realize we misunderstood the setup along with finding some bugs that prevented proper IDs from being generated. For now though, we had a system to reload the scene, the nightmares could be dealt with soon.
GDC is Coming
As it turns out, the big public display was actually the GDC 2014 Conference! We had a quick play test before leaving, mostly for technical and bug fixing reasons and less about design feedback this time around. Nothing too eventful happened during this playtest fortunately. The good thing to note is that our new slick ‘E’ key animation was actually getting people to ping more! Yes, it is hard coded to be an ‘E’ still, even if you change the key or use the controller. We are terrible people, I know. Customizing that is still in our books, but honestly I am not sure if it will ever really happen.
The sprite sheet to prompt the player to ping at the start. This post is brought to you by the letter ‘E’. As in - Email Doug and ask him how he enjoyed the dozen different animation changes to this. This version with a glow around the frame and details to make it look like a keyboard key, finally drew the needed attention.
Now, off to San Francisco! GDC was an amazing experience all the way around. We got to really dig out teeth into the industry and got to show of A.V. to industry experts. We saw a lot more of the same experiences out there. People have a hard time adjusting to the instruments while navigating. People getting confused early on because they missed a piece of information. Etc. We took a lot of advice while we were out there, but most of the information we knew. We also found a technical issues, like the check pointing issues mentioned before, but nothing game breaking. Overall GDC was not as helpful to the game as we were hoping. Most people are shocked when we say this. There are a few reasons why it wasn’t the grand intervention we hoped for.
1. Environment – A.V. is a game that you really need immersed in. The fluorescent lights and loud background noise prevent this. Some people refused to wear the headphones which puts a nail in the coffin.
2. Time of Play – The previous play test sessions were rather short, roughly 10-20 minutes. People touring the booths at GDC are not that patient. Most just played a couple minutes ask us about the basics, said “looks cool” and then left. The true feedback was from the few that stuck around.
3. GDC is focused on professionals, not players – While having developer feedback is wonderful, we had this sort of feedback from local testing with student developers. Having feedback from a player focused perspective would have been helpful.
With GDC done we were also encouraged to attend RPI Game Fest at the end of April 2014. I was against this at first since there was so much work to be done to be sure Zones 1 and 3 were ready. We were also having communication problems with our modelers at this time. Some assets were a bit too farfetched so we had to assign better creative restrictions. Others had WAY too many vertices as Nik was unfamiliar with modeling in the gaming realm. Some assets were just missing, or inferior as the team dealt with tough schedules inside and outside of the project. We worked with Nik and Hunter to determine what we could do to help, including more guidelines or direct involvement. Eventually Hunter was phased out of the project so that he could focus on his school work more. Nik and Doug worked closely together to convert problem assets into low poly, game engine and A.V. art style friendly models. We really needed a good demo of the new Zone 3 before capstone finished up, so under pressure of RIT and Doug, I said alright, let’s head to RPI.
Turns out the RPI competition was a breath of fresh air we needed. Along with winning the Excellence in Sensory Experience award this was a chance to get the game in front of real players. We got a lot of happy players saying how much they liked the game, which tickled out egos a bit. Doug took in a wealth of design feedback from the event but most of all we realized that we missed a target audience… The kids, roughly in the tween age group, showed a much better understanding of the world and mechanics than most adults we had seen. Fortunately we kept the game themes and language rather PG so having kids play was really not a stretch! We affirmed this kid trend with our display at ImagineRIT about a month later. We had two kids get through the entire demo we set up! Clearly it was too late to try to re-purpose the entire game to be kid themed, but it was something we kept in mind as we progressed. ImagineRIT was the end of the academic road though, and we set focus on finishing up the 200 page final write up for the university. After all the main goal was that piece of paper people call a degree.
1. Environment – A.V. is a game that you really need immersed in. The fluorescent lights and loud background noise prevent this. Some people refused to wear the headphones which puts a nail in the coffin.
2. Time of Play – The previous play test sessions were rather short, roughly 10-20 minutes. People touring the booths at GDC are not that patient. Most just played a couple minutes ask us about the basics, said “looks cool” and then left. The true feedback was from the few that stuck around.
3. GDC is focused on professionals, not players – While having developer feedback is wonderful, we had this sort of feedback from local testing with student developers. Having feedback from a player focused perspective would have been helpful.
With GDC done we were also encouraged to attend RPI Game Fest at the end of April 2014. I was against this at first since there was so much work to be done to be sure Zones 1 and 3 were ready. We were also having communication problems with our modelers at this time. Some assets were a bit too farfetched so we had to assign better creative restrictions. Others had WAY too many vertices as Nik was unfamiliar with modeling in the gaming realm. Some assets were just missing, or inferior as the team dealt with tough schedules inside and outside of the project. We worked with Nik and Hunter to determine what we could do to help, including more guidelines or direct involvement. Eventually Hunter was phased out of the project so that he could focus on his school work more. Nik and Doug worked closely together to convert problem assets into low poly, game engine and A.V. art style friendly models. We really needed a good demo of the new Zone 3 before capstone finished up, so under pressure of RIT and Doug, I said alright, let’s head to RPI.
Turns out the RPI competition was a breath of fresh air we needed. Along with winning the Excellence in Sensory Experience award this was a chance to get the game in front of real players. We got a lot of happy players saying how much they liked the game, which tickled out egos a bit. Doug took in a wealth of design feedback from the event but most of all we realized that we missed a target audience… The kids, roughly in the tween age group, showed a much better understanding of the world and mechanics than most adults we had seen. Fortunately we kept the game themes and language rather PG so having kids play was really not a stretch! We affirmed this kid trend with our display at ImagineRIT about a month later. We had two kids get through the entire demo we set up! Clearly it was too late to try to re-purpose the entire game to be kid themed, but it was something we kept in mind as we progressed. ImagineRIT was the end of the academic road though, and we set focus on finishing up the 200 page final write up for the university. After all the main goal was that piece of paper people call a degree.
Into the Industry and out of Academia- A MAGIC-al Experience
Our upcoming publisher, MAGIC Spell Studios, is led by Andy Phelps and Chris Egert. They were the old IGM heads, so I knew them for quite a while and we had kept open communication about A.V. since GDC. Chris was also on our capstone board, so he was very familiar with the project and our principle contact inside MAGIC. The first time Andy sat and played the game was terrifying. Like most our first time players at that time, he had very little idea what to do. Fortunately we took their advice and that of many previous play-testers to advance the UI leaps and bounds. MAGIC was still new and setting up shop, so they couldn’t give us their full support quite yet. Fortunately they gave us a much needed home with computers, white boards, power, software licenses, etc. to continue working on the game. They also gave us many more support channels to help spread the word and get new talent. There was no financial backing at this point though, but we made it work.
We took a week off after graduation to gather ourselves, then hit the ground running. I had already prepped a general schedule but it needed fleshed out. I will detail my scheduling methods in a future post here. We also needed a new AI programmer as Brockton had other commitments. Along with this we wanted to bring on some true QA people to be testing the game as often as possible. We drew up new agreements with all the contributors. Those with minor role we worked out a credits only agreement. As for the others we had several different forms of compensation along with the credits. Most fell along the lines of we will pay X% up to $Y then a Z% for a year after of royalties. The thinking behind this was, that if A.V. was a hit, we would have enough money to start a studio while still paying a fair amount for the current game. Furthermore we could bring back the team for more A.V. content and another game. Even if A.V. didn’t take off, which it didn’t, people should still get a good piece of the pie. Eventually we were even able to offer some people hourly rates and lump sum payments in addition.
We brought on Tucker as the new AI programmer in June 2014. With him dedicated to the AI we reworked the current system and brought things up to snuff. He wasn’t a miracle worker though and AI was the hardest system in A.V. to get right. In fact it is what Doug and I are busy working on as we release our final set of patches. Even still Tucker brought the AI out of the prototyping phase and added the crucial flocking, choke point handling, and other behaviors that made the enemies what they are. We shelved the two final enemies, SCRAPS and ANGELINA, as they were out of scope. We certainly tried, but with the release date approaching we knew it had to wait. More on that in a programming post though.
We wanted more QA people, additional audio help, and money for other miscellaneous expenses. (The team loves surprise lunch ya’ know. Also Doug and I need to live somehow.) We decided it was time to give this Kickstarter thing a shot. Now I could write a whole post about the Kickstarter campaign itself. I just might even do that. We also launched on Steam Greenlight at this time to help build hype. Here are some basic take away points
1. Do some pre-marketing. This is the biggest area that we were lacking. We should have spread the word, built community support, and got more Youtube reviewers on board BEFORE starting the Kickstarter. This ensures that your campaign reaches enough people to hit it’s goal. Face it, even if you have a 100% donation rate, it still will take thousands of page views to hit a goal.
2. This campaign will be your full time job. Even with the help of MAGIC on the side it took all our resources to make videos, pictures, and text content needed for the campaign. On top of this we constantly had to field questions and do ‘cold call’ selling techniques to draw in the press.
3. This one is probably obvious but, having a prototype of whatever you are making is a must. In this case a functional demo of the game was the seller. People need to see you have some credibility to do what you say, especially if you have no reputation backing you up to start with.
4. Think well and hard on those reward tiers. Chris warned me that I made a math error in shipping costs and we almost ended up having a reward tier that we would PAY people to take. Triple check the figures and try to account for problems! (e.g. 3D printing figures may not turn out very well quality wise. Once again, I could make a whole post on these issues…) Make sure you are making enough extra to make it worthwhile. Remember, Kickstarter is trying to help you get your project funded, not just sell the trinkets associated!
The Kickstarter succeeded! Steam Greenlight passed! We meet Anna Sweet, who worked at Valve then! Huzzah! Now we brought on dedicated QA. Hannah, who single handedly broke the game in unimaginable ways for months, and then later on, Andrew and LakshmiNarayanan had a short stint of QA work. The bugs found caused production to slow significantly as we dealt with them and AI obstacles. We also brought on Elena to help fill the audio shoes that Keith and Matt's departure left. She helped make Zone 3 to sound so perfect. We worked out an agreement with MAGIC to continue our sponsorship, this time with some funds involved, from October 2014 to January, and after some Doug resistance, out to February 2015. Then we eventually did launch in February. We really did need the time, even as recent as January we came across major bugs. For example, we were overwhelming the Unity FMOD implementation. Instead of warning us we were running out of sound channels, it cut ones based on the priority setting without any notification. We worked out our own channel management to help out, but it was far from perfect. Unity has no way of accessing the channels under the hood, and there was no time to try and make a plugin. Other small details like lighting and sound nitpicking plagued us. If I had the time, money, and sanity left; I would scrap what we had in Unity and start over. Those bugs from being a prototype were really haunting us, but we had a game to ship.
Well, we made it. Even took A.V. to another GDC. The game has mixed, but many positive, reviews and it is certainly far from perfect, but we did it and we learned a ton. The concept was simply amazing and like most people, I wish we could have continued expanding upon it. Doug and I are working here and there on some of the more important issues and plan on End of Life-ing A.V. at the end of this year. Commercially the game was a failure, but that wasn’t the point. We succeeded in leading a team from start to finish on a journey of game development that ended in the Steam store. This gives us a great experience base for the future. Thank you to all that had a role… our development team, RIT, MAGIC, IGM, the capstone board, family, and of course those fans that went out and bought the game. Alrighty, I’m getting too wordy and worked up. Time to continue the job search. Until next time my minions!
We took a week off after graduation to gather ourselves, then hit the ground running. I had already prepped a general schedule but it needed fleshed out. I will detail my scheduling methods in a future post here. We also needed a new AI programmer as Brockton had other commitments. Along with this we wanted to bring on some true QA people to be testing the game as often as possible. We drew up new agreements with all the contributors. Those with minor role we worked out a credits only agreement. As for the others we had several different forms of compensation along with the credits. Most fell along the lines of we will pay X% up to $Y then a Z% for a year after of royalties. The thinking behind this was, that if A.V. was a hit, we would have enough money to start a studio while still paying a fair amount for the current game. Furthermore we could bring back the team for more A.V. content and another game. Even if A.V. didn’t take off, which it didn’t, people should still get a good piece of the pie. Eventually we were even able to offer some people hourly rates and lump sum payments in addition.
We brought on Tucker as the new AI programmer in June 2014. With him dedicated to the AI we reworked the current system and brought things up to snuff. He wasn’t a miracle worker though and AI was the hardest system in A.V. to get right. In fact it is what Doug and I are busy working on as we release our final set of patches. Even still Tucker brought the AI out of the prototyping phase and added the crucial flocking, choke point handling, and other behaviors that made the enemies what they are. We shelved the two final enemies, SCRAPS and ANGELINA, as they were out of scope. We certainly tried, but with the release date approaching we knew it had to wait. More on that in a programming post though.
We wanted more QA people, additional audio help, and money for other miscellaneous expenses. (The team loves surprise lunch ya’ know. Also Doug and I need to live somehow.) We decided it was time to give this Kickstarter thing a shot. Now I could write a whole post about the Kickstarter campaign itself. I just might even do that. We also launched on Steam Greenlight at this time to help build hype. Here are some basic take away points
1. Do some pre-marketing. This is the biggest area that we were lacking. We should have spread the word, built community support, and got more Youtube reviewers on board BEFORE starting the Kickstarter. This ensures that your campaign reaches enough people to hit it’s goal. Face it, even if you have a 100% donation rate, it still will take thousands of page views to hit a goal.
2. This campaign will be your full time job. Even with the help of MAGIC on the side it took all our resources to make videos, pictures, and text content needed for the campaign. On top of this we constantly had to field questions and do ‘cold call’ selling techniques to draw in the press.
3. This one is probably obvious but, having a prototype of whatever you are making is a must. In this case a functional demo of the game was the seller. People need to see you have some credibility to do what you say, especially if you have no reputation backing you up to start with.
4. Think well and hard on those reward tiers. Chris warned me that I made a math error in shipping costs and we almost ended up having a reward tier that we would PAY people to take. Triple check the figures and try to account for problems! (e.g. 3D printing figures may not turn out very well quality wise. Once again, I could make a whole post on these issues…) Make sure you are making enough extra to make it worthwhile. Remember, Kickstarter is trying to help you get your project funded, not just sell the trinkets associated!
The Kickstarter succeeded! Steam Greenlight passed! We meet Anna Sweet, who worked at Valve then! Huzzah! Now we brought on dedicated QA. Hannah, who single handedly broke the game in unimaginable ways for months, and then later on, Andrew and LakshmiNarayanan had a short stint of QA work. The bugs found caused production to slow significantly as we dealt with them and AI obstacles. We also brought on Elena to help fill the audio shoes that Keith and Matt's departure left. She helped make Zone 3 to sound so perfect. We worked out an agreement with MAGIC to continue our sponsorship, this time with some funds involved, from October 2014 to January, and after some Doug resistance, out to February 2015. Then we eventually did launch in February. We really did need the time, even as recent as January we came across major bugs. For example, we were overwhelming the Unity FMOD implementation. Instead of warning us we were running out of sound channels, it cut ones based on the priority setting without any notification. We worked out our own channel management to help out, but it was far from perfect. Unity has no way of accessing the channels under the hood, and there was no time to try and make a plugin. Other small details like lighting and sound nitpicking plagued us. If I had the time, money, and sanity left; I would scrap what we had in Unity and start over. Those bugs from being a prototype were really haunting us, but we had a game to ship.
Well, we made it. Even took A.V. to another GDC. The game has mixed, but many positive, reviews and it is certainly far from perfect, but we did it and we learned a ton. The concept was simply amazing and like most people, I wish we could have continued expanding upon it. Doug and I are working here and there on some of the more important issues and plan on End of Life-ing A.V. at the end of this year. Commercially the game was a failure, but that wasn’t the point. We succeeded in leading a team from start to finish on a journey of game development that ended in the Steam store. This gives us a great experience base for the future. Thank you to all that had a role… our development team, RIT, MAGIC, IGM, the capstone board, family, and of course those fans that went out and bought the game. Alrighty, I’m getting too wordy and worked up. Time to continue the job search. Until next time my minions!