Why make it a Platformer? - Thoughts on perspective

I love myself a good puzzle platformer. I love how they tend to be based around exploring one single game mechanic to its fullest potential. Currently working on one myself, I have been thinking a lot about the genre and what defines it. And recently I have been wondering: Why is it, so many puzzle games decide to explore their mechanics inside a platforming-environment? When I think about games like Braid, Closure, or even DYO for that matter, there is no immediately obvious reason for why their core mechanics wouldn't work using a top-down perspective. Or is there?

Before further examining this, we'll need to know what defines a (2D-)'platformer'. I'd say it's the side-view perspective in combination with gravity affecting the players game avatar and constraining his movement to maneuvering 'platforms'. That's far from a waterproof definition, but I think it will do for now. I'll take a look at these two aspects (visuals and mechanics) separately.

Visuals

Generally speaking, a side-view perspective is visually more appealing to the player than a top-down view, I think. It's closer to the perspective humans live in every day. We're not used to looking at things from above. Hence, we tend to have more trouble recognizing objects from a bird's eye view. Relating to actors in the game world becomes much harder without seeing their face. For top-down games with non-abstract settings, this can be a big problem.
One might argue that this problem can be solved by using an isometric or axonometric perspective. It means showing objects from an angle (e.g. Bastion) or even in full side-view (e.g. The Binding of Isaac), while still keeping the top-down gameplay. While it works fine for some games, it can bring its own problems. Not only do isometric visuals mean way more work for art and level-design; shifting the perspective like that can make collision boxes much harder to read for the player, which is crucial for action-heavy and precise gameplay.

A great example of object hit-boxes being obscured by their perspective: The Binding of Isaac

Gameplay
Now, this is the most interesting bit in my opinion. Why use the rules of a platformer (gravity) when your core game idea does not require it?
Being somewhat of a 'game-mechanics purist', I've been having a hard time answering this one. My first impulse was to say: "If you don't need it, don't use it. Platforming in itself is an added mechanic that will distract players from the actual core gameplay."
Then I did some thought-experiments: I picked a couple of mechanics-driven games I recently played and tried to imagine them inside a different perspective. And I noticed that while most of them would theoretically work in a top-down environment, different features would have to be introduced to replace the missing platforming-mechanics.
Let's take Braid as an example. It's core mechanic is letting the player rewind time at any point in the game. That would work in a top-down environment, right? Sure. But let's try to recreate a typical moment from the game in this new perspective: The player falls into a pit he cannot jump out of, so the player rewinds time to get back out. Not a complex scenario really, and still demonstrates the core mechanic perfectly. So, what would the equivalent be top-down? We'll need to create a situation in which the player is somehow trapped because he made a mistake, and can not undo it without rewinding time. You can try finding one for yourself; I think it's a really good design exercise.

