14. April 2015


If you look over at the side bar you may notice a “Become my patron on Patreon” banner.  In case you’ve never heard of it, Patreon is a service that enables people to fund the efforts of content producers, such as GameFromScratch.com.


Over the years I have had a number of requests from readers looking for ways to donate to help support GameFromScratch.com (which was awesome by the way!), however I never really had a mechanism to do so.  It was with the birth of my daughter that I started to try turning GameFromScratch into a full time job.  The response has been amazing, GFS currently receives over a 1/4 million views per month and after only a couple months creating videos for YouTube, we passed the 1k subscriber mark and are approaching the 100,000 minutes watched per month milestone and are growing rapidly.  The community response has been nothing short of amazing and for that I thank you all.  The sheer volume of positive comments and emails I receive from many of you are simply inspiring and incredibly appreciated.


From a financial point of view however, I would probably be better off flipping burgers at McDonalds.  I don’t really bemoan this fact.  I am doing something I love and have the flexibility to focus on being a father while doing it, the definition of win/win.  Earning money has never really been a major focus for me, perhaps to my wife’s chagrin! ;)  Obviously there are ads running on Gamefromscratch, something I hope the majority of you don’t find too offensive.  These certainly help and defer server and operating costs but are nowhere near enough to approach what I would receive as a salary “with a real job”.


I had intended to supplement my income writing books.  After completing and publishing my first book, the well received but poorly selling PlayStation Mobile Development Cookbook, this idea quickly went away.  I’ve talked to a number of technical book authors since and let me just say, nobody is making their living this way!  I have flirted with the idea of self publishing a book, and may still, but truth of the matter is any other project I work on like this takes directly away from time I spend developing content for GFS.  Of course, finally creating and publishing a game of my own is certainly another option, but truth of the matter is, I vastly prefer teaching others… I appear to have found my calling in life.


In the end I am essentially developing multiple books worth of content on GameFromScratch every year as it is.  For example, I once converted the Blender tutorial series to iBook format and it weighed in at over 300 pages and I only made it 80% of the way!  The LibGDX tutorial series already exceeds the contents of any book on the market, by a large margin.  On the other hand, a book cannot contain animations, properly formatted and colour highlighted code samples, downloadable files or video format versions.  There is no comment section to answer questions or for the community to discuss topics.  Taking time away from GameFromScratch to work on a book that is in an inferior format, not available to everyone, has less functionality and cannot be updated… this doesn’t seem like a very logical use of time, does it?


Enter Patreon and it might be the perfect fit.  Patreon enables you to pledge a monthly dollar amount (starting at 1$ USD I believe) to help support the work of artists and writers you want to support.  This pledge amount would greatly exceed average royalties I would earn from writing another book and of course far more people would benefit from the results.  I personally like to believe that as a whole GameFromScratch provides more value than most book purchases.


It is customary to offer sponsor rewards on Patreon and this is an area I am struggling with.  The single biggest reward I can offer is first off my thanks.  The most tangible reward is more of my time dedicated to create more and better content for GameFromScratch.  These rewards of course benefit everyone, not just backers.  There are other options, like removing ads or walling off exclusive content or source code access.  Removing ads isn’t generally that effective as the majority of people that dislike ads already run adblock software.  I hate disruptive ads, like landing pages, interstitial or audio ads, the really annoying stuff, so I try to keep them non intrusive to start with.  I don’t really like the idea of exclusive content either, I obviously want my work to help as many people as possible as much as possible.


There are a few reward ideas I have considered, such as making PDF versions of long tutorial series available to backers.  Another option would be to open up the future direction of GameFromScratch.com’s content to voting.  As it stands right now, I decide what to work on next based on community requests coupled with what I find new, shiny and exciting at the time (part of why I love this job so much!).  I could possibly make this process democratic, to let backers vote on what contet GFS should focus on.  As of right now there are no rewards, other than my gratitude and of course more time focused on GameFromScratch!


So that’s my spiel.  I just want to say in closing, that each and every one of you supports GameFromScratch.com simply by visiting.  Your time, support, tweets, links and comments are all deeply appreciated by me.  If however you want to help GameFromScratch thrive and grow going forward, please consider becoming a Patron.


My Thanks,



General, News

29. March 2015


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 been thinking about it long and hard, then recently there were some major announcements I simply couldn’t afford to ingore.  First the folks over at Unreal announced that Unreal Engine would no longer have a monthly subscription.  This is actually something I called for ( with a fair bit of hyperbole… ) when Unreal Engine 4 was released.  Immediately after, and with much thunder stolen, Unity made a very similar announcement.  These lowered barriers of entry vastly increased the appeal of both engines.


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.


Untitled 7


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!

Programming, News, General , ,

1. February 2015


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.


Go to File->Settings… menu.  Locate Editor->Code Style settings.   Find “Formatter Control” and tick Enable Formatter markers in comments. 



Now add // @formatter:off at the top of your file and edit like normal.   Now…




Much better!

General, Programming ,

9. January 2015


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.


During the tutorial we use the following programs:

Mixamo Fuse (Free version available, MSRP $99USD)

Blender (Free and Open Source)

TexturePacker (Free version available, MSRP $50USD)


If you want more details on Mixamo, I extensively review it here.


The ultimate output from this entire process is the sprite sheet powering this animation:



And here is the resulting sprite sheet, click it for the full resolution version:



Now finally, the video.  You can watch it in full 1080p on YouTube.


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.

Programming, Art, General , , , ,

23. November 2014


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.




Site Link


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.




Site Link


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:



  • bloated and complicated format
  • run by Khronos group ( this is a good and bad thing )
  • fragile between versions, breaks easily
  • not game engine friendly



  • 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


Site Link


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.


It was recently announced too that Ogre3D is working to support the OpenGEX format as well.  Again, the developers words perfectly capture why this is important:

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

  1. The format is actually really good, easy; and contains everything we need. It's basically our XML mesh and skeleton format, but in JSON.
  2. 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.

General, Programming ,

Month List