Software geek by night, entrepreneur by day - the difference is unnoticable
About gormio (twitter: @aki_koskinen)
Ludum Dare 23
Since it’s now the last day to judge the entries I think it’s time to write my post mortem which I was supposed to write a long time ago already.
The LD#23 was the first one I participated. I was successful in submitting an entry but it’s not a winner. So some things succeeded, some didn’t. In every case I had fun times during the compo weekend and will definitely participate in future LDs too.
My entry is off course still available so you can try it if you haven’t yet – even if the judging time has already expired when you read this.
What went right:
- Before the compo: I prepared well. I made sure I had all the tools installed and working. I made a simple stub for the game that just showed a white screen (it could have been black as well). I packaged it and asked people on the IRC channel to try it out – and people were helpful there and offered to try it: thanks for the help for everybody who participated. This way I made sure that my “distribution pipeline” was in good order. This was to ensure that people could run my entry after the compo.
- I used familiar technologies. I build my game with the Proton SDK which I have been using for the past several months now so I’m quite familiar with it. I didn’t have to study the technology too much during the competition which gave me time to focus on the actual game.
- At some point during the compo I realised that I was doing a 2D racing game. For that I needed some car physics. First I thought to implement the needed physics by myself. I was thinking that doing a simple bouncy car with some collision detection and springs would probably be a quick job (ain’t it always). But luckily in the end I decided to check Box2D first. I didn’t really have much experience with the specifics of Box2D before. I did know that it is a solid body 2D physics library. But I didn’t know the API or the specifics of it at all. But Box2D turned out to be really easy to use. In the examples that came with it there was also a car physics simulation which I was able to use as a starting point for my need. The end result is definitely better than what I would have been able to achieve with a home grown solution in the limited time.
I really liked Box2D and will probably use it in some future projects as well. It seems a really good library and no wonder it has become the de facto 2D physics library nowadays.
What went wrong:
- I didn’t really manage to do a game in the end. My entry is more like a technology demo. After brainstorming some ideas what kind of game I would do I had a rough idea to what direction I would head. So I started implementing. But I never really cared to think what the game would be about. I thought that it will just materialize somehow in the process. Well, that didn’t happen. In the end I ran out of time and didn’t manage to do much of a game at all.
Lesson learned: spend enough time in the beginning before rushing to implementation to figure out what the core idea of the game is. Then implement that core mechanic first so you’ll have the game in place in the end.
- The only headers coding convention I decided to try out didn’t really work out. As I suspected in the pre-compo post the compiling times with this approach grow quite a lot while the codebase grows. But I thought that one wouldn’t be able to produce that much code in 48 hours that it would be a hindrance. Well, boy, was I wrong about that. After the first day’s coding the compile times were still manageable. But during the second day the compile times were starting to be quite long. During compilation the HDD light on the computer was constantly on so I suspect that the time was spent on reading files in from the hard drive. I have a SSD on the computer which is at least supposed to be fast but still it seems that the compilation process got I/O bound.
So as Mythbusters would put it: this coding convention idea is busted!
Lesson learned: if doing C++ put your .h and .cpp files separately as they teach you in the school. The wise men know what they are talking about
- Music. I did manage to get some music to the entry and people have even given positive comments about it so I guess it wasn’t a complete failure. I’m not that much familiar with audio software so I didn’t really know what would come out as music. So in the end I’m happy with what I achieved with the music track.
But where I failed with the music was the schedule. The compo ended here at 4am local time. So the last 4 to 5 hours everybody else in the neighbourhood were sleeping while I was doing the music track with headphones on. Earlier on the day I had recorded an acoustic guitar track. But I didn’t do anything with it until during the night. At around 1am I was adding drums and a bass track to the music in Garage Band. As it turned out the guitar track wasn’t quite in tempo all the time. It would have been an easy task to pick up the guitar and record the track again – this time with a metronome or the drum track on the background to get the tempo fixed. But in the process I would have woken up my fiancée and the neighbours so I couldn’t do it. So in the end I was only able to use less than half of the guitar track that I had recorded.
Lesson learned: if using real instruments for music (or any foley artist kind of stuff to make sound effects) do those during day time while you won’t disturb other people’s sleep.
Those are the main points that I had in my mind. Overall I really like what I achieved and learned during the hectic weekend of Ludum Dare. See you next time
(tl;dr: check the last paragraph)
I’m using a Linux system. That decreases a lot the amount of games that I can actually play from the entries.
Entering “linux” on the search box gives (at least some of) those games that have Linux binaries available. But this leaves out the ones that would be playable in a web browser.
Basically all other web technologies than Unity can work on Linux. A lot of entries have a “Web” link to a version that is potentially playable in a web browser. Not many of those state what technology the web version is actually using – is it Flash, HTML5, Java applet or Unity. (and many entries do state that, well done!)
A plea to those having a web version of your game available: state clearly on the link and/or on the description what technology your game is using.
I spent the last two-three hours yesterday fine tuning some parameters in my game. That time would have probably been spent better on actually making the game further. There’s still a hell of a lot missing. But I was feeling tired so maybe I wasn’t thinking straight. Now after a good night’s sleep it’s time to finish the game.
It seems that at least I don’t need to spend time on the IRC channel this time since I get this from the IRC server:
Sorry gormio, your Internet Address (IP xxx.xxx.xxx.xxx) is listed by UCEPROTECT as being a historically abusive host, so we are regulating connections from it.
That’s probably mostly a good thing…
I was sleeping when the theme was announced (it was 4am here). When I woke up and checked the chosen theme I was a bit disappointed with it. After searching for ideas from various places and brainstorming quite a long time I started to do some concepts with a “Jones in the Fast Lane” clonealike. Once I figured that two days isn’t enough for such a game and making that kind of game without proper dynamics makes it just dull I decided to choose something different.
In the end I settled for a racing game. The race happens around a tiny world – thus the connection to the theme.
Currently I have the car physics figured out. But there are no obstacles on the track yet so the driving happens around a silky smooth sphere (or circle since it’s 2D).
Graphics are totally place holder and from a still image you can’t really see how the car behaves but here’s a screen shot anyway.
This next Ludum Dare is my first one. I have been doing games for years now and I know from experience that you can only achieve so much in two days (in my case, that’s not much). So I’m looking for short cuts wherever I can find them.
I’ll be using C++ for coding since I’ll be using the Proton SDK. I’ve been using it lately a lot for other projects so it’s fresh in the memory. C++ is a great language in many ways (one of them being its portability across platforms) but there are some features that are more a hindrance than an advantage. One of them is the preprocessor which C++ inherited from its C roots. With the help of the preprocessor and the #include directive especially it’s usual to divide classes into a definition and declaration. The definition goes to a file ending with .h and the declaration (or implementation) goes to a .cpp file (the postfixes might vary slightly from case to case but these are the usual ones).
This is useful for example if you are developing a shared library. You compile the .cpp files in to the library. You collect the .h files and submit them with the compiled library to the users of the library. The users can now find the interface of the library from the .h files and code against it. Then they link against the compiled library and everything is good. The users don’t know about the implementation details of the library since they don’t need nor get the .cpp files.
The extra burden delivered to the developer with this file separation is that the interface in the header file must off course always match the implementation in the .cpp file. Change one and the corresponding method signature needs to be changed in the other file too (this .h/.cpp file separation is so badly against the DRY principle that it makes my head hurt – constantly). Miss that and you get a compilation error. Luckily the error messages produced this way are usually so much descriptive that it’s easy to fix them. But it’s still extra work. Tools off course can help a bit in these situations if your IDE happens to have a suitable refactoring feature.
I struggle with this problem every now and then. Now for Ludum Dare I decided to try something different. Since I’m not developing a shared library here and the code I’ll be writing will probably not be used elsewhere (at least without some heavy modifications) I can mess around with it as much as I like. For this purpose I have developed a coding convention that I shall call “only headers”. All of the code that I’ll be writing will reside in C++ header files only. So for each class the definition and the declaration will be bundled together to a single file. This way the signatures of methods are only written to a single place and whenever a method signature needs a change it will be enough to modify it in one place.
All of these header files will be included directly to the main.cpp file. The inclusion order needs to be correct so that the compilation succeeds. This approach is essentially the same that if you would write all the code to a single file. That file would probably grow several thousands of lines long so it gets hard to navigate in it. By separating the code to multiple files the navigation problem should decrease.
Now the obvious problem with this approach is off course that the compiler (and preprocessor) needs to always parse through all the code that there is in the project. But I’m thinking that the amount of code will not grow too big during the 48 hours of the LD event. But I can’t know that for sure right now. I guess I’ll find out during the week end how this works out. I’ll be reporting the experience after the event.
If you have any experience from this kind of approach, any tips or traps to avoid do share them in the comments.
I have been trying to save the next week end free from other responsibilities so that I could join LD#23. So if all goes well, I’m in!
Tools that I’ll be using:
- pencils (and eraser)
…and who knows what else. Perhaps I have to use some text editor, compiler and stuff too…