Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

8. August 2012

I just finished publishing the GameFromScratch 3D Engine round-up.  This is a guide to the top game engines in use by game developers today, that are available to be licensed. There are a total of 20 engines on the list, and for each one it includes the platforms it runs on, the platforms it can target, the price, sample games, the books available if any, key websites ( generally the forum and wiki or documentation pages if available ), programming language supported and example games published with the engine.


I have a similar round-up in the works for 2D game engines, which I hope to publish shortly.  Additionally, I have already published a similar document for HTML5 game engines.  I made the horrific mistake of authoring the guide in Word ( what was I thinking!??! ), and as a result the fonts are a little wonky in Chrome.  Hopefully I can find and kill this annoying trait.


If I made any mistakes, or I missed a key engine, please let me know.  Hopefully you find the 3D engine round-up useful!

News, Programming, Design , , , ,

7. August 2012


I wrote sometime back about RIM’s open-source Gameplay SDK.  GamePlay is a complete 3D engine that targets Blackberry OS 10/PlayBook OS, Android, iOS, Windows and MacOS X.  They just announced the release of 1.4 and it’s full of some pretty nice additions:


New features

  • Lua script bindings on all public interfaces of the framework.
  • Script binding generator tool for creating user-defined Lua script bindings from Doxygen XML.
  • AI state machine for AI programming/scripting on game objects.
  • Virtual gamepad input support with custom theming using UI system.
  • Optimizations using NEON math for mobile platforms.
  • Compressed texture support for DXT, PVRTC, ATC and ETC1.
  • Improved modular shaders with support for #include in shaders and new light map support.
  • Optimizations and Improvements to the UI system such as inertial scrolling and scrollbars.
  • Pre-built versions of the gameplay-encoder and gameplay-luagen tools.
  • Optimizations in animation and physics.
  • Fixes to support Maya 2012/2013 COLLADA DAE_FBX export.
  • FBX 2013 format support.


The also announced their roadmap for future versions:

The ‘next’ branch features for v1.5, v1.6, v1.7

  • Linux support.
  • Vehicle physics.
  • AI path finding with navigation meshes.
  • Physical Gamepad input for Xbox 360, Wii, and Bluetooth® HID controllers.
  • Terrain.
  • Scene editor tool.



You can read the full announcement here or head over here to get started.  Lua scripting is a very nice addition, especially for those that prefer not to work at the C++ level ( include me in that camp! ).  Terrain and scene editing tools will go a long way towards helping adoption.


Nice work GamePlay team! 


If I could make a suggestion if anyone on the team is listening, I would recommend a rebrand at this point.  Gameplay is an apt name, but it is incredibly generic, meaning that your discoverability is going to be abysmal.  You’ve created a great product here, it would be a shame that people didn’t use it simply because they couldn’t find it!  Just adding a second word the next name (Gameplay NEXT GameplayGO Gameplay-A-GoGo) would help a ton and allow you to keep your existing documentation, website, etc… unchanged.

News ,

2. August 2012


I don’t often get excited about unreleased products, and up until this point I have never gotten all too excited about a Kickstarter project ( although I really look forward to a possible Planescape sequel! ), especially a hardware package that sounds too good to be true.  “The first truly immersive virtual reality headset for video games” is pretty ambitious.


Then I read the quotes:


  • "What I've got now, is, I honestly think the best VR demo probably the world has ever seen"
    John Carmack, id Software

  • "Needless to say, I'm a believer... We're extremely excited here at Epic Games to get the Unreal Engine integrated with Oculus"
    Bleszinski, Design Director Epic Games

  • "I think this will be the coolest way to experience games in the future. Simply that... that big"
    David Helgason, CEO Unity

  • "I’m really looking forward to getting a chance to program with it and see what we can do.”
    Michael Abrash, Valve

  • "It looks incredibly exciting, if anybody’s going to tackle this set of hard problems, we think that Palmer’s going to do it. So we’d strongly encourage you to support this Kickstarter.”
    Gabe Newell, President and Owner Valve

When it come to video game name dropping… that’s a pretty impressive list!


Now about the device itself:


It’s called The Oculus Rift  ( ugh ) and its tentative specs are:

Head tracking: 6 degrees of freedom (DOF) ultra low latency
Field of view: 110 degrees diagonal / 90 degrees horizontal
Resolution: 1280x800 (640x800 per eye)
Inputs: DVI/HDMI and USB
Platforms: PC and mobile
Weight: ~0.22 kilograms


Perhaps most important, and the thing that got my interest, it’s coming out of the box with Unity and Unreal engine support.  That could move it from being a fringe curiosity, to being a device with an actual future.


Ultimately this all came about from their kickstarter campaign, attempting to raise 250,000$ to make developer kit’s available.  Well, that goal is WAYYYYYYY passed, and as of writing they are pushing the million dollar mark. A pledge of 275$ or more got you early access to the device and the SDK, although they are sold out, so I don’t know why I bothered mentioning that! Smile 


That said, pledging 300$ or more gets you:

