I’ve been trying to decide what major project to embark on here at Gamefromscratch.com. All of the current tutorial series are at a stage that I feel they are “good enough” to get anyone started and I will keep adding to them over time. Once I reach that point I need to decide on what project to work on next. It’s both a fun and frustrating problem to have!

I’ve long intended to cover both engines in more detail. I immediately subscribed to Unreal 4 on it’s release and did a bit of an overview post. I never got the opportunity to get much deeper, as frankly, there is a pretty steep learning curve attached and I simply didn’t have the time. Way back when I launched this game I was intending to “create a game from scratch” using Unity. Somewhere along the way I got distracted and we ended up with a series of LibGDX, Phaser, Blender, HTML, C++, JavaScript and more game development tutorials. Oops.

So, basically I’ve always intended to cover both for the longest time, but which one should I cover first?

I struggled with this for a long time, going back and forth between the two so many times I got nowhere. Then I had a thought…

Lot’s of you have got to be asking “What should I use, Unity or Unreal?”. It’s a fair and difficult question, as I obviously can’t decide myself! So I am going to learn both and document the process, both in text and video. So essentially I am going to do a Unity and Unreal tutorial series at the same time, learning both and documenting the process in both video and text form as I go.

That all said… this thread title and the above image are both a bit on the sensational side. I am not actually comparing the two engines, there will never be a “Unity is greater than Unreal” or vice versa conclusion. Both engines are obviously quite viable, popular and each has it’s own strengths and weakness. Determining which engine is better than the other engine all comes down to your own preferences and requirements. At this point arguing which engine is better is about as useful as the endless programming language wars.

Instead I will be going the process of creating a typical 2D game ( at least initially, 2D only ) in each game engine, documenting the process as thoroughly as possible. So by the time I am done I should have a fairly comprehensive tutorial series covering creating a 2D game in each engine, and you should have a nice side by side comparison of how each engine works, which should aid in your selection process.

I intend to cover subjects such as the following, for each engine, in both video and text tutorial form:

Engine overview

Learning resources

Simple graphics

Game loop/Event processing

Input

Audio

Animation

Level composition

Collisions

Physics

AI

Networking ( maybe )

etc…

So basically all the pieces that go in to making a simple game. I will learn it in one engine, document the process, learn it in the other engine, document the process then continue on to the next item in the list. Obviously if there is something you think I should cover, let me know and I’ll do my best.

There are a few caveats of course… first, this might take a very long time. I’ve a lot of learning to do here, so there might be a bit of lag between posts. The biggest catch though is I’ll be documenting things I’ve only just learned! Expect some mistakes, inefficiencies and other hiccups as I go. Obviously as I go I will try to be as “right” as possible, but I am no subject matter expert here! I have a small bit of experience with both engines and tons of experience with game programming in general, but I don’t for a second claim to be an expert with either technology!

One other aspect of a game project like this is obviously game assets. For a programmer, often getting art assets is as much of a time sink as programming! Therefore I am going to be implementing this project in parallel with another very interesting art tutorial over at 2dgameartforprogrammers to create and release all of the assets to create a game called BotBox.

So, essentially I am going to attempt to create that game using both the Unity and Unreal game engines. Wish me luck and I hope you enjoy it!

Of course, any and all feedback highly appreciated. Please have patience with me… this might take a while!

Today I ran into something extremely annoying while typing some JSON for a LibGDX tutorial. LibGDX uses a naming convention that IntelliJ doesn’t like… here, I’ll show you what I mean.

Suffice to say… it’s pretty annoying. What’s even more annoying is there is simply no way to turn this behavior off. There is however a way to suppress it thankfully. It isn’t intuitive however, so I figured I would make this post. So hopefully if you are struggling with turning off IntelliJ automatic code reformatting in JSON, this will be useful to you.

I needed to create a sprite sheet for an upcoming tutorial series and managed to throw one together in an amazingly short amount of time with almost no artistic ability. Good looking art with no ability is something many indie game developers are screaming for, so I figured I would share the process.

Coincidentally, if you want more information on how I created the above animated gif, I used a program called Cryotek Animated GIf Creator, and document the process here. It’s a very cool program and completely free.

Today I was contacted by a developer from the jMonkeyEngine team who was interested in spreading the word about the OPENGEX format among indie developers, and I agree completely with the goal.

