This is our game, Slime Factory!

This is the reverse of a tower defense. In Slime Factory, you start in a deadly stage full of turrets, lasers, mines, and other nasty traps. Your objective is to help the slimes escape by manipulating the level with a limited array of tools. We managed to get thirteen levels created before the deadline. The first few are relatively easy, being introductions to how the game mechanics work. The last two levels are more challenging to complete.

Our goal with the minimalism theme was to see how much enjoyable game-play we could add while giving the player only a few choices of tools. The hammer can break destructible blocks, the wrench can modify some blocks, the bomb can destroy most things in a 3×3 area, and the red block allows you to modify pathing.

We love feedback, so please let us know what you think of the game in the comments!

Alright guys, it’s been two days (more or less) since I finished my LD48 entry (If you haven’t yet, please go play it and maybe rate or leave a comment, I’d really appreciate it.) Last time I participated in a Ludum Dare competition was one year ago for the 23rd LD and I had promised I would eventually write a proper post mortem for The Dream Sequencer. I didn’t. I was too burnt out and I had a lot of other stuff going on so I never got down to actually doing it, I kept postponing and procrastinating and it eventually slipped.

This time I decided I would catch the chance to write a combined Post Mortem, especially considering my two games were very similar and the experiences as well, it’s catching two birds with one stone.

DISCLAIMER: This will be a lengthy post, feel free to bookmark it somewhere or just burn it and never read it. I promise it will be interesting!

The Premise

I enjoy adventure and story-driven games. I grew up playing Sierra and Lucasarts point and click adventures. One of the very first games I have ever played was The Secret of Monkey Island and, 20 years later, I still find that to be my favorite genre. Still today I am always shopping around and buying mostly point and click adventure games. When somebody asks me to make a game, the first thing that comes to my mind is its story and universe. “What would I do?” “What would be a great story to narrate?” The mechanics and actual gameplay come later for me. I know there’s a whole class of game developers that would frown at me for saying this, well, just sue me.

With this said, my rather short history of LD entries speaks for itself. If I had to choose a genre to adapt for a LD competition in 48 hours, only point and click comes to my mind. The other proper candidate would be an RPG of some sort but that’s way out of my league, especially in such short amount of time. This is why I decided to go with this genre, I feel it can be adapted to most themes although there were a couple of themes this time that would’ve made it very very hard to succeed. I’m overall glad Minimalism passed over others. (I would’ve still preferred “Afterlife” but that’s my personal opinion)

The Challenge Within a Challenge

I don’t honestly know why I do this, it’s probably some sort of masochism. 48 hours of full-on game development apparently does not satisfy me enough, I have to explore new approaches and try out new experimental stuff. Otherwise, how can this be a fun and learning process?

Last time, for The Dream Sequencer, I had decided to use C++ with Angel Engine. Keep in mind I had never programmed in C++ extensively before, my main and favorite programming language is C. Most of you game developers know how using pure C or C++ for “quick prototyping” is simply bollocks. There’s too much stuff you need to keep in mind, lots of bugs can be easily caused by pointers or memory issues, bad platform compatibility depending on libraries, harder time porting for Linux/Windows/OSX. And that’s what made it fun for me, I felt like I had to prove myself somehow and that’s the route I took. How it ended up? I’ll get more in-depth about that later.

This time I went for a more “portable” solution, I wanted everybody to play my game regardless of platform and operating system, so I went for the obvious solution: the web. There are many options for game developers targeting web platforms: Flash, Java, Unity Web, Javascript+HTML5 and a couple other less known. Let’s go over them one by one so I can give a rationale on why I didn’t pick them:

• Flash – I use Linux. Flash somewhat “works” on Linux systems and I am well aware of that. Too bad I do not want to support it for many obvious reasons and I am trying not to use Flash for anything at all anymore. I don’t even have it installed on my system.
• Java – Java applets are even worse than Flash, lots of security issues, vulnerabilities and overall annoying for most players. Really a bad choice.
• Unity – I read that Unity was somewhat ported to Linux, I have played and rated several LD games made with Unity with their Linux/Mono executable. Too bad the Unity web player doesn’t work (or at least I couldn’t get it to work). Obviously not an option for me.
• Javascript+HTML5 – This is a really good option. It’s still a bit immature and may have issues with some browsers but a lot of people are using it also on phones to make games, so why wouldn’t I? Well, it certainly is the best option among the rest, but there is only one problem… I don’t like Javascript

Given the alternatives, the obvious choice would be something that compiles and runs as Javascript+HTML5 that doesn’t use Javascript code. There are dozens of languages and compilers that would allow me to do exactly that, a perfect example would be CoffeeScript. Well, why didn’t I choose CoffeeScript? Too mainstream. No, not really, remember when I said I wanted a challenge? Well, I thought ClojureScript would be a more interesting and an overall more enriching experience to me, which is why I chose it. What is ClojureScript? Well, it’s a Clojure (a Lisp dialect) variant that compiles to Javascript.

I’m a big sucker for Functional Programming, ever since I played around with Scheme back in University and then dabbled a bit with Haskell. I have been waiting for a long time to have an occasion like this where I could actually employ a functional language for real. A few months before the competition began, I started playing around with Clojure. It was amazing, a really enlightening experience and solving some Project Euler challenges opened my mind. It was just great. I, however, also decided to keep the juicy ClojureScript parts for the competition itself, because I like hurting myself unnecessarily.

History of Bad Luck

Every developer knows that there is a supernatural force out there that always tries to screw up whatever plans or project you may decide to start. In my case, however, this seemed to have multiplied tenfold when talking about Ludum Dare. Let’s start from the beginning, with my troubled LD entry one year ago.

Around one week prior the competition began, on April 2012, my motherboard fried. I was without a computer and no chance to get a replacement in time for the 48-hour competition. This was a tragedy for me, I was so hyped to participate that I couldn’t just let this problem stop me. I ended up dusting off my old computer that I had been using as a home server, installed a somewhat “fresh” Debian distribution with LXDE and I was good to go… somewhat. The poor thing was so old and decrepit that it could barely run a text editor and a web browser together. Developing with C++ on that was truly a challenge, but I eventually managed.

Successful after my first LD, I decided to participate again in August. I usually never go on vacation or anywhere in particular, I am a very humble (and NEET-like) person, however my friends had managed to convince me to go out of town with them for a weekend. We had everything ready, all paid and done… and later it turns out that the LD had been scheduled exactly on that weekend. I cried a bit inside and decided to skip it, I could always participate in the December competition, right?

Wrong. I’ve been planning to choose a university for my Master’s Degree and my choice had fallen on one in a different country. That’s also when I was able to find a pretty awesome deal for 3 days (plane tickets + hotel) in that very same city for very very cheap, I couldn’t pass it as I might not have been able to find a better occasion to visit the university itself. Too bad the deal was only for that very same weekend on which the 25th Ludum Dare competition was scheduled.

With one whole year past my back, we have come full circle again. Planning and scheduling are still as useless as they were one year ago because even this time I found myself completely overwhelmed with real life commitments and deadlines. The most important of all, my band and I have been pretty much 24/7 in the recording studios for every single weekend of April to rush a new EP release. I really could not spare a week-end for LD… and yet I managed. I thought “screw it” and went for the 48-hour compo no matter what. I’ll get more in-depth with time scheduling in the following paragraph.

Lesson Learned: If you really want to do it, find the time. Sometimes it’s as simple as asking somebody else to cover you, some other times it’s not that easy and may require a lot of sacrifices and lack of sleep. All in all, if you really want to do it, do it.

General Time Scheduling