EARLY RIFT DEVELOPER KIT + DOOM 3 BFG: Try the Rift for yourself now! You'll receive a developer kit, perfect for the established or indie game developer interested in working with the Rift immediately. This also includes a copy of Doom 3 BFG and full access to our Developer Center for our SDK, docs, samples, and engine integrations! (Please add $30 for international shipping)


300$ really isn’t that much, well within reach of many indie developers.  Of course, it’s a pretty big long shot, although if you are working with Unreal or Unity in the first place, the Oculus Rift really isn’t that much of a risk.


What do you think?  Is this the future of gaming?  There were some rumours that next Xbox was going the VR route.  I also seem to recall reading Steam had something in the works too ( ironically, Michael Abrash, who was quoted, was the person I believed was leading the effort).  Personally though, it makes me sick… literally.  I have tried a couple of VR rigs in the past, and beyond a few minutes play I start getting dizzy.  Let’s hope that doesn’t hold true with the Oculus Rift. Oh, and that’s a terrible name.

News ,

31. July 2012


I had intended to end this series on part 4, all I had left to do was add a layer of persistence because Heroku didn’t keep files for more than a few hours, which was a pretty heavy limitation.  So I looked into various storage options, and I ended up going with CouchDB.  The process was a bit more involved ( and interesting ) than I suspected, so I decided to add another post in the series.  This part covers setting up cloud based database, and changing our code to persist to the database.


First off, I went to and signed up for a free database.  They provide (free!) cloud hosted CouchDB installs, including a full Futon management system, pictured below:



You can use this interface to create new databases, configure security etc.  It’s a bit tricky at times to navigate, but it gets the job done.


I created a new database called firstthis, then immediately secured it ( by default your website is publically accessible to everyone! ).  CouchDB works by storing information in documents instead of tables in a traditional database.  Instead of updating individual fields, you update the data in your document then replace the entire thing.  Tracking the newest revision becomes incredibly important when working with CouchDB.  Perhaps most key of all, CouchDB adds two fields to your data, _id and _rev.  _rev represents the newest revision, while _id represents the unique key.  In our case, for our user settings, we are going to use their email address as the key.  We simply store the files variable from our script to the server.  Here is a sample of files stored in CouchDB ( shown in the iriscouch admin page ):




As you can see, its simply our JavaScript variable, with an _id and _rev added. 


When you sign up for IrisCouch, you are given a URL where your database server is located, in the form of


Now let’s take a look at the code differences.  It is pretty thoroughly documented ( combined with the above explaination ), so I won’t go into a lot of detail.  CouchDB is accessed using REST requests, but I instead used a node library Nano for access.  This was a bit of a double edged sword, as it took away a great deal of the complexity and grunt work, however it also removed me a step away from the well documented CouchDB. 


All of the code changes are in server.js

var express = require('express'), server = express.createServer(), im = require('imagemagick'), nano = require('nano')('http://Serapth:[email protected]'), db_name = "firstthis", db = nano.use(db_name), userEmail = '[email protected]', fs = require('fs'), files = { files:{}}; // Helper functions for getting and inserting docs in couchDB using nano function get_doc(docName,res){ db.get(docName,function(err,body){ if(!err) { res(body); } }); }; // There is no update in CouchDB. Just inserts, inserts and more inserts. // If you don't have the most current rev ( or it isn't a new insert ), an error (HTTP409) will occur. // TODO: Real error handling, attempt to get latest file, get it's rev, then try inserting again function insert_doc(doc,docname, tried) { db.insert(doc,docname, function (error,val,newval) { if(error) { return console.log(error); } // The insert will result in an updated rev, update our local files var to the most current rev. return files._rev = val.rev; }); } // Setup server static paths server.use('/cocos2d', express.static(__dirname + '/cocos2d') ); server.use('/cocosDenshion', express.static(__dirname + '/cocosDenshion') ); server.use('/classes', express.static(__dirname + '/classes') ); server.use('/resources', express.static(__dirname + '/resources') ); // Install the bodyParser middleware, which enables form data to be parsed when an upload occurs. server.use(express.bodyParser()); // Handle requests for / by returning index.html server.get('/', function(req,res){ res.sendfile('index.html'); console.log('Sent index.html'); }); // Handle requests for /settings by returning settings.html server.get('/settings',function(req,res){ res.sendfile('settings.html'); console.log('Send settings.html'); }); // Handle requests for images will be the form of // Fetchs the image data from CouchDB and returns to user server.get('/image/:name', function(req,res){ if(files.files[]) { res.contentType(files.files[].contentType); db.attachment.get(userEmail + "/" + files.files[].name,files.files[].name).pipe(res); } }); // Uses ImageMagick to get image dimensions and return them as JSON data // This is to work around the requirement for Cocos2D sprites to know dimensions before loading image server.get('/imageSize/:name',function(req,res){ im.identify(files.files[].path,function(err,features){ if(err) throw err; else res.json({ "width":features.width, "height":features.height }); }); }); // This gets the photo data, which is contained in our files variable. Simply return it JSON encoded server.get('/getPhotos', function(req,res){ res.json(files.files); }); // Erase all images : TODO: Remove images from database as well!!!! server.get('/clearAll', function(req,res){ files.files = {}; res.statusCode = 200; res.send(""); }) // Unfortunately there is no easy way to tell when a multi file upload is complete on the server, On('end') isnt called // Therefore we call /doneUpload from the client once we are done uploading. // Once we are done uploading files, we save our updated Files var up to couchDB, then get it again so it again immediately to have the most current rev server.get('/doneUpload', function(req,res){ insert_doc(files,userEmail,files._rev,0); get_doc(userEmail,function(res) { files = res; }); res.statusCode = 200; res.sendfile('settings.html'); })'/upload',function(req,res){ // This method is going to be called for each attached file. // Add the file details to files.files[] with the key set to the filename files["files"][] = { "name", "path":req.files.Filedata.path, "size":req.files.Filedata.size, "contentType":req.files.Filedata.type, "description":req.body.description }; // Now read the file from disk and insert the file data in our CouchDB as an attachment named "emailAddress/filename.png" fs.readFile(req.files.Filedata.path,function(err,data){ if(!err){ db.attachment.insert(userEmail + "/" +,,data,req.files.Filedata.type , {}, function(err,body){ console.log(body); res.statusCode = 200; res.send(""); }); } }); }); server.listen(process.env.PORT || 3000); // Check the couchDB for an entry keyed to the users email address. If one exists, copy it into our files var get_doc(userEmail,function(results){ if(results){ files = results; } });


