Tag «Ludum Dare»

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.

ld35_20160418_204744_379

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.

ld35_20160416_222626_207

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:

WoodForTheTrees_MakingOfMovement

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.

WoodForTheTrees_MakingOfFog

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.

WoodForTheTrees_MakingOfModels

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.

WoodForTheTrees_MakingOfAdventure

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.

WoodForTheTrees_MakingOfAllSketches

WoodForTheTrees_MakingOfTiles2

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.

WoodForTheTrees_MakingOfPress

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.

ld35_20160418_144327_513

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)

Watch this video on YouTube

(YouTube videos try to set cookies and contact Third Party servers!)

TRI Post Mortem

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.

TRI

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.

The Olde TRI

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

Soon!

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.

Scribbles

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.

TRI, V2

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.

Reading

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.

Puzzles

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.

Screenshot 1

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!

Grid

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.

Thank you!

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.

Thanks to Rising Star Games we're also on GOG. GOG was great regarding the release, as they wrote a very cool release article. And you can also get our game directly on the HumbleStore, too!

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.

Title

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.

TRI is a bit about celebrating freedom and possibilities, and we hoped that a lot of people would love that. For now, we still have to find out how to reach them.

If you enjoyed reading this, you might want to have a look at our Making-of video series, our the rest of our blog.

Screenshot 2

We have a date!

ReleaseDateAnnounce_1

Dear readers, players and friends of the TRI!

We have a date! Fox and Monk are prettily dressed and ready to show you the world they lived in for two and a half years now. We from Rat King are extremely psyched that we made it this far after all the problems and highlights we had while making the game.

TRI will be available for Windows, Linux and Mac. You will be able to get the game on Steam, IndieGameStand, Humble Store and itch.io, with hopefully more platforms to be announced soon.

In other news:

3663-shot0

Friedrich made a new small game for Ludum Dare #30 within 48 hours and called it > Continue. It's a Choose-Your-Own-Adventure where you can read and continue several stories, or start your own from the starting situation as shown in the picture above. Go here to explore what already happened.
Moreover did Friedrich start a little blog on his daily work and updates for the game. He also writes about games he likes or events we are attending. Take a look at THE APE TRIBE.
Remember our last news about Desura? If you bought the game there you can get your personal Steam keys now.

Some new screenshots of TRI:

tri2_screen_september_04 tri2_screen_september_01 tri2_screen_september_02 tri2_screen_september_03

The winners of Ludum Dare, and what to learn from them

This was originally a quick and dirty talk I held in 2014 at our Global Game Jam location in Leipzig, Germany. I wanted to give the audience (mostly students, a lot of them without experience in the art of game jam) an impression on what is possible during a game jam even when you're alone and have to do stuff from scratch; so I showed them the last five Ludum Dare compo winners, which means each of them got the first place in the "Overall" category. The talk would conclude with some best practices, at least in my opinion.

As most of you probably know, Ludum Dare is an online game jam held several times in the year, with the big versions always commencing in April, August and December. Thousands of participants make a game in 48 hours each time, and a lot of them also are part of the quite active community surrounding the jam. Everybody who joins can be sure to get feedback and answers via the blog on ludumdare.com, and via the IRC channel #ludumdare on AfterNET. And don't forget that for three weeks afterwards, every participant can rate all the others' games, so the brutal final ratings for each category (e.g. Graphics, Fun, Mood) are there for the whole world to see. With the high numbers of entries, winning the competition may sound nearly impossible. So let's take a look at some of those who actually did it!

Ludum Dare 24 – Theme: Evolution

Evoland is a Zelda-like with a funny idea implemented well. It has a lot of chests – in each chest you find a feature that hauls the game to the next step of videogame evolution. At first you can only walk right, but you get the ability to walk left soon. After that, you can walk north and south, how cool is that! Scrolling! Colors! Sounds! Weapons! Nicolas Cannasse broke down a pretty standard Zelda clone into its most minimal parts, used those parts to let the player explore them, and made a unique game this way. (Later on he even extended the game and you can now buy it on Steam.)

As a game jam game Evoland is very ambitious and I couldn't believe that it was made in 48 hours. I assume Nicolas had the idea and concept very early in the process, and using a programming language he invented himself might have given him a good headstart.

Ludum Dare 25 – Theme: You Are The Villain