Too much time has passed since I developed The Dream Sequencer. I don’t honestly remember how I organized my time back then but I clearly remember an overall lack of sleep, which is normal for LD, and an intense feeling of rush and purpose as the hours slowly drew closer to the deadline. I had a tremendous issue with the sequence of screens which caused a lot of memory leaks and troubles which made me lose precious hours towards the end, but all in all I managed to do everything I wanted to and I simply slept away the following week.

This time, having to schedule my daily activities and availability around the LD competition was much, much worse. As I mentioned in the previous section, I had to carpool to and from the studios at least once every day. Starting from the early afternoon it would keep me busy until around midnight with an added commute of, more or less, 40 minutes (giving lifts to friends included). I had to do half of my development with my laptop at the studios and I had to be careful with planning if I didn’t want to find myself out of the compo. I always made sure I had the right plug/socket for my laptop charger, the right amount of paper for concept designing and my trusty wacom tablet for drawing. Drawing itself was the worst part, with only a small couch available and no rigid surface… it was pain.

Subdividing the daily routine is important, as I learned, when participating in these competitions. I had to distribute the load evenly between the hours, allowing myself some breaks, lunch, dinner and the aforementioned commute. Some tasks also had different priorities and deadlines. The engine development should come before the actual content creation, lest I find myself with a lot of content but no game. It is also not viable to record music and sounds in the early morning or late night (neighbors would kill me). On this related note, what is actually funny is that I couldn’t really record anything at the studios either if I wanted to do it myself, the equipment over there is not mine and costs money to rent/use so it was out of the question. With all these considerations, here was my planned schedule:

Saturday:

• 4AM – Wake up, competition starts, let’s have a look at the theme
• 4.30AM -> 6AM – Overall brainstorming for idea fitting the theme.
• 6AM -> 12PM – Full head on development, researching on ClojureScript (remember? I never used it), reading short tutorials and example code, implementing base engine
• 12PM – Lunch break
• 2PM -> Midnight – Commute to the studios, keep developing base code and have a fully working engine with everything implemented, proper interactions and everything code-related.
• Midnight – get back home and sleep

Sunday

• 8AM -> 10AM – Wake up, start recording audio and musics ASAP
• 10AM -> 12PM – Designing basic puzzles and small content creation
• 12PM – Lunch break
• 2PM -> Midnight – Commute to the studios, draw lots and lots of contents and puzzles.
• Midnight -> 4AM – Final playtesting, eventual bug squashing and upload to LD website

It sounded like a smooth plan, right? Well yes, it was exactly that, a plan.

This is how it ended up being:

Saturday

• 3AM – Wake up early because I couldn’t sleep all night, this is usually when I go to sleep so my body isn’t used to it
• 4AM -> 6AM – Rage on irc about theme (a staple of LD), try to find a proper story
• 6AM -> 2PM – Read a lot of posts, articles, interesting news and interesting stuff about ClojureScript. Try to implement other people’s code and get a base engine working. Also forget lunch.
• 2PM -> 7PM – Continue developing at the studios, struggle with silly Internet connection that keeps dropping
• 8PM -> 2AM – Get home earlier because change in schedule and keep working on engine getting around half of the required features working.

Sunday

• 7AM -> 9AM – Wake up and try to implement missing features from engine
• 9AM -> 9.30AM – Realize it’s getting late and I absolutely need to record sounds, ignore engine and start setting up recording equipment. Find out that there was a bug with the recording software and my guitar cable is faulty so I have to look for a proper cable and solve software issue. By this time I was frantic.
• 9.30AM -> 10AM – Record 4 improvised tracks, abandon all hope to record extra sounds for the game.
• 10AM -> 2PM – Implement sound system in game, test simple features and get a semi-working codebase
• 2PM -> 11PM – Draw a lot of pictures and silly things sitting uncomfortably on a couch.
• 11PM -> 11.30PM – Try to get back home but realize a friend forgot stuff at the studio, give him a lift back
• 12AM -> 3AM – Frantically try to finish the bare amount of content I have, bugs… bugs everywhere.
• 3AM -> 3.45AM – Implement ending scene, put everything together. No playtesting, final destination, upload it to the website
• 3.45 AM -> 4AM – Wait for last 15 minutes of competition to end, staring bleakly at the screen.

“But… Morg, we don’t really care about your private life.” Well, you should. No, not really, however there is a great lesson to be learned here. Look at the differences between the planned and the actual succession of events. I literally finished writing the last line of the ending scene in my game exactly when the LD countdown hit “15 Minutes”. I had poor planning, no real expectations for the tasks I was required to do, and to top it all, a lot of things went wrong. I was overconfident on the first day, I was too frantic on the second one. There is a huge difference there. I’m pretty sure most LD participants can identify with such behavior, it’s very common. The most interesting thing was how I had to “waste” 40 minutes helping a friend get his things back from the studios. I don’t really blame him but that is the perfect example of something that went wrong and that I should’ve taken in consideration for my planning.

Lesson Learned: Plan carefully, don’t overdo yourself. Always leave yourself some space for a few breaks or unforeseen hindrances and accidents. If all goes well then you’ll be more rested and thinking more clearly. If something goes wrong then you’ll have enough time to fix it.

The Engine

Last time I had used Angel Engine, a C++ engine for the quick prototyping of simple games. It’s really powerful and is the codebase on which I based the whole Dream Sequencer game. This time, however, I coded everything from scratch in ClojureScript. I had no real engine to work with and I didn’t really need it. The purpose of an engine in itself is to abstract away unnecessary boilerplate code for the programmer, to give him more time on actual content creation and less on menial tasks.

Using ClojureScript, it is actually easier and faster to just write your own functions and filters and maps and lambdas and whatnot, rather than trying to integrate someone else’s code. This is obviously true if you’re working on a deadline like this, proper programming practices still exist in the functional world and Clojure is no silver bullet exempt from them.

I am overall satisfied of how the engine turned out to be. There were a lot of bugs and a lot of issues due to proper planning (see earlier paragraph) but in the end it was solid. I have to thank functional programming for that, keeping functions without side-effects, using proper state keeping instead of throwing everything into globals (exceptions taken for some parts). I had a lot of fun passing lambdas and higher-order functions around to schedule events, combinations of items and elements in the game and all that stuff. It was really refreshing and an experience that I would suggest to every serious developer at least once in their life.

On the opposite, though, there were a lot of problems too. I honestly had no idea what I was doing half the time, I had to ask for help on irc, use Google, learn how Javascript and the Dom model work, how browsers act, etc etc. I am surprised I was able to get this much done in just 48 hours, by the end of the first day I was pretty sure I wouldn’t be able to finish in time and I was already considering getting into the Jam instead.

The most troubling part of my engine development was actually realizing, on the second day, that I didn’t develop a mechanic I really needed for most of my puzzles, which is opening a dialog and obtaining a new item when combining an item in your inventory with an item on the scene (aka an actor, like giving the brooch to the fisherman, if you played the game). This is a very core mechanic of point and click games, without this it’s not really possible to advance, else your puzzles will be bland and uninspiring. I ended up solving this issue in around 30 minutes hacking together a few functions in charge to check when a new item was acquired and opening a dialog depending on the item and its “on-pickup” description. This is exactly the reason why the fisherman disappears before you receive the text on screen. It’s ugly but I had no time to implement it properly.

Another funny realization was finding out in game that you could just get rid of one guard in front of the throne room to be able to click on a few pixels of the door behind them and get into the throne room itself without solving half of the puzzles. Obviously you’d still not be able to finish the game but that’s another matter. This sequence break is the consequence of some decisions I took early in development where I decided not to go with actual “game events” and instead assume players wouldn’t be able to sequence break and speed their way through the game. This was developed with cheap tricks like putting items over exits (like the waterfall) to prevent the player from getting through. In retrospective, it was a bad idea, but a least it worked and was quite simple to realize.