Before I even get in to OpenGEX, it’s helpful to first look at the alternatives available for 3D import/export. Moving 3D assets between software packages and into game engines has long been a challenge and there have been a number of popular formats as a result. Let’s take a quick look at the more popular choices.

COLLADA

COLLADA is probably the monster in the segment now, standing for COLLAborative Design Activity, ranking up there amongst the most contrived acronyms I’ve ever encountered. COLLADA started life at Sony and was later submitted to Khronos, the party responsible for OpenGL, for standardization. Several major players in the industry signed on to support COLLADA, pretty much everybody actually, but most importantly, all the big boys signed on, including Alias ( Maya ), Avid ( Softimage, at the time anyway… ) and Autodesk ( 3D Studio Max ).

COLLADA was designed primarily as an interchange format between tools, allowing you to for example use Max and Softimage in your art pipeline rather seamlessly. For the most part it worked too, the industry came together and interchange was probably better than it’s ever been.

Obviously there is a but, or I wouldn’t be writing this, I would just say “hey, we should all use COLLADA!” and be done with it. So, time for the but… and what a big but it is. ( sorry… ) First off, COLLADA is a huge, some could say bloated format, that is ill suited for games. Again, it was designed for communication between authoring tools, ease of use and performance certainly weren’t priorities. Being controlled by the Khronos board certainly couldn’t help either, and it didn’t. The format became convoluted over time.

The next major problem is a change in the industry… you see, Autodesk bought everything. So suddenly most of the software this open standard was designed to work with are owned by a single company. Now with each new version released, things are broken, often needlessly. For a large company like Unreal or Unity, supporting a complicated and constantly moving target isn’t a big deal, they can frankly just throw money at it. For smaller, indie or open source game engines, this isn’t a solution.

FBX

The FBX format started life in a product called Filmbox, made by a company known as Kaydara. Filmbox started life as a motion capture suite and obviously needed to support various software packages, so they created the FBX file format. In the early days, well before the rise of COLLADA, it was supported by pretty much all of the common 3D packages of the day ( 3D Studio Max, Lightwave, Softimage, Power Animator ( Maya’s precursor ), Cinema3D, etc ). Well, Filmbox was eventually renamed MotionBuilder, a product that exists to this day and it was acquired by Alias, the makers of Maya and PowerAnimator before it. Remember how in the COLLADA write up I said Autodesk bought everything? Well, that wasn’t really an exaggeration… in 2006, Autodesk purchased Alias and with it gained control of MotionBuilder and the FBX file format.

So, fast forward to today and Autodesk controls Softimage, 3D Studio Max, Motion Builder, Softimage and more. FBX is the format they use internally to communicate between their own tools. So at the end of the day, if you are working entirely in the Autodesk ecosystem it’s the easiest and safest route to go.

For game developers though, it’s a bit of a different story. Once again, the large guys can easily support FBX, just like COLLADA. Perhaps most importantly, Autodesk make available an SDK for working with FBX. Some game engines make use of this SDK such as LibGDX’s fbx-conv tool. There are limitations on this license however on of the biggest is that it is incompatible with GPL, meaning Blender and similar tools can’t use the SDK. ( although I would put this on the awfulness of GPL instead of Autodesk’s license, but that’s splitting hairs ). This means Blender uses a “clean room” implementation of FBX and this means that the FBX support in Blender is, well, pretty crappy.

FBX however is not a game friendly format either, once again, it’s designed for communication between game tools, not for fast and efficient storage. So even in the case of tools like LibGDX that support it, they ultimately just use it as a source and convert it to their own internal format. This means each time you change your asset in your modeling tool, you have to convert it again and again.

OBJ, 3DS, MD2, DXF, etc

This is a catch all category, but it’s worth noting the above. Open Source game engines commonly support some of the older simpler formats, one of the most common being OBJ. These were the file export formats from popular 3D applications from years ago ( OBJ = Alias, 3DS = 3D Studio, DXF = AutoCAD, MD2 = Quake Engine ). The reason they are supported is the formats tend to be fairly simple with a large body of code already available.

On the other hand, they are also ancient and incredibly limited, especially when it comes to animation data. If you have simple requirements, a simple format should do the trick and frankly you will often see OBJ format supported when animation data isn’t needed ( such as by Mixamo Fuse or Poser, for model data ), but once you start adding complexity, these formats start to show their age.

I am mostly mentioning them for completeness only.

