Ok so I was going to write this big long article about the importance of feedback but honestly it was getting way too long and felt pretty didactic so I think I will come back to that specific thing when I have more time to think it over.
Hello! It is finally summer! Yay! Near the end of school we had two really big assignments. Design Documentation (who knew you had to write so much to be a game designer?!) and Thesis Prototypes! I want to talk about prototypes more today because Ive learned a lot this semester both through successes and failures! Yay failures!
I think the biggest mistake I made this past semester was thinking that “iterative prototyping” and “prototyping” are the same thing. I spent the semester iterating over my original HARDSCOPE prototype even as the game was evolving and changing. Instead of making a bunch of small atomic mechanical prototypes and finding all the pieces that can work, I made one over bloated prototype and stuffed everything into it that I thought would make the prototype “better”. Even when telling other people to rapidly prototype different small ideas, I was turning around and working on the same huge project! Oopsies! However, I had a great conversation with one of my professors who told me I should try and make a new prototype every day for a month if I can. So that’s what Im doing now!
Im going to be honest, it was really easy to open up the same prototype every day and keep tinkering with the same system. I knew in the back of my head that I should maybe try different things, but I fell into the trap of thinking “well I would have to rebuild everything from scratch again so I might as well just keep using this system.” So how do we avoid falling into this trap in the future? Well I have a couple of suggestions!
- Make Template Projects
- After 3 days, you are not allowed to work on the same project
- Don't even bother with Git
Make Template Projects:
I have found this to be the most helpful and the most freeing way to ease myself into the prototyping mindset. However, with Unity there is no “save project as” feature yet so it can be a little annoying to set up a clean workspace without having to build everything every new project. So how can we make a template project then? The answer is Packages!
My package consists of a character who can aim and shoot, some randomly placed buildings to play around with, and a really basic respawn volume and spawn point because Im playing around with physics pushing characters a lot and they fall off the small map all the time. That’s pretty much it. I removed all the unnecessary code from all my scripts (For the player, bullet detection, and enemy behavior) so my known basic functionality is in there, but nothing else. Its clean, its simple, it looks good enough for my taste, and I can easily add and change the code depending on what I want to do. I exported that project as a Unity Package and now its sitting on my desktop.
Now, every day I create a new Unity project and just import the BasicFPS package into the blank project. Boom! Template project achieved.
Making this process easy to import and set up makes it easier to get into the mindset of rapid prototyping. I don’t feel like I really “lose anything” because there isn’t enough in any one prototype to lose. It also works really well because I have at least a basic idea of the kind of game I want to make. It wouldn’t make sense to start from a template project if one day I was making a 2d platformer and the next day I was making a 3d RPG. (although maybe you could?) The idea is to just make something that is functional enough to set up that when you import your package you are ready to start trying new stuff, not fighting against your system.
After 3 days, you are not allowed to work on the same project:
Humans are creatures of habit. As I said earlier, it became really easy to open up the same project and continue iterating over it in the name of “progress”. The point of rapid prototyping is Not to make the perfect player experience. The point of rapid prototyping is to find the little interactions that make your games mechanics. Even more, the point of prototyping is absolutely not to get the Exact mechanic working perfectly in your prototype. That’s what production is for. This is preproduction! It’s not going to be perfect! As soon as you put it in user’s hands they are going to tell you 30 different things that’s wrong with it. That’s ok! That doesn’t mean your dumb or bad at what you do, that’s just the way things work. Tuning takes a ton of time and playtesting. What you Can do in your prototypes though is recognize what is worth exploring further and what isn’t. These little prototypes will tell you in 10 seconds whether they are worth pursuing or not. Il go one further: These prototypes should tell you whether they are worth pursuing in the first 10 seconds. If not, then you probably need to dial back what you are prototyping to something smaller. Is this always true? Probably not, I’m coming up with excuses in my head right now as to why that statement is crap but I think it’s a worthwhile goal for lots of your rapid prototypes! That was a little off track but the point is, your prototype will be incomplete and imperfect. After 3 days working on it you are moving into production territory, so put it away, open a new Project, import that template, and try something completely different!
Don't Even Bother With Git
When I started this past semester knowing I was going to be prototyping I thought to myself “oh I should keep a Git repo so I can track my progress and my changes working on these prototypes”. I think that was part of why I continued to work on the same prototype instead of making new ones. On day one I was already using a single project based system. Of course, I was going to keep working on the same thing. I told myself every day I worked on different stuff I would use a different scene. Until I forgot. Also, even if I use different scenes, the code was all building on top of itself. I had unknowingly entrenched myself in this counterproductive system before I even made my first prototype. Here is an actual screenshot of my HARDSCOPE scenes folder. Look at the dates!
Yeah I didn’t do a great job of rapid prototyping, and thinking I could track my progress using Git was a mistake in my opinion. I ~could~ have made a bunch of different branches and switched between all them I guess but, I really don’t think that would be worth it. So yeah! Don’t even think about version control in preproduction! Its counterproductive! It is a necessity once you are into actual production, but I don’t think it has much of a use in preproduction at all.
Summing it up
I think following these general guidelines and just trying to catch yourself when you get into a mentality of trying to build on something when you are still in an exploratory phase is really important. Hopefully these tips can help you as well!
I have one final thing, in the spirit of putting my money where my mouth is I am going to upload a build of all my prototypes as I create them for this iteration cycle both to give people a practical example of how small prototypes can be. But also to help push myself to keep up with producing these small prototypes over a longer period of time.
So please enjoy my prototypes!
If you liked this article or any of my prototypes please leave a comment!
Thank you for reading and happy prototyping!
-John