A pit in Braid (just pretend there wasn't an enemy with a key in it)

For obvious reasons, falling into a pit doesn't really work here. How about one-way doors, which the player can only walk through from one side? If the player walks through a wrong door, he can not get back and has to rewind time. It would demonstrate the principle, I guess. But on top of being way less satisfying for the player (reverse walking looks way lamer than reverse falling), it would also require additional mechanics (one-way doors). I just couldn't find any scenario as simple and elegant as falling into a pit. (If you did find one, please let me know. I'd love to hear it!)
This was only an example, but I tried this with many games and many scenarios and rarely ever found a suitable replacement.
What it made me realize is that a core mechanic can rarely ever exist in a void. It almost always needs a framework of secondary mechanics to be properly conveyed. So the alternative to using established platforming mechanics is using other mechanics which are more complex and less self-explanatory. Gravity is such a universally recognized and understood principle that it can be used to explain the not-so-universally-understood principles that may be your game's core mechanics.

Butterflies or Ladybugs? - Exploring design concepts outside of games

You always hear about how different design areas inform each other. How a game designer shouldn't focus solely on games, but rather have some general knowledge in as many other creative media as possible, like eg. writing, fashion or web design.

I have been thinking about this a lot lately, and found that maybe as a game designer, you should be looking not only outside of game design, but even outside of other established design categories.

Of course, certain design disciplines inform each other very directly and specific principles can be directly translated from one design field to the other. For example, looking at camera techniques in film will certainly help when thinking about camera movement in your game.

But when it comes to practising and discovering more general and abstract design principles and approaches, you don't necessarily need to (and in my opinion maybe shouldn't) search in traditional design areas. Rather, look for situations that you or others design in everyday life, maybe without even noticing. Only because most people do something unconsciously, doesn't mean you can't design it.

Take, for example, the concept of a conversational question. Conversation happens all the time, and a good way to start one is asking a question, but did you ever think about what makes the difference between boring small talk and an engaging discussion that people remember? Probably not, or at least not in much detail. Yet there's so much to learn from and trying to design a question. Think about what a conversational question tries to achieve, and how to achieve it. Ask different people different questions and analyze why some of them are more effective than others.

For me personally, exploring an unconventional design field like that on my own, is not only more exciting and fun, but also a much better lesson than memorizing design principles that other people came up with. That's a reason why I won't spoil the whole thing for you by writing down my thoughts on how questions work. (The other reason is laziness) I'll just say that I'm surprised by how insanely complex of a topic it is, and how many parallels can be drawn to game design if you just dig deep enough.
Also, turns out "Would you rather eat a butterfly-salad or a ladybug-salad?" makes for a pretty decent conversation starter...

Postmortem: Zeit

I participated in the 48h game jam Ludum Dare again last weekend. The theme was "Connected Worlds" and I started making a game called Zeit based on the multiple worlds interpretation, in which you are stuck in an endless time loop and have to fight off enemies and avoid a growing army of alternate versions of yourself. Sounds fun? Meh. I didn't really like it, so I stopped working on it after 14 hours and left it half-finished. You can still check it out if you're interested.

Zeit

The Good
So here's some of what went well this time.

- Livestreaming. I did that, and a couple of people actually watched it. It's great for two reasons:
Firstly, I was way more focused on the task and way faster than I would have been otherwise. You don't procrastinate when you know you're being watched. Secondly, I now have all of my 14 hours of work on tape and can revise my workflow and do cool things like this time-lapse. I'll probably keep doing that in the future, and I can only recommend it to anyone who does anything remotely interesting.

- Researching. I did that for the first time. I didn't have any idea what to make of the theme "Connected worlds" (at least none that would have been realistic given the time frame and my limited programming skills), so I googled anything related to "connected worlds", "multiple worlds", "other worlds", etc. Eventually I got stuck on the many worlds interpretation, which gave me some crazy gameplay ideas about alternate universes and time-loops. The stuff is actually really interesting, and you should totally do some research on it if you're looking for gameplay inspiration.


The Bad
Here's what didn't work out so well.

- Giving up. I did that way too early. In retrospect, I really regret not finishing the project. Even if in my eyes it wouldn't have been a good game in the end, someone else might have liked it. (And some people already do.) Game jams are not about making a great game, but about making a game. And the experience of that might be worth just as much. I guess I'll still have to learn to from time to time finish a game just for the sake of it.

- Not making sounds. Again. I remember last Ludum Dare I wrote something along the lines of "If everything works as planned, my next LD entry will have at least some sort of noise in it. Promise!" Well. It doesn't. It would have been a good exercise to implement audio into the game, too, but I didn't even get to that stage. I'll really try harder next time. Promise. For real now!


The Takeaway
- Don't give up next time. As one commenter accurately pointed out in response to my game: "Some ideas are just worth exploring, even if there is no fun at the end." Maybe next time explore it some more before abandoning it.

Gamescom 2014 + Facebook

I'll be going to Gamescom in Cologne next week. Two of the games I recently worked on will be showcased at my university's booth: A slightly enhanced version of DYO, as well as Armville, a 2D action platformer yet to be released. You'll be able to play a whole lot of other great games there, too, so make sure to stop by!

This is were we'll be located: Hall 10.2, E011

I'll be there the whole week, and try to be at the booth for most of the time.

Also, since there's not really a comfortable way of following this blog, I decided to create a Facebook page. I'll probably also be posting some work in progress and other stuff that's not relevant enough for the blog over there.

The Floor may not be Jelly - Thoughts on breaking your own game's rules

I just recently played The Floor is Jelly by Ian Snyder. It's great and you should totally play it. I recommend watching the trailer. Not only will it hopefully convince you to buy the game, but it also pretty much explains what the game is all about (so I won't have to bother doing that myself).