So, a TL;DR summary of the negatives of each format:

COLLADA

bloated and complicated format

run by Khronos group ( this is a good and bad thing )

fragile between versions, breaks easily

not game engine friendly

FBX

proprietary file format

controlled by Autodesk

not open source friendly license

not game engine friendly

The Others

ancient

poor animation support

limited functionality

Enter OpenGEX

This brings us at last to OpenGEX ( Open Game Exchange ), an open 3D file format targeted specifically at game developers for use in game engines. It was created by Eric Lengyel originally for the C4 Game Engine and was funded by a successful IndieGoGo campaign. Essentially you can think of OpenGEX as a stripped down, game engine focused version of COLLADA. Instead of being XML based, it uses OpenDDL (Link).

(Edit to fix JSON error)

The easiest way to understand the value of OpenGEX is to compare the format to COLLADA. Fortunately the OpenGEX site provides just such an example. Looking at the OpenGEX format, it’s quite clean, very reminiscent of OBJ, but with support for modern features. The purpose behind OpenGEX’s creation is nicely captured in this comment:

The OpenGEX format was created because Collada, the open standard that we all hoped would provide a well-supported asset exchange format, has proven to be an unreliable mess. The most common source of problems has been the poor quality of the Collada export plugins available for software such as 3D Studio Max and Maya, and we attribute this to Collada’s over-engineered design and its mutating under-specified format.

Now of course, a format is of little use if no tools support it, and this is where OpenGEX shines. There are already exporters for Max, Maya and Blender. Additionally there is an Import template available for implementing OpenGEX in your game or engine. It’s basically a Visual Studio 2013 project with the code used by the C4 Engine to load OpenGEX files.

If you are interested in learning more, you can read the PDF spec here.

So…. what?

So what’s the value in all of this to you as an indie game developer?

Well, if you are working with Unity or Unreal Engine, very little actually. They have the resources to support the COLLADA, with all of it’s quirks, breaks and other warts. If however you are working with a open source or smaller game engine, moving to a much more sane format can make everyones life easier.

As is the nature of any format, the more it’s used, generally the better it becomes ( unless of course committee bloat sets in ). Basically, the less time smaller developers have to spend on content pipeline tools, the more time they have to work on improving their engine. Additionally, the less headaches the game developer suffers getting assets in their game, again, the more time they have to work on the game.

There has been some recent movement in regards to supporting OpenGEX.

First off, the developer who contacted me from the jMonkeyEngine has recently made a Java library on Github available for handling OpenGEX files. This could potentially enable other popular Java based game engines *cough*LibGDX*cough* to support OpenGEX.

Partly to address that I'm planning on adding support for the OpenGEX format. Because of two reasons:

The format is actually really good, easy; and contains everything we need. It's basically our XML mesh and skeleton format, but in JSON.

Joint effort. There are already plugins. Open Source plugins. Which are being used for the C4 engine. If Ogre adopts the same format, we can share the burden of maintaining 3D asset exporters. Those are hard to maintain given Autodesk always releases a new version every year with partically no difference but breaking many plugins on the way. It should also empower more adoption of the OpenGEX format, and hopefully get others in. Unlike Collada, OpenGEX is good.

That second reason sums it up perfectly. If a number of indie game engines all adopt the same format, the burden of maintenance is spread across a number of developers instead of each developing their own proprietary format and all the support that entails. It also makes creating game tools that work across game engines a much easier task. Finally, it helps break Autodesk’s chokehold on the industry!

So mostly it’s a matter of trying to spread the word and gain support. One critical component would certainly be getting support into the Assimp ( Open Asset Import Library ), an open source model importing library that is the underpinning for many game engines importers today. There is already an open feature request, so if you feel an open game friendly COLLADA option would be useful, that would certainly be a good place to start.

This book was written by Alberto Cejas Sanchez and David Saltares Marquez, who is the man behind the Ashley ECS component included in LibGDX. So you can safely the authors know their stuff. Additionally, one of the editors was Joost van Ham ( also known as Xoppa ), this is the guy that wrote the 3D portions of LibGDX. So we can say right up front this is a technically competent and accurate book. Full disclosure, I got a review copy of the book, not that this has any influence. On a somewhat related note, this book is not yet available on Safari Books online.

