Build Systems

Build systems are painful, and I'm sure most developers will agree. Fortunately, there are many solutions for build systems which support various languages and offer a wide range of capabilities. For the typical developer you will never really need to worry that much about a build system. However, if you are serious about developing applications you should not ignore the productivity you will gain from a real build system. The main reason comes from the fact that you will need to deploy your application at some point. Is it really worth putting in all the time to invest in learning about various build systems? I would say yes and no.

Firstly, make sure you research the different build systems for your language(s) and their capabilities for deploying to your target(s). Once you have figured out which ones are feasible, then you really need to look into what people say about the build system. This will usually give you a good indication of what to expect from the build system (i.e. its pros and cons). Never get fooled into thinking you have 'the best' build system, because no matter how great you think it is, there will always be cons.

Secondly, spend the time to learn the build system, practice with some of the basics on how to use the system, build some dummy projects and work your way up to more complicated builds. Once you feel comfy with it, look at your project of interest and create a build for it. Along the way, figure out if this build system really fits what you want and need. If you did the last step, you know the alternatives and before you invest your time into setting up your project. That means you can easily switch to a different build system before you start getting frustrated.

Thirdly, use the build system. Make sure you can automate almost everything so that you will never really have to worry about deployment again. Doing deployment by hand is error-prone, slow, and usually fairly painful. The beauty of using a build system means you can easily do a cross-platform deployment and pre-package your application by simply pressing a button when you're ready. Additionally, you can check for library updates, run unit tests, or simply setup the versioning information for your deployment. This all happens automatically and you really only need to worry about it when you setup your project or make changes to the configuration. The best part is, most build systems provide a configuration script which you can throw into a VCS (Version Control System). When you decided to go back to an old version, the build system will grab everything it needs and run without you having to think about what you used to do to deploy the application.

The real cost is learning how to use a build system, but its no different than learning how to use an IDE, or learning how to use a VCS. The most commonly known build system is 'make' but just because it's common doesn't make it the best or the only one. Remember, there is no silver bullet and one size does not fit all.

Gradle, after doing some research I came to the conclusion this was probably the most ideal build system for me. However, it was designed for IntelliJ IDEA and not for my personal choice of IDE... the bloated Eclipse. Don't get me wrong, Eclipse is pretty sweet (hence why I use it), but it seriously has issues with performance, responsiveness, and memory usage. Netbeans I can't stand working with because it reminds me so much of Visual Studio, but that is more of a personal opinion than truth. Gradle's integration into Eclipse is pretty decent from the looks of things. Finding "Eclipse's Gradle plugin" is a bit of a pain (not to be confused with the "Gradle's Eclipse plugin") and you have to install Eclipse's Groovy plugin. Groovy, in simple terms is kind of an extension to Java so using it as a language for a build system is pretty epic.

It looks like Gradle offers support for Android and offers support for packaging and deploying applications to Windows, Mac, and *nix (read Linux/Unix) in a way that makes sense for each platform. It also has support for many of the JVM languages and comes with integration with other build systems, such as Maven, Ant and Ivy. Really, it sounds almost too good to be true. However, I still need to play with the Scala side of it, and see how effective I can combine the deployment plugins with the 4 platforms I target (Android, Windows, Mac, and Linux). Most importantly, I want to see how well they work with LibGDX and if that works out well I might also write a nice tutorial on how to get it all up and running.

I guess I should also mention how I'm considering writing a number of tutorials for LibGDX, but not a beginner tutorial. If anything, it would be tutorial that quickly covers the basics of LibGDX and then jumps into building an actual game with the above technologies.

Postponing Game Development

Finally, after finally having a bit of free time I've decided to change my focus to enhancing my knowledge in some deeper topics. Instead of spending time on small projects, I feel I should expand my general knowledge  in a couple of areas.

Firstly, I want to explore Gradle to see if I can leverage it for projects and get myself some more knowledge on serious build systems (I was also considering ANT but for the time being I think Gradle would be a wiser choice.) It will also be fun to play around with a little bit of Groovy. I would like to learn how to set it up for non-trivial projects (i.e. libGDX) but also allow me to easily create deployments for each platform. I've been manually doing deployments for a while and I do know how to do it, but it comes to a point where I should be able to automate it and never have to worry about it much again.

Secondly, I really want to expand my knowledge in the computer graphics area. It really fascinates me and more importantly I can see it being extremely rewarding now that I've had a decent taste of some more advanced topics. Rendering is pretty awesome, especially to get some realistic looking images, but I want to dig more into some of the more advanced interactive programming. This will focus mostly on 'desktop' graphics as being so constrained with mobile isn't exactly satisfying. Especially to play around with advanced lighting/particles/fluids and explore geometry and tessellation shaders. Maybe AMD (ATI) will get its act together and work on first-class compute shaders for even more fun, but I'm sure it will simply mean I need a newer graphics card (rolls eyes).

Thirdly, I need to expand my knowledge in machine learning and artificial intelligence. I have a few bits and pieces of basic knowledge from games and a bit from other sources, but nothing substantial that will help me in the next couple years. I am going to need a solid foundation before the end of the summer; otherwise, I will deeply be regretting it and I would rather not make my life stressful if I can avoid it. The advantage of digging into this area is that I will be able to directly transfer my knowledge into other projects and games.

Lastly, I have a couple of other high priority events I need to worry about, contests/personal events/etc. Thus, I want to keep things off of my plate for the time being until the dust has settled.

Parallel Programming

Considering how important parallel programming is today it is incredibly difficult to find ways to utilize the GPU in a truly cross platform manner. I would not be surprised if this area gets huge amounts of attention over the next couple years. Considering many newer supercomputers are very reliant on using CPU/GPU hybrid architectures to push both processing power and reduce power consumption it only seems logical that utilizing the power of the GPU is important for computational intensive applications.

Now that there is finally a serious standard on how to approach parallel programming which supports multiple platforms it seems quite feasible to use this in applications. CUDA is great, but is for NVidia; Renderscript is cool but its for android only; that leaves me with OpenCL. However, trying to do this in a cross-platform manner isn't a trivial task and more so if you are like me and trying to do it from the JVM side.

I had a crazy idea: Scala + LibGDX + ScalaCL + Android while retaining cross-platform capabilities and then applying networking. It sounds fairly straightforward but I already know how impossible that would be to fully integrate without gouging my eyes out. Long story short, I will easily have to wait another year or two before that is even possible. Not that I am concerned, phones with OpenCL support are only starting to roll out and majority of the market wouldn't be able to support such a crazy setup.

At the end of the day, I will have to stick with Scala and LibGDX, which I am still only in the initial stages of testing for feasibility. I can still dream... lol