26 Oct 2014

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...

26 Aug 2014

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.

8 Aug 2014

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.

7 Aug 2014

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?

16 Jul 2014

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.

17 May 2014

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.

7 May 2014

Postmortem: Baum

A bit more than a week ago, I participated in the Ludum Dare 29 compo. It's a themed 48h game jam on the internet. This time around, the theme was "Beneath the surface".

It was my second time participating in a Ludum Dare, and this time around I made a game called Baum about a bone-eating tree with hands for roots being afraid of spiders. You can check it out (and rate it) right here, if you haven't already.

Baum

The Good:
Here's some of the things that worked really well.

- Not working alone. I actually met up with a friend and we both worked on our LD entries in the same room at the same time (check out his game cell.erity), brainstorming together, exchanging ideas, playtesting each others games and giving each other feedback. It was an amazing experience and far more fun than going at it alone.

- Not giving up. I actually started out working on a completely different game for the first ~24h before realizing that it was far too complex a concept to be fully realized in time for the compo. I really didn't want to submit an unfinished experience, so I stopped working on it. I was really demotivated. I slept a couple of hours and played some games. At that point, had I been alone, I would have probably given up on this LD and called it a weekend. But I was feeling some sort of responsibility towards my friend. I was the one who talked him into participating - I couldn't be the one who wouldn't have a game to show for it. So I just started over with something completely new.

- Not giving a shit. Really, when I started working on Baum, I was in a different state of mind than I usually am when working on games. I didn't care if this game was going to be the best I could do. I just needed to get something playable done, and quick. So I went with the first most simple gameplay idea that came to mind, and just did it.
Playing as a tree collecting things with its roots? Sounds like a game. Let's do it.
It was a somewhat scary, yet refreshing experience for me personally, and I while I think Baum is definitely one of my weaker works, I got great feedback so far and at least some people seem to really dig it. And in the end, that's what making games is all about for me.

- Incorporating player feedback into the design. Now, at first I had no idea where to go aesthetically with Baum. I usually do very abstract graphics in my games, because I hate (and am very bad at) doing art. This time though, I was actually working from an idea based on setting, not on gameplay, so I didn't want to go abstract with it. So I just did some really crappy placeholder graphics and worked with those. Then, a playtester (we had some visitors throughout the jam) remarked that those slowly moving root-hands really creeped him out. So I went with it and developed the whole style around the idea of a disturbingly bizarre mood, which fit in perfectly with the concept. I never would have come up with the game's look as it is now, if it weren't for that one player who was creeped out by my shabby placeholder graphics.


The Bad:
Here's some of the things that didn't work all that well.

- Not making sounds. Again. This has been the source of complaints in my last LD entry, and it was again this time. I totally understand it, as sound can be a very important tool to give gameplay feedback as well as creating atmosphere. Now, the problem is, I still don't know how to do good sounds, and that's why I never bothered to put any in my games (unless someone else had made them). I am planning, however, to finally get around to learning some audio basics at some point. If everything works as planned, my next LD entry will have at least some sort of noise in it. Promise!

- Not documenting my progress. I'd love to show some screenshots of earlier versions of the game and how it changed over time. I'd also love to show some stats on how much time I spent with what part of the development, how many hours I worked in total, ect. Problem is, I didn't bother to keep track. In retrospect, I do regret it myself, as I'd be quite interested in analysing my workflow.


The Feedback:
Here is some of the response I got from comments on the game, as well as talking to people who played it.

- People love the mood. Most comments I got were not about the gameplay, but the atmosphere of the game. It was a simmilar thing with my last LD game, where people also seemed to enjoy the tense atmosphere. I find this very interesting, considering I never really start making a game with the intent of creating a certain mood. I always start with gameplay, and usually find a tone while experimenting with the mechanics. I'm wondering how a game would turn out where I actually build it around a certain tone I want to set instead. I might try that in the future.

- Confusing visual feedback. Basically, I used the same particle effects when the tree is eating a bone (positive) and when a spider is crawling up its roots (negative). In retrospect, that was a pretty stupid idea, and happened mostly due to my own laziness.

- No sense of urgency. Some people didn't like the slow pace of the game. They missed some timer, or depleting resource to make the game more tense. Also, someone managed to exploit the fact that there is no urgency to essentially break the game and get real high scores without much effort. This one really bugs me, because I think it's a fundamental flaw in the game's design, and one I could have easily fixed.

- The spiders are very unpredictable. Some players didn't like that and said they would prefer it if they would move in more of a pattern, as to enable more strategic planning. On this one, I heartily disagree. I think, most of what makes up the tension of the game, is never being quite sure, how the spiders will behave. Predictable spiders would make the game a lot less interesting in my eyes.

- Some people hate waiting. Some don't. I got both positive and negative feedback on the 'spiders crawling up the roots'-part before the game is over. Some people didn't like waiting until the spider reached the tree each and every time, while others really enjoyed getting a bit of the creeps whenever it happened. Easy solution would have been to make it skippable. Oh well.

- Most people hate spiders.


The conclusion:
LD29 was a blast, I learned a lot, and I made a game about a tree with hands. Lovely!

And Yet It Kills You - Thoughts on falling damage

