Building a backlog
Right now we’re in quite an exciting part of game development. We’ve decided to fill up on smaller games and to build a backlog of projects that we can produce later in the future to make sure that we never get into a spot where no one in the company knows what to do. In order to create this backlog, we’ve decided to let a number of people in the company to have quite long game jams, where we’re going to make a prototype of a game within a week. This phase will continue for about a month and somewhere in November, we’ll have a great batch of games we can both pitch and iterate on.
I’m one of the lucky ones who’ve been chosen to make these prototypes and I’m going to talk a bit about how we’re going to work when prototyping these products. First of all, let’s talk about time. Usually a Game Jam has a limit to create a game either with 24 hours, or 48 hours. The reason we instead chose a week was due to the limitation of what kinds of games you can make within that time span. During a normal Game Jam, you want to create a mechanic fast, iterate on it make sure everything is great to play and then that one mechanic will lift the game. It is harder to create for example atmospheric games, which requires more work on graphical assets, audial assets and so on. For this reason, we decided to allow our staff to work a bit longer so that these kinds of games could be prototyped as well.
Concept from one of the games in the idea box: A feel good game where you play as a bird.
The rules of prototyping (for us!)
To make everything run smoothly and to make sure that games will be made during this time, we’ve set up a few rules. I won’t go through all of them, but instead I’ll try to summarize how we’re thinking. First of all, motivation is key when creating games like this. People needs to be hyped and want to make the game, else it won’t be a good game. Therefore everyone in the team is allowed to fill up a digital box with game ideas. These game ideas should be pitched in a short manner and the focus is for the other people at the company to understand the game idea quickly and either get hyped, or say ‘meh’. People then vote on the games they are most hyped to work with and at the end of each week, everyone should’ve voted. The games who has received the most vote’s moves on to production and the other ideas stays in the box.
If a prototype ends up bad and you feel that it won’t work. Just scrap the idea early in the process. Trying to get something to become fun even though the mechanic just doesn’t feel good is usually a waste of time. It is better to start working on another idea instead and use the time you’ve got left to try to make something small and funny.
Working with sprints
When we’re making these prototypes we’ll also practice our ability to work in a structured manner and in sprints. This is crucial to do if the game will be iterated on and the scope of the game increases to prevent feature creep and other things that might harm the product and break the time frame for the game. Therefore, after each week of prototyping, each team must have a playable game. If the game is not playable at the end of the week, it is a failed sprint which, in a broader perspective, usually means a delayed deadline. Working to always prevent this is great practice and it will give us a lot of small playable games at the end!
Well then, what is the goal of this? Well as you read earlier, it’s mostly about building a backlog, but it’s also about trying new ideas, improve ourselves and to get other players, such as you who are reading this, a chance to try out some games and be a part of what we create. If a game prototype gets really popular it will be much easier for us to keep working and iterating on it to make into a full game for players around to enjoy. So look forward for some exciting news, playable demos and so on from us in the future, I hope you want to be a part of this as well, give us feedback and become a part of our production!