Ludomancy

Succubus

Prototyping an experimental game is like having to cross an unexplored desert in hopes of finding green pastures at the other side. Since the destination is uncertain and you’ll be alone at least until you reach an oasis of successful gameplay, the trip is going to feel like a spiritual pilgrimage. Only your will is going to keep you from cowering back to known territory.

And as in every religious test of will, there will be devils trying to tempt you out of your ventures into new gameplay. These temptations are the bane of experimentation, and your only aid against them is to be aware of how they work.

One of the devilae that plague the path of the pioneers is The Programming Succubus:

The devil led him up and showed him in an instant a graphical level editor, an XML configuration file and an engine to run the game on. And the devil said to him, “To you I will give their glory and all the coding fun; for it has been told that only on strong foundations a kingdom is built. If you, then, will worship me, it will all be yours.”

Programmers are very weak against this. While prototyping you are not really building a kingdom; you are building a tent that can be moved easily so you can keep going. Many programmers I know will be developing their “engines” and “editors” for a long time until they realize the gameplay they are building upon is sinking into quicksand and they are already working over ruins.

Usual signs of this temptation:

“I will do a level editor before I try out gameplay, so I can test comfortably”
“I will develop an engine to get the technology stuff out of the way”
“It will have some physics, so I am still working on that. Hard stuff.”

Michelangelo made his sculptures by removing the unnecessary parts from the original marble block until only the statue remained. Putting technology before gameplay is like growing the original block just in case you wanted to make an elephant in real scale, taking ages to figure out that you just wanted a tiny statuette.

You might have fun coding a prototype for an experimental game, but if you are spending more time having fun coding than struggling to achieve good gameplay, you’re being led astray by the programming succubus.

7 Comments so far

Less is more. I’ve recently read a book about the coders from 37signals (basecamp, etc). Not really good, but really interesting if I relate it to this post from you. They actually said that when thinking of competition as you make a product, you tend to put more features to surpass your competition.. and this guys said that all you need to do is the contrary: focus on one single aspect and make that aspect your killer feature.
It’s sort of “don’t try to win a race against someone by going faster.. just reach the goal by going in the opposite direction”.. or something like that.
Those kind of approaches are the kind of things that I like to think about when I prototype.
I’ve been prototyping for years now and it’s good to find some spiritual guidance in your posts and conferences.

You know what, this is kind of what happened with Play With Fire. Since the programmer was in India, the project didn’t exhibit strong technical direction, and the engine was (needlessly) re-developed three times, effectively tripling the original project duration. Clearly Argentine’s have a better grasp of gameplay programming than Indians do.

No, thats just racist, but good points.

[...] This is the second article about the demons that plague the path to successful experimental gameplay. This time we’ll be dissecting the behavior of a creature even more dangerous than the Programming Succubus: [...]

Though I get the gist of the parable, I disagree with it’s message.

The trickster takes the devil’s offer, tricks him in the deal, and walks away with a smile and a wonderful tool. The fool says no, and stumbles off to mediocrity.

The Trickster
To cheat the devil, the trickster makes his tool great enough that if his game idea sucks, he can use the tool to make other games. In fact he even sells the tool as he (like others) see it’s value

His XML schema will deal in abstractions rather than absolutes and he has modeled a system and concept that works for games in Heaven, Hell or here on Earth. It is built on simplicity and has no special cases (truely the devil at work). It is flexibility in it’s simplicity and purity. He smiles and says , “Sure we could do that” when something in the plan has to change and his followers wonder if the tools are
up to the task.

The Fool
The fool ignores the Devil’s temptation, and plows into developing the game. The fool says, “Well this is good enough to test the idea, I’ll make it better later.” The fool never gets there and “later” is always next week and shirks away just out of his reach each time he reaches for it. Surely the work of the devil.

The fool has a toolbox with tools just like the others of course. However his soon gets to be too small as it is filled with bits and pieces, cobbled creations held together with twine and prayer. He never tries certain things as he knows his tools are shoddy. He
only builds certain things as he only has tools and jigs for certain cases.
“Hinges on the left of the door? Sorry, the jig only does them on the right. You will have to change your design to match.” The fool always meant to stop for a while and organize the toolbox and perhaps replace a few things, but never got around to it.

There is one other character of course, and that is Average Joe. Average Joe takes the Devil’s offer, and is the stuff of the article above. We dont want to be an Average Joe. We might think ourselves clever by saying “No” to the Devil’s offer, but then stumble blindly into his other traps. Traps far more insidious in some ways than the magic toolbox: the Temptation of Special
Cases and the Labyrinth of the Messy Toolbox.

Tim,

The “Trickster” might never realize he is actually a fool, and that the hinges actually can only be put on the right.

His difference with “The fool” is that he can work out a good game anyway.

In any case, the point is that investment in tools is dangerous when you are not sure what the game is about (remember it´s about experimental gameplay).

Tools are an optimization of the development process, and the moment you create one, you are making a choice. Some things will become too hard to do, and others will be easier.

But if you don´t know yet what the gameplay is going to be about exactly…how can you make a good choice?

Now, if you are making a tool for a section of the game that you know you will be doing in any case, then a tool is a perfectly good call, like all the ordinary acadamic books tell you.

It´s funny calling people who trip on this “Average Joe”…you would be surprised as to how many Joes that are not Average made this mistake…

And the Demons are judgment calls, not rules

[...] Now it’s the beginning of the second day. Morning so to speak. I still have something like 15 hours to go, which should be plenty, if I don’t end up wasting it by doing something idiotic. Like starting to build this elaborate animation system, which seems really tempting… I sense the presence of a Programming Succubus. [...]

[...] Daniel’s work captivated me moreso than just about anything I’ve seen in quite some time. It stands out among the barrage of Flash garbage, not because it is deeper, longer, or more complicated; in fact, I think it’s the opposite. I think I enjoy his work so much because it’s so simple. He explains this philosophy a bit in this particular post. [...]

RSS feed for comments on this post. TrackBack URI

Leave a comment

The demons of experimentation: The Programming Succubus

Play Games!

Fun Posts