Ludum Dare 30
Ludum Dare 27
Ludum Dare 25
Ludum Dare 24
Ludum Dare 23
Ludum Dare 22
Ludum Dare 21
Ludum Dare 20
About ratking (twitter: @RatKingsLair)
Outside the Box Game Idea Award
Awarded by rfgpfeiffer
on August 31, 2014
The "Your Games Are Really Cool" Award
Awarded by bentog
on January 15, 2013
Crown of Innovation +5
Awarded by sorceress
on January 8, 2013
Award for Pooping during an LD
Awarded by thedaian
on December 11, 2012
The Smallest Game Technologically Possible Award
Awarded by Tim Bumpus
on May 30, 2012
Brain Melter Award
Awarded by NeiloGD
on January 8, 2012
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 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.
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.
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.
This is my lamest posting ever, so I’ll keep it short.
Yes, I want to be in even though I’m still sick from Gamescom week, yes, I will use Unity as usual because it’s the tool I know best now, and yes, I love Ludum Dare.
Here’s hoping that I can actually deliver this time. My ego needs it.
* This one.
Are you near or in Kassel, Germany, at the weekend from 29th November to 1st December? There’s a local game jam going on, in the context of the Spielsalon 2013 (a festival about author games, i.e. games by individual people, often artists). This means you can also attend talks and workshops before the jam!
As usual the game jam itself will be about making a game in 48 hours. It will take place in a bar.
- no fee for attendance
- a place to sleep will be provided by folks from Kassel (couchsurfing)
- the theme will be given at the beginning, but you can choose your own tools of course
- make friends in teams
This is a slightly edited version of my post on our own blog!
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.
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 know, 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. RottenHedgehog 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.
RottenHedgehog 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 RottenHedgehog 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 RottenHedgehog‘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. RottenHedgehog made the logo and the button graphics, and also captured a video of the game.
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.
- RottenHedgehog 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 RottenHedgehog, 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!
- RottenHedgehog 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 and rate BLAM BLAM PLANET here!
For the people who are too lazy to actually play our game, ratqueen made a video of it:
Yes, we make an FPS, although 7DFPS is over. The theme didn’t gave us good ideas (good in the sense of feasible), so we’re doing something new for us (we never did an FPS with shooting before, as far as I remember). We will add the theme afterwards – like “your weapon changes every 10 seconds” or so.
Some basic gameplay and graphics were done today, so we can go to sleep now.
Team Rat King will try to participate in this honorable event once again!
As I (ratking) seem to have forgotten everything about any other tool (like Flash, Haxe, or Visual Studio), I will use Unity as game engine with the language C# for scripting. My own base code, which consists of some helper classes (partly stuff written myself, partly stuff copied from the Unify wiki or other places, plus iTween, plus some useful shaders) and a very simple rigidbody-based character controller, will hopefully make the development faster so I can concentrate on the actual gameplay. I might include cInput 2.
My partner, ratqueen, will probably do the graphics, with Photoshop and 3dsmax.
If there will be any sound, we will use Audacity, sfxr and/or whatever generates some interesting notes.
Good luck and much fun to all entrants!
This article is a copy from my blog.
On December 15th, Ludum Dare 25 started. As usual, this 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.
second 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.
first 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.
the 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.
- 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.