Lesson Learned: If you can, take your time to learn a proper engine and avoid making your own, it will save a lot of time later on when actually developing your game. However, keep in mind that cutting corners is a viable technique and if you’re going for quick development/release (like in LD48), your player will never know how many cheap tricks you pulled out of your magic wizard hat to make the game work.

The Story

For those of you who played my previous entry, you know I tend to do stuff like this. I enjoy starting from A, getting the player through B and then suddenly jump to D, skipping C altogether. I am well aware this is an approach that a lot of people don’t really enjoy. I fell for that trap with The Dream Sequencer, turned the story 180 degrees in the opposite direction halfway through and then unloaded a massive mindfuck bomb at the very end. This time I had promised myself I’d be more careful with that sort of things… and I somewhat failed. I don’t really know, the ending is very disconnected from the rest of the game but that was on purpose, however it does look like it was very rushed and poorly planned.

Maybe it’s true, I didn’t plan properly. Maybe it’s not true and that was the intention, it doesn’t really matter. What matters is how the players perceive it. At the end of the day, that is what really counts and you can try hiding behind words as much as you like, facts are still more important.

 

WARNING! Spoilers Ahead!

At the beginning, during early brainstorming phase I had imagined a totally different story. In the very same universe and with the same vibes, just a different purpose. I imagined the main character to be some sort of magical spirit of “Art”, trapped into his prison by an evil sorcerer who turned the whole world into a minimalistic mess. You’d eventually wake up one day and have to find a way to break the evil sorcerer’s curse and bring color and details back to the minimalistic world.

All in all, it made sense in my head, however it lacked the mood I was looking for. It felt really generic and bland, a staple of point and click games. That’s when I decided to add the twisted ending, taking a bit of inspiration (subconsciously) from The Whispered World. First, I considered making the main character actually a patient of a mental asylum, suffering from schizophrenia (or some other illness of the mind) and eventually coming to terms with his condition, realizing he was living in a fictional world and breaking out of his psyched chains.

The concept itself would have been great, I’m sure. I’m actually noting this down for a possible future game, no kidding. The problem is that there was no way I’d be able to deliver an appropriate narration and closure for such a theme in just 48 hours. That’s where I changed direction and went with a more generic (and rather unimaginative, if I have to admit) main character trying to escape from this weird world and get back home, to a place he doesn’t even know about. Then I properly transformed the ending into a messy-but-somewhat-convincing grand finale that hardly tied to the rest of the story and yet delivered the proper punch to the reader.

Lesson Learned: Aim high, but not too much. If you’re a developer focusing on story, don’t try to pull plot twists everywhere, especially at the end. It’s way too simple to lump together an innovative and experimental writer with an actual inept and bad one. The players decide how good your story is, not you.

The Puzzles

This is an area that really improved with the transition between last year’s LD and this year’s. The Dream Sequencer’s puzzles were hardly there, there was no challenge, no real purpose. Just a mass of jumbled crap, one-way transitioning areas and small inventory. Prior to this I had never actually wondered about the effective complexity of designing interesting and yet challenging puzzles in adventure games. Make them too hard or too illogical and the players will get frustrated. Make them too simple and you might as well not put them at all.

There are several things that I managed to improve and I feel this part was actually somewhat successful (by the 48 hours limit, obviously), from the humbleness of my green game design experience. Here’s a quick list and explanation:

Give the player the chance to backtrace

Nobody wants to be confined in a corridor. For The Dream Sequencer I was limited by my own knowledge and engine, I made it only possible to go forward, advancing each room and solving puzzles individually. This time, by giving the player the chance to go back on his steps and decide to tackle multiple puzzles at the same time, I managed to make the game broader and more open. A more open world means better immersion and less constraints on what players do.

Add somebody to talk with

I didn’t have enough time to add proper dialogues and character interaction in either game, but I realized The Dream Sequencer was lacking a lot of classical point and click spirit. It was lacking NPCs. You really need to have a window to the world you’re playing in, you need to immerse in that and the best way to do that is to have somebody to connect with. By adding the fisherman, the princess, the two guards, some interactive notes and all of that, I made the world more real and more interactive. It doesn’t matter if they don’t participate in puzzles, they still populate an otherwise empty universe.

Useless stuff is not useless

On a related note, The Dream Sequencer mostly had only useful items. It was pretty obvious a good 90% of the game’s content was pickup-able from the get-go and players knew exactly what to do. This time I decided to go with more background details, add a window here, a bed there, some useless and uninteresting stuff. At least people now had to actually think (somewhat, in the 48 hours limit obviously) to solve puzzles, they had to actively examine items and further learn about the game’s universe without actively playing it all.

Make logical puzzles

This is something I have failed to properly achieve in both The Dream Sequencer and Art Attack. I acknowledge that, I had poor planning and didn’t take enough time to properly formalize the games themselves. Cracker with parrot isn’t a good puzzle, mushroom with water isn’t either. A good puzzle integrates well with the story and makes sense. All puzzles should be logical, straightforward and intuitive. This, however, doesn’t mean they should be easy. Just a bit out of reach for the player, to give him enough room to think it through.

 

The Art & Style

Fitting the art and the style to a LD theme is always a challenging task, especially with some less-inspiring themes. This year, with Minimalism, I have seen a big amount of games with pixelated and “minimalistic” graphics. I don’t really agree with their interpretation of the theme as I mostly consider Minimalism to be different from “minimalistic”, however this is all down to personal interpretation and all is good. What I have also noticed is that a lot of people implemented and emulated Mondrian‘s style. Mostly because it’s one of the first examples in the Wikipedia page for Minimalism and he’s got a very unique and eye-catching style.

I fell into the latter category of developers, adding my own touch to the artistic current, using also other colors like green… pretty much whatever seemed to look good at the moment. I decided to go for a very “unique” and stylized art style, this doesn’t mean it was a good decision, though. It certainly helped me develop a good amount of content in little time, and that is a really important thing to consider in a 48-hour competition. The downside is that the idea felt much better in my head than it was on screen.

Honestly, from some comments I received in response, it seems like people enjoyed the art, somewhat. I don’t fully understand it, I created it and I think it’s not that good but I’m glad others are actually liking it. Either that, or they just feel pity for my so-called “art skills”. Time (and voting) will tell.

Related to the art, the same rules as the story apply. No matter how intended it was, if people perceive it as bad then they will most likely think you’re a bad artist and consider it a silly attempt at spriting, rather than an intended innovative art style. I’m not really trying to justify myself here, I am not the best artist in the world. Far from it. However I know I could’ve done a much better job had I given more thoughts to the art department. I wouldn’t have been able to finish in time, however.

Lesson Learned: Even if it’s on purpose and you want to make a game so bad it’s actually good… well, people will still think you’re a bad artist. Always put effort in the art department as it’s what most people notice first, even before playing the game itself. Although, always factor the time it takes you to create good assets and come down to compromises to deliver the promised product in time. That is the #1 priority.

The Music and Sound

I love music. If that wasn’t clear enough from my previous mention of recording studios and all that jazz. I always try to achieve something original in my soundtrack for the games. I have seen way too many LD developers use sfxr for sound effects to actually consider it myself, regardless of the fact that it’s an amazing tool. As a musician I prefer recording my own tracks even though I’m probably not the best audio technician in the world (far from it).

The sound recording process for both The Dream Sequencer and Art Attack was fairly similar. Just get my guitar, plug it into the computer and record the track with some effects form my pedal. Loop it as needed and eventually call it a day. There were, however, a few differences between the two processes, mostly related to the actual hardware.

