Tag «Unity»

Ludum Dare 35: Wood for the Trees – Post Mortem

Wood for the Trees is my entry for the 35th Ludum Dare game jam which took place in April 2016. For now I don't know how the other participants will rate the game, as the voting is still going on. Yet it's maybe time for a small post-mortem, especially as my last few entries were not really worthy for one of those.


The theme of this Ludum Dare was "Shapeshifting", which was a good theme, or at least I heard far less complaints about it than usual. For my part I didn't have an idea from the beginning - or rather I prepared several in advance, but none of them actually motivated me when the weekend began. For some time I just ignored the theme anyway and did some physics-based experiments, but everything of that was scrapped in the end. Semi-inspired by the theme I then went on with an environmental experiment, which would be about looping and changing level tiles. A bit like our 7DRL Me against the Mutants, but this time in 3D. As usual I did all this in Unity.

My base idea was to have tiles as parts for the level map, and each tile would be 10x10m (conveniently the size of Unity's standard plane), and instead of connecting the tiles in a linear fashion or even in a grid, I would define the connections manually so they can loop or have "impossible" connections. This way, a tile could be connected to itself (this actually happens in the game)! A lot of time went into developing the system of instantiating and destroying the needed game assets on the fly.


With this representation of the game world it's possible for the player to see things that won't be there when they move. Thus I added smooth scaling to all objects when they get spawned or removed, just to make it more appealing and let people accept this strange environment. This system also imposed some limitations which actually turned out to make the game tighter and more focused:


1) The player is allowed to move only from a tile's center to the next, in cardinal directions. At first I had free movement, but this imposed problems with the tiles that lie diagonal to the current one. It would just feel alien. Restricting the movement was the only solution, and it also made the gameplay (adventure game) much more clear.


2) With my system it only made sense to display 3x3 tiles at once, thus I had to limit the view distance to 10 meters. This made me a bit depressed in the beginning, because it meant a pretty big, boring wall of fog in front of the player. But then I invented the "fog trees" - trees that would exist only in the fog, vanishing when the player comes near. In the end, they really helped making the distance fog less boring and even gave the game its name.

As usual I experimented only regarding gameplay mechanics, but as soon as I added the fog I naturally began to design the game's appearance. The fog had to have a colour, so I chose one I actually liked. Everything else had to look (more or less) good from now on, which helped tons with not having to do that later. If I remember correctly the pixelation post-effect shader was added at the same time, and I just liked it - I don't really have a justification for it. But it also helps to hide the fact that my 3D models are all very low-poly and have no textures.


By the way, this is the first time that I used Blender for a game jam; I like it more and more. It fits my style quite well I guess. For the trees I utilized a tool called HappyTree by Sol_HSA, which made it easy for me to generate four different trees and reuse them all the time. I only changed the materials.

The narrative structure of the game also developed more or less naturally: due to the fact I played some "walking simulators" beforehand I was okay with incorporating a personal story. So all content grew out of certain relationships that occupy my mind often enough. As a result it didn't become a straight story really, but more like a set of emotions I wanted to share.


I didn't plan to do a full puzzle game, but somehow I actually added enough elements like finding typical items and having to combine them, so I can now call it an adventure game without shame. Overall it's a simple game in the sense that I didn't even add a visible inventory (as it wasn't needed), but thanks to the shifting environment and the somewhat allegorical hints the game should be longer than just a few minutes.

You could say the background story and the adventure game mechanics are somewhat contradicting or at least exist in parallel only. But whenever I think of my childhood (which the story is touching), I have certain games in my mind which I played back then, and Wood in the Trees actually recreates them in an abstract way. Furthermore, the seemingly mundane tasks represent the protagonists quest for absolution somehow. The mechanics and plot combined with the fog trees, the game's name, the colors and some of the objects in the game, it all is symbolic and it's okay that only a small percent of players understand them fully.



Right next to creating the world system in Unity the hardest part of the game was actually planning it. I'm never big with story (something I really have to train), so I just wrote down a lot of things I'd like to say. Not everything made it into the game. And I laid out the puzzle progress on paper as soon as I decided that I would actually have puzzles. But only by actually implementing them I'd see if an item would make sense or not and from time to time a whole path was changed - thankfully always for the better.

Unfortunately I was not able to follow my initial plan to make the game within 48 hours ("Compo") and had to extend to 72 hours ("Jam"). I never felt that I would actually be able to finish it, which send me to a rollercoaster of emotions during the game jam - either I was relaxed and had a "it's okay, I don't care" attitude, or I was angry at myself that I would fail at Ludum Dare yet again. I'm still surprised I actually finished - and it sure helped that for the Jam I didn't have to create my own music. I suck at this still, and don't stop hoping this will change some day. Instead I used a track by my brothers, which they composed many years ago for a game prototype Jana and I made in university. It fits the game well enough and actually adds to the symbolism of Wood for the Trees.

