As a general warning, some of this is going to contain some real-talk. Some of it might sound harsh, but none of it is meant to be personal.
Stage: 1st Pitching (Speed pitching)
Anybody that knows me knows that I am a supremely confident person. I was confident that the idea that I had been drumming up for a while would get picked up and developed in a capstone group (and I had been chewing on the idea for quite a while - over a year). Admittedly, I set myself up for a big disappointment and it caused me a lot of stress thinking about what would happen if my idea was rejected.So this first stage of pitching began. We were challenged to come up with a bunch of random ideas and pitch a lot of them very quickly, just getting the absolute basic point across. Basically, you would come up with (I think) 15 ideas that you were going to pitch to somebody you didn't know, and you had to pitch each of them in one sentence. The purpose of this was to get people to think of ideas that are unconventional and weird, since we are students and can take the risk of developing something crazy and failing at it before we get jobs.
The games I thought of to satisfy the assignment were things I did spend some effort thinking about, but I wouldn't want to make any of them more than the one I thought of before this class even started. I honestly kind of BS-ed the assignment because I already had my champion game that I was going to carry through, but I get the point they were conveying. I'm pretty sure a lot of other people did the same thing.
This also gave me some idea of what other games I was going to be up against when it came time to narrow our ideas down to one and pitch a longer version to classmates again. At that point, I really wasn't intimidated by any other ideas I had heard.
Lesson Learned: If people aren't attracted to the first 2 sentences you say about your game, it has no chance of succeeding. We continued to struggle with this even a couple months into alpha development. GET A GOOD, SHORT DESCRIPTION FOR YOUR GAME, even if it's literally "You're a guy that melts stuff with a special gun, then sucks it up and uses it to rebuild the environment around you". If you have to explain complicated mechanics just to get your idea out there, nobody will listen. It's just a fact of development.
Stage: 2nd Pitching (From ~60 to 11)
This time we had to decide which game among our list of 15 that got the best feedback from speed pitching and develop it into a bigger idea. The pitches had to be one page, and could include images that would better paint a picture of what the game would be if it were developed.We would be broken up into smaller groups (10 to 12 people) and only the top 2 or 3 would move forward to the next stage of pitching. We would have about 5 minutes to talk about our idea, then everyone would vote on the best pitches once all of them were heard.
This is where the brutal reviewing process begins, and it sucks to have to tell people that their precious idea isn't actually all that great, but sometimes they just need to hear it and see another one succeed instead. I also think some people put so little effort into their game cause they didn't care and didn't really have an idea they believed in, and it showed during their pitch presentations. Although, for every person that didn't care and mailed the assignment in, there was a person that was passionate about their idea that got rejected by the other students (rightfully so, to be honest).
People came with all sorts of random ideas and random presentation methods. Honestly, some of the ideas were pretty interesting but I think just catered too much to one demographic (and the typical demographic is 20-year-old male). Any game has no history other than a piece of paper and an idea will get slaughtered by being too narrow of an appeal. About half of the games died out because of this one aspect alone. Especially girls and male gamers with refined tastes will not want to make another Shooter or MoBA for their senior project.
After hearing a few others, the time came to pitch mine and I kept it very simple. Some of the other pitches that I saw had big drawings or pictures all over it, some of them used backgrounds, art from other games, etc. They clearly wanted the page to jump out at somebody and I felt like it was a flimsy attempt to get people interested in their idea, because once they started explaining it, it was clear that the idea was way too mutated and wound up being confusing to somebody that had never seen their pictures before.
My pitch literally had 3 paragraphs about the idea and stick-figure drawings that showed the very basic concepts (learn photoshop if you don't already know it - it fixes everything). I kept it as simple as possible and explained much more about my development philosophy rather than the game itself - explaining that we will have a better appeal if the game is simple and demographic neutral so as minimal people will be turned away because of the subject matter as possible. I also phrased my way of talking about the game as "we will do X and Y" rather than "I came up with this idea". It showed that I was already considering the team demographic and giving a small piece of the idea to everyone that was listening. The only way you will ever get support is if you include other people from the very second they hear about your game.
The time for voting came, and we each got 3 votes to spread around. The top 2 (or a 3rd if there was a strong 3rd) would move on to the next stage of pitching. My game went through, another game about horror from the perspective of a little kid went through, and we never settled on a third as the remainder were all too close in the tie-breaking voting, so we decided to just go with 2. I am pretty sure that every person in the group voted for my game as it clearly lead the pack. The funny thing is that I really didn't say much about my design ideas at all, I painted a simple picture and explained philosophy much more than anything.
Link to my original pitch document
Lesson Learned: The only way you are going to get support for a game that nobody has ever heard of, especially if they don't know you, is to keep it as demographic neutral as possible, and don't over-develop it. I feel like the only reason I made it through this stage is that my game was very simple, I didn't blow them away with big mechanics or ideas, I just said what it was and riffed off the idea a bit to create examples of gameplay that they could imagine. A couple of paragraphs, a couple of stick-figure pictures, and being very willing to give up small bits of ownership and that's all you need to get peoples' attention.
Lesson Learned: Don't get too attached to an idea that you have. It happened to work out for me, but just because you have a good idea doesn't mean that other people will think the same thing about it. Plenty of other people that were pitching were very into their idea, and it got hammered right away.
Stage: 3rd Pitching (The last 11 standing, prove you're worth it)
This stage of pitching is just you in front of the rest of the class with nothing more than a presentation and your own ability to convey ideas. Instead of talking to 10 other people, you're now talking to over 60 people. You have to stand up there, take criticism from the everyone, and accept that if the classroom doesn't think it's a good idea, then your idea is dead.When it came time for me to pitch, it sucked that I was one of the last people to pitch and I was pitching into a tumultuous sea of 2D platformers that had already pitched before me. I had to somewhat begrudgingly state that "sorry, this is another 2D platformer" but say it in way that conveyed "it's just a coincidence that there are so many that are 2D platformers".
Once again, I provided very few examples of the full design that I had in mind, and the presentation was a lot about the very basic ideas and admitting that I have no idea where it's going to go when all is said and done. I talked again about the philosophy that the idea should be simple, easy to understand, and appealing to every demographic instead of just 20-something males. I also used words like "we" in the presentation, rather than "I", to again give bits of ownership to anybody that was interested.
I also made it a point to try to distance myself from a stale puzzle game since that was the immediate vision from everyone that had seen the pitch. I stated that this isn't just "figure out how to put the ball in the hole", it's more like "you need to improvise solutions to your problems". The funny thing is that both of these gameplay feels are totally not what makes the game fun in it's alpha stage.
After all of the pitches were done, people had to vote on what games they wanted to work on. I had to wait a while but I was pretty sure that my idea wouldn't be cut, due to the lack of skepticism that I saw during the pitches. Only a couple of them were cut, and I think justifiably so because the presenters didn't seem too attached to their ideas. The good news was that there were people that wanted to be on my development team but didn't make it because of a lack of space.
Link to my original pitch presentation
Lesson Learned: People are very attracted to you admitting that you don't know everything, and leaving plenty of room for other people's opinions. When people think of an idea for a game, they assume that when I am a game designer, I'm going to think of all of these concepts that are awesome and my game will rule the world. That's simply not how it works. Check out this presentation and note that just among the examples that I provided of gameplay, basically none of them exist anymore. All my pitch intended to do was put ideas in peoples' heads. I honestly had very little planned beyond the absolute core idea.
Stage: Initial Design
After the initial jitters of meeting a bunch of new people had settled (and most importantly directing them to make something), we finally started the process of establishing what we were going to make for the prototype.This is where I'd say I made the biggest mistake, by not keeping the overall goal in mind. To be somewhat fair, I didn't know that our project had the capability of being scrapped after we demonstrated the prototype to the class, so I started planning months in advance when I should have been only planning for the weeks leading up to the prototype demo day.
Going back in time about a year, I used to love to draft big complicated design documents about ideas that I had, and for whatever reason, I disregarded all of that when I came into this class. I could have easily said "here's the book I wrote about this idea, let's read it and do it", and I know that if I did that, it would have killed the idea immediately. I gained traction by including people onto my idea before the first line of programming code was ever written, so to go against it would make no sense. I can't explain why I decided to approach as if I didn't have any further design plans, but it proved to be the best and possibly only way to approach production. That was probably the one thing that kept me afloat in this entire process - being willing to just say that I don't know and letting it resolve itself.
I'll talk a lot more about design as it goes on, but let's jump back to the present time.
So, in this stage we started talking about the character, the setting, the game mechanics, etc. We got into lengthy discussions about where we should go with it, but all of my team really looked to me to provide most of the design ideas and direction. At this point, my teammates seemed to assume that I had a direction for the game to go and I had it all planned out, but I honestly didn't, and that was intentional.
Looking back, I really felt like I put my team in a crappy position because of how much I was looking forward and getting excited about the idea. We talked way too much about story, game mechanics, etc, and not nearly enough about making something cool for the demonstration.
The one thing that any prototype needs is something that will make people go "wow, that's cool", and we felt from the start that our whole idea of liquids and solids was something cool, and showing that transition as clearly as possible would lead us to success. If you don't have that moment of "wow" when you present a prototype, your game will look boring and routine. Maybe the idea itself just doesn't have "wow" in it, and if that's the case, then it's probably not a good enough idea to spark peoples' interest.
Lesson Learned: Keep your excitement bridled, focus on the objective, and put your team in a position to succeed. Even though I made a big mistake by overlooking what our initial goal should have been, we fortunately still got in the right place when we needed to. Things worked out, but I certainly didn't make good decisions when allocating design time.
Stage: Building a first prototype
Part of this process is making sure that you can actually do your idea with the people and tools that you have. We immediately started to solve problems that we knew would eventually come around, such as a liquid physics system and a way to fake liquid goo while still being able to interact with it. We knew that platforming, building objects and stuff would more than likely be easy, so we started with the hardest and most cumbersome thing first to be sure it was actually possible.We started with a 3D liquid physics script that Tigran actually paid for and implemented, and I frankly was not happy with it's potential once I saw it working and saw how it just looked like bouncy spheres rather than liquid. I made a hard decision to get rid of that script and it caused some arguments between the two of us. I know that Tigran was excited to get something going and get something interactive in our game, but I knew it just wouldn't stand the test of time. These are hard decisions that you have to make as a production lead, and you have to be able to talk people into your perspective and ultimately be confident that you know what is good for the lifespan of the project.
I guess this is the time that I should say that planning and thinking about every single scenario is always going to be a better solution than just doing something because you're excited to do it. Don't get me wrong, excitement is awesome and it's the driving force that turns a mediocre project into something great, but it needs to be bridled with logic and eventually contribute to not having to re-do things because they were a bad idea or implementation. Also don't get me wrong in saying that you shouldn't implement something just to see if it works, but definitely try to be thinking 10 steps ahead about what it means rather than what it's doing right now. I'm pretty sure that if we didn't switch off this script to the one we are using now, we stood a very high chance of getting cut during the demo day.
When we dumped that script, we managed to find something awesome and implemented it (big shoutout to Rodrigo Fernandez Diaz - http://codeartist.mx/tutorials/liquids/). It took us a little while to understand how it works, but once we got it working it definitely popped and gave us that "wow" factor that we needed for our prototype during a demonstration.
We worked incredibly hard on implementing some very basic ideas into the game and getting it to a semi-playable point. It was very, very dirty and primitive, but it conveyed the basic game idea. We had only a couple of weeks to get to know each other and churn something out. Thinking back, it was crazy what we got done in such a short amount of time.
Lesson Learned: Like I stated above, you always, always, always, always, always, always have to think 10 steps ahead of where you are right now. If something just won't work for one reason or another, getting rid of it right away and hurting feelings is ultimately going to be better than waiting and getting attached to something that is inferior. It sucks to have to hurt somebody's feelings and essentially throw their work away, but it's your responsibility as a production lead to make those hard decisions and manage the backlash that will ensue. Most of all, you need to be absolutely confident in what you are throwing away because if you go back to it later, you'll lose a lot of credibility. If it comes down to you making the wrong call, take full ownership of the chaos you created by being unsure. If I didn't make the right call there, the game might have been dead right away
Stage: Final Pitching (Industry Panel - From 9 down to 5)
This was, by far, the most stressful part of the entire process. We already had a product that we believed in and put a lot of hard work just to get to this point, and it would be hard to accept our team being scrapped and all of our design/programming work fading before it ever got started.We got our prototype all ready, solved a lot of problems and had a good base of ideas and gameplay mechanics that we were ready to show to industry professionals. And yes, industry professionals to a student can be very intimidating because you always have a mindset that you need to trot out there and prove to people that you are the next person that they want to hire once school is over.
The day came to present to the industry panel, and again we had to present into very rough waters. We came up after all of the other 2D platformers had shown their game, the panel was starting to lose interest and some of the previous ones had either received very positive or very negative feedback. Still, I was confident, prepared, and I did my best to show my competence while still leaving the door open for development ideas.
Once we presented, everything went nicely - we showed what we wanted to show, we finished in plenty of time to allow for questions and feedback. It came time for the industry panel people to tell us what they thought, and we got absolutely nothing. I think the only question we got from anybody in the entire room was "how are your controls going to work?". I simply said I'm not totally sure and we will just have to resolve that as development goes on.
On one hand, we thought it was good that at least we didn't get negative feedback, and on the other hand, we thought that they might have been so uninterested in the idea that there's no way they can make it through the final round of cuts. We were beyond stressed that we got literally no useful feedback, and nobody really seemed interested. It also seemed like everyone was distracted by the fact that when we fired a new brick at a wall to rebuild, the shots would come from his crotch, and everyone was giggling about that. It was disappointing to see people thinking about that rather than the damn game we were putting on the screen and worked hard to make.
Another big problem for me personally was that a lot of the original ideas that made it through had totally changed their pitch/prototype by the time the industry panel came around. Honestly, I was mad that people changed their idea to something that they thought could help get them through to the next stage. I felt like my idea was solid from the start and I didn't need to change it to win some kind of contest. It was really stressful dumping time into the prototype and thinking I could lose to people that didn't actually have a prototype and just threw an animation together.
We had to wait five agonizing days just to find out if we would still be a team. I said my thanks and goodbyes to my team just in case we were getting cut, and somewhat accepted my loss and was ready to move on. I kept envisioning myself being just one of the guys on another team, knowing that I would never start with the level of respect and confidence that I'd have on my own team. I guess I was hopeful that we would still go through but felt that I would be better off assuming that we weren't. Still, I was stressed beyond belief because of the way things unfolded to that point. It was made even worse that we got information that we were not in the top 3, but also not in the bottom 3, so we knew we were right on the border the entire weekend.
The day finally came that the instructors were going to announce who was making it through, and of course they dragged it out until the very last moment of class, while we were all stressing and wondering what was going on. We again got very random and nonsensical feedback from the industry panel, still leaving us completely in the dark as far as what they thought of our idea. Finally, they announced the five teams that made it and we were on that list. We were very happy about it and we were ready to accept team members from the other games that got blown up.
I'm not sure why but I am honestly surprised that a game like this hasn't already been done, and I wonder if people in the industry just don't really know what to expect out of it because it is something they haven't really seen before. So I guess we just had to say that no feedback is good feedback, and keep venturing into uncharted waters without much of a guide.
Link to the video presentation (I talked over it during class) for the industry panel
Lesson Learned: Industry professionals still aren't experts by any means. Yes, they make games. They program them, design them, make artwork, whatever. Still, they can be caught in a position where they have nothing useful to add or even consider when looking at a game that they have never seen before. I would personally take this as a good sign, especially in student games, because for a huge majority of student games they will either complain about almost everything or they will dismiss it in some manner because it has been done before. I would be surprised if this scenario comes up often, but if it does, I would be happy with people at least not complaining about the idea.
Stage: Integrating new team members
It came time to accept that other teams were being broken up and we were absorbing new members. We had a nice starting group, and we were happy moving forward with our group regardless of who we inherited. I'm normally a person that just assumes that integrating new people will be fairly simple, but it was an interesting experience.Kyle, who is by now a good friend of mine, came over to our team. His game (that he was very much enthralled with) was one of the games that got cut, and honestly I thought his idea was better than some of them that were approved. The nights before they announced the winning teams, I was taking inventory on all of the prototypes and wondering if we would make it. I had basically assumed that his game would make the cut based on the reaction and feedback that he got from the industry panel (largely positive).
All of a sudden my job grew to managing the largest group of people that I've ever been in charge of. Everyone looked toward me to provide answers and get us on the same page, so since I knew that I had some stability since our game was committed to being produced for the remainder of the year, I was confident that I could lead us in the right direction to set a nice production pace.
I told people from the start that if you were on my team, more would be expected of you than probably any other group, because my philosophy when it comes to project-based classes is that if this is why I went to school (to show an employer that I produce quality work), we need to flat-out embarrass the rest of the competition and leave no doubt that we were the leader of the pack. It sounds ridiculous to a lot of people to be that competitive over a class in school when we will all graduate with the same degree, but I have done that in every other class that is project-based, and the intended result is having an immaculate portfolio that out-classes my competition when interviewing for jobs.
I think if you're going to be a team lead, you need to set very strong goals and make sure everyone understands what is to be expected of them if they want to stay on the team. I've felt for a while that people can adjust to almost everything as long as they are happy with what they are doing, and I try my best to assign work based on what everyone enjoys. I figured as long as people are happy with what they are making, they can take on slightly larger workloads than what is expected.
I think the biggest downside to the new team members that joined is that we inherited only artists, producers and designers. All of our programmers were in the original prototyping team (4 of the original 7), and it kind of forced my hand to stay in programming and do more work than probably any other team lead in the class. I would have loved to be the lead designer, do no programming work, etc, but ultimately that would have probably resulted in a less-refined project and it would have made me more complacent if I just waited on other people to get stuff done before I could do what I needed to do.
Now that we had all of our new team members, it was time to move forward with design and plan out the rest of the workload until our alpha showing at the end of the semester.
Lesson Learned: Setting clear expectations for your team is something that any lead has to do right away, to set the tone and make it clear that we are going to be the best. More importantly, if you want to be the best it's not because you say you're going to be, it's because you're willing to put a LOT of work into being the best. This is a funny lesson learned because it seems so obvious to me right now, but the first time I talked to everyone and told them what I expected proved to be the reason that we're able to put out so much stuff in such a short period of time.
Stage: Designing the Game
This was a weird stage for me. The strain of adding new people and the rush to get the game designed in some fashion or another proved to be very awkward and was definitely something I was not expecting.I was still being the leaf when it came to design and was kind of trying to let the chaos ensue and do my best to keep it under control. Kyle had somewhat assumed the lead design role but seemed uncomfortable with how I wanted to do things. During the span of this class, I was (again somewhat inexplicably) under the mindset that it's stupid of me to assume that I know exactly where everything is supposed to go, and by far, the design process of this game has taught me the most about how a game should really be developed over time.
Even though I took the correct approach when it came to design, I was still wrong about a LOT of things that I thought would be cool in the game. When I imagined it, I wanted to play around with different surfaces that had different effects, introduce like 6 types of goo, and I just wasn't focusing on making every single element have it's own purpose and work in harmony with everything else I wanted to do. For what it's worth, as of Alpha, we have 2 goo types and no surface properties, and the game is in a wonderful spot.
If you want to design your own game, you need to design it like a web rather than just throw ideas down on paper and assume it will be awesome. You need to start with a very basic idea and every connection from that basic idea has to connect to every other part in a very nice way. If you can't find a way to connect everything together in a meaningful way, it's not worth implementing. Every idea and every mechanic needs to have it's own purpose, and you need to focus your attention on implementing the absolute most basic actions and make sure they are fun before you go anywhere else.
Kyle's job, for the most part, was to define what our game was and corral all of our mechanics into a coherent package that anybody else could easily understand. It took him a while to actually understand what our game was and what it was trying to be, and it's not his fault because we honestly didn't know. I kept giving him somewhat unclear messages regarding the importance of the prototype and what kind of concepts that we had fleshed out, but also gave him a lot of freedom to explore and lead the design from that point. He kept trying to respect the prototype, and some people were still latched onto it, but I told him that the prototype just doesn't matter and was only intended to spark ideas and get us through to this point.
The most interesting part of this though, and something that I can't stress enough, is that you really need to play your own game and decide what is fun about it. I see way, way too many game design ideas centered around things that don't actually make a fun game, like managing an inventory or running some complicated programming script. Most of what people find fun in a game is their very first impression of it, and it took us a while to realize that. Think about the most absolute basic way to describe any good game and you should be able to extract the fact that their very core piece of gameplay is fun and rewarding by itself. Our core idea was melting stuff, and people seem to enjoy watching stuff blob around. It's stupid and doesn't accomplish anything, so that's why we have to make all of those events meaningful and make an actual game around it.
We got to an initial point in design where we thought we had enough ideas to start making something and playing with it, so that's what we did for a while. The design still wasn't done and I wanted to keep adding to our game to see how big we could make it, and that proved to be a mistake that I don't want to repeat again. I'm sure many other people make this mistake and try to cram stuff into a game that really doesn't need to be there to make the game better. I foolishly pushed this issue for a while before realizing that I was wrong.
Lesson Learned: Every single thing in your game has to have a purpose. You can't make a shooter MMO where you can use magic, plan out your battles, control hundreds of units, have a great story and introduce a new way to compute physics while also appealing to a wide audience. Start from a seed, a very basic idea, and slowly build out from there if you want to have a solid game idea turn into a solid game. If you are thinking of game ideas, take the time to make a really dirty prototype and play it. It's much better to see if your core game is fun by actually playing it than it is to write it on paper and assume it will work out if you can just convince people to make it.
Stage: Demonstration Days
Throughout the process of development, we were supposed to make builds on regular intervals to show the class what was going on with our game. The purpose of these was to re-visit our design show the class/instructors that we are producing something that makes sense and is still cool to a wide audience.The first pitch was all about not being able to defend yourself. The first group that went up there tried to justify every thing that they were showing to the class. The reality is that you can't defend yourself from people making complaints. You can't ever sit down with every player of your game to describe how they are doing it wrong. If people notice a problem or don't understand something, then you need to find every way possible to fix the problem so that they can't possibly complain about it anymore. You need to simply say "okay, it is a problem, we will fix it" instead of explaining why you did it that way.
Throughout the subsequent pitches, we had a convenient problem of always succeeding and never receiving negative feedback. It was a little annoying that people would focus on the stupid parts of our game (such as the goo being white or the shots being fired from the crotch of the player) rather than try to offer some meaningful feedback. Again, we had to assume that no feedback was a positive rather than a negative. We got into an awkward spot where we felt like we were always going to be right and that we should continue to develop whatever we wanted since we hadn't missed a beat yet.
However, we still got to points of design where we finally had to say "you know what, the game is designed, and we should stop trying to cram stuff into our game just for the sake of having it". We started to figure this out after trying desperately to fit a third goo into the game, and realized that we couldn't fully justify it being there. We were learning as a team and growing to the point that we filled the space that we needed to occupy in order to legitimize our game. An easy way to make sure you're not over-designing is to ask yourself if you can accomplish the same thing with a method that already exists in your game. If it's a duplicate way to do something, there better be a damn good reason to introduce something new unless it is a huge attention-getter, and if so, is it worth keeping the old method?
More importantly, we still hadn't sat down and figured out what our game actually WAS. It sounds silly to ask this question, but we realized that we had no idea when the instructors came up and flat-out asked us. We did nothing but talk circles and make no sense, and it was clear that we just couldn't explain what the underlying point of our game was.
We were almost in a mode of existential crisis despite always showing very well at every presentation, and the instructors were smart enough to notice that and make sure that we had every base covered. We were riding a wave of success and needed a wake-up call in order to figure out where we were going.
This is where I will talk about our stage of finding an identity and taking it from a mostly-developed idea to a full-fledged game that everyone understands.
Lesson Learned: You always, always, always need to stay centered on what your game actually is. Our game is about altering the environment to favor you, and you do that by melting things, gathering up the resources from melting, and using them to overcome platforming obstacles or deal with enemies. Our design wobbled but eventually stabilized because we reached a point of saying "we have enough material, let's just make a game with it".
Stage: Finding an Identity
By this point we were a little bewildered regarding what our game is actually going to be. Is it about the different goos interacting? Is it about the things you can do with solids or liquids? It was clear that we needed to start subtracting from design rather than adding to it.Most importantly, our team was fragmented on what our final game was going to be like. Some people thought it was about building stuff, and some thought it was more about what happens to the different resources in the game when you interact with them. Everyone had their own input and ideas on what would make a great game in the end, but the problem is that none of us actually played anything even close to what we were talking about. It was a serious case of the blind leading the blind for the few hours that we were discussing what makes a fun game and what we should do.
We knew that at the center of our game, a person could melt stuff, suck it up, and rebuild. It wasn't even necessarily about altering the environment because an entirely meltable environment just doesn't work - it was more about how fun each of those individual mechanics were and the small things we could do make each of them more relevant and more fun.
The discussions at this point were very rough once again. There were arguments and some political jousting over who was in charge of what decision, but again the cream rose to the top and we came out in a good spot. My philosophy of letting the chaos settle and doing my best to control it with as minimal interference as possible proved to put us in the correct position again. It hopefully taught people that eventually things will work out if they are willing to admit that they were wrong and move forward. A lot of the time that was me saying I was wrong and demonstrating that anybody can be wrong, and it's okay.
Even after we came to a consensus on what the game should be, there were still stragglers on the team that didn't attend the meetings where we made these decisions, or just didn't fully agree with everything, that continued to add their input as if we were going to change the game after already stabilizing what it actually was. As team lead, I needed to do a much better job assuring that everyone is on the same page, everyone understands our goal and knows what they need to do to get us there. I had an idea at the time that if you weren't there to help us reach this point, then you don't get to complain about it later. While that is still somewhat true, I should have done a better job making sure everyone understood what the game was and where we were going.
Over time, we started to find things that we could remove from the game, because they seemed too complicated or didn't have their own space to live in. Every time we removed something, it made the game even more fun, both because we had a lot less work when finding a way to integrate significant aspects of each mechanic, and because it was way easier for a new player to understand what we are trying to do with this game if we eliminate the less interesting parts of it.
The design was FINALLY shaping up, and it happened in several iterations. After each iteration we thought we were doing things correctly, and it turns out that we weren't. We had found a way to admit that we were wrong and start taking things out of the game that didn't need to be there instead of shoving more crap in. We finally all had a good grasp on what the game was, how it was going to grow from this point, and more importantly what an outsider would see.
Lesson Learned: I know I have said this a few times, but stay focused on the core of your game. If you have a solid core, everything from beyond that point should be very simple implementations, such as a door opening and closing. If your core is cool, then you don't need to dress it up or add more to it. Often times, taking a step back and making sure any level of player can understand your game is far more important than trying to add on new bells and whistles.
Stage: Teaching a Player
Again, we were visited by an industry professional and we were expected to demo our game to this person. This person has a fairly respectable resume and we were hoping to get feedback from an industry professional now that we've had a good chance to refine our game to a point where people can start playing it.The day came, the person played it, and honestly they did nothing but bad-mouth every component of the game. It was a very weird experience because we believed in the idea, we finally were getting it stable and fun, and this person that has had a lot of experience making games told us to remove about half of what we had in the game because it was too hard to understand what was going on.
People in our group were freaking out on some level or another. I did my best to try to analyze why this person thought what they did instead of just accept that they are right and do whatever they say. Afterall, you can't argue with a player that experiences your game for the first time - the only thing you can do is patch out the things that caused them to arrive at that point. I felt like I clearly saw what was going on from the start, but again took a little bit of a backseat approach to see how it would resolve naturally.
The group was very rattled by the overwhelmingly negative feedback we got from this person, and it took a while to talk to everybody and convince them that we weren't wrong in this situation even though we got dragged through the mud by somebody that has made a lot of games. This is where I knew I needed to be much more of an active and vocal leader, because a lesser group would take what this person said literally and scrap half of the game they had developed because he was way too critical of it. Afterall, somebody that didn't take the time to learn how the game works can't really say it sucks because they put in zero effort into understanding it.
After this demonstration, the team leads met to discuss the future of the game. Kyle entered this class with the mindset that we are a student game, and if somebody can play our game for 5 minutes and have fun, then that's all we should expect. I had always disagreed because the idea was so much bigger than that, and demoting it from a game to a toy would be such a huge waste of what we already had. Yes, most student games should accept that they are student games, but if your idea can be bigger than that and people will legitimately use your core mechanics over and over without getting tired of it, then you should go bigger.
The core of my point was that if people find your very basic mechanics fun and believe in the potential of the idea while playing through tutorials, then they will stick with it even during the harder parts because they've already had time for the game to grow on them, and they liked it enough to keep going. Up until demonstrating our game to the industry professional, our levels were designed to show everything we had as quickly as possible because we only had that 5-minute window to make an impression, but I still completely disagreed with this philosophy because it showed that we were settling for something that people won't really care about.
We re-visited basically every design decision that was in the game and discussed whether it was still necessary to keep it. I said that every mechanic was necessary, and maintained that if we taught a player how to play it properly, then they would learn and adapt as new concepts were introduced. To be fair, we still do have a somewhat complicated game and it's hard to realize that after we've done nothing but think about it for the past several months.
Kyle eventually agreed with me and that our game should be more than just a toy that people play with for a few minutes and move on. We also agreed that the industry professional was wrong about most of what he said. What he was right about was that a new player wouldn't understand what was going on, and our solution was to lay out a clear plan of what a player needed to be taught in order to have fun with this game.
The irony to all of this is that we were specifically instructed to not make tutorial levels during our demonstrations, because we still weren't supposed to know exactly what our game was by this point. We somewhat disobeyed this advice because we felt like we were ahead of the other groups, and we knew that teaching players was necessary for our game to have any chance of success.
When going through the process of designing tutorials, it was quickly apparent to me that even the most simple things that we take for granted are things that a new player just doesn't know. The classic example of this is that once something is melted, it turns into goo. This has been the case since the very first day of design and programming, and we all knew what we could do with it - suck it up, move it around with air, ignore it, etc. However a new player has no idea what the goo even means - as far as they know it's just some graphical thing that is there to look cool. They see something melt but are never given an indication that they can actually interact with the goo, which is why we need to be extremely diligent and thorough about teaching people what our game is. Our pacing and overall list of things that people needed to be taught was deliberately implemented so that ANY player, regardless of age, experience level, etc could pick the game up and not need an explanation of what to do. If they ever got stuck or had to ask us what was going on, then we failed.
Since we were confident in our mechanics and that the only problem with our demonstration was the speed at which players were supposed to know what to do, we moved forward with some very simple tutorials. EAE's Open House was just in a few days, and this is where the public, other students and whoever else has a free crack at your game. This was the day that you'd either make a name for yourself, or just be another underdeveloped, broken student project.
Lesson Learned: Just because you understand your game and you know everything that happens within it does not, by any means, indicate that other people know what is going on. Deliberately outline every single mechanic to your game, even jumping, and point it out to a player so they know what to do with it.
Lesson Learned: Just because somebody complains about an unfinished version of your game and makes wild suggestions on how to "improve" it, that doesn't mean you should take their advice and obey it. You should be asking what provoked them to get to that point of their thought process and re-examine if it's because the game is just broken, or if you are simply not presenting it correctly to a pair of new eyes. Making the wrong choice here can have catastrophic results, and I've seen it happen on other teams.
Stage: Final Alpha
The open house was finally here. The day of, we were scrambling to get all of the levels put together, fix some last-minute bugs and send it over to the rest of the team that was anxiously waiting. Everything that we had done up to that point was on the line. This was our chance to make a big impression.We got the game sewn up, dropped it off and ran over to the demonstration room. The rooms were already packed with people waiting to play, and aside from some minor technical issues, the game deployed and ran without any problems at all.
We didn't have an official protocol to talk to people and ask what they thought about it, and again I took a backseat approach to glean what I could from watching somebody play. We noted some minor issues with controls and some very minor mechanics that players just didn't understand. Outside of that, I was very proud to see that we could literally let somebody walk up and play and we didn't need to tell them anything from start to finish, meaning the game stands on it's own, and our plan to teach players rather than cut mechanics worked out perfectly.
Player autonomy was a big thing that I was pushing for all semester. It seemed like the other games in our class needed a team member there to explain what was going on in their game. I felt over-explaining a game was what made people bored and lose interest, so the fact that we only had to do that very occasionally was a big, big boost to our confidence.
I personally feel that we showed better than basically any other game there. We had a crowd around our game all the time, and every station was always filled. Perhaps most importantly, people wanted to play every bit of the game that we had in there (which was about 20-25 minutes of gameplay) and wouldn't just leave or get bored in the middle of it.
We again came back to the funny realization that while we are obsessed with people accomplishing goals in the game, sometimes people just want to mess around, try to break stuff and interact with what you have in the game when it has no bearing on the game's state. It was a pleasure to see that even though we are in alpha, we have a game with the freedom for people to mess around and accomplish nothing while still having fun, as well as one that poses some interesting challenges that people want to play repeatedly because they like the game, even though they are losing. It satisfied basically any type of player that wanted to walk up and play.
The most satisfying part is that what we busted our butts for all semester panned out exactly the way we wanted it to. Our game was demographic-netural, it was easy to play, it was fun for all types of players and we didn't receive any sort of negative feedback. The game is still in alpha and honestly we would polish a few things and release it if we really wanted to. But, we still have more to do.
Lesson Learned: If you really want to accomplish very difficult goals and stand out among a group of students, you need to waste as minimal time as possible and be willing to put in a lot of overtime to make sure your game is as perfect as possible. The road getting there is rough, but it's worth it in the end.
Stage: The Next Semester
Of course, knowing me, the first thing I do after the demo day is fix some issues I saw and make a big list of stuff for us to do. You can always find something better to do in your game for as long as you work on it, and the only reason games get released is because the developers either are reasonably satisfied with a majority of it, or they are forced to release it because it is the release day.We have accomplished so much already, and I think this next semester will be nothing but refining what we have and working it into a full package. Knowing that we have already come this far assures me that we will be fine throughout the rest of development.
If you were interested in playing our alpha version, I will be releasing it on Wednesday Dec 17th on MelterMan.com. It will be available for download and it works either with an Xbox controller or a mouse/keyboard. If you decide to play, please leave us feedback on the game testing link!
Thanks for reading and I'm sorry this was such a huge post. But hopefully it gave other people some insight into the project and provided something useful for other people that want to make a game. See you soon with more updates!
No comments:
Post a Comment