For the Dream Sequencer, as I mentioned earlier, I had a very old piece of crap computer to use for the development. Getting Audacity to work with that was simply pain. It would crash every time I clicked on the record button, it would create useless static noise, high latency, it couldn’t keep up with more than one track… I am actually surprised I managed to record what I did.

For Art Attack, it was much easier. Having at my disposal both my new laptop and my actual desktop made it much more comfortable to work with. After solving some cabling issues and understanding how to get real-time monitoring on Ardour (it was surprisingly easy, it just took me too long to explore all the menus), I was good to go. I quickly improvised four different tracks which turned out not so bad. I am actually very fond of the ending song, sporting a nicely improvised solo.

Unfortunately I didn’t have enough time to record additional sound effects or voice acting, time was running low and I was already out of my daily schedule. I also had to rush any post-processing and added mastering/mixing to each track which would’ve made them way better.

Lesson Learned: Make sure your hardware actually works prior the competition, you don’t want hidden surprises half-way through the weekend. Use any kind of content creator (sfxr is fine too) to ease your process but always try to be original, it does pay off in the end.

Bugs and Issues

Bugs… the bane of any developer. Who doesn’t hate them? From my personal experience, bugs can literally kill your development and productivity and make you drop out of the competition straight away. I risked failing everything both times because of silly bugs that kept me busy with petty maintenance tasks instead of letting me focus on actual polishing and content creation.

With The Dream Sequencer, I realized near the end that under some very specific circumstances my game would crash seemingly random. Some pointer allocation and memory leak was making the whole application fail brutally. As I mentioned earlier, using C++ for quick prototyping of a game isn’t the smartest choice in the world, and here is why. If I kept adding dialogues screens I would slowly start losing memory and dropping frames and eventually the game would crash. I realized a few hours before submitting my entry that the game had started failing to load some lua scripts, seemingly for no reason. Turns out later that an apparently innocuous assert() was failing silently and the whole thing would go down. What’s funny is that it started doing that only later during development, until then it had worked fine.

As for Art Attack, using Clojure has saved me quite a lot of pain. Thing just worked and there were very few issues at first. Later on things got a bit worse when I introduced proper asset loading and migrated from localhost to a real website. The added latency would occasionally freeze the loading process and up to this day I haven’t been able to fully solve the issue yet. What is ridiculous is that it would behave in a totally different way on Chrome or Firefox (haven’t had the heart to test it on other browsers). I know browsers and HTML5 can behave very differently but there was apparently no reason why the loading of a few images and sounds would freeze the whole application on one browser but not on the other.

A pretty big downside of ClojureScript was proper error reporting. Having to compile your code to Javascript means you get to lose the ability to see which function is actually failing in the game because the names are all mangled and you have a much harder time debugging stuff. All I could do was add a lot of console.log() and js.alert() functions everywhere until stuff started working again.

One thing that hit me both on my previous and my current game is that after the games end, they both crash. It’s something that I found very hilarious because no matter what language and technology you use, old friends (and enemies) still come back to haunt you. Still to this day I decided to just let it go and ignore those bugs, I don’t really care if the game crashes upon completion, I’m still happy I was able to get it that far. After all it’s just a 48-hour competition, right? Right? (I know it shouldn’t be acceptable but pretend it is)

Lesson Learned: Bugs are everywhere, a single bug can really screw you up. Always be careful when designing and debugging your game, you don’t really want old bugs to show up at the end of the development process. Trust me. However, keep in mind that sometimes you need to coexist with less harmful bugs and just deliver your game. That’s what counts the most.

Words of Closing

Well, this has been a fairly lengthy post, as I had promised. I tried to give some insight in the development process for both my previous and my current LD entry. Who knows, maybe somebody will find this interesting or even useful. I’m not a very experienced  game developer but I enjoy sharing my experiences with the community, just remember to take everything I say with a grain of salt.

One thing that should always be important for every LD participant is to enjoy it and have fun. There really shouldn’t be any other reason to participate, you don’t win anything, you don’t lose anything. It’s just for fun and because you want to create new games and put yourself to the challenge. Always keep that in mind.

I’m really looking forward to playing a lot of good LD games, there have been a lot of submissions this time and the ones I have already played have been great.

Feel free to comment below and share your experiences, I’d really love to hear from other developers about their own LD submissions.

Hey, I decided I’d write a short post-mortem for my first Ludum Dare entry – Terminally Ill. Quite fitting I thought…

Play the game

Watch gameplay

Before I begin, let me introduce myself: my name’s Sebastian and I’m a sixteen year old aspiring game dev from South Africa. I think that covers everything important..

 

I stumbled (well actually crawled on all fours) out of bed at 4am on Saturday morning to read the theme announcement. I had spent a half hour the previous night sketching out some rough ideas for the themes I thought most likely, so the first thing I did upon hearing the theme was minimalism, was to just flip through my notebook to find the relevant page. This is what I found: http://bit.ly/theLDSketch

Not the most awe-inspiring of GDDs! But I decided to go with the idea anyway.

So the first hour or so I spent just getting a basic text system down where I could give the program a string array and it would type it out nicely and not go over the edges or anything silly. And of course I also had to get the player’s side to work with basic functionality like backspacing and detecting commands. Nothing too difficult, but it still took a while, groggy as I was.

Then I decided I should probably give the player some context, so I started working on a few basic story ideas. At first I wanted to have a kind of Portalesque story where computers have taken over the world and are performing tests on humans to determine whether or not humanity poses a threat to them. I had some vague ideas of making it so that you had to do very badly in the tests so that they wouldn’t wipe your entire race out, but I struggled to find a way to turn that into enticing gameplay. Unable to find a story I was satisfied with I decided to leave it until later, but I did make the decision that I would take a rather dark theme. In general I prefer more light-hearted games so I’m not sure what the logic behind that was, but anyway…

At this point I thought it was time to start working on some actual gameplay so I decided to create the first minigame – pong. Pong is pong, so it didn’t take much time to make (although I do think I could have implemented it a lot better than I did) and I started thinking about some other ideas. In retrospect I think I should have sat down and planned all the minigames out because as time went on I started running into problems with things like the multiple games requiring the same controls and I didn’t want to make the player use obscure controls like IJLK to move around, because thats just completely unintuitive. Another thing I feel I should have planned better is the layout of the game. I am quite happy with the end layout, but I must have changed it at least six times during the creation process which really slowed things down. One of the main problems there was that I couldn’t figure out how many games should be playing at once. I also wasn’t sure if I wanted to keep the players’ terminal open so they could type stuff in, for example I was going to have a minigame where the computer would ask you a random question and you’d have to input the answer before the time ran out.

By the end of the first day I had a fairly decent system where I could add games in and the terminal would output what game was being added and what controls were required to play it. I had only managed to complete two minigames however, pong and a falling block dodging one. At this point I was unhappy with my progress and contemplating spending Sunday just relaxing and not submitting my entry after all. When I woke up I decided I might as well just see where the game would go if I spent another day working on it.

I dawdled quite a bit, watching some tv series and the like and by midday I had only managed another three minigames. I decided I should at this point turn the game into something playable and from there I could refine it and add more minigames if I had the time. So I decided on a final layout with two games split horizontally and the computer terminal on a strip on the side. After some intense arguments with the framework I set up on day one I had everything working semi-smoothly.

Now it was time for the part I was most apprehensive about – the music. I play a bit of piano and I have a nice little midi keyboard that I’ve never learned to use properly, but I’ve never actually tried to compose anything. Well I did try once, but the results of that once was the main reason I was feeling so apprehensive :P