Atomic Creep Spawner!! reminds me a bit of Dungeon Keeper, although you can only do a fraction of what is possible in that game. A pompous knight is raiding your very own dungeon, stealing your money and destroying your orbs, and you have to stop him by spawning a lot of monsters. You create those hordes of zombies and ghosts via simple clicks on the floor, and they find their own way (more or less) to the rampaging knight. A fair bit of AI must have been programmed for this game.

Made by Sébastien Bénard (known as deepnight, one of the most successful Ludum Darers!), Atomic Creep Spawner features great humor and amazing pixel art. Sébastien even found time to include a tutorial at the beginning. What the game lacks in interactivity it makes more than up with polish and love for details.

Ludum Dare 26 – Theme: Minimalism

MONO implements the theme via its graphical style (which looks simplicistic, but is actually very well done), but most certainly not via the gameplay. While at first glance it seems to be a minimalistic game in every sense – you navigate a small sphere through a world of rectangles – the levels soon become more and more diverse, which is what keeps the game interesting. This is a nice trick you can learn from: make a game with only some basic functionality, and if you have the time, add another level with new elements and mechanics inside it – rinse, repeat.

Tim Hantel managed to make a neat dexterity puzzle game with a lot of atmosphere, mostly by adding a fitting soundscape. The gameplay mechanics sometimes make the game a bit frustrating (you die by touching a wall already), but in general the player's death is a forgivable experience: you spawn instantly at the level start again. An important lesson I think.

Ludum Dare 27 – Theme: 10 Seconds

PROBE TEAM could easily be part of the Ludum Dare before – it uses one single color only, enhanced by some cool looking post effects. While I never liked the theme in itself, because I always felt that it would cripple gameplay concepts instead of fertilize them, Andrew Shouldice actually made an interesting type of exploration game out of it. You start little probes which have 10 seconds of fuel each (so be economical with your commands), lead them through some kind of maze and activate triggers to open doors. It feels a bit repetitive, but the moody atmosphere absolutely helps to tolerate and even enjoy it.

Ludum Dare 28 – Theme: You Only Get One

One Take by Daniël Haazen is a great example for an unusual idea creating a whole new experience. You play as a camera operator taking one continuous take from a movie scene, and all you do is following orders from a film director in the form of short sentences, like "Zoom in on the sheriff" or "Go back to the guy in the alley". The scenes are a bit animated (while most of the action comes from yourself) and actually feel like small movies – already worth an honorable mention in my opinion. The cherry on top are the pixelated newspapers after each level, including reviews about the 'movie' and your performance.

Learnings

So what can we learn from these great examples of Ludum Dare rapid game development, for our own jam games?

Make something simple. All the mentioned games concentrate on a single idea. Be it spawning monsters in a dungeon or moving a small sphere around obstacles – important is to focus the game's concept on one aspect and not trying to add more and more features. Of course, this implies you actually have a nice idea that can be played barebone and that you like.
Be inspired by the theme. This one surprised me a bit, probably because more often than not the theme of a jam hinders instead of helps me. But all the winners above are very close to the theme, and that must tell something, probably about inspiration.
Think in two dimensions. Although one of the games uses Unity, all of them are 2D games, varying from totally abstract to concrete pixel art. I don't know exactly why that is, but there is probably more than one factor why jam games prefer to be 2D. My guesses are: the game is simpler to make, the graphics look better while being less work, there are a lot of premade frameworks, and you get a nostalgia bonus.
Use a framework. The Ludum Dare rules state that you must make your game from scratch, but it is allowed to use libraries, tools and engines that were already made by you or others. So use them! The winners from above utilized Haxe (compiled to Flash), Java with libgdx, Unity and LÖVE. Three of these games were playable in the browser (with plugins), which might also be a small factor adding to their successes. Remember that Ludum Dare's winner are determined by people who have to play thousands of other entries, too – the less problems they have to play your game, the more likely they will play it.
Generally you should try to make your game as accessible as possible. Deepnight's winning game Atomic Creep Spawner includes a tutorial, but you don't always have to go this far. Just don't innovate where it isn't needed, and explain things when they come up for the first time, be it via text or picture (better yet, force the user to play it to understand it).
The last learning for now is somewhat vague, as the games tackle this very differently. Some of them use a lot of humor, via little comments from the characters for example, others are pretty atmospheric, often thanks to their great use of sound. What we can take away from this is: don't shy away from trying to evoke emotions in the player. It seems the humoristic way is a bit easier than the one with the dark mood and the feels. Speak to the player, or let them explore interesting places. Give them reasons to attach to your game!

