Another wall of text!
Who does not enjoy winning things? I cannot say I was not satisfied when our team won the last Three Thing Game. But winning a competition which only spans on the duration of student life does leave a bitter taste in the mouth. Since this is the last year for us MEng students, it will also mark their last year taking part in the Three Thing Game. Some other teams who have been taking part since their foundation year were quite unhappy about us winning three times in a row, which is easy to understand.
Here are a few tips from what I gathered throughout the competitions that I hope will prove helpful. Make sure you also check Rob Miles’ blog, for other useful infos. I know he wrote a post with tips and tricks, but I just cannot find it… If anyone finds it, please give the link in the comments, and I will update this section. Speaking of comments, feel free to disagree, this is purely advice, and I’d gladly stand corrected.
Take time to think.
I often see teams coming up with a concept in less than a day. This is mind-boggling, as everything a team will subsequently do revolves around that core concept. Getting the concept right should be something you spend time on. With a good concept, you will also thouroughly enjoy the competition! Taking time to think goes hand in hand with the next point:
Be evil with your ideas.
Be awful with them, as if you were a member of an elitict jury just waiting to tear them apart, like the Dragons on the BBC. When something comes as ‘The Best Idea Ever’, it might be a good idea to twist it, twirl it, and examine it first. Be a perfectionist. If something does not smell right (and there are many reasons for something not to smell right, as there are many more constraints in the TTG – see below) either drop it, or alter it in a way that remains meaningful to what the game is set to achieve. If you have an idea of a game that works and fits fine on very first hour, you are either a genius, or the idea will need refining. You’d be surprised how different (and potentially better) a game comes out when you had time to think hard. This difference needs to pop out at the design phase, and not at the implementation. The truth is, when you are starting to program, you must feel confident and have a clear picture of the game in your mind.
Do not be over-ambitious.
There is only a week. Think in terms of time, and how long making the game would take. Make sure programming the basics of the gameplay won’t take all of your time. This will give you some breathing space, and you will be glad to have some breathing time, which you can use in polishing the game.
Keep the art simple but coherent!
The game does not have to be pretty. It can, but it does not require very detailed/well drawn graphics to please the eye. However, what can make a game visually irritating is the inconsistency of its graphics. Like having an ugly texture in a very pretty game for instance, or using different graphical styles which don’t fit together. This usually happens when more than one person is working with the graphics, or when temporary art is left in because ‘it doesn’t look that bad’.
Mind the polish (I heard they are dangerous people).
Joke aside, and although it may seem like an afterthought, polish is extremely important. When speaking about the topic of polish, the phrase “You cannot polish a turd!” usually ends up being mentioned. While I agree with the principle, its opposite is, to me slightly different. A game with brilliant mechanics can be considerably less fun when it is rough around the edges. Take some time during development to refine the points that stick out, or the interactions the player execute the most. The key is to find which parts of your game are relevant to polish, and which ones would just be a waste of precious time.
(Brace yourselves, here’s a pompous bit):
One key aspect of polish is feedback to the player. Feedback, in a way, is the way of the game to tell the player that his/her actions have a meaning. Lack of feedback is often the biggest lack of polish. As Ralph Koster puts it in his Theory of Fun, what makes a game fun is the assimilation of the patterns of its mechanics. It is learning. A very predictable pattern which is easily learned makes for a boring game, while a complex pattern leads to a challenging game. But challenging can still be boring right? The question is how? A hard game becomes boring when it stops giving cues for improvement, or when you just don’t get them. It is when you just cannot be asked to identify its patterns. By adding effects, such as simple particles when an enemy dies instead of just making it dissapear, you will show the player the result of his/her actions, and encouraging the learning of the pattern. Feedback directs the learning process.
Make a small, but complete package.
As Rob Miles quite often points out, a game needs a starting point and an ending point. It does not necessarily mean “A main menu with several options and an ending to the story”. What it does mean however is: “When I stop playing, I must feel that I accomplished something”. In other words, I should not feel like I am stagnating. When player control is removed (death, win), things like a win sound or message, or even a change in the character’s behaviour (in Pocket Starlight, when the boy got too close to the darkness, he would start falling down as a game over sign) can express progression feedback and help the game feel more complete. The easiest way to make a game feel complete is to introduce a simple, straightforward goal (which self-provides the progression feedback to the player).
You do not need multiple levels to make a point.
Another important point is that the game should not necessarily have multiple levels. Multiple levels will likely require a level editor, and the time spent building it could very well be spend on making other things. The word game stands for something that can be played and enjoyed, but it does not necessarily require a full suite of levels. If it is immediately shippable and sellable, good for you, but if you can get the point of the game across in one, well realised level, it would be well enough. Even better, find a design that does not necessarily require levels (multiplayer? survival?…).
Integrate the words.
You WILL get silly words. Everyone does. Everyone. The key in getting a game that fits with the theme is… well… to have the theme fit. Many people (including my team) have a more or less precise idea of what game they’d like to make. And when the words are attributed, this idea needs to change. Tacking on the words is not the solution. They must fit not only with the graphics, but with the context and the gameplay. Keeping the same game concept will only get you as far as a game with three things taped on it. Which is why you will absolutely need to go creative with the words. Being litteral isn’t always the best solution. (And I’ve heard that Nicholas Cage will be in the next word selection. Hope no one’s gonna be litteral with that one.)
Sometimes tacking on the words gives a wacky, zany result… And most of the time, to the point of mental indigestion. The game can be crazy or weird, but it still needs to make sense, to have a common ground on which the zaniness can stand on.
To conclude. DO. NOT. MAKE A PLATFORMER.
Choosing to make a platformer summarises most of the issues covered up there. They are harder to make than they look, they feel unoriginal in terms of the words (and making an original platformer gameplay would be even more time consuming), they often require levels, polishing them is a lot harder.
Only try going for a platformer if you are ABSOLUTELY SURE of what you are doing and how much time it will take to build.
And most of all, have fun, eat pizza, and wear a silly hat!
Because pizza comes best with silly hats.