Among some recent thoughts I’ve been having is the idea that “play” is more important than “game”. When you play with a system, or with people, you engage in a testing of boundaries, an exploration of the configuration space. A game is just one kind of system supporting such an activity.

I’m fascinated by people who can take a seemingly closed system or game, and rework or reinterpret the goals to such a point that the original game loses all relevancy. One such field is TAS — Tool-Assisted Speedrunning. Usually, no holds are barred, and speedrunners exploit every bug they can get their hands on to shave seconds off their time, which often has the players running through walls or flying directly to the end boss. But sometimes the very idea of “completing the game” takes a back seat to simply showing off. (A recent example involves corrupting Super Mario World so thoroughly that the clever speedrunner actually reprograms the game to run arbitrary code!)

How far removed are these self-set challenges from the original intention of the game designers? How much richer? The game becomes an impersonal, arbitrary infrastructure for a means of expression that carries subjective, personal value.

But you don’t need to destroy the game to find it. Minecraft has no “goal” yet allows for expressive building and interaction with its many complex systems. Skate 3 allows the player to curate video replays of one of the glitchiest physics engines I’ve ever seen. Even America’s Army allowed players to throw their weapons to the ground, and I fondly recall trying to get the opposing team to do the same so we could peacefully cavort in an awkward jumping dance at the center of the map.

It’s wonderful when a game yields to personal expression.

A coworker of mine recently spoke proudly of how his 3-year-old daughter plays a tablet game called Rat Fishing. The player is told to brutally murder helpless rats by placing bits of cheese in strategic spots, luring the hungry rats unwittingly into death traps.

But my coworker’s daughter doesn’t play that way. Her self-set goal is simply to feed the rats. She enjoys watching them eat the pieces of cheese.

Another interesting case is a modified game of chess, invented by two daughters of a friend. I saw this photo (above) posted to Facebook and immediately asked what the rules were. My friend answered,

It’s a role based game. Pieces move at the whim of the player. They also converse, argue and have relationships.

A dry, closed set of rules suddenly becomes an open world, full of expression and intrigue. And yet the chess board and pieces are no accident — this is clearly meant to expand upon the well-known idea of a formal system. To me, it is a brilliant repurposing of the ancient game.

I, too, made a short game exploring this idea. Called Dressed, the game allows the player to dress in whatever combination of clothing they wish (from a closet I populated with whatever came to mind at the time). It’s a little bit of a parody of “customizable characters” from role-playing games and open worlds like GTA. But ultimately, I wanted to distill the most basic personal expression into an interactive format. You can see more info and play Dressed online here.

In conclusion: Like many aspects of game development, I believe popular opinion is misleading us. We don’t necessarily need to “hone our game mechanics”, or playtest until smoke comes out of our ears. We don’t necessarily need to curate the ultimate experience for the player. Maybe we need to take a step back from thinking we are in control at all, and let the game breathe and exist simply as a means for the player’s desire to express themselves. Maybe we don’t have to be so afraid that people will play the game “the wrong way”.

I’ve disabled comments — if you want to discuss this post, please join me on Twitter or use the Contact page.

snake snake snake snake snake snake snake

Less than a week ago, I was busy developing a game called “Ghost Town” (see relevant post). This has been, by far, my most productive and successful Ludum Dare for quite a while, perhaps since April 2010. That’s not to say I haven’t gained anything from these other Ludum Dare competitions, but I’ve usually gone into them half-heartedly or with too grandiose a concept. The main reason is probably because I was trying to juggle my Physics degree and work at the same time.

However, I would like to save the motivational analysis for a future post (I have much to say in this regard!), and let’s get down to the technical/artistic breakdown of what happened.

The theme

I’m going to let you in on a secret: I didn’t do any voting for the theme! Not a single round. I think SoS Sosowski and the other Ludum Dare organizers did a fantastic job of weeding out the “weak” themes before the voting even began. Each round, I found myself looking at the list with indifference, because any one of the themes could work as an inspiration for games. I’m happy to say I didn’t build any expectations, nor did I feel any disappointment when I woke up on Saturday morning to find the theme announced as “Alone”. That said, I didn’t feel much in the way of identification with the theme either. (Though I will say that it was a crushing blow to see “Kittens” pushed to the end of the list. That was undeserved cruelty.)

When I awoke that morning, I didn’t get up immediately. I kind of went back to sleep. During this quasi-sleep, or maybe when I woke the second time, the idea of having a snake jump out and bite the player in a surprise cut-scene came to me. I put it aside in my gigantic brain, in the hopes that I’d come up with something better.