The Floor is Beautiful!

Minor spoilers ahead, I guess... (next two paragraphs)

I enjoyed most parts of the game really, but I found the last world to be especially interesting. In this world, the "jelly" of which the floor and walls are made, changes properties every few levels. In one level it's hyper-bouncy, in another one it doesn't bounce at all. I'm not gonna spoil any more, but it gets really crazy at some point.
I loved these sections because they're a great example of how much variety you can get out of an existing mechanic (in this case: jumping around on jelly) without having to add new secondary mechanics. In fact, the last world doesn't use any of the secondary mechanics that have been introduced in previous worlds (e.g. water), and instead focuses solely on the jelly itself and possible variations of its attributes. Granted, some of the sections are less fun than others, some even barely playable, and I personally would have cut out a couple of those parts. Still, in my opinion it manages to be one of the more entertaining and gameplay-wisely diverse worlds of the game.

Also, I very much liked the theme of the world which is somewhat glitchy and pseudo-broken. It fits the gameplay perfectly and I'm guessing this might be a hint as to how the concept for this world came to be. As someone who makes games, you know those moments when you tweaked some variables and suddenly your game behaves in some weird, unintended way. Most of the time, you'll have a quick laugh, maybe even take a screenshot to document this glorious moment, then fix your mistake and get on with it. But sometimes, you might find something really amazing by accident.
Bugs turning into features isn't an uncommon occurrence (e.g. Tribes: Ascend). But actively looking for interesting new gameplay within a working system can be even more effective (and more fun). It doesn't even have to be complicated either. I'm guessing in The Floor is Jelly it was just a matter of changing some constants to make the floor behave in a different way, and yet it allowed for such diverse gameplay.

I would love to see this approach to game design realized in more games: Build a solid working system that can stand by itself. Then, when you think you exhausted everything you could do with it, instead of adding new features, play with the ones you already have. Go crazy with it. Think about possibly interesting "What if...?" scenarios. Then try them out. In case it doesn't turn out to be as fun as expected, you can still always go back to status quo. Either way, you'll probably have learned something from it.

This is actually how the concept for Snake Pit was born, except I took an already existing system and tried to change the gameplay to be something completely different. What if the game didn't end when you bite your tail?
Also, the idea for some yet-to-be-released bonus levels in DYO came to be in a similar way...

What if the minotaurs weren't of the same size?

Tech: "Old Movie"-Filter

Some people asked about a tutorial on how I did the graphical effects I used in Baum. It's really a lot simpler than it looks, so I'm going to quickly go through what I did. Sample code will be in GML, but I'll try and explain it in general terms.

(All of the effects belong in the Draw-Event)

- Make the screen flicker

For this, I just drew a rectangle in a random grey-value and a low random opacity across the whole screen.

// I used intensity to balance how extreme the effects appeared; default in Baum is 1
draw_set_alpha(random(.2*global.intensity));
draw_set_color(make_color_hsv(0,0,irandom_range(100,200)));
draw_rectangle(0,0,room_width,room_height,false);

- Darken the corners

This one is so simple, yet does so much to enhance the mood of a game. I use it in several of my games. Just draw a gradient from fully transparent in the center to a somewhat transparent black on the edges. I used a background, which is probably the quickest and easiest method to do it in Game Maker. (You can download the image I used right here.)