Conclusion

Making a game in 48 hours is hard, winning Ludum Dare is even harder. But if you look at the above examples you see it's not impossible! Sure, you need to know your tools in and out – the Ludum Dare Top 10 isn't the place for learning a new programming language. (This could be a bonus learning.) Just keep in mind to have fun and make something worth playing. Everything else comes afterwards.

Ludum Dare 27: BLAM BLAM PLANET – Post Mortem

Greetings!

Back in April, Ludum Dare 26 was not so great, as I couldn't participate. It was right after the AMAZE IndieConnect, and this convention drowned my energy so much that I got sick. All I made was some visual experiment, which I couldn't develop much further because the headaches got too strong – partly because of my chosen art style. :-P

So, last week's Ludum Dare 27 was much better in this regard! And after kernel exception, this is the second Ludum Dare we entered together (thus being a Jam entry, not a Compo entry). We had a lot of fun, but also some problems, of course.

Our entry is a first-person shooter, with a little twist: you have five weapons, and every 10 seconds your current weapon switches automatically to another one, randomly selected. And there are "floating devices" all over the world (= a medium-sized planet) which you have to stand near for 10 seconds, so a bunch of power-ups get spawned (ammo and health packs). Enemies spawn in waves every 10 seconds. And when you collect ammo, you basically get an additional 10 seconds of shooting time.

As you might have guessed, this Ludum Dare's theme was "10 Seconds", and we called the game BLAM BLAM PLANET.

After some minutes of playing the game becomes quite intense, because more and more enemies spawn. If you just run and shoot around instead of waiting at a device now and then for a while, you will soon run out of power-ups, and thus health and ammunition. So it's even a bit tactical, one might say.

The development of the game had its ups and downs, but it went well in most cases.

On Saturday, we thought of the game idea by talking about different possibilities and going for a walk. Ludum Dare starts 3 am here in Germany, and if I remember correctly, it already was afternoon when we agreed on making a first-person shooter, because we never did one really. To make it more interesting we decided that the setting should be on a round surface, which meant the game would need spherical gravity for all entities.

At the beginning we named the game "GLITCHIG", because we wanted a broken look and have destructible environment, so lots of triangles are flying around. Jana started building a neat planet surface with some asteroids around it in 3dsmax, while I started to let my character controller be influenced by gravity pointing to the level origin. Shooting little spheroids was also a priority.

So both Saturday and Sunday were all about getting this right: a planet, a player, a weapon, some enemies walking around. Mostly I tried to get it all working smoothly, by getting the physics of the character and the weapon right. But the hardest part were the enemies and their AI on the round planet. For this, I searched for some code for creating the vertices of a geosphere, mapped this via raycasts on the planet geometry and connected the resulting points – those were then the nodes for the enemies' path-finding. Just letting the enemies walk directly towards the player probably would have been much easier, but less fun to create. ;-)

Another nice part of development was inventing the different weapon effects – two weapons in the final game deform the geometry, so I can push the vertices of the planet around a bit when the bullets hit something. It looks quite ace. As "glitches" was our personal theme from the start we knew the geometry would look strange and broken the more you use this weapon and we embraced that. In fact, when I last played the game, I fell through the level and I could attack all the enemies from below while they couldn't see me – but that also meant I didn't get any new ammo, so it was okay.

Jana was mostly busy with modeling the three types of enemies and animating them. They look kind of deformed, emphasizing their low-poly nature, and it really looked well. Especially when she added the walk/fly animations, which are really hilarious. When the enemies spawn in masses it becomes a really cool effect.

In order to tie the look together, she also created a color code in Photoshop. After that, the game looked "right", as the colors of most assets didn't need much tweaking afterwards. Having only very few placeholder art from early on really helped the motivation somehow.

Sunday evening Jana also started to make some sounds for walking and shooting by using our laptop's inbuilt microphone. High tech! All the sound effects you hear in the game are actually Jana's voice. :-) Adding sounds instantly made the game more alive; in the end, you can't have enough of them – that's why she made more on Monday, along with the art for the bullets and particle effects.

On the third day the theme of "10 Seconds" still wasn't in the game, and I thought long and hard about how to implement it. I weighed the pros and cons inside my head of different game mechanics, like "every 10 seconds, you have to collect new ammo" or "activate 10 bases, 10 seconds each, and then you won (whatever that means)" – and only when I finally began to create the five different weapons and let the enemies spawn in waves, the probably best restrictions (automatic weapon switching, time-limited ammo, etc.) came naturally. So there's that: sometimes tinkering too long can be bad, and you should just "do it", I guess.