As per tradition, I left the house almost immediately, carrying my trusty camera. Instead of standing around waiting for an idea or forcing one into existence, I try to clear my head and frame photos around the theme. You can see these photos here, on my G+ photo album. I think they captured the feeling of “Alone” pretty well.

When I got back, I stared at the whiteboard for a while, trying to build some free associations. This didn’t lead me too far, and I just kind of ended up starting to code and draw things without really having a clear idea of where it was going.

I don’t believe that this thoughtlessness did much harm to my project. I knew something had to happen with ghosts, and something had to have a dangerous, filthy atmosphere to it. I knew there was a snake in it, and the snake was meant to surprise the player. This would be introduced by a cut scene, in which the player has a near-death experience by a hit-and-run snake.

With these things in mind, I set to work.

Coding

I used my boilerplate Flixel code to put together this platformer. On the one hand, I’m quite pleased with Flixel and I’m very comfortable with it as middleware for my Ludum Dare games. It is extremely fast and easy for me to get up and running, because if I forget how to do something, I have tons of in-house reference code I can look at. On the other hand, it means my games usually look and feel the same, and not just because Flixel lends its own look-and-feel. It has to do with how I build them, always in the same kind of general way. If I ever want to branch out and try something new, it will probably be difficult if I use the same Flixel basecode I am used to. But like I said, the learning curve was absolutely flat, and my game was up and running in no time at all.

But this smooth flow of coding was not to last. Following up on my “surprise snake” cutscene, I decided I needed a generic[ish] scripting method…. Things started to slow down here. I implemented a generic scene that would receive an embedded XML with a list of triggers and actions. The triggers would be read from each scene’s maps built in Tiled. It was daring and risky, because once you start building such a system, there really is no end to it. You can keep adding features and trigger options until coding each script takes longer than it would to simply add a huge “switch” statement with special cases.

It ended well, because it did work. But I think things would have been smoother if I had either already built such a thing (elegantly, unlike how it came out during the competition), or if I had just added special cases (ugly, but much faster to get working, and justified because of the small scope of the project). So this goes on the list of things to practice or wrap in an Eli Basecode library for the next time.

The artwork

Artwork for this game splits itself into two neat categories: spriting and backgrounds. Spriting was a huge challenge for me, because I really suck at animating. I think I did better than usually, because the walk cycle for the main character has more than two frames in it.

But the sprites did come out ok. Especially the ghosts, which I made using Photoshop, not GraphicsGale.

The backgrounds are a whole different story. For over a month, I’ve been attending “intuitive” drawing classes, and drawing something on my own nearly every day. While the idea was not to make “intuitive” style backdrops, I decided I would use the painterly style. These backgrounds were very easy to make, and I blitzed through ten of them in a really short time on Saturday night (direct link to portion of video with “background blitz”). Doing these backgrounds (and the tiles that went with them) are surely the high points of my Ludum Dare entry. Feeling at home with a tool is the greatest. In this case, it was Photoshop.

Sounds and music

And after that bout of self-congratulation, we arrive at the hardest part of the post-mortem. This part went all wrong! There are no sounds, and only one tiny musical riff played when the player finishes a screen. (I have been told that it does more harm than good, and I should probably have just left it out.)

So what happened here? I’m no stranger to music and sound in games, especially Ludum Dare. In retrospect, I think there was a certain kind of pressure I fabricated for myself, demanding too high a level of quality for the game. I could have made something simple and had a more complete entry, but the “visionary” Eli decided this was not good enough. I had great ideas for atmospheric sounds (windy building interiors, ghostly ambience, etc.), and five minutes with bfxr just weren’t enough to make it happen for me. I gave up on sound.

Music had a similar failure. I wanted some kind of moody music. The original idea even had more than one tune: Quiet ambience from the start of the game, followed by tense action sounds after the snake cut-scene, and finishing up with a wistful melancholy song for the ghosts. Obviously this was too much.

I think there are two ways to deal with this in the future. Either I should practice throwing together simple songs on a theme, or I should lower the demand on myself when it comes to the compo. Perhaps a mixture of the two will do it. Either way, being paralyzed because “it probably won’t come out good enough” is against the spirit of Ludum Dare and my own recent mindset about creation.

Overall

Overall, it was an excellent Ludum Dare weekend. I had a terrific time. Stress levels were high, and I had a very hard time getting to sleep, even after submitting the finished entry. But I did eat properly (mostly thanks to having a caring wifes — highly recommended), and I don’t feel I neglected myself.