/* Try drawing this before or after the screen flicker, to see how you like it better; I drew this one first */
draw_background_ext(bgrOverlay,0,0,1,1,0,c_black,.8);

- Shake it up

To get even more of a flickery effect, I made every object in the game draw itself on a random position within a small radius (1 pixel) around itself. This makes it shake just enough to create a neat little dynamic effect while not hampering gameplay.

// I used this script instead of draw_self();
draw_sprite_ext(sprite_index, image_index, x + random_range(-global.intensity, global.intensity), y + random_range(-global.intensity, global.intensity), image_xscale, image_yscale, image_angle, image_blend, image_alpha);

- Draw some random stuff

To get some more variety into the flicker effect, I just drew some vertical lines of random position, alpha, value and thickness across the screen. Also, I reused the sprites from my only particle effect in the game, and drew single images from it randomly positioned, colored and scaled on screen. Experiment with different images to create really weird effects. Don't overdo it though, as it can easily distract and irritate your players.

draw_set_alpha(random(.2*global.intensity));
repeat(3*global.intensity) {
       // draw random sprites:
       draw_sprite_ext(sprParts, irandom(5), irandom(room_width), irandom(room_height), random_range(1, 6), random_range(1, 6), random(360), make_color_hsv(0, 0, irandom(255)), .1);

       // draw vertical lines:
       var _rd = random(room_width);
       draw_line_width_color(_rd, 0, _rd, room_height, random(5), make_color_hsv(0, 0, irandom(255)), make_color_hsv(0, 0, irandom(255)));
}

So that's it, really. Have fun experimenting with this. Let me know if any of you found this useful and I might do some more (advanced) tech stuff in the future. Cheers.

Of Bones And Spiders - Thoughts on setting

So people have been asking me about how I came up with the setting for Baum, as it apparently is one of the features that is most memorable about the game.
As I briefly mentioned in its postmortem, this was actually the first* game in which the gameplay was inspired by a general setting and not purely by abstract mechanics. The high concept was to make a game in which the player directs the roots of a tree and has to collect certain things and avoid touching certain other things.
*excluding Mini Tanks, but that's a different story...

When it came to deciding on what these certain things should be in the final game, I mainly took three aspects into consideration and asked myself various questions on each:

- Context: What is the setting of the game? What kinds of object would appear believable in the context?

- Function: What is the object's function in the game? Is it passive or active? How does it move/behave/interact with other objects? Should players perceive it as a "good", "neutral" or "bad" object?

- Visual Appeal: Is the object interesting to look at? Is it easily distinguishable from other objects? Does it draw the players attention? Does it distract the player?

As this was my first experience with explicitly thinking about setting, I'm sure this list is all but complete. Hopefully, it will grow and improve over the course of future projects.


There are not that many objects in Baum, so I'm going to briefly explain why I chose each of them.

Bones
The first decision I made was about what the collectibles should be. They had to be static objects (catching moving objects turned out too difficult) and they had to be underground. Based on that, bones came to mind pretty quickly. I really liked the idea of a tree silently and secretly devouring human remains beneath a graveyard, which was a perfect fit for the creepy mood which had developed over time. I did have some concern about the symbolic implications of bones, thinking maybe players wouldn't want to collect them at first (which turned out to be true). But I decided to keep them anyway and risk players not getting what they were supposed to do on their first try.

Spiders
The enemies in the game also had to be underground, but mobile. Also, it had to be something that would make players really uncomfortable when crawling up their arms. Worms or maggots would probably have been a better fit for the underground setting, but considering the unpredictable movement pattern, spiders made more sense to me. Also, the black silhouette of a spider draws the players attention much more, and makes for a great contrast with the white bones.

Balloons
The balloons came into being mostly because I wanted to use the space above ground in some way and add an additional (yet optional) challenge with moving collectibles. They started out as birds, but I quickly replaced them with happy balloons. My intention was to create a humorous contrast to liven up the mood and make it even more bizarre than before. And players really seemed to enjoy it.