A monster?

After several days between me and the development I can now think about the game again. In hindsight I would change a few things, especially as players rightfully complained about those. Being able to re-read the notes and texts would be a great addition, and probably easy to do. Not removing the notes in the game would be a good start for that. Moreover, the hit boxes for the clickable objects are sometimes to small, and generally it's not clear enough if you can interact with something or not. I would add a few more descriptions to some elements in the game, and also tweak the controls so they would be easier to understand. And I would take extra-care that players find the solution to the first puzzle easily. Last but not least I'm disappointed I couldn't add any sound effects - not even some step sounds!

If I find time and motivation, I might do these changes and upload a post-jam version.


In any case I'm happy that Wood for the Trees already got some media attention - AlphaBetaGamer made the start (with a title optimized for SEO a bit too much), followed by WarpDoor, PC Gamer and Killscreen. Wow! It shows once more that pixel games - even fake ones - are the way to go I guess. And I visited the A MAZE (a festival for indie games in Berlin) a few days after Ludum Dare, so I even made an Android build of my game. It ran very laggy and the controls weren't working correctly, but it was cool to actually being able to show something when talking about it. Even though I didn't show it around that much I had a lot of fun - the fruits of productivity.


If you're a participant of Ludum Dare 35, you can rate Wood for the Trees here. In any case, the downloads can be found on itch.io - have fun!

And here's a video - be aware, it's the full walkthrough, so of course it contains spoilers:

Ludum Dare #35: Wood for the Trees (Full Walkthrough)

Be aware that YouTube videos try to set cookies and contact Third Party servers!

Ludum Dare 25: Tale of Scale – Post Mortem

On December 15th, Ludum Dare 25 started. As usual, this 48h game making compo was an interesting experience, as exciting and awesome as it was soul-crushing. But this might be just me.

Like before, I didn't have the right idea for the theme. This time it was "You are the Villain", which was a better theme than usual, but unfortunately it only triggered gameplay concepts for me which all belong into the "that was already made before" category. So the first thing coming into my mind was "Dungeon Keeper", and as much as I'd like to do a game similar to this awesome piece of gaming history, it just would be a clone without the right amount of innovation (or would it?). Among the other ideas I had were a "Pirates!" roguelike, a game where you control four bandits at once (robbing innocents and wandering around) and a board game creator where you're the dungeon master placing the monsters (think "HeroQuest" or so).


None of these ideas were the incentive for me to actually start developing (although I still like them). In my mind, I combined them, added features and the result got bigger and bigger, and after finally deciding that it would be too much of a hassle, I started at zero again. Then I came back to a thought I had days before, namely the thought that often, good ideas for games (mostly puzzle platformers) are those which are inspired by childrens' fantasies. So I imagined a bit what a child could think, and being able to grab the moon with the fingertips and move it around just like that, well, that seemed like a good candidate. At this point, the theme was still in the back of my head, but I tried to ignore it mostly as it obviously would just hinder me to actually develop anything. I never was good in the "Theme" category, and for that I'm sorry, but I don't think it's the category I want to shine, really.

I tried to create a Unity3D prototype out of that idea with the moon. Of course, prototypes become the real game eventually when doing a game jam, but first I wanted to see if I could actually create something like that. The main problem to begin with was the scale of the object currently grabbed, as it always has to be the same size for the player, no matter how far or near it would be away. I read something about the focal length of a camera before and I thought I had to factor this in in any case. I experimented (using some basecode I already announced in my "I'm in!" post) and searched on the internet, but it just wouldn't work right. The object's subjective size didn't stay constant, and being very frustrated, I stopped after a while.

Thus, I re-evaluated the idea of the four bandits. This one would follow the theme and I'd really like being able to control a group of (evil) adventurers - in first person perspective! In order to make it easier for myself, I started programming the movement (again in Unity3D), which would be along the cardinal directions only and also on a grid. Just like those age old games you might know, "Dungeon Master", "Eye of the Beholder" or "Legend of Grimrock". In the end, the movement worked somehow, and you could add NPCs to your party, and press a button to see all four viewports at once. Probably I could have made a more or less full game out of it, but at this point I didn't see how I could add "fun" easily and I stopped yet again.

prototype 2second prototype, no fun

