Postmortem: 2016

Now that another year is over, I want to take the chance to look back at some of the games I worked on in 2016 and what they meant to me personally. So let's get right to it:

Snail Trail (January)

Made for the #screensaverjam on itch.io, Snail Trail has you watching a snail really slowly crawl across the screen and hopefully towards some unknown goal on the right. It's some of my more conceptual work, and looking back at it, probably my personal favourite of my releases this year. Exploring how to make a game where the only interaction is ending it was certainly an interesting challenge and I might revisit it at some point.

Tanks Ballet (June)

Tanks ballet is a game about driving an ever-growing number of tanks at the same time and trying not to srash them into one another. My main focus with the project was to explore a more sophisticated visual style for a change. Graphics tend to be an afterthought in most of my projects, and I mostly try to find ways to avoid painting at all cost. Or at least find a stylistic excuse for not putting too much effort into it. 

With Tanks Ballet I wanted to see if I can actually can come up with an interesting and pretty artstyle without limiting myself to 'only if I can draw it in two minutes (or generate it via code)'. So I came up with the game's one-bit aesthetic. And I really fell in love with it. It was more complex than most things I had done before, but still fairly fast and easy to produce good-looking results in. I liked it so much, I'm using a very simmilar style in my current card-game project (More on that further down).

I'm generally not that confident in my drawing abilities (hence my aversion to it). But this was the first time I felt like I actually found a style that I enjoy and feel comfortable working in. I'm not sure how long it will take for me to get bored of it, or if I ever will. And I have been thinking about whether or not I even want to develop a certain recognizable visual style instead of experimenting with new ones for each game. I don't know. We'll see. Until then, I'm rediscovering how much fun digital painting can be.

Loco Motion (August)

This one came as a real surprise for me. For Ludum Dare 36 I made Loco Motion, in which you draw wheels on a physics-enabled vehicle and watch it try to beat an obstacle course. The game didn't get too much attention upon release, just the usual amount of people finding it mostly through the Ludum Dare site. That is, until I submitted it to be part of the Good Bundle. The Good Bundle was a big indie game bundle for charity that got some attention among the indie gaming community. And with that, Loco Motion got some attention too.

On the bundle's launch day alone, Loco Motion got over 500 views, which is more than most of my other games (except 2) currently have in total. At the time of writing, it has over 5000 views and almost 1000 downloads. Now, more than a month later, it still gets around 20-30 views a day. (For comparison, DYO currently gets around 5-10) These numbers might not sound like much, but I only have the frame of reference of my own games. And compared to those, Loco Motion was huge.

Which was weird for me, because I myself don't think it's that good of a game. I think it's lazily designed and has no real depth or interesting mechanics. For a while, I was honestly a bit anxious about this being my most 'successful' game yet. This wasn't the game I wanted to be known for.

Then in December, I got the opportunity to show the game at the AMAZE X-Mas market (thanks to BerlinGameScene.com). It was the first time I publicly showed the game and saw other people play it. And they loved it. It was amazing to see that many people genuinely enjoy themselves playing my game. This made me realize that even if a game doesn't mean that much to me, it can still bring joy to someone else's life. And for me, that alone is more than enough of a reason for it to exist. So I guess in a weird way, Loco Motion accidentally became the first game I made for someone other than myself. And I'm fine with that.

Loco Motion at the AMAZE X-Mas Market
(Photo by Lorenzo Pilia)

Players shared their creations
(Photo by Lorenzo Pilia)

0h (October)

I made this as part of the #0hjam, which is an online game jam that takes place in the one extra hour between daylight savings each year. I liked the concept of the jam, so I extended it into my game; you can only play it during the same daylight savings hour each year. Can't really say too much more about it, since I don't want to spoil the experience. You'll just have to wait another 298 days to see for yourself.

behold the cryptic (December)

For the last Ludum Dare, I teamed up with Ooku (who makes really cool games and music; go check him out!) and we made a weird little game-thingy. We had never met or worked together before; he just wrote me a mail one day because he found me on itch.io and asked if I wanted to do a collaboration. So we did.

The game we made is simple and weird and far from perfect, but I still like it very much. Primarily because it has so much personality. It plays like a mixture between two different game making styles and if you look closely, you can definitely see the influence each of us had on the final game. To me, that makes it super-interesting and likeable.

