SY!NSO! Controls

1 Apr

[I posted this on RR a while back, but I figured it deserves an outing here too...]

One of my major design goals with SY!NSO! was to make the end user experience as easy as possible and to keep everything as streamlined as possible. The easiest way for me to get a grip on this was to build it with an arcade cab in mind. Now, obviously if you’re building a GUI heavy game such as a strategy title or whatever, then there’s a limit to just how much you can streamline without making things harder – but I tend to view that sort of thing as being as close to application building as games get and it requires a different thought process. If you will, it harks very much back to expected app behaviour and not forcing the user to learn your system because you decided for whatever reason to break away from the way things work without actively improving the experience.*

Golden rule of thumb as far as I’m concerned is if you, the user, have to think about what to press next, then there’s a flaw in the control system. But I digress.

Now, working with the constraints I’d set myself left me with a series of expected behaviours. The standard being that certain functions are generally mapped to certain keys thanks to MAME setting the standard, so if I was to get this to work, I was designing around the way MAME behaves. It’s how people will have their cabs set up and if I break with that standard, I’ve lost the cab user. Instafail.

So, I end up with a series of rules to make the user experience the best I can. All part of the challenge, see. (I didn’t quite get it right as the menu is a bit of a cluster, but I *will* remedy this in a new build when I get chance)

1. The structure of the game must adhere to MAME standards. So, 1 and the fire button will start the game (I had this in all builds, but forgot to actually switch it on until the last one because I’m a spaz), TAB will be the menu system and so on.

2. The game must default to the lowest possible setting as not many people tend towards putting an uber powerful rig in their MAME box. Also, the game *must* open in fullscreen for what should be obvious reasons by now!

3. You shouldn’t need to set the control scheme. Joystick control and keyboard control is defaulted to. Thanks to X-Arcade’s exciting diagram, I was later able to add in default X-Arcade stick support too. Not at any point does the user have to make a choice – it just *works*

4. Essential content must be accessible from the off. In this case, that means the game. You can load it up and just hit fire and never have to visit the menu once. When you die, you’re returned *quickly* back to the main titles and only ever one keypress/buttonpress away from starting again.

5. Non essential content should be hidden from view. The menu is not essential, it doesn’t need to be seen unless the user *chooses* to see it.

Sticking to these constraints meant that I ended up with a game that could be restarted within seconds, the user never has to see any interface features unless they choose to and you can literally just pick up and play. Ok, I’m biased, but I don’t think that’s too bad a goal to aim for at all.

One of the things I want to see more of (and partly what I’m generally railing against round these parts) is that it’s alright keeping a checklist of guff that wot which games do, but you should be designing every part of your game with offering the best possible user experience in mind. Yes, even if you’re designing the game for yourself because y’know, don’t you at least owe it to yourself to give yourself the best possible experience.

Obviously, MAME cab rules aren’t going to work or apply to every genre but you should always be thinking about ensuring the shortest route from startup to game and not exposing the user to stuff they do not need to see. That doesn’t mean obfuscating it, assigning a menu to the { key, keep it accessible (and in a way the user will expect your game to behave). And you achieve this by removing as many obstacles as possible unless for some reason you’ve decided to make a game where your menu is the main feature.

So, it’s ok to build a non standard GUI, but remember that every new thing the user has to learn is an obstacle. Every single step they have to take to get to where they want to be (playing your game) is an obstacle. If you’re doing something just because another game does it (or using “another game does it” as an excuse to justify your decisions, no – more so if you do that) and what you’re doing doesn’t enhance the user experience or make it easier for the user, then you’re building obstacles. Which is the point I’ll ask you to sit down and ask yourself why you’re doing that if all it’s doing is creating obstacles. Despite what the ilitterati hardcore elitist nutcases try and tell you – learning a control scheme, fighting your way through a menu system – whatever – is not something that should be part of the experience. No-one *really* wants to do that, they just want to play the fucking game.

*and I don’t mean “well, I thought it was good but everyone else hates it, they’re wrong. HA!” – I mean genuinely pushing things forward.