SpaceRace: Post-mortem
What went well
SpaceRace was a 12 week project with the goal of creating a mobile game from scratch. Using proper market research and designing with personas in mind, our task was to create a monetised mobile game for public release on the Google Play store. The project started with prototyping out three concepts for single-interaction mobile games. With these three prototypes from each of the two game designers per team, we then had to choose which one we would make into a full game, start it from scratch, and release it.
Right from the get go, I was excited about this project. A chance to do 2D art for a game, a public release, an unfamiliar platform. My prototype was what we selected. It was a circle outrunning a much larger circle while picking up green circles and avoiding brown circles. Occasionally a blue circle would appear with the purpose of increasing score. Simple. When we were told we would be making three prototypes, I panicked. I hadn't made a prototype, or even coded anything in quite some time, and I was rusty. But, a couple of hours in, I had gotten my groove back and bashed out three real easily. I actually really enjoyed prototyping, though I get the sneaking suspicion that no one looked at how I had made it, because the final game's code was nearly incomprehensible to me by the end. I thought I'd done it really simply, but programmers can be very particular and, I mean, it worked, so what right do I have to judge?
Prototyping helped dramatically in the end, as it allowed some very easy mistakes to be noticed and fixed right away and some good and bad ideas to be tossed around. The purpose of these particular prototypes was to throw them away in the end and start fresh, so I got a bit hacky with the code just to get the ideas down. I was under the impression that our prototypes would form the basis of the game, but only the concept remained. I've learnt a lot from prototyping those 3 games, and I'm going to practice my coding skills to make sure I can keep doing it.
Getting the game's documentation started and up to a stage where it could be read by other people early also helped a lot. It meant I could sell people on the game a lot easier, as they could just read the document. I later learnt (as you'd know if you've read my post on project management) that I shouldn't take all the documentation on by myself. But at the time, it seemed like a good idea. It was my concept after all. So I wrote the document and it was good.
What didn't go so well
The first pitch was not the game we ended up making. As such, it was a disaster. But that was our fault. We changed the design to something we hadn't prototyped and it showed. We couldn't answer any questions and the design was flawed in uncountable ways. We were idiots, and we paid for it. I'll never forget how embarrassed I was. After putting so much pride into my presentations, to make such a brutal and simple mistake like that hurt me badly. But I pulled back and focused on something we actually had a prototype for. That was SpaceRace.
I made a rough code plan very early on, once the game had been designed but before anything had been made for it. This, as it turns out, is apparently offensive to programmers, as it's their job to make their own code plan. I didn't ever see one, but I have to assume there was one. Besides, that wasn't my job. I got all but pulled aside and asked about why I had a code plan. Why I'd DARED to make one. I thought that was a little much for something I made in a genuine effort to help out my team. I also I think my code plan, had it been followed, would have helped out with the project's timeline and making sure we weren't blowing out of scope. Not that we over-scoped by much, but in my experience, there is no such thing as not over-scoping.
Having to share a programmer with another team didn't help much with the timeline or scope, but that was something unavoidable. No one's fault but, I would have preferred a dedicated programmer. Nothing against our programmer, of course, we just had to make the best of bad luck. I believe we would have done a lot better with a single programmer for each team, rather than 3 programmers split between 4 design teams. There would have been a lot less stress on everyone had this been the case, and I believe a lot more would have been accomplished.
We didn't get to test the game properly. Milestones weren't met on time and that meant time had to be cut from other things. Testing was the first to go. Otherwise those simple mistakes would have been noticed, and a fresh outside perspective could have been attained. Testing is crucial and we missed our opportunity. I was shattered. I was really looking for that feedback from testing and the lack of it meant that the game we published had some issues I wasn't satisfied with leaving in. I'd love to have been able to fix them, but with the code being indecipherable to me and my already rusty skills, I was pretty useless in the code. Practice makes perfect. I don't even need to be perfect, but I need to be better.
For future reference
Next time I wont bother making a code plan. I'm not a programmer and I don't want to get yelled at again. I thought it was an essential part of planning out a project, and I figured if we had one, we could use it as a base for what we want to accomplish. I ended up deleting it. It wasn't worth the argument.
I'll also not do all the documentation myself. Against my better judgement, and my gut instinct, I'll have to learn to delegate tasks to other members of my team in future. It's not my job to do every piece of documentation. I just feel that I can do it and not much else (besides art) and so I should. I suppose it makes me seem like the fabled 'ideas man'. Just someone who handles the concept and documents. But in reality, creative director is the job I eventually want, and, to my understanding that's the closest job to 'ideas man' as you can get. I don't mind writing documentation. I mean, nobody reads it unless you directly force them, but I find it relaxing to get everything about a game down on (digital) paper.
I think I got too hung up on passing this unit of university rather than designing the game. There were gaps. Gaps that could easily be filled if only someone had noticed. Since nobody seems to read documents, those gaps are things I need to notice. I got lazy towards the end of the project and I had some mental health troubles that really slowed me and my workflow right down.