I recently played through And Yet It Moves by Broken Rules. It's a 2D platformer in which you can rotate the whole world around you to solve puzzles and overcome obstacles. (Go check it out, if you haven't already!)
And while I overall really enjoyed my time with it, there was one issue that really bugged me. Whenever the player lands on the ground a bit too fast, he instantly dies from falling damage.
Now, in other games, players learn to approximate how far they can fall pretty quickly, and can from there on avoid getting themselves killed by it. Unfortunately, it's not all that simple in AYIM.

This is what death by falling looks like. I got to see it quite a lot.

As the player often needs to rotate the world around him mid-jump, approximating any distances beforehand is made relatively impossible. I could often only be sure if a fall was going to be lethal by trial and error.
This was made even worse by how the world rotation is implemented. See, you can only rotate the world in 90°-turns (at least in the PC-version). And while the world is rotating (which takes about 1/4 of a second) your movement is effectively stopped. Once the rotation is done, you get back all your momentum from before, but in a completely different spatial context. As a result, I oftentimes completely lost the sense for my own speed and didn't even expect do get killed by a fall right up until I hit the ground.
To make things even more confusing, whether or not an impact kills you, also depends on the angle in which you hit a surface.

While rotating, time stands still. Not helpful, if you want to keep your sense of momentum.

All of this resulted in some frustrating moments in an otherwise great game, which got me thinking about the design decisions that probably went into this. So, why is there falling damage in AYIM?

First of all, let's consider concept. AYIM is a game, in which a player that can rotate the world around him at will. With only that overall concept in mind, if I were asked what could the main challenge for the player, avoiding falling damage would probably be among my first answers. The rotating mechanic itself being the greatest help as well as the greatest danger to the player, is a genuinely appealing idea to me. Also, if you could just turn the world around at will in real life, your greatest foe would probably be gravity (and maybe motion sickness); it just makes sense.
So I do think, that in this case falling damage is a very elegant and intuitive concept. The question is, however, if the overarching concept is more important than the gameplay. This is, I think, very much a question of personal taste, and of the creators intent, and I won't criticise one or the other at this point. Instead, I will continue talking about this particular mechanic from a purely gameplay-focused perspective.

Secondly, let's consider flow. Falling damage, as implemented in AYIM, very much emphasises a methodical approach to traversing space. To succeed, many jumps have to be carefully planned before execution. Which, together with the environmental puzzle elements (which make up the other half of the game) and the rather obtrusive visuals, set an rather slow overall pace throughout the game. Which I generally do not at all dislike.
The problem, in my eyes, is that the rotation mechanic itself tends to invite a very different pace. I personally enjoyed those passages the most, where I could use the world rotation to just intuitively and efficiently traverse a part of the level, without having to stop and think about my next move. Sadly, those moments were rather sparsely spread throughout the game, mostly being hindered by my fear of falling to my death with every false step.
The game itself even seems to recognise this appeal of a faster paced gameplay in some way, encouraging speed runs and time trials as optional challenges (which, of course, most of the time don't actually work all that well with the mechanics).

Lastly, let's consider level design. This is probably one of the most common reasons (besides "realism", which I may talk about some other time), falling damage is implemented in games. It is an easy solution to a lot of problems. If your level is ascending, you don't want your player to fall all the way back down and have to start all over again. Rather kill them and have them restart at the last checkpoint. If your level is descending, you don't want the player to just jump all the way down and miss all the carefully placed obstacles you left for him. This is especially true for AYIM, where there are no predefined ascending or descending passages, but you can basically just fall in every direction.


Now, I did think about how to solve this problem for quite a while and thought of some possible approaches, but this post is already becoming quite long, so I'm not going to go into any detail on that. In summary, all of my ideas that included fundamentally changing or removing falling damage had some flaw or the other. The only thing that I think would definitely improve the game, would be some changes to the implementation.

  1. The player needs an indicator of his movement speed that is independent from spatial awareness. Because, as mentioned, your spatial awareness gets disturbed every time you rotate. I would probably propose auditory feedback, maybe the wind rushing by louder, the faster you are. 
  2. Maybe not stop time while rotating? I'm saying 'maybe' because I think changing this could have unwanted side effects like even more disorientation. Can't say for sure without playtesting.
  3. Move the death threshold a tiny bit up. Let the player fall that extra half a character height without killing him. Make him not fear for his life whenever he takes a step. I think only a minor change here might make the overall experience much less frustrating. 


In conclusion:
I loved And Yet It Moves. I recommend it to anyone who is even a bit interested in puzzle games, extraordinary art styles, or level design.
I also loved the concept of falling damage in AYIM. However, I disliked its implementation and think it could have been done better with only some minor tweaks.


PS:
This was originally going to be a post mainly about falling damage as a general game mechanic, with AYIM only serving as a starting point. I guess I got a bit caught up in the matter. Maybe I'll do the general thing some other time.

1 May 2014

Hello World!

So I finally decided to start my own blog. Oh boy...

I guess I should start out by introducing myself. My name is Josia Roncancio. That's quite a mouthful though, so on the internet I usually go by the name of Waterman7. 
I have been making small games as a hobby for some time now, and about half a year ago started studying game design at a university in Berlin. That should be enough for now, I will probably go into more detail about myself and what I do at some later point.

In this blog, I will share some of my thoughts regarding games I work on, games I play, game design in general, and anything even remotely related. Let's hope this actually works out as intended.

If you haven't already, go check out some of my games over at http://w7games.bplaced.net/.

Cheers,
Waterman7