In the final hours I was able to quickly implement the main menu and a death screen, which always is satisfying as it ties the game together and makes it look complete. Jana made the logo and the button graphics, and also captured a video of the game.

Ludum Dare 27: BLAM BLAM PLANET Gameplay

Watch this video on YouTube

(YouTube videos try to set cookies and contact Third Party servers!)

So, that's how it went. Let's take a look on some quick facts about ...

... what went wrong!

Finding the idea was hard for us, as we couldn't agree on most things. In the end, the game we created isn't as innovative as I would have liked, but at least it's superfun to play this time!
As we struggled with the idea, it's clear the theme didn't help much. Although "10 Seconds" is in the game more than once now, it feels a bit off.
On Monday I nearly lost the will to finish the game, because of the lack of a clear direction regarding the gameplay, caused by the theme.
Jana had some severe problems with the CAT animation system in 3dsmax. It seems to be buggy as hell, and I heard her cursing a lot. ;-)
There are no game-breaking bugs in the game, phew – only some small stuff, like resetting the option settings when you open the "Options" menu. The bigger problem might be that the game is "broken by design", because of the Glitcher (the weapon that deforms the planet's geometry) – we should have used this feature more often, so it doesn't feel strange when you fall through the geometry.
A lot of feedback is missing, like some kind of visual hint when you got hit, or a sound and animation when the ammo is depleted. Also, the "story" isn't communicated in the game: you don't know what you're doing here, why your weapon system is defective, and why you have to stand near the floating devices. (Some people didn't understand that the enemies only start to spawn when you do that for the first time.)

... what went right!

It's always great to work together with Jana, because we know exactly what each of us can do, and how. While I do the scripting, she does the modeling, texturing and sounds. Perfect team work – all in the same room!
I set up an SVN repository, which sped up the work flow incredibly, and also saved my ass at least once when I accidentally deleted some files in the Unity project folder.
I prepared some basecode a day before Ludum Dare, by skimming through my former projects and picking useful helper code snippets. Having a basic character controller, path-finding, simplex noise and other functions ready before you even have to think about where to find them is wonderful!
Jana recorded the sounds with her own voice and distorted them in Audacity, which was much faster (and cooler) than trying to find sound effects on freesound.org with the right license.
The abstract, low-poly, somewhat "broken" graphics style looks quite well and gets very positive feedback, even without textures – AND it also was done very quickly.
The five weapons are fun and pretty diverse. This way, the whole game is fun enough for a few minutes, and that's the most satisfying part of this Ludum Dare for me.
Before we started I thought the spherical gravity might not work at all, neither as a gameplay mechanic nor as a visual style. I especially was concerned with this style the player would see too much sky and not enough ground surface. In the end, with the recoil of some weapons (so you fly away, looking down) and the high amount of flying enemies, this wasn't any problem.

... what we learned!

Due to the lack of time at the end, the balancing is kind of subpar. Good thing the game just is an endless shooter, and thus it is good enough. It's also cool that you can "learn" the game, as using the floating power-ip devices is important, but not obvious. Always try to add stuff like that.
"Crappy" graphics often look awesome when animated and with a nice shader. ;-) Coherence is very important though – that's why creating a color code sheet early in the process is a must.
Try to not make any placeholder art, because it either means you will have to make an asset twice – or it will be in the final game.
Even if you lose motivation near the end, at least try to give the game an ending. Sometimes, it helps to finish the game nonetheless, because this, this and, oh, that too, has to be done before the game can have an ending and be called "done" ...
Three days are still too long for me, because it automatically makes the project too ambitious.
Every time I see a Unity project with the standard Unity button graphics I get the urge to close it instantly. Really, it's easier than most things in Unity to add some custom button graphics and a downloaded font to the GUI skin. Give your game some love!

As much as I'd want to extend the game a bit, like adding more levels, I don't think it will get much bigger than now. The feedback of players and Ludum Dare ratings is really nice so far, but I don't know if having more enemy types and whatnot would increase its popularity. An online highscore would be nice, though, so maybe I will add that.

Thanks for reading this post-mortem, and I hope you had as much fun with this Ludum Dare as we had. If you want you can play BLAM BLAM PLANET here! :-)