After listening to the Castlevania song Bloody Tears a bunch of times over I finally started bashing away at some keys and after a little over two hours I had something that could be considered more or less not completely unbearably awful.

I then put everything together, spent a frustrating hour chasing down elusive bugs, spent an even more frustrating two hours trying (and completely failing) to get my mac, pc and linux builds to not completely break when downloaded (not sure if there’s something wrong with dropbox at the moment or what) before finally admitting defeat and just uploading a web build.

So I think in the end I’m quite happy with my game. I’ve received a number of positive responses which is very gratifying. Despite some ups and downs my overall impression of the event is a very good one and I’ve found it extremely fun playing through everyone else’s games. I think the main thing I need to remember for next year is simply more planning!

Well that’s it for me, didn’t mean to write quite so much..

Cheers – Seb.

Tags: First Ludum dare, postmortem

0

This entry was posted on Wednesday, May 1st, 2013 at 7:32 am and is filed under LD #26. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Background:
This was my 5th Ludum Dare 48 and the 3rd time I actually submitted a game, so that alone made me happy =).

For the first time in LD I didn’t have any stress and the design phase didn’t feel like “endless grind”, which for some reason usually happens for me.
This was also the very first time I’ve ever used Love2D and Lua for well, anything, and I really learned valuable things in just one short weekend (actually made me order the Programming in Lua third edition to help me integrate Lua scripting to my work-in-progress engine).

In general this was the most fun I’ve had in LD ever, I’m very satisfied with my game, mainly because of the earlier mentioned “no stress” approach and that the tools were new to me.

The short story
I woke up at 06:15 Saturday. The theme was announced 05:00 Finnish time, but I’ve learned from previous LD’s that it is much better wake up well rested even though it means hour or few head start for other than to wake up feeling like you know what and just forcing yourself to design.

When I noticed that the theme was minimalism I immediately knew that I wanted to be shown in the game-play itself rather than just graphics or audio-visuals in general.
Took me a good few hours to get the design down, and at first I kinda doubted it, but when I started to actually working on the development I grew more fond with it.

The coding went fairly well even tough working on a new language always poses its own difficulties. If I could change 1 single thing from Lua I’d definitely would prefer that variables and functions would need to be declared before used. This might be just because of my own sloppiness, but I had few occasions where I had typoed some name and the error didn’t pop up until much later.

Art has always been my main nemesis especially when the schedule is tight. I just can’t do it. The game only has 2 distinct tiles (and few variations of them) and a few sprites, yet making the art took about 3 times as long as the coding… not good!

Music is along with coding my other passion and I had a real blast making the “main theme” for the game. I had this strange inspiration/”image” in my head of a sad Russian cartoon when composing the song and I think the music kinda fits that. I’m not saying the music is any good, but the fun alone I had making it, made it very worth while.

The Good

No-Stress approach, having much more fun, which echoed itself in to the end result I belive

Learning new tech gave the event even more meaning for me, which helped me motivate myself

Simplistic design, which could’ve been easily expanded if I so should’ve desired

The bad

Art, as usual, takes way too much time for me and the result itself does not justify the time spent

The verdict
Not even knowing (or really caring about) the results yet I can say that this was the best LD I’ve had so far!

Some screenshots from development
Coding in Geany, a great editor for Linux & Windows
Composing in TuxGuitar

EDIT: Ofc I forgot to link the game in the post, so here it is: Grasshopper

Tags: development, post-mortem, screenshot, story

We’re done! Play it here: http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=10296

Tower is a very simple platformer with an integrated level editor.

We are very satisfied with the result, although we did not completely finish it. We are currently in the middle of final exams at our university, so we did not have as much time as we would have liked.

What went right:

We wrote the whole engine from the ground up, using my framework, Inugami, for graphics. There are no external dependencies for the Windows version, and the Linux version needs only very common shared libraries, such as GLEW and all the silly X libraries. The engine’s infrastructure is very extensible, which allowed us to add new functionality very easily. Getting things on the screen was trivial.

What went wrong:

Too much time was spent making the integrated level editor. The level editor is awesome, but the actual levels we made for the game are very terrible. We also didn’t have time to add two more planned enemies or sound. I’ve never submitted a game with sound because I always wait until the last minute, but it takes more than a minute to make sounds. In fact, the source code has a bit of sound infrastructure, but it’s all commented out.

Overall, we had an overwhelming amount of fun while making this game, and we plan to keep developing it until it reaches our original vision.

Uploaded the time-lapse for ‘My Mini Castle’!

Link to the game here

Iceberg Explorer is now avaible for Windows and Linux (32bit and 64bit).
Best wishes to everyone who helped me with providing the binaries.

“I arrived at the small iceberg I want to explore. The chance to find something here is minimal, but
I’m optimistic. Hopefully I’ll become a famous explorer and make my mummy proud.”

Start exploring the iceberg

I had some grand ideas for this game, but of course the 48 hour time limit forces one to be a pragmatist. It was going to be all the best bits of Age of Empires or Rise of Nations, mashed into a side-scrolling, minimalistic theme.

The list of “essential” features missing is endless, but i’m still pretty happy with the result.

 

http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=4380

http://aaroncowie.com/LD26/

The minimalism theme was to extend to the controls which should be all intuitive, gestural based with little to no HUD. Of course such a thing is hard to achieve while frantically debugging some of the most confusing bugs I’ve ever encountered (e.g. Flash/Flex classloader issues and circular dependencies… yuck).

The final game became a kind of ambient war simulation that you can just sit and stare at for ages.

Despite being a programmer, my strategy was to begin with the art. This was very out of character for me, but I thought I’d give it a go and I think it paid off pretty well. The focus on art forced me to distill exactly what I wanted the game to “feel” like rather than to stick my head into the code and lose perspective of what i was trying to achieve. I strongly recommend it to anyone who’s reasonably confident in their game dev skills and wants to try out a bit more game design.

Over the coming weeks I’m going to give this some polish and release it in some form (maybe android/iphone) and then move towards an HTML5 rewrite and fully featured version.

All in all a great experience. Will definitely being doing this again

 

Play it Here! http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=10976 Lack of sleep, FlashDevelop open three days straight, and twenty tabs open at all times littered with documentation? Yep, it must’ve been a Ludum Dare weekend! It was a total blast, and I think we must be doing something right because this last LD was the most fluid and least stressful yet! I think Stargazers is our most complete game and one that I would enjoy working on some more.

It took us a few hours to decide on a theme but it eventually blossomed into a game idea. We wanted to keep the gameplay as simple as possible to fit with the Minimalism theme so we decided that the mechanic would only be clicking on stars to connect them. We got some incredible feedback already on features people wanted to see included to keep the gameplay from getting repetitive and stale and hopefully we’ll invest some time into a post-LD version of the game to incorporate some new ideas and mechanics. For this LD though I think keeping it minimal was a necessity and it helped us really polish the game.

Once the idea had been decided upon I started prototyping the gameplay while Cake started work on the graphics. It didn’t take long at all before there were dots on a screen that could be clicked and linked up to each other, then a bit more and the level would “end” when you linked back up to the star you started with. That was all well and good but we needed a way to evaluate how well someone did. I ended up doing a bitmap comparison system that draws the “correct” constellation and compares it to the drawing of the constellation the player created. It’s not a perfect system but it worked well enough.

The most fun was probably working on the moon cycles. Looking up documentation for curveTo and tons of examples of people using it to draw circle segments so that I could accurately represent a shadow traveling around the moon, it was awesome. We originally had bigger plans for it, and you all might see the fruits of those ideas in our post-LD version of the game.

As always, LD was totally worth it. I would trade away restful weekends for LD anytime. I can’t wait to play all of your games! Now then, we’ve got games to play. Thank you all for being such an amazing community!

