Ever since I got my first 8-bit computer (a Dragon 32), I've always found coding to be something akin to magic. With the right combination of numbers and letters, a coder can appear, like pulling a rabbit from the proverbial hat, to conjure images and sounds from the very ether itself - or at least, in my case, from the 9 inch portable black and white television I was allowed in my bedroom. Nevertheless, I found that with a little imagination, epic stories could be told. Combine that with a little diligence, and whole new worlds can be brought into existence by the power of code and will alone.
Then again, it could just be a buggy mess with lots of flashing colours plips and plops... and whilst the coder as magician may be a romantic image, it's not an entirely inaccurate one when it comes to the ones who know what they're doing. It would not be inappropriate to think of an accomplished game creator as a kind of spellcaster - the spell in this case being the means by which the imagination of the player is captured and held. The quality of a game can thus be measured by the extent to which this spell succeeds, or indeed fails.
In essence, imagination is about creating emotion - in other words. a truly playable game needs to engage its audience on a basic emotional level, and a classic game needs, in effect, to be spellbinding. It's a form of immersion - the player should almost forget where they are, and what they are doing, and escape to the world the coder has created. This world need not be complex, but it does have to be captivating at some level. Encouraging and allowing gamers to suspend their disbelief, and then maintaining this illusion, is something that early developers like Shigeru Myamoto (Donkey Kong), and Toru Iwatani (Pacman) understood very well. The premise of such games is deceptively simple, and yet they have an atmosphere all their own which is surprisingly difficult to recreate, and this is surely the reason why such games stand the test of time, and like anything classic, continue to charm across generations.
It should be clear then, that this kind of wizardry is not about bells and whistles - most of us agree that great graphics and sound don't make a great game. They can, no doubt, greatly enhance a game and make it even better, but without the rock solid foundation of playability, it will feel hollow, and will lack longevity. Much like the action scenes and CGI graphics found in many modern films, there is a kind of sophistry at work here - the guiding principle with this kind of work is that if you throw enough information at the senses, you can distract the viewer from the real world, and thus fool the imagination. In the short term this may actually work, and is often a shortcut to success in terms of profitability - but there is a world of difference between tricking or distracting an individual, and really engaging them, and if you want your game to really be enjoyed, then understanding that difference is important - whether you are creating a 300 million dollar blockbuster, or a homebrew game on an old computer.
So, as independent developers thinking about how best to cast our spell, we need to understand that spectacle can never be allowed to triumph over substance. It should never be forgotten that the work we do is interactive. There is nothing wrong with tech demos that are designed to beguile the observer and show off our coding skills, but games are there to be played. Gaming is active, not passive, and we should always prioritise the player experience. As coders, we have to understand that true success comes when the player's imagination blends perfectly with our own in a kind of symbiosis. Achieve this at any level, and you will have made something special.
There are, of course, limitations, particularly technical ones. This piece will not help you to create a masterpiece. Noone expects you to recreate GTA 5 on a ZX Spectrum (though feel free to try!). People who enjoy playing games on older machines will be patient when it comes to graphics, sound and scope. They know the limitations of the machines they are playing on. Their expectations won't be especially high when it comes to storyline, and they won't demand that the games are groundbreaking. They do however, expect a game to be fun, that is to say playable, and if possible, even immersive. The spells you can cast on these older machines are limited, but with care they can still be magical. By their nature, however, they are also fragile, which is why as coders we must take care to ensure that our designs are robust, and that our carefully planned creations do not break at the slightest touch.
So what do we mean by 'Breaking the Spell?' What I'm talking about here are those moments when as a player you're enjoying a game, having fun, your imagination captured, your disbelief suspended, and all of a sudden something happens which makes reality bite. It could be a simple bug, a poorly designed level, a random enemy, or a poor control choice. Momentum, and immersion, is lost - the carefully constructed web the creator has woven comes a little undone. The player gets a peek behind the curtain, and instead of looking at what you've done, they are looking at what you didn't do. Instead of working with the player in the symbiotic relationship I described earlier, your code is working against them. This is why it's important not to break the spell.
Obviously, as I have already conceded, there are limits here, and there is only so much that can technically be done within the scope of the machines we work on. Yet this challenge we willingly face actually makes it all the more important to avoid spellbreaking, so here are a few thoughts - my top ten tips, if you will, on how best to do so.
1) Controls - don't assume that controls you like are suitable for everyone. Your audience will have a varied range of dexterity. Controls should be natural, intuitive and simple. Redefineable controls naturally help. Think carefully about which keys may be used in combination and order, and code accordingly. Being able to skip menus and intros, and turn off music should also be there if you can fit them in. Remember, once the player takes control, they should feel it's their game, not yours.
2) Difficulty curve. Making a game challenging does not mean simply adding a few more enemies or making them move more quickly. Challenge and frustration are not the same thing - players know the difference - make sure that you do too.
3) Bugs. Test you game properly, give it to others to test. Nothing breaks the spell like a bug.
4) Polish - don't be lazy Think about the gamer experience and put them first. Yes it's extra work, but it helps suspend disbelief. Gamers notice shortcuts.
5) Don't show off too much - flashy colours, big particle effects and so on are all very well, but not if they distract the player too much. You're making a game, not a demo. Eye candy is nice, but only if there is solid gameplay underneath. If you feel the need for such tricks, you may be compensating for lack of playability, and if you are, players will see through it instantly.
6) Play fair. Any situation where a player can simply die with no means of avoiding it is simply unfair. Unfairness breaks the spell. It might sound strange, but there should be an element of the predictable about unpredictability. Death and damage should come from player mistakes, not developer mistakes. Random death isn't fun.
7) Variety is key. Learn the basics of simple A.I. This increases both the challenge and the choice, which always makes for a better game.
8) Feedback. Get feedback from people you trust to tell you the truth. You might not like it, but it will push you to do better when you know that someone is going to let you know what they honestly think.
9) Know your strengths and weaknesses. Don't be shy to collaborate. Most of us like the idea of creating an entire game ourselves, but there are plenty of people out there willing to help bring a bit of an edge or fresh perspective to your game. In doing so, you will improve as a coder, and your game will benefit.
10) Always do what the game wants. This in a way is a kind of mantra for me. There are many times when I don't really want to do something in a game because I know that the balance between fun coding and faff coding is just not right. Coding it will be complex and / or boring, and I feel lazy. But a voice in my head always says 'this is what the game wants', and generally, when I listen to that voice, the game is all the better for it.
So, that's about it for this one! I hope you found it useful, and feel free to share, and of course comment.
Then again, it could just be a buggy mess with lots of flashing colours plips and plops... and whilst the coder as magician may be a romantic image, it's not an entirely inaccurate one when it comes to the ones who know what they're doing. It would not be inappropriate to think of an accomplished game creator as a kind of spellcaster - the spell in this case being the means by which the imagination of the player is captured and held. The quality of a game can thus be measured by the extent to which this spell succeeds, or indeed fails.
In essence, imagination is about creating emotion - in other words. a truly playable game needs to engage its audience on a basic emotional level, and a classic game needs, in effect, to be spellbinding. It's a form of immersion - the player should almost forget where they are, and what they are doing, and escape to the world the coder has created. This world need not be complex, but it does have to be captivating at some level. Encouraging and allowing gamers to suspend their disbelief, and then maintaining this illusion, is something that early developers like Shigeru Myamoto (Donkey Kong), and Toru Iwatani (Pacman) understood very well. The premise of such games is deceptively simple, and yet they have an atmosphere all their own which is surprisingly difficult to recreate, and this is surely the reason why such games stand the test of time, and like anything classic, continue to charm across generations.
It should be clear then, that this kind of wizardry is not about bells and whistles - most of us agree that great graphics and sound don't make a great game. They can, no doubt, greatly enhance a game and make it even better, but without the rock solid foundation of playability, it will feel hollow, and will lack longevity. Much like the action scenes and CGI graphics found in many modern films, there is a kind of sophistry at work here - the guiding principle with this kind of work is that if you throw enough information at the senses, you can distract the viewer from the real world, and thus fool the imagination. In the short term this may actually work, and is often a shortcut to success in terms of profitability - but there is a world of difference between tricking or distracting an individual, and really engaging them, and if you want your game to really be enjoyed, then understanding that difference is important - whether you are creating a 300 million dollar blockbuster, or a homebrew game on an old computer.
So, as independent developers thinking about how best to cast our spell, we need to understand that spectacle can never be allowed to triumph over substance. It should never be forgotten that the work we do is interactive. There is nothing wrong with tech demos that are designed to beguile the observer and show off our coding skills, but games are there to be played. Gaming is active, not passive, and we should always prioritise the player experience. As coders, we have to understand that true success comes when the player's imagination blends perfectly with our own in a kind of symbiosis. Achieve this at any level, and you will have made something special.
There are, of course, limitations, particularly technical ones. This piece will not help you to create a masterpiece. Noone expects you to recreate GTA 5 on a ZX Spectrum (though feel free to try!). People who enjoy playing games on older machines will be patient when it comes to graphics, sound and scope. They know the limitations of the machines they are playing on. Their expectations won't be especially high when it comes to storyline, and they won't demand that the games are groundbreaking. They do however, expect a game to be fun, that is to say playable, and if possible, even immersive. The spells you can cast on these older machines are limited, but with care they can still be magical. By their nature, however, they are also fragile, which is why as coders we must take care to ensure that our designs are robust, and that our carefully planned creations do not break at the slightest touch.
So what do we mean by 'Breaking the Spell?' What I'm talking about here are those moments when as a player you're enjoying a game, having fun, your imagination captured, your disbelief suspended, and all of a sudden something happens which makes reality bite. It could be a simple bug, a poorly designed level, a random enemy, or a poor control choice. Momentum, and immersion, is lost - the carefully constructed web the creator has woven comes a little undone. The player gets a peek behind the curtain, and instead of looking at what you've done, they are looking at what you didn't do. Instead of working with the player in the symbiotic relationship I described earlier, your code is working against them. This is why it's important not to break the spell.
Obviously, as I have already conceded, there are limits here, and there is only so much that can technically be done within the scope of the machines we work on. Yet this challenge we willingly face actually makes it all the more important to avoid spellbreaking, so here are a few thoughts - my top ten tips, if you will, on how best to do so.
1) Controls - don't assume that controls you like are suitable for everyone. Your audience will have a varied range of dexterity. Controls should be natural, intuitive and simple. Redefineable controls naturally help. Think carefully about which keys may be used in combination and order, and code accordingly. Being able to skip menus and intros, and turn off music should also be there if you can fit them in. Remember, once the player takes control, they should feel it's their game, not yours.
2) Difficulty curve. Making a game challenging does not mean simply adding a few more enemies or making them move more quickly. Challenge and frustration are not the same thing - players know the difference - make sure that you do too.
3) Bugs. Test you game properly, give it to others to test. Nothing breaks the spell like a bug.
4) Polish - don't be lazy Think about the gamer experience and put them first. Yes it's extra work, but it helps suspend disbelief. Gamers notice shortcuts.
5) Don't show off too much - flashy colours, big particle effects and so on are all very well, but not if they distract the player too much. You're making a game, not a demo. Eye candy is nice, but only if there is solid gameplay underneath. If you feel the need for such tricks, you may be compensating for lack of playability, and if you are, players will see through it instantly.
6) Play fair. Any situation where a player can simply die with no means of avoiding it is simply unfair. Unfairness breaks the spell. It might sound strange, but there should be an element of the predictable about unpredictability. Death and damage should come from player mistakes, not developer mistakes. Random death isn't fun.
7) Variety is key. Learn the basics of simple A.I. This increases both the challenge and the choice, which always makes for a better game.
8) Feedback. Get feedback from people you trust to tell you the truth. You might not like it, but it will push you to do better when you know that someone is going to let you know what they honestly think.
9) Know your strengths and weaknesses. Don't be shy to collaborate. Most of us like the idea of creating an entire game ourselves, but there are plenty of people out there willing to help bring a bit of an edge or fresh perspective to your game. In doing so, you will improve as a coder, and your game will benefit.
10) Always do what the game wants. This in a way is a kind of mantra for me. There are many times when I don't really want to do something in a game because I know that the balance between fun coding and faff coding is just not right. Coding it will be complex and / or boring, and I feel lazy. But a voice in my head always says 'this is what the game wants', and generally, when I listen to that voice, the game is all the better for it.
So, that's about it for this one! I hope you found it useful, and feel free to share, and of course comment.
Comments
Post a Comment