I have to admit that I tend to be a bit wary of working with people I don't know very well. I think it's mostly because I'm afraid that I might disappoint them. It's a fear I've been actively trying to get over, so this was a big step for me. And it worked out great. My plan is to see if I can get to work with a different person on each Ludum Dare from now on. 

So if you're reading this and you'd like to make a game with me, don't be shy. Seriously, just hit me up. I don't even care about your skills. Let's just have some fun and make a thing together!

Cocktail Mafia (in progress)

Cocktail Mafia is an analogue card game I only started to work on pretty recently. It's a party game in which players invent actual cocktail recipes and try them out. This is an interesting project because it might be my first game that's intended to not only be fun, but also an exploration of certain social dynamics. Balancing those two aspects might turn out to be a difficult task, but I'm looking forward to the challenge. Also, noone has played the game as of yet, so I'm really excited to start playtesting and see how people respond to it.

DYO (in progress)

Yeah, this game is still in development. Initial plans to release in 2016 didn't turn out to be realistic with most of the team currently working full-time on other things. I'm pretty confident that we'll get it done this year though.

We got to show DYO at AMAZE, which was pretty cool. And shortly after, we released a free demo. It has also been shown on some other events in the US and UK. It's great to see the game starting to get some attention, and I hope that we can deliver on everything people are now expecting from us.

Needless to say, this project is currently the most important one for me personally, as it's reception will probably have quite a big influence on what I decide to with my life once the game is finished. Regardless of that though, it's also a project that I'm super proud of starting and bringing this far.

In summary:

I think 2016 was pretty good.

Tech: Split screen merging in DYO

As you might know, I'm currently working on a game called DYO, where the main game mechanic is merging two halves of a split screen together at will to manipulate the level's geometry. Which looks something like this:

Merging and splitting screens in DYO

The first thing people from a programming background tend to ask about is how the screen merging actually works. So that's what I'm going to talk about in this post.

Choosing an approach

So when I started prototyping this mechanic, the first essential question was how to conceptionally approach merging the screens. I knew what I wanted to happen on screen, but what should happen behind the scenes when the screens were merged?

I could think of two options:

- Actually temporarily merging the level geometry
which I imagined to be the cleaner and more versatile solution, but would require a lot of work up-front

or

- Having players "teleport" between the two screens each time they cross the border
which would be easier to implement, but might also offer less possibilities

Long story short, I went with the teleporting approach. Not because of laziness (at least not primarily), but because I wanted to have a playable prototype as quickly as possible, so we could see if the mechanic would even offer interesting gameplay possibilities. DYO was originally intended to only be a one-month project and I didn't want to waste too much of that time before we even knew if the concept worked or not.

In retrospect, I think it was a good decision. I had a rough prototype working in a day, which allowed the team to start refining the concept and working on assets pretty early on.

This is what a merged screen looks like ingame

And here is the actual level layout behind it

Handling colliders

The main problem with the teleportation approach was properly handling collision detection when players approached the screen border. Simply teleporting the player as soon as they crossed the border only worked as long as there were no walls near the split screen border. There were two main cases I had to account for: 

Two possible collisions that complicated teleportation

- Ignoring collisions that were outside of the camera viewport (1)
In the example in the picture, the highlighted collision has to be ignored, otherwise the player wouldn't be able to walk across the screen border.

- Predicting collisions that would happen after a teleport (2)
Before letting the player getting as far as to teleport, I had to make sure the space he would teleport to would even be free. Otherwise he'd be stuck in the terrain upon doing so. (Or, like in this example, he wouldn't be able to stand on certain ledges)

At first I tried to just hard-code exceptions for both of these cases (once again trying to save some time with a messy solution), but that really didn't work out very well. Especially once we started to introduce pushing and other more complex mechanics. In the end I went with the probably most obvious solution of using two seperate colliders as soon as the player started to intersect with the screen border and scaling them according to the player's position.

The most straight-forward solution: two colliders

This approach worked out fairly well. I had written all of the collision handling from scratch anyway, which made it a lot easier to implement this dual-collider setup. 

I feel like going into any more detail on the topic would probably not be all that interesting, so I'm going to leave it at that. If you have any more specific questions, feel free to contact me. Also, if you want, let me know what you thought about this post and if it was interesting to you. I don't usually post about tech stuff and I'm honestly still a bit unsure about how to approach these properly.

Cheers.

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?