Month: December 2014

The Great Big Blog Of Things I Should Get Marks For – Vol 1

So, over the past thirteen weeks I have been part of the production of several games/games prototypes as part of my university studies. As this trimester comes to a close, I’m taking this time to create a small gallery of some of the specific work I’ve done. Primarily, this will be a place to show my 2D and 3D creations, with some audio, programming, and level design here and there. Oh, and some management stuff, if I can manage to find a decent way to showcase that. So, without further ado, let’s get to it.

(more…)

Advertisements

Speaking Without Words, Or Anything Else Really – The Art of Ineffective Communication

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…

Speaking Without Words – The Art of Effective Communication

In any video game it is critically important that the player is always aware of what is going on and what they should, or at least can, be doing. Most video games have a huge assortment of rules, states, and information in general all which are conveyed to the player in one way or another. Some games convey these instructions and pieces of information in straight up text plastered on the screen. Others use audio, sometimes as blatantly as if it were text, and other times more subtly, guiding the player with hints and references. And of course, there are the visuals. All the bright shiny stuff designed to make you look at exactly what you’re meant to look at and to make the important stuff really goddamn obvious without you ever noticing. To further explore this, we’re going to look at everyone’s favourite hypothetical office sim: Casual Office Extreme: Learning Edition.

Imagine you are designing a game about office workers, where the objective is to make your way around the office building delivering various items. Normally, the level would be designed with all of the furniture and important items either on the floor or on top of other things that are on the floor. All of these would then be arranged such that the player could make their way between and around them, and get from all of the Point A’s to all of the Point B’s.

Now, let’s say that the artistic direction for this office is the same as any other regular office ie. none. A pretty drab combination of greys, creams, and browns. Now, once the game begins, the player needs to know what they are supposed to be doing, what they are then grabbing first, and where they are taking it to. One method of doing this would be to slap a big block of bright red text in the middle of the screen that reads “GRAB THE COFFEE CUP AND TAKE IT TO THE MAN IN THE BOSS’S OFFICE TO WIN THE GAME”. Direct and effective, sure, but not a very eloquent solution. If we were to take the non-text visual approach, it could be done by having some icons on the HUD, such as a picture of a coffee cup then an arrow pointing to a picture of the boss sitting at his desk. However, I feel the best solution for this particular situation would be through audio. Have the boss call out “Hey Bradley, could you bring me that coffee cup I left on your desk?” Clear, effective, and far less in-your-face than the text.

But then what about communicating the smaller details of the world? Looking around the office, half of the items are going to be built into the furniture as part of the scenery, and of the half the remains half of those will be glued to whatever they’re sitting on with supernatural force. It is the quarter that remains that can be moved around the world, but how do we distinguish that quarter from the rest so poor Bradley isn’t just wandering around the office pulling and tugging on everything he sees like some kind of lunatic. Again, we could make use of obnoxious text prompts, with the words “PRESS E TO PICK UP THIS PARTICULAR ITEM THAT YOU ARE CURRENTLY LOOKING AT” being plastered over the screen in bright red whenever you glance at something you can interact with. But there are other options.

We could use the audio, and have Bradley say something whenever he looks at some thing he can pickup like “That should do.” or “Is this what they want?”. Yet quite possibly the simplest solution here is a glow. A simple, faint, light blue aura around anything that he can pickup. It’s not exactly realistic to have a glowing coffee cup on every desk, but this game is called ‘Casual Office Extreme‘ for a reason. And that reason is primarily the coffee cups.

So, hopefully now you get the gist of what I’m talking about. If not, the point I’m trying to get across is that effective communication is about telling the player everything they need to know without them ever knowing that you’re telling them.  In the most recent game I was working on as part of Ludus Empire, Deadwood Tune-up, this is not what we did. But this post is far too long already, so I think I’ll write about it in the next. So until next time, dear reader.

Prototype Art, Just How Good is ‘Good Enough’?

So as you may have guess, I’m here to ramble on about prototype artwork this time. So let’s jump right into it because I have little time to spare here.

Now, as per usual, we’re going to use my classic video game example “Casual Office Extreme: Learning Edition”.

Imagine you are designing a game about office workers, where the objective is to make your way around the office building delivering various items. Normally, the level would be designed with all of the furniture and important items either on the floor or on top of other things that are on the floor. All of these would then be arranged such that the player could make their way between and around them, and get from all of the Point A’s to all of the Point B’s.

So you have made a prototype for this game, and currently all of the art and models are pretty basic. The desks are grey cubes, the chairs are grey cubes, the workers are grey cubes, the office is the inside of a grey cube (at least something’s already done), everything is just grey cubes. Now, this may be just fine for you, since you know how everything works, you know the ins and outs and all the subtle differences in the shapes of the cubes and their various shades of grey. But you’re not the only one who has to play this prototype.

