Chapter 7: Project Planning

              While this is my first commercial project, I am not entirely new to game design.  Almost a decade ago, I was the Lead Writer on my friend Paul Burgermeister’s project, a computer game called Traded Blades.  While Paul’s passion project has not manifested yet – something which I attribute to the vast scope of his project rather than any lack of talent on his part – his project management skills are beyond reproach, and it’s thanks to him that I acquired my preferences for the use of a Kanban Board in project management, as well as Unity as a game design tool.  Part of the deal that I had originally made with Paul is that even though I was volunteering to work on his project for free, I could reach out to him at any point in the future for advice on my own projects.

              Since I am currently studying project management in order to get my PMP certificate – as well as to learn the skills needed to eventually start my own company – it’s worth talking about the project management methodology I settled on.  As an independent game designer with limited resources, it doesn’t make sense to use anything other than the Iterative Project Management Lifecycle Model, getting a rough alpha build out the door as soon as possible and then refining it.  The reason for this is because in an oversaturated games industry, marketing is critical to getting word of mouth to circulate about your project – and if you’re confident in the quality of your product, the easiest way to get people hyped up about your upcoming launch is to give them a taste of it as early as possible.  Triple A games may have the luxury of being able to use traditional project management models (although I suspect that Agile methodology like Scrum sprints are the norm throughout the games industry) but project managers in the indie game market need to be fast and Lean.

              The Kanban Board is an Agile methodology, which means that it is low on bureaucracy and paperwork.  Rather than creating a timetable of the project, you break it up into individual tasks, which go on little cards that are dragged around a board.  The columns on the board have labels like “To Do, In Progress, Under Review, Completed” and typically a task will travel from left to right across the board as it nears completion.  When all the tasks have travelled from the leftmost column of the board to the right column of the board, the project is completed.  Kanban boards have the advantage of being highly flexible, because if you forget a task (or if a new unplanned task arises due to an unexpected issue) you can simply add it as a new card in the To Do column.

              I decided to go with the Rational Unified Process of software design.  What that means (for those who are not constantly reading project management books) is that software code is designed explicitly for testing.  It creates a little bit of overhead work in the short run because of the effort needed to create all of the testing code that functions as the scaffolding of the project, but in the long run you reap immense time savings from the ease of testing.  This is really the only viable way of doing game design, because you need to be able to set up all the different scenarios available.  I suppose that’s why it’s called the Rational Unified Process, as opposed to all the other irrational processes out there.

              Anyway, to get down to brass tacks, the plan was as follows:

• 1)Create the client/server infrastructure (websockets, authentication, push notifications, etc).
• 2)Create the map generation process.
• 3)Create the in-game models for everything and develop the game physics.
• 4)Create the gameplay mechanics and connect them to the in-game models.
• 5)Connect everything together to create the alpha build.
• 6)Begin the marketing campaign and begin building up a core group of power users.
• 7)Implement monetization via ads or purchases.
• 8)Either pitch the game to a publisher or create a Kickstarter to get a more refined version of the game to the general public.

              Although this was the general order of the tasks, there were not many dependencies involved, so it would not be necessary to complete one task before starting another.  Indeed, many of these tasks would be worked on concurrently with each other.  For example, the first three of these tasks were mostly completed fairly early in the project.

              For the client-server infrastructure, I briefly considered having the game be something that could be downloaded in the app store, but a discussion of the downsides quickly made me realize that there was no benefit to it.  The app store typically takes approximately 30% of your earnings, and requires you to frequently update your code to accommodate a new phone’s operating system, resulting in recurring costs over time in terms of support and updates.  Instead, I made the choice to have the game be playable over a standard web browser.  This design choice increased accessibility for the player base because it allows players to be matched to each other and play from multiple different devices and operating systems, without having to pay a surcharge for the “privilege” of being able to use the app store.  (I would later change my mind about that, for reasons that will be discussed in a future post.)

              The map generation was fairly simple to do (for the programmers, not me) and was created using Perlin Noise.  This created fairly realistic types of terrain while allowing players who purchased the paid version of the game to have realistic maps that could be adjusted for a wider variety of challenges.

              The in-game models had already been generated because as I mentioned before, the same OBJ files needed for a 3D printer could easily be repurposed as in-game assets for Unity.  A model is a model is a model, after all.  Unity has a physics engine already built in so really the only physics models that needed to be incorporated was the pathing needed for when pieces moved up mountains: an issue that Unity had recently solved with the incorporation of splines into its most recent stable version.

              Interestingly enough, creating the gameplay mechanics turned out to be one of the most time-consuming processes.  One of the features that makes Mech War unique is the fact that your pieces will have different powers and abilities each turn.  This feature was designed specifically to foil learning AIs but it added a lot more complexity to the game because effectively the rules change every turn based on the strategy card you play, so there are thousands of potential permutations of the rules themselves, not to mention the fact that each map is unique.  This fact means that learning AIs are constantly being thrust into new situations which their training models have not encountered, putting them at a disadvantage when compared to the human ability to correlate similarities of circumstance.  It’s a very simple and elegant way to mess with AI but apparently it can be a real pain to code.

              As the game steadily progressed, it was very heartening to see everything gradually come together.  I won’t bore you with the details of the various decisions that came up throughout the project (just as the choice to use Unity vs Rust) but when you have a good team combined with a good plan, projects tend to run a lot smoother.