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.
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!
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.
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.
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.
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.
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. |
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. |
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.
- 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.
- 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.
- 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
Subscribe to:
Posts (Atom)