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

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.

TRI is a game with a long story, so I won't even attempt to remember every detail. Instead, I will write down what comes into my mind. This way the following article might be a bit inconsistent; I hope it's still an interesting read.

The story begins in April 2011, when I participate for the first time in a big Ludum Dare event. It was the 20th Ludum Dare, with the theme "It's dangerous to go alone! Take this!" (a quote from Zelda) – but the theme didn't really matter, as I got the idea for my entry the evening before. I was inspired by working with 3D modeling software, where you create and manipulate polygons, and I thought: how could I use that for a game? Good thing the eventual Ludum Dare theme kinda fit – I just equipped the player with a "Tri Force Field Gun" (the "this" for the theme), and TRI was born, where all you do is creating triangles to walk and jump on them, and solve a few puzzles.

My entry was kinda successful: I submitted it to the Compo, but eventually switched to Jam, because I copied a character controller from the Unify wiki (as Unity's inbuilt one was too wonky). The Jam worked a bit differently back then, so my entry didn't receive any ratings. But PoV featured TRI in the results announcement post, and people who played the game (the community of Ludum Dare, and players on Kongregate) liked it well and some even asked for more levels.
A few months later, in October 2011, we were searching for a cool new project. Somehow we convinced ourselves that we could create a full version of TRI within a few months, which of course was very naive. We actually already made twocommercial games back then, but as those were done in a much shorter timeframe and were for mobile only we still underestimated how hard it is to make a full-blown game with individually designed levels, somewhat complex gameplay, physics and a story-line. Also – and this was the worst part – a lack of clear direction (due to missing experience) hindered a straight development, and so we changed the design several times before TRI became the game you can see and play nowadays. Of course, we learned a lot during these three years, but I often wish we would have learned this stuff faster.

TRI was made by Jana and me, Friedrich. Jana created the visuals and most 3D models, while I programmed in Unity/C# and also made the GUI. We both created the levels and searched for and worked on the sounds. The music was composed by my brother Ludwig.

It is still funny for me how each department is received extremely differently by different people: some love the graphics, some find them bland. Some adore the gameplay, some think it's clunky or just headache-inducing. Some bought the soundtrack, some just found it repetitive. I know that tastes differ, but as most feedback nowadays comes from official reviews, it's just silly how one piece of opinion claims that our levels are "not convincing" while the other describes them as highly genius.

But yeah. A lot of reviews miss the "polish of Portal" in TRI, and I can't do anything else than concur. We are a two-man team, still learning, with a fraction of the budget of Portal. I guess the secret of success is to hide such facts as well as possible, but I don't know how. So the biggest learning for us: we won't do anything this big again soon. At least we shouldn't.

We even had to take breaks during the years, because of interfering contract work, or just because we had to take some time off. Both didn't make development any shorter, and if Rising Star wouldn't have approached us to give us some funding and a deadline to kick our asses, we probably would still work on TRI (or having a break from it).

In reality, TRI was a good project for a small team, as the game has a narrow scope: the main gameplay is about creating triangles, and almost all of the other mechanics somehow work with this mechanic. For example, there are light rays, and you can reflect them – with the triangles. And you can walk on the walls and the ceilings – thanks to the triangles. There are also some basic physics puzzles (dropping crates on platforms and so on), but the physics are built into Unity. So how did TRI become a "too big game"?

By not being absolutely clear about the game's direction.

One indication for this is the game's story. We wanted a background story from the beginning; the original TRI has one, although fairly simple and only communicated via texts on walls. And yet it added a big portion to the package – so we still think some kind of narrative is necessary as a hook. Just think of how showing triangles would be boring for reviewers and YouTubers. This is why we needed some characters in the game. Unfortunately our story changed a lot during the development, or rather: the whole design and with it the story. From a sci-fi setting with a mad professor and a fantasy story with an alchemist, to the now present fable about a Monk and a Fox. This last iteration of TRI's plot feels a bit tackled on sometimes, and really you can still complete the game (hopefully) even when you skip all story bits (hopefully not). So it's there to entertain, but the narrative sadly isn't an integral part of TRI.

The most problematic thing was that Jana and I never fought over what TRI actually should be – at least there never was a clear winner. Jana was all for making a game about atmosphere and looking at nice architecture. I on the other side was totally focused on the gameplay, and how there should be a lot of puzzles, because I feared people would be bored otherwise.
This way TRI became a game with two souls – there are parts that are mostly about the design, and parts that contain a lot of riddles and obstacles. Thankfully it doesn't feel too much like a game with multiple personalities because Jana added her personal touch to each level after they were done by adding the textures and decorations. And fortunately the Monk and Fox also help to string them together, at least in my opinion.

Nobody ever complained about the sound design – apart from our very own voices for the climbing. Still, this fact is kinda great because although we actually tried to hire someone to make sound effects, the deal didn't come to place and we found our best partner in freesound.org – really a great resource for indie developers. Most of the sounds actually were done within a few days. Sound design may be something that we still neglect, but TRI didn't focus on sounds anyway, even though we wish we had time to create atmospheric "sound carpets" for each level, because sometimes everything is silent and nothing happens, and it then feels a bit too lifeless.

Although we normally tell everyone that the game was released on 9th October 2014, we actually put TRI online for the first time in June 2012, as a "pre-alpha", which was a stupid description. We renamed it quickly to "alpha", and a bit later I also tried to get rid off the version numbers (like 0.3.0) which always were low and unattractive, by replacing them with something cooler: code names! The next version was then "MagicalMonk", which sounds much more confident.
These early-access versions (purchasable via our website and Desura) were not very successful in terms of sales, but we actually never did much marketing for them. We rather tried to get feedback from people interested in the concept and art style, by pre-selling the game for a low price and adding a survey at the end of the game. The later versions even included the possibility to give direct feedback via an inbuilt form. (Thanks to Jedi for the idea!) This was great, because people could send us bug reports or suggestions together with a game save. And it was a solution for our QA problem – every game needs testers, and this way everybody can be one!

In October 2013 we submitted TRI to Steam Greenlight, and some months later it was finally approved by Valve. It also made a lot more people aware of our game. But unfortunately Greenlight was a better marketing tool when it started in 2012. While the first batches of greenlit games were celebrated by the press, this effect became non-existent, thanks to the countless, bi-monthly batches with 100 titles approved at once – and TRI was part of one of these, in February 2014.

It was like winning $20 – nice, but absolutely underwhelming. On the other hand we're a bit proud of being greenlit before TRI even reached the Top 100, although I am not sure what exactly that means.

Anyway, at least we're on Steam – and as the saying goes: “be on Steam, or don't be”. A little anecdote: to be visible to curators (the new thing on Steam) we had to rename TRI, as the name was too common (think “Counterstrike”) for the search form to work, as it relied on auto-completion only. This is why TRI is now called “TRI: Of Friendship and Madness” (Jana's idea) almost everywhere.

Overall we are happy with the reception of TRI: more reviewers than I would have expected like or even love the game, and our Steam user score is pretty high – as of writing we have 30 positive and only 2 negative reviews, resulting in 93%. Yet, the game is still missing visibility – Steam, Greenlight and reviews alone don't do that for you (anymore). We need more YouTubers with a high amount of subscribers, playing the game on their channels. And probably some sensible discounts, as it seems a lot of potential buyers are just waiting for the inevitable XY% off sale. I can't even blame them: with so many games on my backlog, I do the same with most new titles.

What can TRI offer you? It has 16 levels created by our hands, 5 different "worlds" each with a different background music and a new look, two animated NPCs, all degrees of freedom, and unlimited triangles. You conjure these to overcome abysses, to block and reflect light rays and lasers, and to walk on the walls and the ceilings. A lot of areas can be approached differently, depending on your own play style. Even some of the puzzles have more than one solution, and I sometimes see people solving them in a new, unique way. There are very open levels where you can fall into the void, and levels with a lot of narrow hallways. You can jump, crouch, climb, run, carry crates around and use levers.

Before we began to create "Me Against The Mutants" we had other ideas for our 7-Day-Roguelike Challenge entry. All a roguelike needs is a turnbased gameplay with a walking player and some enemies – and then you add things. Things like different zones, the ability to break walls, end-bosses, etc.

So our first real idea was about a prince who has to be protected by several amazons. You would play the whole group, and while amazons are good at fighting, collecting items and other stuff, the prince would be a whiny weakling with no skills at all. But as soon as he dies your mission fails, so you'd have to use the amazons as his wardens.

We liked this idea very much, but unfortunately it transformed into a full 7-day-roguelike and even beyond, and we had to plan for something with a much smaller scope.

We knew we wouldn't have much time during that week, so after some rethinking we scratched the concept and went for a simpler approach: the player is in a world full of radioactively contamined mutants and has to use "infinity fields" in order to reach places and get rid of enemies. Why was that easier? Because it means focusing on a single gameplay mechanic (the infinity), which we invented a year or two ago but never used it for anything. This way, we could concentrate on the basic mechanic of roguelikes not just by making a simple clone, but rather by adding something new to the genre which hopefully doesn't need so much work.

Of course, it was much work and there still were problems. No matter how small the focus of a game is, the whole thing at least needs some time to become an actual game. However, the technical hurdles of "Me Against The Mutants" were bigger than anticipated. Even though I already tried the infinity mechanics via smaller prototypes, I never implemented it with entities other than the player. When all the tile-based movement of the player finally functioned inside an infinity zone, it became clear that the current implementation would not work with the enemies. A big modification of the code was necessary, and for some hours I even lost all hope to get it to work again as error followed error every time I tried to compile the project.

In the end the whole thing was worth it, although it cost me a whole day – not only the player could create infinities and enter them now, but also the world and its inhabitants were able to do so. Thus the idea of the radioactive zones was born, and now the player had to be careful not to walk into a "natural" infinity field unprepared.

One decision we reached very early was to make the game realtime instead of turnbased, i.e. NPCs and monsters can move and act all the time. We are still not entirely sure if this was a good decision (as it is a downer for many fans of roguelikes), but somehow it makes the game more dangerous and it complements the infinity fields.

As "Me Against The Mutants" is very small in focus, there is not much variety; in my opinion realtime helps to tighten the gameplay in this case. Would it have been turnbased, people would get bored of the pretty obvious AI very fast.

Learning from our first 7DRL "Pitman", balancing issues were less crass this year. I will never make a game again were a fight could go on for hours because both parties are too weak and too agile so one combatant would never hit the other (which happens in "Pitman" quite often). Hence the mutants all have their basic damage and the player has his basic damage, and both cannot be zero (only very low). There are also much less stats – and in hindsight even with six important values only (Attack, Defense, Speed, Health, Mana, Stamina) not all of them make sense ...

For instance, a varying speed of the player isn't much of an issue for the gameplay – even though having different speed for every character was one of the reasons we wanted to have realtime gameplay!

It's also essential that the self-created infinity fields don't exist forever, so a tactical course of action is desirable; but I was never quite content with the approach of using mana. If it drains too fast, the infinity isn't much fun; but when it drains too slow, it doesn't make much sense in the first place. Either way, automatic mana regaining was needed – which made the mana refill containers I placed in the world useless in the end.

The differently coloured slimes are another part of the balancing act. As the game has no concept of the player's progression level (it is far too short for that), we invented another way of changing the player's various skills: slimes. In the beginning, when we thought we could add much more things to the game, the slimes would be large radioactive pools and change everybody around them. They would have been the real reason for normal creatures suddenly being mutants. As we never really had a plan how exactly that would happen and also not the time for elaborate mutations, the slimes became the simple, but double-edged swords they are now. They can boost the player or make him weaker or both – the effects are random, but don't change per colour, so every red slime in the world does the same. Of course, sometimes the God Of Randomness decides that every slime colour has to have mostly negative effects, so this gameplay mechanic really could benefit from a little bit more thinking.

The slimes are also one of the reasons why there are bunnies outside the contamined building. The little rabbits were planned as creatures not yet mutated but with the possibility to do so. As the game progressed only slowly over the week, it was clear that they would regress to decoration.

But they also serve as a tutorial – the player can approach the bunnies, hit them and even backstab them without having to fear them to counteract. In fact, the whole outer region, the grassland with the forests, was planned to be a dangerous zone but instead it is now an interesting contrast to the mutant-infested building. Somehow, it promises some kind of peace and happiness this way.

On the other hand, our roguelike is missing handholding at the beginning, and some people were really not sure what the game was about and how to control it. Sure, they could have read the instructions at the start of the game or below the embedded SWF, but never one never should expect something like this. Nonetheless we like that the game is even more about exploration this way, and the first "Aha!" moment when you get into the building is really fulfilling.

About the graphics: pixel art was an unconquered field for us. We mostly dabble in the third dimension, so concentrating on single dots instead of polygons was a small challenge for Jana's skills as an artist. Nonetheless we were eager to try it, and it also convinced us to make a full game with pixel graphics some day, as they are neat and have an abstract style which can make forget the lack of detail. And even though retro pixel graphics already are widely used in the indie gamedev scene, the pure form of the pixel still can produce novel looks and an interesting atmosphere.

Conclusion

What went right?

learned a lot about 2D pixel graphics

game was finished within time

interesting gameplay mechanic, even worked as intented

small scope, lots of fun

used Flash, which works on all desktop computers

sound and music!

featured on freeindiegam.es and rockpapershotgun.com, woah

And what went wrong?

stupid coding problems

not much time

balancing still an issue

very sparse in content and variation

some people are confused about what to do and how to do it in the game