I can’t believe LD is already over. D: I feel like it goes by way too fast *EVERY* time. Zeik and I had a blast this time, having barely recovered from spending 3 scorching days at the Coachella Arts and Music festival the weekend before. And honestly, “Stargazers” is definitely one of my favourite games we’ve made to date. It’s the most complete game we’ve made so far IMO, and I’m really proud of how it turned out.

Time

Time was awful to me this weekend.  I had to periodically pull away to work on school projects and google hangout with classmates, or friends would come over and hang out. >.< But at the same time, we dealt with our time management a lot better this time around than in the past. Less crunch time and more sleep as well!

Art

I had spent the whole month or so beforehand gathering different images to absorb for inspiration. While I only used a fragment of those images due to the theme, I was fairly happy with the way the art started coming together. I was actually pretty disappointed the theme was Minimalism. I felt a small sense of obligation to hold back on what I originally intended to do art-wise. My original ideas and direction for a LD game were much darker, detailed, and elaborate. But at the same time, the art style really helped in having me work on less detailed art work and more of the game’s general visual design.
Lessons Learned I think next time I’m going to really try to put less heart and determination in pre-deciding the game’s art style before we even make it! Stargazers looked great, and my process was slightly hindered by begrudgingly changing my original ideas to something new. I also need to sketch more! I’m starting to get out of the habit of sketching, and I feel like it’s making my art slowly more and more static and less interesting.

Also, something that Zeik didn’t mention is that this LD is marks the 1 year mark of when Zeik and I started making games!

Cheers, Zeik! You’re a fantastic and amazing partner!

Tags: postmortem

6

This entry was posted on Wednesday, May 1st, 2013 at 9:24 am and is filed under LD #26. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Hello, here is a little postmortem of my entry on LD26 : !Complex

First, you can find a time lapse here : http://youtu.be/HBs6oL3Qv1k

I have made an HTML5 game using THREE.JS to manage matrices and vectors, and mostly because i like making shaders !
WebGL give you a lot of raw power throught the GPU, that javascript can’t.
My view of the theme was : making a game looking simple, but by playing it, the player will disturb it, transforming it to a more chaotic or complex version.

I started by making a voxelize character, all proceduraly, starting from a single cube spawned on the edge of some primitives : cube, sphere, and capsule.
Then, the individual cubes are snapped on a 3D grid, witch give you this proper voxel style, and enable you to change the resolution by changing the size of the snapping grid and cubes. Animations are made from sinus functions apply on rotation of individual body parts.

So enemy and your character are simple bix flat boxes when you remain still, but become a recognisable character when walking or fighting. The ground also is plain white and become shaded and lighted when you move around.
At this point, the simple style was a little bit unreadable, and so when you prepare a jump, you cant even seen platforms edge while remaining still. So i added an edge detection pass that draw lines around everything. A last thing i added is the red “lava” under the ground, because a lot of time, i was falling into death without even knowing the ground wasnt there. With a bright red, at least you cant miss it.

The level only use a heightmap to displace some cubes, and a spawn map to place the enemy spawning locations.

Then, the gameplay was a bit hard to do, specialy with my basics skills in javascript. I made collision system, pathfinding, and it took a lot of time, and the enemy keep falling into trap or getting stuck on corners. In the end, i have managed to avoid falling, but not the getting stuck one.

In conclusion, i am prety satisfy with the graphic result, even if i wanted to do more by realy morphing the ground and adding cool voxelized FX. The gameplay is realy simple but working, i just need more content, meaning several enemy types, bosses, some weapon or buffs for the player, and a final ending like Fez !

I realy like the LD format even if its hard on sleep time, and it’s like the only way i can motivate myself to finish a game ! Thank you all ! Now i go back to rating and playing.

Finally getting around to posting my competition entry here on the blog! What a couple of days that was. This was my first Ludum Dare and it was truly quite an experience. I guess I was still recovering! Hehe. In fact, this is my first game ever, so let me know what you think of I Know Nothing.

I will write a full postmortem hopefully in a few days. I also hope to port it to HTML5 but I’m facing some strange bugs that I have no idea how to fix. I will post an update here if it works.

Looking over the games there are some real gems. I’m amazed at some of the creativity on hand but really bummed that I can’t check out most of the entries that are hosted on dropbox due to my current location (I assume).

Either way I hope you enjoy this little thing I made. Your feedback is welcome and thanks in advance.

Tags: LD#26

Like everyone else now I have to vote other games, some games are very fantastic. Good job everyone =)
A normal developer just play other games and read comments of other people that commented your game.

And here is the problem. I can not only play other games, I have to play my game too, because if someone want to play and no one is playing he can not test the game and vote!

So, I’m alt-tabbing every second when my game… (wait.. someone just entered in the game)… ok back, what I wanted to say? Ah yes, so I’m alt-tabbing and watching if someone want to play my game and lets play together and chat a little with him.

 

This is very stressful, I have something like 30hours of developing and 60 hours of playing my game! haha
Playing and chatting with other people that have to review my game is very fun. I’m becoming a maser in my game, so I have to slow down a bit my skill and let him win sometimes.

Then there are some oddities. There are some people that log-in, play something like 20 second, I kill them and… they log out and vote. Ofc I don’t know what they vote, but what you can understand about a game in 20 second of playing? Log-in another time, I promise you I won’t kill you! T_T

 

my game is a easy multiplayer game made in DART (lang) using websocket.

Here is the link if someone want to play =) http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=8548

Here’s the post-mortem I wrote for my blog. Great way of reflecting on the game dev process!

My last LD experience in December didn’t quite go as planned, but was still lots of fun. This time I had even less time than the meagre 48 hours given to compo participants. I had played Volleyball all Saturday and was too tired to even switch on my computer in the evening. Sunday morning I slept in, woke at 11 a.m., had breakfast and only then took a peek at the Ludum Dare theme: minimalism.

Finding the game concept

