Game mechanics is often considered the more pure design aspect of Game Design - often put on a higher pedastal that level design - though I feel that both are equally deserving of respect, but do require differing skillsets.
Displaying game mechanics in a portfolio is fairly tricky. We can simply document game mechanics via mechanics spefications, which proves you can document, but does it prove that the mechanic is fun? There really is only one surefire way to do that - that is to present mechanics ideas in the form of a game that you have developed. There are a number of ways you could approach this...
Development Approaches
DIY
If you are going to embark on your own game design, then bear one thing in mind - keep it fairly simple! If you try to recreate Final Fantasy all by yourself, then you are highly likely to fail. Small games that have impressed me in the past have started with a very simple mechanic and embellished it across the course of the game. I hired a great designer (Giles Coope*) based on his small game involving one button press - Pizzicati.
There are plenty of methods of developing your own games these days. We've already mentioned UDK and Unity in previous articles, but there are also plenty of other options - XNA is another create framework to get started building games. There are also old school options like Flash.
If you are going to build your own game to showcase mechanics, I'd probably choose Unity, as it is the most rounded engine, is available on all platforms (including browsers) and supports several well known languages. XNA is interesting and very fully featured, but is limited to windows 7 phones and the Xbox 360 - it does however have a route to market through the indie games on Xbox LIVE, but if you are looking for good sales figures here you might find it somewhat lacking. UDK is just very complicated when going beyond level design - as it means digging around in UnrealScript and altering several important game files. Unity is a bit more abstracted and less prone to complete meltdown, plus you are really writing mostly your own code, not delving around in others.
You are going to need to be able to program, it's unfortunately a bit of a pre-requisite for building your own game. However, I cannot stress how helpful knowing a programming language is going to be for a designer. Most studios require designers to be able to script in some rudimentary form. The more programming knowledge you have, the easier this will be. If you really know about scripting, it also informs you about what is possible - which is great when certain programmers might be trying to pull the wool over your eyes ;)
* After working at Ninja Theory for a few years, Giles has now go on to become an indie developer - massive good luck to him - he'll do great ;)
Modding
The mod scene is a great place for would be level designers to learn their trade, but can also be a place to learn about mechanics design - assuming that the mod is significantly changing the original game.
Due to the way that most games are made, changing mechanics in game mods can be fairly hard work - it definitely requires coding experience. UDK / Unreal 3 mods are perhaps the best to get into, since the engine is so ubiquitous these days. Using UnrealScript will give you a real advantage in the workplace, but be warned, it can be a real pain to get things up and running, and because everything is so complex and interrelated, it is very easy to break something and find yourself in a code mess (keep very regular backups!).
Of course when showing a team built game you are going to have to explain to employers exactly which parts you worked on.
Competitions
I am slightly jealous of students these days, since there is now a wealth of opportunity to do game design - all sorts of free engines and most interestingly for me, a wealth of game design competitions to enter.
These can be a great way to build up a portfolio piece quickly, and have the added advantage of working in a team - demonstrating to you future employer that you can fit right in.
Of all the competitions around game design, the one that has really gained an international reputation for game design students is Dare to be Digital (which I had the privilege of being a guest judge for in 2009). This requires students to form teams and submit a game proposal to a panel. The panel then select finalists, who will spend a summer building their game before it is finally judged at the end of the competition period. The best game even wins a BAFTA!
There are of course others: DreamBuildPlay is run by Microsoft for its XNA suite. Epic run their Make Something Unreal - then there is the fantastic work done at the Independent Games Festival.
There are many more of these around, so keep your ear to the ground. If you can get into one of the bigger ones, such as Dare to be Digital, it can be a real highlight for your Resume/CV.
What to Show
So what do you need to show in your game to highlight your game mechanic design skills? Well really good mechanics tend to be composed of the following elements:
Good Haptic Design
A good interface between control device and game is essential. The mechanic needs to be built to suit the input method.
Far too often I see touchscreen phones with the HUD D-Pad as an interface - this is a case of a game being forced onto an unsuitable mode of input. If you are developing phone games then use a suitable input method that is suited to touch control.
This also applies to game controllers. Be aware of the general pattern of hand movement during play. For example, first person games nearly always use shoulder buttons for major functions such as firing, as the face buttons cannot be used well whilst moving the second stick. Putting binary controls onto analogue triggers is another problematic control input, as it becomes fuzzy as to where the on / off boundary is.
Think about what the major actions of the game are, and map the controller according to these main actions - for example: the primary face button should map to the most performed action of a game if it is 3rd person.
Intuitive - Yet has Depth
A good mechanic should be intuitive - the best way to be intuitive is to have real world correlation. Whilst being intuitive is a key part of being a good mechanic, it also has to have depth - it needs to stand up to repetition. Generally the best way of doing this is through combination with other mechanics. Again the interrelation of mechanics has to be intuitive - if it has a real world correlation, then it is much simpler for a player to grasp.
User Feedback
A good mechanic will communicate with the player - it will tell them when it has been performed correctly, and will inform them when the player has not done the right thing. User feedback should be unambiguous. It should clearly show consequences of actions. There are many ways to do this, from animation, SFX, particles, screen flashes, HUD information, voice over lines, controller rumble, etc. Use what is suitable for each purpose, but always be clear about the message you are giving the player.
One example of a great game that I felt was completely undermined by bad (or even non-existant) user feedback is Uplink. This game by Introversion required you to hack into systems. If you leave any trace then you will get caught. Unfortunately they never told you when you had left information that leads to your capture, so you never learn how to prevent yourself from being caught. I felt it destroyed the whole experience for me - but I know that this was actually a conscious decision by the developers.
Engagement
Above all a mechainc has to be fun, especially one that will performed many thousands of times over the course of a game. Whilst all the above are a vital factor of making an engaging mechanic, there is also an element of "special sauce" - the feeling of flow when performing an action, the quality of the animation, the exquisite timing of an action or reaction.
This is where a lot of the talent lies, it's fairly easy to get a workable mechanic up and running, but the polish and refinement to make the mechanic just right requires time, a lot of playtesting and constant balancing to get just right.
No comments:
Post a Comment