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.
