Ludum Dare, a lesson about self management.

During the weekend of the 18th and 19th of April 2020 I joined my first game development competition, Ludum Dare. You may ask, what is it? Long story short, Ludum Dare is an online game development challenge/competition, that started back in 2002, and that had 45 (this one is the 46th) editions ever since.

TL;DR: here is what I built https://ldjam.com/events/ludum-dare/46/feeding-mr-biggs , here is the repository on Github, and here is the game engine I used. The conclusions are at the bottom of this page, no links for that.

The goal is simple: you're given a theme (this time  called "Keep it Alive") and within 2 and 3 days you have to create a game. From scratch.  There are two categories: the Compo (or 'Hard Mode') that gives you 48hrs, and the Jam, which allows you to code for 72hrs. The Compo (the one I joined), requires to share your source code, create all assets within the 48hrs and to work by yourself. More informations here, on their website.

Does it sound ridiculous and insane? Yes, because it is.

I always wanted to participate and I've always felt a profound sense of admiration for all the hardcore developers with the right skill set and the will to invest a lot of energy and time into the creation of a short game, but I have never felt ready.

That is because I wanted to use my own game engine, a project that has been in development for a few years and that has never been good enough to produce an actual game, until now (I'm still writing an article on why I built a game engine).

The entire event quickly became a lesson on how to manage time, priorities, resources when you have to deliver something with strict time constraints.

So here is what happened, and what I learnt.

The night before

The theme is announced at around 9PM EDT (approx 2AM in Uk): "Keep It Alive". Whether it's a competition like this one, a hackathon  at your workplace or just a regular event, the theme is what sets the mood: it might create confusion and disorientation if  it's not clear or if it doesn't give enough freedom. I found this to be hitting just the right spot: there are endless possibilities and it's not too broad and generic.

My mind goes immediately to what will be the final game: a robot has to collect crates of food around the map and feed the last human on Earth, hence keeping him alive.

Here also comes the first big decision of the competition: some people might be tempted to grab a cup of strong coffee, get ready and start writing some code/creating 3D models or start designing levels.

I didn't do it. In this specific context, it's 2AM, I was tired and also incredibly excited, so everything seemed like a great idea. There's a high chance it's not.

The right thing to do is to go to bed. Sleeping on the idea you just had will help your brain process it during the night, so you will probably wake up with more details or an entirely (and potentially better) new idea. Side effect of sleeping, you will be rested.

First day

I woke up thinking about the idea I had the previous night. The concept still seemed to fit the theme so I decided to go ahead with it. This is a crucial moment because you're facing the most important decision of the next two days: whether you should keep your idea or start with a new one. Don't be afraid of discarding what you had entirely and start from scratch: it's definitely better starting with something new  rather than keep working on something that is not convincing. I didn't have time to regret not having changed my mind earlier, so I tried to be as critical as possible, following a simple rule of thumb: the simpler the plan is, the better.

I then decided to start the day following my usual routine: prepared breakfast, had a nice shower and filled my mug with coffee. The last step is definitely the most important, coffee was going to be a very good friend for the following two days. I felt like that sticking to a normal routine was going to help me get into the right mindset, and it worked perfectly.

Prepare your workspace

I understand that there hasn't been a lot of coding so far (well, no coding at all to be honest), but I wanted to make sure the workspace was ready to go.

I'm not very good at focusing on something for a very long period of time, so I wanted to reduce the amount of distractions around me. So I cleaned up my desk, removed everything that wasn't strictly necessary (except my coffee mug) and grabbed my laptop and what would become the most important tool of these two days: my notebook.

Before writing the first line of code, I wanted to plan and design the features of the game, decide which tools I was going to use and which language. Being a 95% Javascript developer, and having written my own game engine, these two decisions were pretty obvious. I also thought it didn't make sense trying to learn a new technology or try using a tool I wasn't familiar with (e.g. Unity).

After spending some time designing features, I finally opened my laptop.

Priorities, priorities, priorities

Where do we start? I had two main paths ahead of me: start doing some 3d modelling or implement the base game logic and mechanics. Even if the first option is definitely more exciting, I went for the second one for obvious reasons: I thought that the first was going to be about making sure the game was playable and with working mechanics, leaving the "art" for later.

The approach I used is similar to creating a new Web application: the first step should be implementing the logic, using placeholders and wireframes until the layout is ready to be created.

So this is what I did: I used cubes, wireframes and placeholders before spending time with a 3D modelling tool.

The goal for the first day was simple: have the base functionalities in place, and iterate the next day if necessary. There is something quite hard to understand for things like this competition: it's perfectly fine if the final product is rough around the edges. I always try to reach perfection (and obviously failing every single attempt), but this time it was obvious that it's much better to have something playable and complete, rather than perfect and bug-free. Also, there is no time to over engineer your code, so it's also fine to not being using best practices: don't complicate your app, iterate later and set goals you can reach.

Something really valuable I learnt during the first day is this: feedback. If you have someone around you like a partner, family or friends, show them your project/idea/whatever you have ready and listen to what they say. This is the only way for you to get some real feedback about what you're building. So I did, and found out initial flaws and inconsistencies I then fixed.

If the only person giving you feedback is yourself, it's like a snake biting its own tail.

At the end of the first day I had a working prototype, and the only thing that was missing was a bit of "sound design", 3D models and a nicer ui.

I didn't want to continue coding the entire night, I thought it was going to be pointless and potentially counter productive. The more tired you get, the higher the chances of introducing errors. Plus, this is like running a marathon (no, never tried running a marathon, but tried preparing for a half, feels like a valid comparison to me) so I tried being wise with my energy consumptions. I kept myself hydrated (coffee is 90% water) and had regular meals. I also took breaks here and there, which prevented me from losing my mind.

Second day

During the second and last day I followed the same routine I had during the first day. Prepared my workspace, had breakfast, showered and filled my mug. It was now time to make things look prettier, improve the UX and work on 3D models, as well as adding sound effects and fixing eventual bugs.

Nothing major happened today, except my fights with Blender and my absolute lack of modelling skills.

There are two major steps to face during the second (and last) day of development: testing and distribution (aka deployment).

Testing

First of all, once your game is completed, play it. You should have already conducted some tests during development, but you should play the game from start to finish so that you can fine tune levels/difficulty or whatever parameter in order to keep the player balanced between frustration (game too hard or impossible to understand) and boredom (game too easy, too short, too obvious, not challenging). This is also the perfect time to decide whether to cut or not incomplete features: remember, it's better having something complete than perfect (at least for a competition like this one).

Remember the guys you used when you asked for feedback? Take them out of the box where you put them, it's their time to shine again. Make them play the game, listen to what they think and fix/change whatever needs to be fixed/changed.

Distribution

This is the end of the journey. Or is it? You just completed something and you can't wait to show it to the world. Only question is, how?

I decided to go with a Web application, which makes things much easier than desktop applications, mobile or console games. Now, the initial decision of which technology to adopt is tied with the final decision of how to deliver your product: a web app needs a place where to be hosted, mobile, desktop and console games need permissions, complicated flows and a more sophisticated build process.

The pros of building for Web are obvious: your app doesn't need to be installed, only requires a browser and are really easy to setup. The downsides are the same as any other Web application: your target is the multitude of commercial browsers and displays out there, so you need to be careful with the technologies you will use (not every browser supports every technology) as well as the size of the assets your game requires: every thing you put in the final application will be downloaded  by users' clients, so if it takes 2mins to download all the required assets your users will probably end up abandoning the page to never come back.

Don't reach the very last second to do your testing and deployment, you need time for it. Also, when the time is almost over, everyone will start deploying and submitting, so try to plan ahead and deploy your app every now and then: this will ensure you will always have your app running in the same environment where your users will be playing and will drastically reduce the time required to fix eventual crashes or deployment failures.

Once I pressed the submit button on the Ludum Dare website, it was done. I was exhausted and couldn't stand the sight of my laptop anymore, but I made it.

Conclusions

That's it. This is what happened during two crazy days of even crazier coding (If you're here and you haven't read this ~2500 words essay, shame on you). Here are some of the things I learnt during the competition:

• Plan ahead: planning was fundamental. This is a competition about how you manage your time: plan your features, plan how you're going to use your time and energies. Without a plan, you will be frustrated and you will not finish the game.
• Give yourself tasks and goals: Define tasks (complete feature#1, fix this bug, finish the player model, design a level) and complete them. Creating tasks will allow you to define your goals and will allow you to move towards them without losing precious time.
• Don't be afraid to start from scratch: you might end up in a place where you have to start from scratch. Either because your idea no longer convinces you, or because the fundamental logic/mechanic of your game is flawed beyond repair. You will need to push harder, but don't be afraid to start again, you can always reuse your code and your art.
• Sleep and rest: this might look like a joke, but it's incredibly important. You're running a marathon, you need a full tank of energy and you need to be focused. Take breaks, have regular meals, go to sleep and rest if you're tired. A fresh mind will solve bugs faster, identify issues better and will proceed smoother than a tired mind with 2hrs of sleep.
• Drink coffee: I mean, do I need to say more? Coffee is life.
• Preparation: Do not start something like this if  you're not prepared. You need to know your tools from inside out, be familiar with them, know their potential, downsides and flaws. Make sure you have everything you need before you start.
• Priorities: 95% of this competition is giving the right priority to the right thing. Don't be afraid to drop a feature that will take too much time if it's not worth the investment. Instead, focus on what will make the game functional first, then proceed with the "nice to have" features. Some things will look more exciting (creating the UI, modelling, creating sprites or textures or doing sound design), but they might be low priorities. Be strong and focus on what it's important first.
• Iterate iterate iterate: Yes, iterate. Work in small iterations and deploy every time the iteration is over. Example: you have the first level in place? Deploy it. Your "test users" find a bug? Fix it and deploy. You produced a feature that works but it's not ideal? It's fine, deploy it and iterate on that later. As I said before, it's more important to have something complete rather than having something perfect but incomplete.
• Test: You're essentially writing an application that someone will use. You need to thoroughly test it and make sure that's usable and it's working fine. If you can afford (based on time and opportunity) to perform user testing, do it: having someone playing your small game will give you incredibly valuable informations, and guess what? You can iterate on them and make an even shinier game.
• Have fun: yes, this is a competition, but you're doing this for fun! Enjoy the challenge, have fun creating something weird, unexpected and a bit crazy. You have the rare opportunity to create something that has no constraints: unleash your mind and see what comes out of it.

This was the first time, but definitely not the last one. I learnt a lot, and I'm sure next edition will be even more fun. Here are some links for you:

1. What I created: https://ldjam.com/events/ludum-dare/46/feeding-mr-biggs
2. The repository: https://github.com/MageStudio/LudumDare46_FeedingMrBiggs
3. The Game Engine: https://github.com/MageStudio/Mage

Thanks for reading this,

Marco