Another difference this time was the recording of the timelapse. I found this to be a great productivity tool. I did take breaks, and I did find myself staring at Gmail or Google+, but every time I did so, I remembered the timelapse photos being taken and these breaks sort of ended themselves. Trying to make a good impression for the camera is an excellent motivational tool, (as long as it is voluntary!). Of course, when it’s all said and done, the timelapse looks pretty much the same. A blur of code and pixels flying by, and it inevitably looks like the subject is some kind of magician. So who knows if this productivity “trick” will work next time….

All in all, it was a fantastic weekend, and I look forward to the next one: Ludum Dare’s April 2012 edition will mark its 10th anniversary, and it will surely be a compo to remember.

The competition, hosted by the elusive MrDude, broke the classic competition mold and asked participants to strive for the one thing they would never consciously desire to make. But what is “bad”? If one succeeds in creating a bad game on purpose, does the game become good? If a game achieves “worst game” status, doesn’t that make it good automatically? Would the 2nd-place Worst Game be promoted to first place, thus eventually emptying the “Worst  Games” set?

We could run in philosophical circles – but what about practicality? Can we analyze the entries (in, say, a blog post), and use the results to better our game-making skills in the future? Can we help identify what makes a bad game so bad?

Non-games or games that are meta-bad

It’s hard to call these “games” at all, and thus hard to learn from them. Anything I add at this point would probably deteriorate into a “what is a game” discussion, so we’ll just leave it as-is.

Examples:

Glitchy and buggy games

Of the glitchy games, the most pronounced was probably the nearly-unplayable “BOBER<S QUEST”, in which the simple task of moving left or right becomes a tiring chore.

More importantly is “Upside Down”. Besides being (as the title suggests) an upside-down and backwards platformer, the glitches here are so woven into the fabric that some puzzles relied on glitches in order to be beaten. This kind of broken game-world opens new venues of exploration. I tired of this game rather quickly, but the takeaway here is that the rules don’t have to be constrained to higher-level concepts, but can blur into technical limitations as well.

Examples:

Games with viable concepts that were seemingly thrown together

To these developers, “bad” meant “unrealized potential”. The core gameplay was (supposedly) good, but the game was tacked together hastily or unskillfully (on purpose or not, obviously). Are these bad games? Could they be considered prototypes, or proof-of-concept material?

Examples:

Games that insult the player’s intelligence

Some developers interpreted “worst” on a higher level. My favorite was “Hero Test”, which leads the player through a series of unbeatable challenges, served with insults.

Examples:

Boring/repetitive games

The worst kind of worst. Making a boring game is easy. A developer is nearly guaranteed to succeed in making a game repetitive. Any takeaway that I could offer is: don’t do it.

For example:

Games that defy categorization!

Potato, potato: potato. Potato potatoing potato, potato. Potatoes, potatoed potato.

For potato:

Final thoughts

I am mostly interested in how these games differ from a game that was not meant to be bad, yet came out that way. The most famous was E.T. the Extraterrestrial, but there are many, many others. Further research into previously-made bad games will undoubtedly improve the way we build new ones!

On a related note, this competition taught me that letting go of our ideals can lead to many new concepts and directions. Also, it’s easier to finish something if it is meant to be bad! And finishing things is the way to salvation.

You can check out the other entries in the competition, as well.

Audio: 8th place

Humor: 10th place

Everything else: wayyyyy out there!

This game was definitely not innovative. Innovation was not one of my goals this time around – mostly because of the theme (“Enemies as weapons”). Another excuse I have for not being innovative was my worry that I wouldn’t manage using the Unity platform, so I decided to keep it simple.

Similarly, I did not intend to put much into graphics, and the game looks appropriately. Nothing is animated, the textures are ill-fitting and simpleminded, and basically everything is a barely-modified box or sphere. (The audio, however, came out pretty much as I hoped.)

One of the goals for this competition was to make a fun, humorous game. I went for light-hearted sounds and flavor text, instead of the heavier, mysterious atmosphere from You are me now. The feedback tells me I succeeded in making it lighter and funnier.

However, the big lesson I learned here was that “funny” does not mean “fun”. Most responses to the game were positive when it came to their initial reaction, but the controls were so bad that nobody could actually bear playing it more than one or two rounds.

(See feedback on the entry page.)

And so we arrive at my weakest point of all: control schemes. All three of my attempts at the Ludum Dare competition have resulted in badly-controlled games. This is something I should work on before the next competition.

Thanks to everyone who played my game, I hope to make something better next time.