Presumably, you are going to playtest your prototype in some capacity. So here’s the thing, your play-testers don’t know the subtle differences between all the grey cubes and so will likely have no idea what’s  going (is that cube paperwork or my coffee mug?). This is where prototype are comes in.

Now let’s get this clear straight away, prototype are does not have to be good. Not by any means. To resolve the issue above what is needed is art that communicates. Specifically, art that communicates what it is and what it does (or at least is likely to do).

So in this example, you don’t need the desks to be modeled as antique writing desks with complicated and intricate etching done in their textures, you need a brown slab with four black poles beneath it. Bam. Looks like a desk. Or at least a table, which is pretty much the same thing. Further more, something like a water cooler could simply be a blue cylinder on a white box. Done. Art. Beauty. Magnificence.

Now all of this is something that I learned recently when making some prototype artwork for our current game. I was initially concerned about the quality of my work until I realised the whole point of prototype art. Not to look good, simply to convey. So for many of my models and textures, when I finished asked myself “Does it look good?” No. “Does it get the idea across?” Yes. “Perfect.”

How to Write Down the Right Stuff so Your Project Doesn’t Suck (At Least Not Completely)

Wow, my titles sure are terrible these days. You’re welcome.

So, the whole purpose of this particular post is to cover the importance of documentation. Not only the importance of it existing, but the importance of it existing in such a way that it is of a well written nature. Or, in a less convoluted way, why you should have documentation that is written well and makes sense.

For the purpose of this, we’re going to use my classic video game example “Casual Office Extreme: Learning Edition”.

Imagine you are designing a game about office workers, where the objective is to make your way around the office building delivering various items. Normally, the level would be designed with all of the furniture and important items either on the floor or on top of other things that are on the floor. All of these would then be arranged such that the player could make their way between and around them, and get from all of the Point A’s to all of the Point B’s.

Let’s say that this is the game we’re trying to make and write documentation for. So let’s start with the first point, the importance of documentation existing. This one is pretty straight forward. You have this great idea about a game called “Casual Office Extreme: Learning Edition” and you pitch it to your team. They love it and you start making it right away. With no documentation. At all.

You try to bring everything together to discover things have gone terribly wrong. Joe seems to have some kind of office-y level going except there’s all kinds of desks and such on the walls and ceiling. Amelia’s gone and designed the gameplay around a parkour movement system WHICH IS TOTALLY INAPPROPRIATE OFFICE CONDUCT. And Sean, he made a dragon because he thought the office was set in the medieval era. Really, Sean? Really?

Why has all of this gone so horrifyingly awry? Because you had an idea and wrote NOTHING down. There was absolutely no record of what needed to be done for your idea to become a reality. So because your team had nothing to reference, they did what they thought you meant (which was wrong).

So, let’s say now you have documentation, why does it need to be well written? Because if it’s poorly written, you end up with the exact same problem that you had before. It is critical that as much detail is included in the document as possible in the simplest, clearest way. Otherwise Sean still ends up making a dragon because you wrote:

“The player collects things for a large and powerful enemy in the final stage.”

For it to be written properly, it should be detailed more like this:

“The player* must collect and deliver 5 reports, 3 boxes of staples, and 1 cup of water (from the water cooler) in order to defeat the boss of the final stage. The boss is the large, middle-management, HR, executive, CEO*.”

*There should be another section that covers everything about this in great detail

So now when Sean makes a dragon you can slap that moron in the face and yell “THAT WASN’T IN THE DESIGN DOC YOU FOOL!”. But don’t do that, that is also TOTALLY INAPPROPRIATE OFFICE CONDUCT. Still, you get the point.

So, on a more personal note, the documentation my current project was initially running on was detailed, however not nearly detailed enough. What’s more, the document was not structured as well as it could have been. This would have resulted in team members having to waste excessive time trying to find small simple bits of information about something, all of which were scattered about the document rather than in one place. Which defeats the purpose of the documentation entirely: To give easy access to all necessary information about the project quickly and clearly.

Now, our documentation has been improved. The entire design document has been restructured and each individual section expanded upon in detail. Whilst this has resulted in some delays, we’re no doubt better off for it as we ended up with a clearer idea as to what the game was meant to be than before. Which I suppose is the other purpose of documentation: To make it clear to all team members what the project actually is. Otherwise, you just end up with that mess I described earlier. And I can assure you, no matter how cool Sean’s dragon is, it does not belong in the workplace.