Game Engines

So when I decided to start focusing on this project (this project being, this blog) I figured at the same time I’d try to start participating in the Ludum Dare competitions (for those who are not familiar).  For this goal and the fact that I want to be able to iterate quickly on my ideas, writing a game engine myself would not be prudent.  It’s a pretty well understood problem, so there are quite a few “out of the box” options for the common developer to consider.

I’d now like to take a moment to explain something.

If you want to be a game developer, its probably in your best interest to at least try to create some of these “game engine components” on your own first.  Yes it sounds like a daunting task, but undoubtedly you need to know how these things tend to work.  You don’t need to be an expert (unless that’s the job you want, working on Unreal Engine 4 or something) but you will most likely be asked questions in a job interview related to “cross product this” or “mesh intersection that”.  Many game engines are going to abstract you from a lot of core concepts (that’s the point of an engine!) which can prevent you from learning.

So at the very least, you should probably read up on different areas of an engine (rendering, ai, networking, input, ui, serialization) just to make sure you understand how it works.  You might even find something you want to specialize in or have great ideas about that could even end up landing you a job working on something related!

Even position like “Gameplay Programmer” which usually never touches engine code at all, will have engine related questions in an interview.  Don’t ask me why, but I’ve heard of it happening (in almost every case) and I’ve seen it happen myself.

Now that that’s out of the way, if you’re interested in “Indie” video game development, this information is all you.  You’ll need a game engine.  Do not write your own, not for your first game, probably not even for your 5th game.  Can you write your own and succeed? Yes, probably.  Will it take you a long time?  Of course.

The title of this post is a little misleading.  I’m not going to list more than one game engine here.  The title should really be “use this game engine”.  I’m opinionated, and I’ve done a little research.  I’m far from an expert, and you can obviously make amazingly great games using something else like Ogre3D or even Blender.  But what do I recommend?

 

JMonkeyEngine 3.0

It’s important that you use version 3.0 (get Jmonkey here).  The older versions are much much less fully featured, and to the point that I don’t think you could succeed in making a game using them.  This newer version has quite a few things I think that really set it out as the perfect tool for my research / experiments, and anyone who wants to get up and running incredibly quickly.

Why can you make things so quickly?  First of all (hold back your boos and hisses) it’s Java based.  Yeah, I know what you’re thinking.  Basically the same thing I was thinking when I was looking.  The games industry revolves around C++.  Everything is C++ at some point or another, it’s fast, it has efficient memory management (read: manually managed) all the examples are going to be in C++.  Why would you use anything else?

Well Java is “cross platform” as long as you have a JVM for your platform that meets the standard and performs well enough.  Jmonkey ships with natives for Windows, Mac, and some Linux distros.  I’m sure you can extend this to “all” I’ll leave that as an exercise for the reader.  Since they are already compiling native libraries for these platforms (for OpenGL bindings, input bindings, etc) they also have taken the liberty of including some other native code based implementations.  Yes, they’ve included a “FastMath” library that runs native code to try to bridge a little of the performance gap between C++ and Java with respect to game development.   This is a good thing for you.  Trust me.

Java is also very easy to iterate on.  I think personally, I’m still a C++ programmer.  It’s taken me so long to warm up to Java, but I do agree with the iteration speed (and testability, but that’s a discussion for someone elses boring “coding” blog).  If you haven’t tried developing a game in Java, try it and use JMonkey.

With that out of the way:  JMonkey 3.0 supports Android.  What? Yes, you can make games for your cellphone using Jmonkey.  I haven’t played with it, so I can’t say whether it’s awesome yet or not but the fact that they are doing it and the engine is actively updated gives me great hope in this area.  So now, as an indie, with one game engine you now can possibly support Windows, Mac, and Android.  Three of the biggest markets you’re going to want to target.  More importantly for me, if I want to start providing demos of things I’ve done on this website they are likely to be able to run anywhere with very little updating from me.

Bullet Physics.  Bullet has been getting a ton of traction lately as a great alternative (free) physics engine.  As of JMonkey3.0, Bullet is integrated in the engine fairly seemlessly.  One mark on the score however, I’ve had some trouble optimizing usage of it currently (and ended up by passing it for most of my projects that don’t really need physics).  I think they’re most likely using an older version but again JMonkey is pretty actively developed so I would expect optimizations here.

JMonkey’s design is one of the best I’ve seen for easy to follow game engines.  There’s a bit more overhead than there needs to be here, pretty much everything is driven off of the scene graph and doesn’t need to be, but I actually kind of like that.  It’s easy to get at any of your objects (through the graph or by name), collisions will return objects and their place in the tree along with most of the information you need (with some catches, but they are minor).  Networking, sound, input, and serialization are all built in nicely.  I was surprised at how much thought they actually put into serialization for saving games.  The built in UI system is pretty good (Nifty UI), it’s all pretty much there.

My last point, and this is a pretty big benefit to using 3.0 over 2.0.  They are now using the OpenGL shader pipeline as opposed to the fixed function pipeline.  Without going into too much detail, this is huge.  What’s even more awesome is setting up your own GLSL shaders (or even using any of the ones from their core library) is so simple it’s laughable.  Okay maybe not that simple, but if you try it you’ll see what I mean.  They also have a ton of tutorials available for people who rather learn by doing instead of reading the JavaDoc.

So yeah, I’m probably a huge fanboy but when I set out to get started on these experiments I posted on forums and did a ton of research for “C++ game and graphic engines”.  I didn’t even want to consider Java.  I stumbled upon Jmonkey, saw some (bad) demos and some very good demos, wrote a couple tests myself, and I’ve been hooked ever since.  My first ever LD attempt (might not be an entry) will definitely be using JMonkey.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>