A minimalistic game seemed possible to do, especially with lots of experience gained since the last LD through making games for One Game A Month (#1GAM). so I started brainstorming. Soon the basic visual concept was clear: 2D & cubes. Using physics was intended at first, but later was dismissed, because the game worked fine without, minimalism was the theme and physics are always a hassle to work with.

The first gameplay idea was to have a ‘player cube’ that the player would use to collect other cubes of the same size only. If the player cube collided with a larger cube, that cube would split up into smaller parts. Smaller cubes would simply be destroyed on impact with the player cube. I wanted to make this concept more dynamic, so the thought was to make all cubes grow in size in random intervals. This way, cubes that were the right size would become impossible to pick up and would have to be split up again. At the same time, smaller cubes would grow to the right size. The cubes would move randomly and colliding cubes were supposed to merge into larger cubes.

To add some complexity, I then added colours. Only cubes of a specific colour could be picked up. The correct colour would be indicated by the interface which would change randomly. The interface itself needed to be simple and clear to read but at the same time very flashy so the player would notice its changing colours immediately.

Time for a break. In my case this was a couple of hours during which I did some non-game related work.

Prototyping the game, and changing it

I built a prototype in Unity3D and found that discerning the correct cube size was very difficult. That’s why I tabled the cube splitting concept and used the different cube sizes to indicate differently score values.Picking up a cube of any size would now not split it but randomly spawn 0-5 new cubes of random size. This also removed the last physics elements the game had. Any cube pickup of the right colour would score points, the wrong colour would subtract them. Since picking up small cubes is more difficult they got the highest value. Logical, but a bit counter-intuitive, since bigger is usually considered better.

Giving the player a purpose

The game’s goal was still unclear at this point, I simply had a random cube distribution, a cube pickup, and a scoring system. But what was the goal? Why would the player keep playing? He wouldn’t. At some point the screen would simply be full of coloured cubes making it impossible to discern right from wrong and the player would have to give up.

To remedy this situation, I introduced a target score and a countdown timer. Countdowns give the player a sense of urgency, a drive to reach the target score in time. To make the game more interesting to continue, I added a level system that increases difficulty with each time the player wins a level and continues. Difficulty is governed by time, target score and the frequency of colour changes..

Adding the potato

I love Easter eggs and hidden features in games and my game wasn’t very funny so far. That’s why I joined the Official Potato Challenge by the fabulous McFunkypants (creator of #1GAM) and added a random potato feature. The potato is a super scoring (50 points) item that flies through the screen. Its worth was later reduced to 25 points because it was too overpowered.

Adding sound

A soundless game is half as fun as a game with great music. Sword & Sworcery would have been pretty boring without it’s fabulous music, no matter how great the graphic style is.

Sadly at this point I didn’t have much time left, so I had to content with making simple pickup sounds for the cubes. A ‘ding’ for a correct pickup and a ‘dong’ for an incorrect one as well as a special potato pickup sound and level win and loss sounds (those last two, by the way, didn’t work properly in the compo entry version). I used the free Software NanoStudio for this.

Adding a start & end screen

Finally, I added a startup and an end screen. The start screen got an intro text with explanations of the game & controls, the end screen features the statistics (points scored, cubes picked up, time played etc.) as well as instructions on how to continue and quit. There are two different texts, depending on whether you won or lost a level.

Post-compo: Fixing bugs & making improvements

The rating & comment system of Ludum Dare is a great thing, because you quickly get feedback from other game developers. They brought attention to some minor bugs and many said that they found the immediate colour switch annoying or irritating. They wanted a short warning before the change so I added a feature that makes the GUI flash briefly before a change. Initially I didn’t want any warning because I found it funny how you steered towards a blue cube and right when you reached it the colour changed to green, but getting input from other people changed my mind.

The other major improvement was mainly intended for the mobile version (see next paragraph), but also helps on the desktop / web versions. Originally, the player could leave the fixed camera field of view and move outside of it. With keyboard control, this isn’t a problem, because the controls are quite accurate and the player never gets to be very fast. On mobile devices, using the tilt acceleration of the device for controlling the player cube, it would shoot out of the screen too easily. So I added a boundary (created dynamically for different screen sizes) that resets the player on the other side of the screen.

Porting the game to mobile

Having finished the game, I realized that it would perfectly fit mobile devices, and also be fairly easy to port. Only the player controls would have to be changed from keys to a tilt-acceleration control.The main problem was that I only have a Unity 3.5 mobile license and had made the game in Unity 4. You can’t just open a Unity 4 project in 3.5 – the engine has changed too much for that to work. But some things can be simply copied & pasted: assets like sound, textures and models as well as the scripts. Scenes can be imported but not opened, GUISkins, materials and prefabs crash the editor immediately.

Since my game mainly consists of scripts and only 2 prefabs, 2 GUI Skins and 3 materials, remaking these and the 3 scenes wasn’t too hard. That’s the advantage of programming as much as possible and using very few non-dynamic game objects.

I then added the Input.acceleration commands and built the game to test on my nexus 10.
Here’s a first look:

The game ran smoothly, but I noticed the above mentioned problem of the player cube falling outside the camera field of view. The second problem was the text size since mobile doesn’t allow dynamic font resizing that I had used in the web/desktop versions. Thirdly, allowing the device orientation to turn the game automatically is really annoying when playing a tilt-controlled game. I fixed that by allowing auto-rotation only in the start and end screen and fixing rotation as soon as the player enters the game.

The game that could have been

In retrospect the first concept with the splitting cubes could have been reworked in a different direction that would have played out fine. The problem of the user discerning different cube sizes quickly could have been removed by making different shapes. A cube would split into triangles, the triangles could split into circles and additionally, each type could have been colour coded, too (which would remove the colour-matching element, of course). I think I’m going to make that game sometime soon. 😉

Another way of making cube sizes more clear would have been to add a dimension. 3D cube size might be easier to discern than 2D cubes.

Where to go from here

What is the future of this game? What can it become and what could it become? Here are some ideas: online (global) highscore & music. An endless level system, implemented via a function that simply takes the difficulty up a notch each time a level is won and the player continues (currently that’s a fixed function for 5 difficulty levels).

Final words

The jam was great fun! Thanks to all who organized it and participated & special thanks to everyone who rates my game 😉

Play it now

Here’s the LD game page: http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=18208

The game can be played in both compo (v1.0) and post-compo versions here: http://david-arndt.de/cubecatcher/ (the game source can also be downloaded there).

 

Tags: cubecatcher, post-mortem, unity3d

When the theme first came up, “Minimalism”, I wasn’t happy or sad… I was more like… whaaaa? So, off to Wikipedia I verily did trundle. The part of it that I was most familiar with was art… and art discussion… and art discussion makes me think of art critics, and art critics make me think of the wonderfully plummy-voiced UK art critic, Brian Sewell, so I decided early on that the game would have him in some way.

This is not the game I intended to make!

Original Plan
… was to have Brian as a sprite and similar to Ghostbusters (on the ZX Spectrum), you’d move around a grid city, except this would be London and you would be chasing art students who are turning London’s lovely landmarks (“St Paul’s Cathedral”, “Nelson’s Column”, etc.) into Minimalist versions and you had to race to correct them, all the while with Brian shouting “ghastly, you rotters”!

What went wrong

Well, it soon dawned on me the amount of sprites that I would have to draw to do this. There was (at a minimum) 4-directional Brian, a series of buildings, detailed landmarks (in both real and minimalist version). So, if Brian wasn’t going to be running and shooting, he could be talking!

My flat is rather small, and I was embarrassed that my neighbours might hear my Brian Sewell impersonations, so I took my little Zoom H2N into my office as no one was about and went BRIANTASTIC without a care in the world.

What went right

I started with a small sprite before I even got the game together and very much built it on the fly (as you tend to do in LD).

A fair bit of time was spent in Unity3D learning how to draw dynamically on a Texture2D. As I was pressed for time, I ended up using the native Texture2D.SetPixel, GetPixel and SetPixels(Color[] ) functions… which actually turned out to be really fast!

The more I use Unity (which I only started using for the last LD), the more I fall in love with it, and how it makes it so easy to get your ideas moving as quickly as possible.

A game in which you can bite your own head !

We now have a post-jam version, with easier to use Creature Editor!

http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=8588

We plan on continuing to improve it, and remember, the blur is not a bug, only that your creature doesn’t have eyes.

Enjoy!

 

 

 

Hi, there! Here are some links while we prepare a postmortem…

Entry Page (play it in your browser!)

Facebook Page

Thanks to all of those who voted and commented on our minimalistic take on minigolf!

 

Tags: LD#26, minigolf, radius minigolf, unity

Minimalist Timeline

Saturday morning , around 6:00 CEST ( Paris), I woke up and immediately turned on my computer. After some everlasting minutes, I saw the theme : [Minimalism]…ok: Challenge accepted!

[Brain)]: “so Minimalism…minimalism….hum…[open google]…ahh!…That’s great…yep there is something there…[See Mondrian stuff]Uh?…wait a minute…oh yeah!….YEAH! This is THE THING I WANT to do!”

>>|Saturday|6:40 am | CEST|: CONCEPT DONE <<

[[  Code, code, code…]]

>>|Saturday|3:40 pm | CEST|: AVATAR CODE DONE <<

[[  Code, code, code…]]

>>|Sunday|00:20 am | CEST|: CORE GAMEPLAY DONE <<

[[  Code, draw, code…]]

>>|Sunday|02:30 am | CEST|: SLEEP TIME! <<

[[ Brain’s dream : code, code ,code…]]

>>|Sunday|07:00 am | CEST|: What year it is?What is that place?….Aah right: Ludum dare! <<

[[  Code, code, code…]]

>>|Sunday|1:40 pm | CEST|: GAME NAVIGATION (menu&stuff) DONE <<

[[  Code, rage, code…]]

>>|Monday|2:50 am | CEST| H-1h: LEVEL IMPLANTED <<

[[  Think, write…]]

>>|Monday|3:10 am | CEST| H-30m: PROJECT NAMED <<

[[  Write…]]

>>|Monday|3:30 am | CEST| H-30m: PROJECT PUBLISHED <<

[[ -blank-]]

A thousand lines of code and a blurry vision later, I had a little “game” (without real tweaking ) that I threw in the arena and went to bed.

Today, I wrote a post-mortem about it…

What went right ?

•  Using the tech:  at least enough to be comfortable for coding the whole core concept without researching and being stressed about how to do every little things.

• Having fun : what a relief it is to just enjoy the challenge, the community and all the little things that community produced.  As a result, I just enjoyed the whole LD and even more, touched from the tip of my finger this “territory”: where you built your game without be harassed by technical pitfalls or unknowns life crisis and having fun by doing it! Well it’s the key…

• Loving and quick idea/concept : or how to have a core concept about forty minutes after waking up ! Well, as a “beginner programmer”, to have a concept that you love,that  you are capable of doing it and this the earliest possible  is a rare delicacy: that allows you to be focused on the damn coding thing!But it has its hidden traps…see below!

• Mondrian : I know…It wasn’t the theme…But I do think it help me designing the concept and that concept is well adapted to the theme as a minimalist dungeon explorer!

What went wrong ?

• Too focused on the production aspect: At the point that I didn’t pass much time on the conception: questioning the theme, thinking about different ideas, deepening the core gameplay. I did have others ideas but I quickly chose to go with that’s one. It’s not entirely a negative thing to quickly choose but it became a major weakness if you didn’t clearly identify the core features of your gameplay, the ones which are literally the border between an experimental “thing” and a game(with defined rules, a goal…) .To be too much focused on the tech part ended like: – My brain : “Is it a scoring game?But you have too much to do. So…here, write a score formula in 10 seconds, it will do! Trust me…” Ahem…So this time, I did have flaws in my game design and I didn’t said :” Stop! Stop producing like a mad man and take a moment to think about your gameplay!”. Next time, I will…

•  No level Editor: Raaaaahh! I can’t use a tiled editor and I don’t have time to create my own level editor. ‘have to place every little things the old way! (by the way: thanks Mondrian for the basic Level Design.) – My brain(again): ” So we said about 4 or 5 levels? How about one fake-tuto level and one basic level? Yeah…That’s it! Oh! And you have to forget the polish&sound time because this task will take you every minutes left…Have a good night!”

What I failed to do :

As expected for a 48H project, There is many defaults but I only have one little thing about which I’m a bit mad:

SOUND !!

Why I treat you so badly, so unfairly? Because you’re not important? because I don’t have any time left to make you? It’s a mistake… Sounds = Universal Feedback,  Music = Mood levels up like hell! In my case, the solo use of the sound should have greatly enlightened what happen to the avatar entering my little white rooms. So I failed that part…(this time at least!)

What’s next?

 – For the project itself – (link)

I want to take time to polish that one. That means:

• Add sounds,musics…anything even noise!
• Change Avatar’s controls
• Add dynamics feedback.
• Insert a real Scoring formula…
• Maybe, potentially… create a level editor.

 -For the next Ludum dare-

Be even more comfortable with the tech…

…for really focusing on the concept and theme!

Make and use sound, music and noise !

Having fun again and again and forever…

Tags: journal, LD#26, post-mortem, postmortem

I’ve now ranked just over 10% (161) of the compo entries. You’re all amazeballs. I’m incredibly impressed by what everyone is able to accomplish in a weekend. But there have been a few that have really stood out to me. So, here’s the start of my LD #26 must-play list. I chose games-to-rank fairly randomly from the rating listings. And, I only played web-based games (unity, flash, html5, etc.) so if there wasn’t a port, I didn’t play it. Sorry. These are also all compo games, no jam. All links go to their LD rating page.

0. My game, Distradiction, of course =). A short and sweet game of distraction elimination. I’m happy enough with it I’m pursuing a post-compo version.

