Game designer
Lately, some general game development pitfalls caught my eye and I decided to combine them to one post.
Please comment on missing pitfalls!
Entering production without something fun.
It appears that in practice, games that are not already fun before they go into production have a really hard time to find the fun at all during production. Beside the fact that working on a not -yet- fun game is bad for the morale of the team, visions of the game are almost never the same for each team member, resulting in unclear goals and uncertain artist and programming work. Having a fun vertical slice of the game that captures the core of the game early in the process greatly enhances the production because everybody knows where the project is going and can work on fine-tuning that feeling, instead of continuously trying to find that fun factor.
Start big, end up small.
3 core mechanics, 25 levels, 20 skins, 4 environments and a 6-player co-op campaign to start with, end up with 1 mechanic, 3 levels and no multiplayer. Unfortunately, this happens a lot in practice and is a very demotivating, economical and time consuming issue. Starting with something small and ‘finishing’ it long before the final deadline will not only be very motivating, it will also increase the chance on ‘happy accidents’ and remove a lot of stress from you and your team.
Peer reviews not taken seriously.
Designers can often have the habit of not playing each others work, being too focussed on their own work and neglecting to play the work of others. A peer review is something that should be structurally integrated in the process, as it will lead to sharing ideas and a healthy environment for constructive critique, after which the designer responsible for the work can iterate on his work.
Starting too late with play testing.
Doing play tests early in the game development process means a more stable version at the end of the process. It helps to set your focus on what is important and what has to be changed and will eventually lead to better end results.
Not enough games played.
Teams, but mostly the game designers, are expected to already have a strong knowledge of games, what works and what does not with the genre you are currently working on. Unfortunately, this is not often the case. Devoting time to play games with your team can greatly enhance the ability to express ideas or come up with new ones.
Too much importance on design documentation.
A designer can try to imagine how the game would play, but more often there are too many interactive elements that can have a huge impact on the eventual game play and the overall ‘fun’. The only way to prove your theory is to actually see it in action. A lot of great ideas are discovered through experiments and ‘happy accidents,’ but unfortunately, these are discovered quite late in the process and often treated as correcting previous errors, as designers are expected to get it right the first time. Try to test more than to write!
Not taking advantage of placeholders.
Team members, particularly artists and animators, generally prefer working on final assets than low-quality ones that will have to be replaced later. Unfortunately, this often means that the designer has to wait to test his features, resulting in a slow-down of the design process. By extensively using placeholders, the design process doesn’t just speed up, the designer can focus more on the game play than the decoration.
Not keeping design documentation up-to-date.
When documentation is not kept up-to-date, people lose faith in it and at some point they will stop using it as reference. When the main goal of design documentation is cross-department communication, this is a disaster and the design documents are seen as ‘worthless’ by the rest of the team. Although time consuming, design documentation is important because of its ability to keep all the information together and to leave few room left for wrong interpretations.
Also, design documents do not have to be bibles. Don’t try to make them as such – try including as much as visuals as possible, as images can really say a thousand words.
No external play testing.
Unless the game designer is able to erase all experience with games from his memory and think like a casual gamer, you will need external playtesting in order to test your ideas. You would be suprised how intuitive your ‘most-intuitive-interface-ever’ would be according to a 45 year old mother. But also for the hardcore audience, original features that work perfectly might not be that straightforward for your hardcore audience. And what about difficulty and feedback? If you know the drill and the underlying system, you play the game very differently from a new player.