next »

[Alex Vostrov]

I was speaking with pixelante recently and we both agreed that the ability to cheat is essential to being a good game designer.  No, I don’t mean that you should look over the shoulder of Petri Purho to copy his next game.  This type of cheating is a bit different.

Cheating by Design

Cheating for a game designer is the ability to deal with a difficult problem without actually solving it.

I don’t know about you, but I sometimes get enamoured with the “proper” solution to a problem.  Maybe it’s a challenging bit of code or a tangle of game mechanics.  These types of problems throw up roadblocks in front of you and waste days of time.  Solving them is satisfying, but it’s often wasteful.

Instead of seeking the best solution, I suggest that you develop your skills in papering over the problem.  Have a thorny AI problem?  Change the level in such a way that the player never sees it.  Do the game mechanics lack depth?  Maybe you can throw in something novel every level to keep the player from realizing.

The Cost of Purism

When I was writing Swarm, I had a heck of time making the AI.  It’s quite hard to write a defence routine against hundreds of enemies that move in arbitrary patterns.  In the few hours that I had I managed to throw together something passable.

Coincidentally, pixelante has made a Flash game that’s very similar to Swarm.  It’s much more polished, but the vibe is that same.  Instead of banging his head against AI, he made several simplifying design choices.  The game ended up better off after this.

I did it the “proper” way and paid the price for purism.  Don’t be afraid to trade off design against programming.  A truly creative designer will find a way to realise his vision despite the restrictions.

Conclusion

When your audience plays the game, they won’t appreciate the brilliance of your solutions.  All they see is the game, and how compelling it is.  If it’s all a tangle of duct tape inside, it doesn’t matter as long as the game is stable.

You have to exercise restraint with this, of course.  Sometimes choosing to dodge the problem will bite you in the behind later on.  Very often quick fixes have a long-term price.  Your challenge as a designer is to make the right tradeoffs so that the game hangs together just long enough to carry the player to their destination.

[fraxcell]

Sometimes choosing to dodge the problem will bite you in the behind later on.  Very often quick fixes have a long-term price.

This happens to me all the time. I'll come up with some obscure fix to a problem ("alright, I can only put turrets in this kind of location"), and then confuse myself when I violate said fix a few months later.

That being said, I agree that cheating is a great way to stay sane while creating a game. Trying to make everything perfect seems to lead to more frustration than it's worth.

[drChengele]

Your code is your enemy. It is dangerous and maleficent. Of course you should cheat. Fight dirty. Oppress it. Keep it in line every chance you get. Hit it where it least expects, when it least expects. Distract it with some candy while you take apart its innards elsewhere. Hunt the bugs down mercilessly before they grow into terrorist cells.

Do NOT negotiate with your code. If it smells weakness, it will defeat you. You are the master and it is the servant. Rule with an iron fist lest you be overthrown.

[team_q]

Of course you should cheat, unless you make it obvious to the player that you aren't doing so, and that is part of your marketing for your game.

If you promise superior AI, you have to make sure you are doing it better then most. Unfortunately that isn't enough for people playing, so you have to make the AI project intentions to the player so that they percive a difference from monster closet AI.

[ஒழுக்கின்மை (Paul Eres)]

crawford talked about this somewhere, he said that when you first start writing code, make it as clean and as general-purpose as possible, but when the game is like 80% done feel free to insert hacky special-use code.

to me this isn't an issue of a proper or cheating way of doing something, because there is no proper way of doing something. it's more of an issue of general-use vs specific-use. general-use is better because you can re-use it, and specific-use is better because it's tailored to specific cases and often quicker to code.

[Jason Bakker]

Yep, although it's pretty important to separate Cheating and Laziness. If you're lazy in your approach to an integral system in the game, you'll either find yourself rewriting it, or cheating yourself into a bandaided-to-all-hell solution that you can't touch for fear of not being able to recover it.

There's cheating with the design of the game systems (okay, as long as it's not obvious to the player), and then there's ugly code cheating. You might be able to get away with a few ugly fixes/patchups right near the end of the project, but in general I'd definitely advise against it

[Valter]

I generally always assume that I'll be expanding the program later, so I don't take shortcuts with even the most remote chance of biting me in the ass later if I can avoid it.

[Chris Whitman]

I always feel like my code is a little dodgy, structure-wise, but I have made a lot of sweeping code changes throughout the course of my current project and my average time for serious refactoring is usually only a couple of days. My big focus is just logical separation of systems. If the assets were already ready, I could switch my current project from a platformer to a top down viewpoint in probably a couple of hours, because only the object scripts know much of anything about the actual gameplay.

People spend way, way too much time on avoiding shortcuts where it isn't necessary. Particularly in languages like C++ that lend themselves to overdesign of code, I find a lot of people waste a huge amount of time just making work for themselves. You have to be really utilitarian. Only put time into design at all if it will save you work later. The priority is to make something that runs. Do your best to be organized, and if you really mess something up in terms of organization, ask yourself whether you think you can live with it before you go around refactoring, otherwise you will never get anything done.

I've had a few things in my current code base that were messy or wasteful, but I took a look at them and tried to judge them in the context of everything else I had left to do. Sometimes it was worth it to go back, gut the code and refactor, but sometimes I wound up leaving something in that was inefficient, slightly illogical or just didn't read well, because it worked, and I couldn't justify the time expenditure on redoing something that wasn't broken.

[Toeofdoom]

I wrote a quick "guide" to making a game in 7 days for a class recently... one of the things I mentioned was to refrain from hacking for the first 2 days or so, at least. Hacking together code can be interesting, but like others said - near the end of a project.

[Zenorf]

In Commercial games it makes sense generally toct corners wherever you can.
Obviously it's important to have solid working structures for all aspects but later in development all's fair.
Cheat with Code.
Cheat with design.
Cheat with Art.

Anything you can get away with that won't affect the end user experience saves time and money.

[Paul Jeffries]

I think generally this is good advice, though personally solving a complex problem well is one of the things I find most entertaining about programming - though as I do it mainly as a hobby I'm obviously not as constrained by time as commercial developers.

Doing things 'properly' can also lead to unexpected rewards - I'm thinking of emergent behaviours developing within complex systems which can lead to gameplay mechanics which you might not expect and leave you much less restricted in your design.  I think some of the best games I've played recently have been those that take a particular system and then exploit it to its limits (Portal, Braid etc.) - obviously if you're only faking it then you can't really do this.