If you’d like to try out our submission for LD48, NeuroDiver, you can find it here: https://ldjam.com/events/ludum-dare/48/neuro-diver

Ludum Dare 48 represents a major milestone victory for me and my development team. I have entered a handful of game jams over the past few years, and this was the first that was completed and submitted prior to the deadline. This was an improvement over our previous jam attempt, that took an extra two weeks to get to a fully playable state. This is also the case for my teammates: my wonderful girlfriend who created the art and music, and my friend who is also an aspiring game developer and whom led the design of the project.

So, what is there to take away from the development?

Scope is everything.

This is a lesson that we’ve learned every time we’ve tried to make a game, and finally got right. Make the game small: make the idea small, keep the story small (or preferably non-existent), and reduce it down to the smallest thing it can be. Once you have that working, you can expand on the idea. Now, it doesn’t work exactly like that – you always get sidetracked. But, if you keep the initial scope small, and you only make small adjustments, you should hopefully stay within the realms of a submitted game. You should also regularly reflect on what you’re doing, what you’re planning, and how long things are taking – and then readjust your plan. If you have to chuck things in the bin, do it. We had some phenomenal ideas which really could have brought the game to life in ways that sadly are not implemented. But much more important than that: we have a finished game. A wise game developer I know strongly adheres to the belief that you should “kill your darlings”, and I believe it is a wise mantra to follow throughout game development, but particularly for jams. I am always the one brandishing the blade, ready to cut down any ideas my co-workers have, and tell them that we have to keep the scope small. Its a somewhat thankless task, because perhaps those ideas could have been implemented. However, having a finished game at the end is a much greater reward. Every time I miss out on implementing something cool, I think of the time that others have played the game in a finished state, and the joy I get from it. That feeling beats the feeling of loss from cutting out a cool idea every time. If you haven’t yet experienced that feeling, I can only implore that you believe me that it is worth it, and that finishing something you don’t think is up to scratch is still better than having something which could be great, but is only half-done.

Source control gives freedom.

The second big lesson from this game jam is that source control gives us a lot of freedom, even for game jams. I’ve used source control in professional environments in the past, and I know their worth. I’ve also used them for my own projects, but mostly only to keep my code online to show to prospective employers. After our previous jam, where I was the only one with access to the unity files and also did all the programming – I had to take on almost all responsibility for the game. Whilst leading the project is a task I am happy to take on, directing people where I think might be important, having complete control of the design of the game, and implementing every feature (including art assets, placement in the world, music, sounds etc.) takes a lot of time. Time that could be spent on development, and that others could easily help with, if they had access to the files. This time, we did it right. We started figuring out the source control systems we wanted to use the day prior to the jam, and got everything working on the first day. Aside from one small hiccup with Unity’s scene files not working with our GUI source control application, where I had to manually delve into the files to fix a conflict, it was a seamless experience. This meant me and my game designer could largely work on our tasks without blocking each other, and we made considerably better progress throughout the jam. So get your workflow sorted ahead of time, and reap the rewards when the timer starts counting down.

Don’t treat game engines at face value.

Less of a lesson, but something that I got to indulge in this jam is that you shouldn’t treat your engine at face value. Instead, you should whiteboard technical problems before trying to implement them, and extend the functionality of the engine. I have used Unity many times in the past, but in each of those projects I have looked at the engine and tried to live within the walls it presents to me. However, with the goal of engine development, I am well aware that there is a lot going on behind the scenes. Relying solely on the inbuilt functions and default interface will hamstring your development experience. When it came to implementing certain rotation mechanics in the game, I scribbled some 2D drawings down and did the trigonometry. In the past, I would have googled it and been on my merry way (probably leading to a bunch of issues due to not fully understanding the problem, and then settling on a solution which is an approximation of what I want, but not what I really want). Unfortunately, in this case, I ran into issues with quaternions and gimbal locking in my own implementation, and so still had to rely on Unity’s in-built functions. But, this time, I was well aware of the problems they were solving, and had a much better idea of why they worked the way they did. As for extending the functionality of the engine: I also tried to make sure that the inspector for each gameobject was useful, hiding public variables which wouldn’t need to be tweaked, showing private ones that might be, adding sliders for ranges and so on. This is essentially extending the in-built functionality, and extending the usefulness of Unity within the context we were using it. Both of these things were big plusses, and I will take forward with me in my future game development endeavours.

Final thoughts

Game development is hard, but it is littered with small victories that should be held dear. For me, my favourite part of the jam (aside from working with my wonderful teammates and finishing a game), was having implemented invincibility frames and having the player flash after being hit. I’ll have another blog post on some of the features of the game and their development soon, so keep an eye out for that where I’ll expand on it in more detail.

Finally: whilst we finished our game, and scoped well enough that we hit that major milestone, we still need to aim smaller. Our initial game idea was simpler, and also in a different direction. We deviated and ended up with a slightly different game. We also worked more or less non-stop for the whole time that we could (except to get a decent night’s sleep), and had very little time to get playtesters to try the game out. Ultimately, we ended up with a game that could have been much better, if we had finished a day earlier. That would have given us a lot of time to tweak the design, to polish, and to provide a truly satisfying and enjoyable experience. However, there are always things to improve upon – and this time, we finished a game. So that’s a reason to celebrate! Next time, we’ll try to finish faster.

We still need 10+ ratings, and would appreciate any feedback: https://ldjam.com/events/ludum-dare/48/neuro-diver Thanks for reading, and feel free to share your games with us after playing!