So as you may recall, in my previous entry I said:
“… effective communication is about telling the player everything they need to know without them ever knowing that you’re telling them.”
Now, in the most recent game I was working on as part of Ludus Empire, Deadwood Tune-up, this is not what we did, and this is what I’m going to be talking about this time. The player didn’t know that we were telling things them for sure, because we told them practically nothing.
So first, I’m going to talk about the state our game ended up in. By the end of our time frame, our game was at a point where it worked (mostly, anyway). In this state, we had several methods that were designed to communicate the information necessary to the player. The key part of this was the voice acting.
The player had a handy helper, Billiy-bob the Mechanic, around to give them tips and advice on what they should be doing. He generally told the player things like ‘Get me some car parts’ or ‘You’d best grab some guns’, two of the core objectives of the game. Whilst to us, this was more than enough information to make it clear what to do, we forgot that we would have far more info than the general player because we made the damn thing. So this created a problem.
The big problem was Billy-bob conveyed info, but not nearly enough. Whilst it told the player exactly what needed to be done, it told them nothing of where to go, what to look for, how to pickup the stuff up, or why this stuff needed to be done. In what little ‘play testing’ (and I use that word lightly here) we managed to do, often players said something like ‘Right, so I need to get car parts, where are they?’. At that point it was pretty clear there was a problem. Obviously, this problem could have been easily fixed by changing the voice lines to say something like ‘Grab me some car parts from the Gas Station’, but alas, we had no time to make any edits at that stage.
In another method we employed, we attempted to convey the types of various buildings using icons and symbols. Whilst this is not in and of itself bad or ineffective, our execution was poor. Whilst you could generally work out what the building was related to (eg. The one with the army helmet on it is probably a military building of some king) this alone was not enough to communicate the gameplay effect of that particular type of building.
We could have better communicated this in a couple of different ways. Firstly, by making better use of the voice lines, this wouldn’t have been as much of a problem. If the mechanic gave you a name, you’d likely be able to work out which building was the one he meant based on the symbol. Alternatively, we could have used more icons to indicate the kind of items they would spawn, or we could have simply put all the definitions for everything in the instructions, but that falls back into the obnoxious text issue a bit.
An important thing to make note of here, is why did this happen? Why did our game end up in such a state and why were we so clueless as to these flaws until the very end of the project? Firstly, it happened due to a lack of time, we over-scoped and under-performed leaving us no time to invest in improving the game and making it fun. It also left us no time for play testing until the morning we had to present it, at which point it was too late to make significant changes. And that is also the reason that we didn’t see the flaws until the end. We had no one else play the game before the end, because before the end we had no game to play.
From this, we can gather some very important lessons. Firstly, PLAY TESTING IS CRITICAL, MAKE SURE THERE IS TIME. Secondly, make sure the work you’ve set out can be completed within your time frame and do everything you can to stay on schedule. Lastly, be prepare to start cutting content as soon as you begin to fall behind; it’s better to have less content that is more polished and enjoyable than more content that isn’t. Had we managed to do all these we may have ended up with a game that worked and made sense. But we didn’t. Next time though…