1. You Must Escape, a personal favorite. An incredible mood game that is an elegant, beautiful implementation of a great concept (echo-location) and it fits perfectly with our theme.

2. Balls, Balls, Balls. A physic puzzler which was easy to pick up, yet became delightfully infuriating. Simple to play, but complex to finish with the ideal (or minimal) completion.

3. AlterSpace. A fantastic, and fun, game mechanic. You’re both the editor and the player of the game. Would like to see this developed more, as it’s currently a little too easy but awesome and inventive idea.

4. O.R.M. Ontological Resource Management. Not the best looking game, but an addictive resource management game which kept me playing a while to maximize my output in the restricted time. (Took me a little while to understand the mechanics, but worth checking out).

5. Boximalism. Unique and intriguing game mechanic. Pretty, and once I played a few times to understand the mechanic the developer was after (there’s a spoiler in the comments if you can’t wait) I had fun trying to get a personal high score.

6. hru. Relaxing, pretty, 3D game with some pleasant audio that was still pretty challenging. Bounce a ball higher to win, with every bounce a new note. Nerve racking getting close to winning (saves wouldn’t be missed =). A great implementation of a quality concept.

7. Colorus. Simple game of switching colors to hide whatever is about to hit you, that was extremely well-implemented. Smooth, good learning curve, humorous,  and a bit addicting.

8. 0. Elegant puzzle game that is trixy to play. Has a great aesthetic and interface.

9. Minyrinth. Addicting every changing, moving, labyrinth game that will stress you out a bit (recommend playing without sound).

10.Equalizer. Very clean puzzle platformer, with a cool gravity based mechanic and a great implementation of good learning curve.

11. Mesh. A clever game where you add torque to a gear to move it around and to connect with another gear. It’s fun, and well-considered.

12. Love Connection. A very polished, charming, game that’s will make you smile. Not a complicated (or particularly hard) game, but incredibly cohesive.

13. Solix. Cool mechanic where you change shape based on what color you’re on. Great concept, but still needs more polish to really shine. Still worth checking out.

14. Join. An interesting take on a familiar (snake game) mechanic. Delightfully polished, with a good learning curve and well-thought-out puzzles.

15. Cube cube cube. An enchanting variation on tetris, where you rotate to capture falling pieces. Smooth, well-implemented and a bit addicting.

16. Just for fun, I’m including Get the Potato because the audio is redonkulous and funny. The game is meh, but clean.

 

So, that’s a few games I’ve played which I think are awesome. Which games do you think rock? What inclusions do you disagree with?What web-based games should I play next?

Bonus games:

Ponkmorten. Making a game on an (actual) Commodore 64 over the weekend.

Monoboy. A jam entry I thought was particularly pretty and fun.

The Lamp. A jam entry which was creepy yet delightful to play.

 

 

I took into consideration all the feedbacks and I currently working on a new boosted version of “Text adventure” planned to be released to “One Game a Month”.

 

 

forthcoming :

– list of available directions directly on screen.

– a real goal.

– some shortcuts/alternative commands (eat, use, watch … ).

– bugs fixes.

– ton of new rooms / items.

and more …

Thank you.