With the thought of fun being the most important part of it and without really expecting any results for this Ludum Dare anymore, I got back to the first prototype, and suddenly, the old problem was gone. Thinking about the focal length was a dead-end, and just getting rid of it was the way to get it work. The only problem now was the collision detection of an object that would get bigger the further it goes. Using Unity3D's SphereCast() was the wrong direction, because the size of the collision sphere would be always the same. So now CheckSphere() gets called with a gradually increasing size of the radius parameter, and it does that a lot of times every frame - because of the simple nature of the rest of the game, this was possible without any noticable performance hits (at least on my computer). Of course, this means that every object basically has an additional bounding sphere, and that's why most objects sometimes don't behave as expected, especially those which don't have uniform dimensions.

prototype 1first prototype, working

I uploaded the first prototype of the game - just a simple demonstration of the gameplay - late in the night, and those who actually started it and "got it", said it could be awesome. Yay, motivation! Also, I earned myself some sleep. The next day I "only" had to make levels and fix any occuring bug. Also, story. Also, sound. Also, ...

I planned five levels at the beginning, and because of some very sad events before Ludum Dare, I didn't think about it too long when I realized that I wouldn't have time for all of them - as one of the levels would had have a kindergarten setting. So, three levels were made (in 3dsmax), and they describe how the protagonist is a kid with just an overly active imagination, and how this leads to an unfortunate outcome. I didn't have time for more, and the ones I made aren't really balanced/tested, so I am sorry for that. On the other side I am just relieved that the main gameplay works and can maybe be the foundation of a cool game; the Ludum Dare version of the finally named game "Tale of Scale" is mainly a sandbox game which happens to have a subtly communicated goal in each level.

2the end result: Tale of Scale

A short summarization of What-Went-Bad:

  • The start, or rather the theme. Either it is the start of a game for me, or it just stands in my way. Harumph. I squeezed the theme into the final game, but as most people won't play it through, they probably will wonder where it actually is. I got a bit inspired by the movie "Looper".
  • I still can't make music. I tried composing some once or twice before, but I'm always embarrassed by my own efforts, so I don't ever get over a certain point.
  • I don't have a cool base code which actually would free me of the burden to do some stupid and boring stuff again and again. At least that's a learning and can be helped ... some day.

And What-Went-Good?

  • The idea was cool enough to let people ignore the crude levels and graphics, hehe.
  • I actually managed to make three levels, even in the timeframe I wanted to make them. Seems like I finally get the hang on estimating such things, and this is one of the things a game jam really can help with.
  • I made most of the sounds myself with a microphone, and they sound okay enough. Nice.

