Product development is a hard thing to do. It is so easy to want to go too fast. The reasons don’t matter: if you don’t have enough information on your product and its market yet, you are in for a bumpy ride if you push through.
I know all this stuff from business software development, and from developing my first game ‘Find the Gnome’. It seems I got myself trapped again.
In this article I shed some light in how I continue to keep the speed and agility in my product development.
First prototype
While working on the first prototype of ‘Manage the Universe’ I slowly came to a halt.
A few things that happened:
- I hadn’t decided on the art style of my game yet, nor experimented with it, nor researched how to get a good looking art style in my game engine.
- I started needing models for my terrain, I needed design guides for my UI elements.
- While modeling my terrain I was not happy with the results. Partly because it didn’t look good, but also because I had no idea where to aim for.
- I was slowing down. Since I was building a vertical slice I got things thoroughly connected and reaching certain parts in game while developing became hard. I was countering this by creating debug screens.
Don’t get me wrong. This first prototype phase was a very fruitful one because I could explore the possibilities of the idea that is ‘Manage the Universe’. I now have a more clear understanding of the core mechanics, that they work, and that this product is worth dedicating more time to.
The thing is that with me trying to make a slice is based on the assumption I know what is in that slice. I do know about the outlines of the mechanics, but not their relations and I certainly have no idea what I want to do with the art.
So, there is my problem.
Second prototype
A lot of stuff still needs refining and exploring. But now the components are clear. So I have redefined my plan.
It was this:
I revisited it to this:
As you can see there are now 28 items with prototyping art vision or an ActionBlock on a certain aspect of the game. Finishing each part will result in a delivery of a test scene (with art or game-play) or a code improvement.
There is still a lot of work to do, so I probably need to scrap more features. But I like it that the roadmap is a lot more clear now.
Next phases
The end goal of this phase is to have a clear understanding how things ‘work’:
- How does the game look like.
- How much time would it need to create certain content.
- The relation between the amount of content and the amount of playtime this will get.
- A code base / architecture that is not likely to see drastic changes.
- A good working pipeline with tools, a clear understanding how to easily add content.
- Good QA tools to see if the game-play still works out.
So then I could make calculations on how much content I want to have given the time available. And to layout the needed assets to be created.
Then the production phase starts. This is where all these assets get actually build and put together. While testing and fine tuning. And with the help of other freelance developers I want to hire.
Somewhere in the beginning of the production phase, early alpha builds will start to get available. Probably on Steam Direct or/and funded through Kickstarter.
And when all content is created, the product is ‘final’. Then I can look at what is created and how well the community responds to this game, and decide on adding additional content.
GameFeelings 