At this moment, we’re working on a brand new game, and it’s going to be our very first time management game. The game is aimed at more casual gamers and will feature no explosions or cars whatsoever. Promise!
All we can say at this moment is that we’re very excited to be working within a genre and setting that is new to us. It’s a well deserved change. Release date is TBD, but the platform will definitely be browserbased (3d).
My job is to work on the game design document of this game. The game is far from done, but we’re already well underway with the whole design. The first technical tests and temporary art assets are already being made.
In my blog entries, I’ll try to explain major game-design issues that we need to tackle, hopefully providing a little bit insight into our design process.
Arcade VS Casual
The biggest challenge for us is to determine the main gameplay focus for the game: will it lean more towards an arcade or more towards a casual game? If it is an arcade game players will try to get as far into the game as they possibly can, fail, and then retry to improve their score (much like Donkey Kong). When they’re done with it, they may (or may not) come back to have another go. The scale and variety (i.e. amount of different characters, backgrounds and functionality) of the game can be fairly limited; the player must be able to have a fun experience for let’s say 30-60 minutes. If it’s not an instant classic however, people tend to get bored with the game fairly quickly and the replay value / fun is not very big.
If it’s more a casual game, the player will only gradually advance in the game. The game needs to be huge. Players will play a couple of levels for 10-20 minutes. They can come back later to pick up where they left off, completing more levels, unlocking more functionality and collecting more trophies. The pacing of these types of games is usually a lot slower. Problem here is, that you need a whole load of content to keep the game interesting.
To make things even more complicated, there are client demands, deployment limitations and resource issues to consider. In most cases, you’d automatically start compromising, adding gameplay elements from both types of games until the game concept feels okay and meets the most basic external demands. My fear is, that, if we create a combination of the two types of games described above, we’ll end up with neither a good arcade game nor a good casual game!
Our approach will be to get the core of the game going as soon as possible. Creating a good fluent test level that is typical for the game. We can then get an idea of what kind of pacing feels right for the game-mechanics that we’ve come up with. Then, we might create a couple more levels to test a longer sequence to determine the more global pacing and learning curve that is necessary for the game. It may turn out that our game-mechanics our too hard to get the hang of without some sort of tutorial. This might drag the pace down, making it less fun to replay early levels for a pick-up-and-play experience. To sum it up: Pretty tricky stuff!
-- Diederik
Geen opmerkingen:
Een reactie posten