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.