The last few weeks have been all about planning and defining the scope of development production from here on out. As I’ve touched on in previous posts, it’s quite overwhelming to continue working when you’re not entirely sure where you’re going.
And I must admit that I’ve been struggling with this planning. I think part of the problem is that I am thinking of it from a “marketing and story first” perspective. This is in large part due to the fact that this is what I know. Whereas many indie companies have the developers doing the marketing, we are trying to diversify a bit – hence my job to take the marketing and business planning burden off of Rich and Austin.
However, when it comes to the project management aspect of this job, to be honest sometimes I feel a bit inadequate because I’m trying to organize something that I don’t fully understand, especially when it comes to developer production processes. I guess this means I need to start using those communication skills that business school seemed to love so much.
Fortunately for me, Austin is good at most everything in this arena. So, I’m trying to piggyback off of his organizational suggestions to develop a good “product roadmap” for our game. What I’ve realized is that we need to be more dev-centric in planning. Everything ultimately needs to start there, because without dev, we will definitely have no game. This sounds like a simple concept, but I’ve found that it’s harder to put into practice than I initially thought. It’s really easy to slip into a weekly routine where everyone works on their piece of the project without a ton of thought as to how everything will fit into the bigger picture.
So, without further ado – I want to walk through some of our thoughts (mostly Austin’s) about how we are going to structure this dev-focused plan.
The first thing to realize is that a portion of our game will be driven by a combat engine and a smaller portion will be driven by a non-combat engine. As you may have guessed, since we are making a tank game, the combat engine is definitely the first priority. Currently, we have Richard slotted as working on the combat engine until mid-February – tracking progress through tickets on our Bitbucket account.
Austin has also prioritized these tickets with the following categories: Essential Feature, Custom Feature, Trivial Feature, RPG Feature, Weapon Feature, Level Feature and Advanced Feature. Within these feature categories, we have specific features listed out according to our Master Feature List for the game. Eventually, I will describe many of these in more depth – but I don’t want to spoil too much of the surprise yet. Suffice it to say that there are such things as Dozer Blades, EMP Weapons and hover tanks. And of course, let us not forget lasers.
We hope that this organization structure will be helpful for Rich and also help him to remain sane as the dev process really gears up. We’ve found that weekly goals are not always the best way to track dev. After all, sometimes life events happen – like that one time a few weeks ago when Rich’s lovingly crafted custom computer more or less imploded.
So, with this new system every month we are selecting 6-7 ticket items and setting those as the production goals for the month. Our September goals include several building block features such as support for pre-level tank customization and interchangeable parts that modify player stats. However, there are also some fun and easier items to give Rich a bit of a change of pace – such as the hover tanks of course!
Beyond providing Rich with a concrete schedule, monthly dev goals provide us with natural opportunities for periodic internal demos. Judging from the internal tech-demo we did earlier this summer, I think that internal demos are one of the most powerful things for team motivation. After all, what’s better than seeing your game actually come to life on the screen? As we advance further, we also plan to use these monthly releases as sources for more promotional material such as screenshots and gameplay videos. Consistent feature releases are also wonderful for me because they provide me with great blog content each month – I plan to write one post a month detailing the features that Rich added that month.
In the end, I’m sure that no matter how much we plan, things will be more difficult than expected. I’m beginning to learn that this is something of a law of nature when it comes to indie development. But, this is part of the adventure – and at least now we are not flying completely in the dark. Thanks for taking the time to investigate our project management plans – we’d love to hear from other indie devs about how they manage this process!