That's it! Thanks for reading, and don't forget to play the game (here's the entry page) - or at least watch this gameplay video:

Ludum Dare #25: Tale of Scale

Be aware that YouTube videos try to set cookies and contact Third Party servers!

#04 – TRI – Play-testing and a dogma

Just 1.5 weeks and the TRI pre-alpha plus demo will be out! This means testing, testing, testing. This article is about what makes TRI so special and which problems it breeds, too.

Typical pre-alpha problems

We decided to make TRI as early available as possible. Not only to fund our development, but also to get feedback for game design decisions we made. To provide a smooth pre-alpha experience in this early state of development, we tested as much as possible.

Here are some thoughts I had on game design elements and a certain dogma we developed over the time.

1. "What is the goal of this game?"

The biggest problem we faced in our pre-alpha was motivation and a clear main goal, which is mostly the same thing. The main goal is some kind of McGuffin which triggers the player, like “Rescue the princess!”. It is not really necessary, but with it you can build a chain of suspense – as soon as the player reaches one spot, lead him to the next one ("Your princess is in another castle!", haha). This could be the motivation.
But more important for me is the flow that happens when you fully become one with the gameplay. Which was enough for us playing around, as we knew what the game is about. We had a story in mind, but totally focused on gameplay. Because of that at some point the testers wondered what the game is about and what they're doing.
Our early testers started without knowing who they are in the game, where they were and what they should do. Amnesia? Shouldn't that be enough to just find out what's going on and explore? … no!
Although the starting area is linear and very streamlined, people need a certain motivation – where they are heading to and why. Some kind of progress bar with story.

Although gameplay alone should be enjoyable, you might give the players some starting mission/quest/task to let them know where they are heading to. This keeps up motivation and helps finding a way through dead ends (and even recognizing those dead ends).

Character reading scroll

2. Feedback and rewards

Implementing sounds is very often the most neglected thing about games. Just adding walk-sounds give the player the impression she really is 'in' the game, first of all in a game where you can't see the character you are playing.
But there are also feedback sounds that are really needed because of our puzzles. Switches, doors, laser beams and little ghosts (Kami) appear repeatedly. Without sounds people often don't recognize that there is something happening at all. Or that a certain element changes its status (from open to closed, activated to deactivated).
Even if the sounds you have at the beginning seem shitty, you should implement them to help your players.

Another feedback is light or markers. In our game we have special switches to open doors: you have to assemble crystal holders with a crystal to guide light rays through them. Which means they have three different phases of activation: 1. The crystal is just lying around (no light). 2 The crystal gets a bit illuminated after combining it with the holder. 3. After sending a ray through it, a sparkling particle effect appears.
In the early tests players put the crystals into the holders, expecting that this was enough. But we want more from them - activation through the light rays!
Those mechanics enable some fun puzzles, but also needed proper feedback in the game to tell the player that there still is something to do: there is an empty pedestal – find a crystal and put it on the pedestal – AND activate the crystal via a light beam by deflecting it – only then a door opens or so.

Give objects as much feedback effects as possible. Sounds don't just add atmosphere, they are often necessary to communicate progress. Of course, without stupid flying cameras showing the goal or pop ups informing you about your next target.

3. Design of game objects

As you might have read, our game is mainly inspired by games like Portal (puzzles, first-person mechanics), Thief (level design) and Zelda (puzzles). Although TRI uses typical game elements like levers, doors, switches – things to activate and deactivate, we have the entitlement to integrate these game elements as naturally as possible. Which means that they shouldn't blink spastically or permanently rotate around themselves, but players still should immediately recognize which elements are those to interact with.
This was and still is a great task for us. Portal, for example, used huge switches on the floor plus stripes that lead to the doors they activate. Those game helpers are extremely clever, but also very clumsy. (You can get away with it, though, when you call your levels “test chambers”.)
It is always a challenge for game designers to combine a reality the game tries to create with game objects that convey rules.
Modern games disappoint me, primarily the photo-realistic ones, which try to re-build reality with floating weapons waiting for you to grab them and huge arrows darting in the direction you have to take. Less seems to be never enough, sadly, but it is our duty to find out what is enough for players, before using clumsy out-of-the-world game objects like giant arrows.

crystal holder
4. Non-linear versus linear

Something that most of our games have in common is a certain non-linearity. This means that our level design or decisions a gamer is able to make will always be as free as possible. We hate invisible colliders, tube-like levels and decisions that unnecessarily limit your creativity. This sounds cool, but is also very ambitious and hard to convert into gameplay. Particularly when gamers these day start loving their tubes.
With TRI we try to master the balance act of free choice and leading level design. How accessible do we want the game to be? How many elements should get activated automatically?
We decided that creating your own platforms wherever and whenever you want should be enough non-linearity, at least at the beginning of the game. Because it is important to understand the game and its basic elements without too much distractions, the layout of the first few levels is still fairly linear.

The look of game objects and the decision whether a game is linear or not, is determined by your choice of target audience. Casual players with not too much time and experience – or people that love to dig deeper to explore a game? I would love to see the players start the game and explore on their own, find out what is possible and search around. But players today are spoiled; most games are extremely streamlined and guide you through some interactive scenes without the need to think. With TRI we hope to be able go into the opposite direction.

TRI Demo level

Any other difficulties?

Making a 3D game that uses physics leads to problems which you might consider before deciding whether to use a physics engine in your game or not: Often, physics are great. It always means lots of fun and more interaction possibilities. People love dragging crates and barrels around. It's a sandbox game of its own.
But physics always need more time and effort to implement: every physicalized object demands special adjustments, like mass and drag, or the rock over there doesn't feel heavy enough to be really a rock. Yet there might be collision and performance issues. In our case, the combination of physics with the triangle creating feature (the 'TRIs') multiplied these problems.
Static objects are always easier to handle. You should ask yourself if sophisticated physics are really necessary for your game. Integrating a physics engine not only as a mere decoration, but as an important part of your gameplay leads to an even higher error rate. Especially when objects start to fall through floors instead of neatly landing on them. And you never know in which situation players leaves a room full of physical objects after toying around ...

For us, 3D is the most immersive form to play and build games. The third dimension opens tons of possibilities 2D will never have. (And doesn't want, of course.) But as always it also adds difficulties to the game design.
While 2D games look timeless mostly (but often typical indie 8bit-like), you always see in which era a 3D game was made – often enough, which engine was used. I still love the look of Thief 2, but how many people out there still appreciate low poly and abstract graphics?
The art style, especially for small teams, is harder to create. Even though you are indie, players will always compare your game by AAA standards. Photo-realism is the most common way of designing games, although it's the most boring form of expression, too. Building abstract or fantastic looking worlds is more difficult in 3D than 2D.

TRI - Early Alpha Footage

Be aware that YouTube videos try to set cookies and contact Third Party servers!

So many things to fix and prepare before you can take a look at it and TRI the game! Meanwhile you can read more about the game now!

#01 - First look on TRI
#02 - Creating the look of TRI
#03 – TRI – Doing the big Reset