Now when you upload images, they will be stored to your CouchDB database on IrisCouch.  When you restart Node, it will automatically grab and populate files from the database. Note, the application from parts 1-4 aren’t updated to use this new code.

Keep in mind, this code isn’t production ready… error handling is sparse, there is no authentication, it would be easy to exploit with a DoS attack for example.  However, if you are interested in storing data from your Node App in a CouchDB database, I hope this sample was useful.

Programming , , ,

29. July 2012


I recently completed work on a tutorial series A Simple JavaScript Game using Node, cocos2D, YUI and Heroku, which followed the creation of a simple app for my own use.  It was a pretty complete application with one glaring fault…  there was no persistence.  The application was hosted using Heroku’s free tier which doesn’t keep files for more then a few hours.  This obviously leads to a bit of a problem.


So I have been looking into the myriad of options for persistence with Node. There are a few options, all of which have various advantages and disadvantages.


The easiest solution would probably be some persistent storage like Amazon’s S3 or even my local file system ( and move the application from Heroku to my servers that are running on Windows Server ).  There is nothing wrong with either solution, but I don’t really want to add more load to my servers with a technology I am still learn learning, least of all to minimize security issues.  Also, I started thinking I wanted a bit more database functionality as I may be adding more functionality.


Once I start thinking Database + Node, that changes the landscape quite a bit.  I am already running SQL Server, and amazingly enough Microsoft has been embracing and contributing to Node, including a driver for MS SQL Database with Node.  However a) it is extremely early in development b) the syntax looks… wordy and crude, hopefully this improves massively, because accessing data values by offsets seems so very… retro.


In the world of Node, there seems to be 3 front runners:






All of them have strengths and weaknesses.  All three are part of the NoSQL movement, but each approaches things quite differently.


Redis is stored entirely in memory ( but syncs to disk ), and works with key/value pairs.  It is not ideal for file storage, but is wonderful for quickly storing away JavaScript objects.  Also, Heroku has Redis support as an addon.  Now the downside, Redis isn’t available on Windows, at least not in a supported capacity.  As I develop using both Windows and Ubuntu, this was pretty much a deal breaker for me.

MongoDB is another NoSQL option and to be honest, I forget why I didn’t go with it, at least not initially.  I know I didn’t particularly want to install the underlying DB server, but it was at least supported on Windows.

CouchDB is what I ultimately went with.  It is another NoSQL database, but it could probably be best considered a document store, that stores JSON documents ( and other files ).  Given the nature of my application ( serving lots of files that don’t often change ), this is actually a very good thing.  That said, my SQL trained brain is having a whole lot of difficulty dealing with the change in mindset.  Storing “data” in documents that aren’t in fact documents seems horrifically unnatural to me.  Worse, I am really having trouble coming to grips with the idea of not being able to delete versions!  The idea that every time I change data it creates a new document, there is no update, only inserts.  These seems horrifically inefficient, but I have to assume I am thinking about things wrong.


What ultimately sold me on CouchDB was the low barrier of entry in the form of Iris Couch, which is a cloud hosted Couch DB, with a very generous free option.  Like Heroku, having someone else handle the heavy lifting is always enjoyable.


Being new to NoSQL, I am still going through the learning curve, so there is nothing to say I will stay with CouchDB, but I will say, I have gotten some impressive results very quickly.  I really wish Redis was available on Windows, as I would probably use redis for “data” and Couch for documents.  Anyone have alternative suggestions?

Totally Off Topic ,

Month List

Popular Comments