I participated in Ludum Dare 33 with Skyfish.
The game can be found here.
I will not describe how it was made, but rather what I learned and experienced while using the tools I had. The relevant Unity Project can be found here, but I advise against looking at it if you are a programmer. Or someone trying to become one.
However, I will describe what could've been better and how I intend to tear through the coding bit in less time next Ludum Dare.
A weekend with Unity
The day the theme was announced, I met with Skyfish and another person that ended up not contributing to the project. I had laid out a plan before I got there. Grab a language I know (Python), use a framework resembling one I've used before (Cocos2D), make a game and use the spare time to make music assets. Easy-peasy.
This sounded like a great plan up to the point where Skyfish made me aware the fact that web deployment is a de facto requirement for (more) people to play your game. After half a day of testing various setups, I ended up going for Unity with C#. At least it deploys straight into the browser I thought.
This had the following consequences:
- I had to work from home. My laptop only runs Linux and the Unity Editor doesn't run on Linux without some serious work. This was a serious problem considering that Skyfish was responsible for a meetup related to LD at a hackerspace. This split our team in half.
- General frustrations with the Unity Editor. In my opinion, the Unity Editor has some of the most clunky workflows I have ever seen in a program. Ever. A few examples:
- To rename an item in your project, you must know the appropriate key (F2, yes, I am not making this up). There is no right-click menu item and the items do not respond to two slow left clicks. I seriously do not get this design decision.
- To create animations, the sprite you want to use has to be in the frame. The same goes for creating prefabs.
- When creating an animation, the Unity Editor also creates an associated animation state machine. You only need one per character/object, not one per animation.
- General silliness in regards to how you end up structuring your scene. It is very typical that you end up with an otherwise empty GameObject containing a script that acts as a "GameController" that does certain centralised actions such as triggering menus and other things. You can't attach this behaviour to the scene itself.
- You end up feeling dirty for using the prefab-system. It feels like a corrupted version of dependency injection.
- I'd estimate that the Unity Editor crashed on me at least 10 times while working. This may or may not be my PC's fault.
All in all, I didn't have time to do everything I wanted to and the resulting project isn't exactly optimal. I made sound effects for the game, but unfortunately I had no time at all for the music so I re-used some stuff I had made before.
Future plans
This has been a very valuable experience and I now know how to prepare for the next Ludum Dare.
Well in advance I need to have boilerplate code ready consisting of C++ and SDL (or some other graphical framework) that I know successfully compiles to JS+WebGL through Emscripten. Preferably on as many OSes as possible. C++-to-JS projects already exist and there's a long list of them that can be found here. I tried tweaking one of them, but the code was hard to get through (this was before I went for Unity).
While the Unity Editor offers some great debugging features (this is not to be underestimated), I really feel that for a setting like Ludum Dare it is more important that you can do more things faster using something that does exactly what you need with really simple workflows. To mitigate the lack of debugging tools, you can make your own. For instance: add an integrated webserver + websocket that provides access to ingame variables/functions.
I will publish my entire boilerplate code for everyone to use on my Github-account some time prior to Ludum Dare 34 if I intend to participate.