If you’ve never read a Packt cookbook series book, the basic premise is it’s a collection of “recipes”, which can be thought of as task oriented code samples coupled with a description. With a traditional cookbook, say you wanted to cook a Quiche Lorraine ( for whatever aberrant reason! ) you’d flip open the cookbook to the quiche section and follow the recipe. These cookbooks work very similar, except instead of retched pies it’s got recipes for things like creating a 2D depth of field shader or generating and rendering bitmap fonts.

Over time, I have read a number of those Packt cookbooks, I’ve even written one and let me tell you right up front, the quality varies massively from book to book. One of the big flaws with many of these books is the author’s grasp of English, whether it’s that English is their second language, or they simply aren’t great writers. Fortunately, this is not the case with this book. The language is clear, the grammar is solid and there were very few errors that I spotted. Most importantly, language was never a barrier to my understanding what the author was trying to say. Nothing is more frustrating when trying to learn something than being tripped up by the authors inability to articulate, so this is a big point in the books favour.

Let’s take a quick look at the book’s Table of Contents:

Chapter 1: Diving into Libgdx

Chapter 2: Working with 2D Graphics

Chapter 3: Advanced 2D Graphics

Chapter 4: Detecting User Input

Chapter 5: Audio and File I/O

Chapter 6: Font Rendering

Chapter 7: Asset Management

Chapter 8: User Interfaces with Scene2D

Chapter 9: The 2D Maps API

Chapter 10: Rigid Body Physics with Box2D

Chapter 11: Third Party Libraries and Extras

Chapter 12: Performance and Optimization

Chapter 13: Giving Back

The book weights in at 487 pages. I suppose I should clarify, the Chapter 9 title is very confusing. It covers 2D TileMaps, creating them in Tiled and loading them into LibGDX. Remember back at the very beginning where I said “this book wasn’t at all what I was expecting”?, well… here’s why...

Looking at that list of topics and you probably come to the same conclusion as me, that this book is going to guide the reader through the process of learning Libgdx in escalating difficulty, frankly much like my own tutorial series does. You would be wrong though. To understand why, you need to look into one of these chapters to see what typical recipes look like. Let’s take Chapter 9 as an example, the chapter on tilemaps, and not just because it’s one of the shortest… ;)

On a chapter on tilemaps, what do you except to see covered? Creating and loading certainly, but what else? Maybe something on layers, possibly something on mixing sprites with tilemaps maybe? Nope, what you get is:

Introduction (an overview)

Creating maps with Tiled and loading them into Libgdx

Adding and querying map metadata

Developing your own map loaders and renderers

It’s that last one that defines this book, in my opinion. I would have never expected to see that topic covered in this book, and I find it shockingly awesome that it is there. It’s this level of technical detail that really makes this book.

So often these books are written to target beginners, and that makes sense, as they are generally the biggest audience for a book. In all honesty, and this may sound more conceited then I intend it to be, but I was expecting to personally get nothing out of this book. I know LibGDX pretty well myself and as an example when I read Learning Libgdx Game Development I don’t believe I learned anything new nor was it ever a source I went back to when I was encountering difficulty. This of course isn’t a bash on that book, I’m just not the intended audience.

This book however, as an experienced LibGDX developer, represents a new and very useful tool in my toolbox. It’s technical enough, applied enough and deep enough to be genuinely useful to developers writing real world code.

This however is a double edged sword. If you are completely new with LibGDX, this may not be the book for you. You have to absorbed a LOT of information all at once and this isn’t really a book that is set up to teach you from scratch. For example, instead of teaching the user how to draw a sprite, then rotate and scale it, then deal with it in a resolution independent manner, the first drawing example does it all at once. Incredibly useful information to an experienced developer… confusing as hell to a beginner.

The breadth of content is pretty solid. If you are creating a 2D game, chances are what you need to know is covered in here. There are a few odd decisions (IMHO), such as covering Git usage ( entire books are written on this subject already ), but not covering 3D at all, even though the guy that created the 3D api’s is one of your technical editors! :) I know what writing to a page budget feels like, so deciding what to include and what not to include is an excruciating process.

If you are an experienced developer working with LibGDX, buy this book, it will most certainly be of use to you. I know my own copy will be dog eared from use! ( well… if digitial copies could get dog eared that is ).

If you are a beginner looking to learn LibGDX, this book will certainly be of use to you, especially as you get more comfortable. That said, I wouldn’t recommend starting here, this is not a beginners book… fortunately, I know a good set of tutorials to get you up and running!