Now that we’re wrapping up work on Battle Group 2 we’ve begun planning out our next major project. I’ve briefly spoken about this previously and today I’m going to share some further discussions that have come out of our planning. The main theme revolves around creating enough content for a game with a small development team. With three main developers (a programmer, a designer and an artist) and a project timeframe of 12 months we need to make smart decisions about how we will create enough content for our game. I see the same problem crop up with a lot of other indie friends and I thought I’d give my thoughts on the subject.
The Problem – Not Enough Content
The underlying problem is the creation of enough quality content to keep players engaged for a set period of time. For Battle Group 2 this was a handful of hours, however for our next project, we are aiming for something people can play for months without running out of content. The problem is that a small team is limited in what it can produce in a given period of time. For us, 3 (hu)man-years of work. So what are our options to solve this problem?
Solution 1 – Reduce Scope
The first solution is to reduce the scope of the game. Instead of providing x-months of content for the player, cut this back to weeks or hours. This is the usual advice I give to game developers when they are concerned with the amount of time/budget required to develop their game. It’s a common trap to overscope a project and have the development go on for years, abandoning it entirely or releasing something that doesn’t live up to the original vision of the game. Reducing scope has the advantage of focussing the design back on the core “5 minutes of fun” and making sure the game being built is the tightest play experience possible.
Solution 2 – Change Design
The second solution is the change the design of the game to cater to limited resources. From a business point of view, this can involve changing the monetization for the product. Free to play games often require a large amount of content to keep people engaged/playing and therefore draw out more money. Switching to a paid model allows developers to “get paid” up front and focus on quality over quantity. The game is then more about providing an enjoyable experience than keeping people playing and extracting as much money for as long as possible. From a game design perspective, this involves changing the underlying design of the game to cater to reduced resources. The difficult part to this is keeping the original vision of the game at the same time.
Solution 3 – Roadblocks
The current trend for free to play games (Boom Beach, Candy Crush) is to stop the player from racing through the content by placing artificial blocks on their progress. Players continually run into roadblocks that require them to wait, ask a friend for help or pay cash. This is not something we want to do for our future projects. While it has become the norm for a particular set of games, I’m glad to see it hasn’t made its way into more mainstream games outside of F2P mobile domain.
Solution 4 – Procedural Content
The solution I am leaning towards on our future project is to use procedural content generation for the majority of our content. This changes the problem from one of time/resources to one of solving complex problems and tweaking algorithms to make quality content. This in itself can sometimes be as time consuming as simply creating the content and therefore needs to be handled carefully. The major advantage to this solution is that it frees the team up to make the building blocks for the game and have players explore the space in the direction they enjoy. One risk of this approach is creating content that all feels the same. Players quickly see through procedural generation when all that changes is simple stats or superficial changes to content. However games that are built upon procedural content from their core (Minecraft, No Man’s Sky) can give deep experiences that allow almost unlimited play time.
We are in the middle of making this decision for our next project at the moment. We have not decided on the best option and this blog post is a way for me to think through our options as clearly as possible. Have you encountered a similar problem and what was your solution? Are there any other solutions you would suggest?