Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
8. October 2012


As per this post I am currently going through the process of creating some simple game creation tools using HTML5, more specifically using the YUI 3 library as well as the EaselJS canvas library.


This post illustrates the very skeleton upon which we are going to create our app.  YUI3 provides a full MVC framework which you can use to create your application so I decided to make use of it.  The end result of this code is remarkably minimal, it just creates a single page web application with different views representing different portions of the UI.  Specifically, we will create a top zone where the menu will go, a left hand area where the level editing will occur, then a right hand panel which will change contextually.  I also created a very simple data class, to illustrate how data works within the YUI MVC environment.


First off, if you have never heard of MVC, it is the acronym of Model View Controller.  MVC is a popular design practice for separating your application in to logically consistent pieces.  This allows you to separate your UI from your logic and your logic from your data ( the last two get a little gray in the end ).  It adds a bit of upfront complexity, but makes it easier to develop, maintain and test non-trivial applications… or at least, that’s the sales pitch.


The simplest two minute description of MVC is as follows.  The Model is your application’s data.  The View is the part of your application that is responsible for displaying to the end user.  The Controller part is easily the most confusing part, and this is the bit that handles communications between the model and view, and is where you actual “logic” presides.  We aren’t going to be completely pure in this level in this example ( MVC apps seldom are actually ), as the Controller part of our application is actually going to be a couple pieces, you will see later.  For now just realize, if it aint a view and it aint a model, it’s probably a controller.


It is also worth clarifying that MVC isn’t the only option.  There is also MVVM ( Model-View-ViewModel ) and MVP ( Model-View-Presenter ), and semantics aside, they are all remarkably similar and accomplish pretty much the same thing.  MVC is simply the most common/popular of the three.


Put simply, it will look initially more complex ( and it is more complex ), but this upfront work makes life easier down the road, making it generally a fair trade off.


Alright, enough chatter, now some code!  The code is going to be split over a number of files.  A lot of the following code is simply the style I chose to use, and is completely optional.  It is generally considered good practice though.



At the top level of our hierarchy we have a pair of files, index.html and server.js.  server.js is fairly optional for now, I am using it because I will (might?) be hosting this application using NodeJS.  If you are running your own web server, you don’t need this guy, and won’t unless we add some server-side complexity down the road.


index.html is pretty much the heart of our application, but most of the actual logic has been parted out to other parts of the code, so it isn’t particularly complex.  We will be looking at it last, as all of our other pieces need to be in place first.


Now within our scripts folder, you will notice two sub-folders models and views.  These predictable enough are where our models and views reside.  In addition, inside the views directory is a folder named templates. This is where our moustache templates are.  Think of templates like simple HTML snippets that support very simple additional mark-up, allowing for things like dynamically populating a form with data, etc.  If you’ve ever used PHP, ASP or JSP, this concept should be immediately familiar to you.  If you haven’t, don’t worry, our templates are remarkably simple, and for now can just be thought of as HTML snippets.  The .Template naming convention is simply something I chose, inside they are basically just HTML.


If you are basing your own product on any of this code, please be sure to check out here, where I refactored a great deal of this code, removing gross hacks and cleaning things up substantially!


Let’s start off with our only model person.js, which is the datatype for a person entry.  Let’s look at the code now:



    Y.Person = Y.Base.create('person', Y.Model, [],{
                return this.get('name');
                name: {
                    value: 'Mike'
                height: {
                    value: 6
                age: {
}, '0.0.1', { requires: ['model']});

The starting syntax may be a bit jarring and you will see it a lot going forward.  The YUI.add() call is registering ‘personModel’ as a re-usable module, allowing us to use it in other code files.  You will see this in action shortly, and this solves one of the biggest shortcomings of JavaScript, organizing code.


The line Y.Person = Y.base.create() is creating a new object type in the Y namespace, named ‘person’ and inheriting all of the properties of Y.Model.  This is YUI’s way of providing OOP to a relatively un-OOP language.  We then define a member function getName and 3 member variables name, height and age, giving each of the three default values… just cause.  Of course, they aren’t really member variables, they are entries in the object ATTRS, but you can effectively think of them as member variables if you are from a traditional OOP background.  Next we pass in a version stamp ( 0.0.1 ), chosen pretty much at random by me.  Next is a very important array named requires, which is a list of all the modules ( YUI, or user defined ) that this module depends on.  We only need the model module.  YUI is very modular and only includes the code bits you explicitly request, meaning you only get the JavaScript code of the classes you use.


So that is the basic form your code objects are going to take.  Don’t worry, it’s nowhere near as scary as it looks.  Now let’s take a look at a view that consumes a person model.  That of course would be person.View.js.  Again, the .View. part of that file name was just something I chose to do and is completely optional.


        Y.PersonView = Y.Base.create('personView', Y.View, [], {
            var that=this,
                request ='/scripts/views/templates/person.Template',{
                            var template = Y.Handlebars.compile(response.responseText);
            return this;
}, '0.0.1', { requires: ['view','io-base','personModel','handlebars']});

Just like with our person model, we are going to make a custom module using YUI.add(), this one named ‘personView’.  Within that module we have a single class, Y.PersonView, which is to say a class PersonView in the Y namespace.  PersonView inherits from Y.View and we are defining a pair of methods, initializer() which is called when the object is created and render() which is called when the View needs to be displayed.


In initializer, we perform an AJAX callback to retrieve the template person.Template from the server.  When the download is complete, the complete event will fire, with the contents of our file in the response.responseText field ( or an error, which we wrongly do not handle ).  Once we have our template text downloaded, we “compile” it, which turns it into a JavaScript object. The next line looks obscenely complicated:


A couple things are happening here.  First we are using that because this is contextual in JavaScript.  Within the callback function, it has a completely different value, so we cached the value going in.  Next we get the property container  that every Y.View object will have, and set it’s HTML using setHTML().  This is essentially how you render a view to the screen.  The parameter to setHTML is also a bit tricky to digest at first.  Essentially the method template() is what compiles a moustache template into actual HTML.  A template, as we will see in the moment, may be expecting some data to be bound, in this case name, age and height which all come from our Person model.  Don’t worry, this will make sense in a minute.


Our render method doesn’t particularly do anything, just returns itself.  Again we specify our modules dependency in the requires array, this time we depend on the modules view, io-base, personModel and handlebars.  As you can see, we are consuming our custom defined personModel module as if it was no different than any of the built-in YUI modules.  It is a pretty powerful way of handling code dependencies.


Now let’s take a look at our first template.


<div style="width:20%;float:right">
    <div align=right>
        <img src= 
alt="GameFromScratch HTML5 RPG logo" />
    <p><hr /></p>
        <h2>About {{name}}:</h2>
            <li>{{name}} is {{height}} feet tall and {{age}} years of age.</li>

As you can see, a template is pretty much just HTML, with a few small exceptions.  Remember a second ago when we passed data in to the template() call, this is where it is consumed.  The values surrounded by {{ }}  ( thus the name moustache! ) are going to be substituted when the HTML is generated.  Basically it looks for a value by the name within the {{ }} marks and substitutes it into the HTML.  For example, {{name}}, looks for a value named name, which it finds and substitutes it’s value mike in the results.  Using templates allows you to completely decouple your HTML from the rest of your application.  This allows you to source out the graphic work to a designer, perhaps using a tool like DreamWeaver, then simply add moustache markup for the bits that are data-driven.


What you may be asking yourself is, how the hell did the PersonView get it’s model populated in the first place?  That’s a very good question.


In our application, our view is actually going to be composed of a number of sub-views.  There is a view for the area the map is going to be edited in, a view for the context sensitive editing will occur ( currently our person view ), then finally a view where our menu will be rendered.  However, we also have a parent view that holds all of these child views, sometimes referred to as a composite view. This is ours:


    Y.EditorView = Y.Base.create('editorView', Y.View, [], {

            var person = new Y.Person();
            this.pv = new Y.PersonView({model:person});
   = new Y.MainMenuView();
   = new Y.MapView();
            var content =;

            var newDiv = Y.Node.create("<div style='width:100%'/>");

            return this;
}, '0.0.1', { requires: ['view','io-base','personView','mainMenuView','mapView','handlebars']});

The start should all be pretty familiar by now.  We again are declaring a custom module editorView. This one also inherits from Y.View, the major difference is in our initializer() method, we create a Y.Person model, as well as our 3 custom sub-views, a PersonView, a MainMenuView and a MapView ( the last two we haven’t seen yet, and are basically empty at this point ).  As you can see in the constructor for PersonView, we pass in the Y.Person person we just created.  This is how a view gets it’s model, or at least, one way.


Our render() method is a bit more complicated, because it is responsible for creating each of it’s child views.  First we create a documentFragment, which is a chunk of HTML that isn’t yet part of the DOM, so it wont fire events or cause a redraw or anything else.  Basically think of it as a raw piece of HTML for us to write to, which is exactly what we do.  First we render our MainMenuView, which will ultimately draw the menu across the screen.  Then we create a new full width DIV to hold our other two views.  We then render the MapView to this newly created div, then render the PersonView to the div.  Finally we append our new div to our documentFragment.  Finally we set our view’s HTML to our newly created fragment, causing all the views to be rendered to the screen.


Once again, we set a version stamp, and declare our dependencies.  You may notice that we never had to include personModel, this is because personView will resolve this dependency for us.


Lets quickly look at each of those other classes  ( mainMenuView and mapView ) and their templates, although all of them are mostly placeholders for now.



    Y.MainMenuView = Y.Base.create('mainMenuView', Y.View, [], {
            var that=this,
                request ='/scripts/views/templates/mainMenu.Template',{
                            var template = Y.Handlebars.compile(response.responseText);
            return this;
}, '0.0.1', { requires: ['view','io-base','handlebars']});


<div style="width:100%">This is the area where the menu goes.  It should be across the entire screen</div>



    Y.MapView = Y.Base.create('mapView', Y.View, [], {
            var that=this,
                request ='/scripts/views/templates/map.Template',{
                            var template = Y.Handlebars.compile(response.responseText);
            return this;
}, '0.0.1', { requires: ['view','io-base','handlebars']});


<div style="width:80%;float:left">
    This is where the canvas will go

Now, we let’s take a quickly look at server.js.  As mentioned earlier, this script simply provides a basic NODEJS based HTTP server capable of serving our app.


var express = require('express'),
    server = express();

server.use('/scripts', express.static(__dirname + '/scripts'));

server.get('/', function (req, res) {

server.listen(process.env.PORT || 3000);


I wont really bother explaining what’s going on here.  If you are going to use Node, there is a ton of content on this site already about setting up a Node server.  Just click on the Node tag for more articles.


Finally, we have index.html which is the heart of our application and what ties everything together and this is the file that is first served to the users web browser, kicking everything off.


<!DOCTYPE html>

    <title>GameFromScratch example YUI Framework/NodeJS application</title>

<script src=""></script>
<script src="/scripts/models/person.js"></script>
<script src="/scripts/views/person.View.js"></script>
<script src="/scripts/views/map.View.js"></script>
<script src="/scripts/views/mainMenu.View.js"></script>
<script src="/scripts/views/editor.View.js"></script>

    YUI().use('app','editorView', function (Y) {

        var app = new Y.App({
            views: {
                editorView: {type: 'EditorView'}

        app.route('/', function () {




This sequence of <script> tags is very important, as it is what causes each of our custom modules to be evaluated in the first place.  There are cleaner ways of handling this, but this way is certainly easiest.  Basically for each module you add, include it here to cause that code to be evaluated.


Next we create our actual Y function/namespace.  You know how we kept adding our classes to Y., well this is where Y is defined.  YUI uses an app loader to create the script file that is served to your clients browser, which is exactly what YUI.use() is doing.  Just like the requires array we passed at the bottom of each module definition, you pass use() all of the modules you require, in this case we need the app module from YUI, as well as our custom defined editorView module.


Next we create a Y.App object.  This is the C part of MVC.  The App object is what creates individual views in response to different URL requests.  So far we only handle one request “/”, which causes the editorView to be created and shown.  Finally we call app.render().dispatch() to get the ball rolling, so our editorView will have it’s render() method called, which will in turn call the render method of each of it’s child views, which in turn will render their templates…


Don’t worry if that seemed scary as hell, that’s about it for infrastructure stuff and is a solid foundation to build a much more sophisticate application on top of.


Of course, there is nothing to say I haven’t made some brutal mistakes and need to rethink everything! Smile


Now, if you open it up in a browser ( localhost:3000/ if you used Node ), you will see:



Nothing too exciting as of yet, but as you can see, the menu template is rendered across the top of the screen, the map view is rendered to the left and the Person view is rendered on the right.  As you can see from the text, the data from our Person model is compiled and rendered in the resulting HTML.


You can download the complete project archive right here.

Design Programming

5. October 2012

I am about to embark on a bit of a sidetrack here on, hopefully a few of you find it interesting.


Basically I am going to start looking at developing game tools using HTML5.  Tooling is a massive part of the game development process and traditionally i've used RAD client only tools like C# + WinForms in this capacity, but HTML5 is becoming increasingly appealing.  I have done a great deal of traditional web development, but nothing really like this.


My first project is going to be a dry run on a level editing tool.  I have NO intentions of actually using the end result in a production environment, it is as much a learning experience for me as anything else.  This unshackles me from spending time on stuff like… design, as I intend to throw away everything anyways ( famous last words? ).  Besides, until you have a solid grasp of what you are doing and what problems you are going to face, it's pretty hard to create much of a design anyways.  Now, if I enjoy the experience and the results, I will put a great deal of thought into the design of the finished product.  But when just trying things out, design mostly just gets in the way.


This is not the first time I have gone down this road, I've started a number of times and run in to the same problem over and over.  Too much choice, not enough knowledge to make the decision.  I always end up looking at frameworks, design patterns, libraries, toolkits etc, and always end up getting nowhere.  Even picking a client side JS library can consume weeks of your life, throw in a persistence framework, MVC or MVVM framework and months of your life are gone.


In the past I went down this road, I looked in to technologies ( such as YUI, Kendo, jQuery, Backbone, Moustache, Dojo, etc… ) and found strengths and faults with all of them.  What I didn't find is success…  This is an area that is anathema to me.  I like to research things, know my options going in and make a decision from a position of some knowledge.  Problem is, there are just too damned many frameworks and options.


So I am doing something I never do.  I am picking the technologies up front, and come hell or high water, I am sticking with them until the end.  Therefore for my upcoming project I am going to work with:

- YUI 3 for UI, controls, data, program flow, etc...

- EaselJS for graphics.



Why YUI 3?  Well because it is pretty much an all encompassing framework, it does about everything, taking decisions away from me.  I don't need to pick a client side technology like jQuery, nor a mobile suite like jQueryMobile, nor a back end like Backbone or ember, package system like require, etc…  YUI pretty much has it all out of the box.


Why EaselJS instead of a plethora of game/animation HTML5 libraries?  God knows there are enough of them!  Well, because I haven't used it and I intended to look in to it.


So, I am not saying either of these technologies are better than their alternatives, I simply don't have the experience yet to make such a judgement.  I am going with them because, well, they are there.


Hope you find the process interesting.

Design General Programming

23. September 2012

This is one of those things I am constantly searching for, so I figured I might as well put something together so I end up on my own site!


The following is simply a list of devices and their respective screen resolutions.  I am writing this as much for me as anything else, but hopefully some of you find it useful too.


Device Name


PlayStation Portable (PSP) 480x272
PlayStation Vita 960x544
Nintendo DS  2 x 256x192
Nintendo 3DS 800x240 upper screen ( 400 per eye, effectively 400x240 ). 320x240 lower screen
iPhone 3 320x480
iPhone 4 640x960
iPhone 5 1136x640
iPad 1024x768
Galaxy S2 480x800
Galaxy S3 720x1280
Galaxy Note 800x1280
HTC OneX 720x1280
Lumia 920 768x1280
Lumia 820 480x800
Transformer Prime 1280x800
Razor HD 1280x800
Common Resolutions by name
QVGA 320x240
VGA 640x480
WVGA 800x480
XGA 1024x768
WXGA 1280x768
UXGA 1600x1200
WUXGA 1920x1280
Television Resolutions
Standard Def NTSC (480i) 720x480 interlaced
Standard Def PAL (576i) 720x576 interlaced
720p 1280x720
1080i 1920x1080 interlaced
1080p 1920x1080
4K 4096x1714 ( varies by manufacturer )

Design General

21. September 2012


Alright, the title might be a bit over the top… what we are about to do is look at some of the most popular 2D game engines powered by Lua.  First there will be a matrix of features, to give you an “at a glance” view of what each engine offers.  Then we will follow up with a simple Hello World example for each, so you can see what the code would look like.  Hopefully this will help you decide which engine is right for you.


Engine Features Matrix








Site Link

Link Link Link Link


199$ /year iOS
199$ /year Android
349$ /year Both
Free trial available
149$ /year Indie
449$ /year Pro
0$ /year Community
Free Free

Free Limitations

Cannot publish to app store with free version Mandatory splash screen
Pro required if income greater than 100K$

Target Platforms

(Mac and Windows under development)
Linux (in late stage development)
Chrome NacL

Dev Platforms


Support Available

Paid support
Forum Forum Forum
Paid Support

Open Source

No No Yes Yes


Corona SDK Mobile Game Development

Learning Corona SDK (DVD)

Other Details

Builds occur on Corona Labs servers, internet connection required
3rd party tools available
Enterprise version available
Includes it’s own IDE Gideros Studio   Paid cloud computing offering for back-end services

Example Published Games

Go Ninja
The Lorax (Movie Game)
Joustin Beaver
Cerberus: The Puppy
Unpublished list
Crimson Steam Pirates
Strikefleet Omega


* Note, I gave iTunes link only, although many of those games are also available on Google Play.



Now we are going to look at a simple Hello World app written with each suite.  I do not pretend mastery of any of these suites, or Lua in general, so take the code for what it’s worth.  If you wish to submit a better rendition, please do so!


In this sample we are going to create a window at a resolution of 1280x800, then we are going to start a background song looping ( Richard Wagners – Ride of the Valkyrie taken from here ).  Then we are going to create a Hello World text/graphic centered to the screen, and position it where ever the user clicks/touches.  Some files handle window creation in a different file, some handle it in a single file.  That is why some versions have two lua files, while others have only one.


Corona SDK Hello World



-- config.lua

application =
    content =
        width = 1280,
        height = 800,
        scale = "letterbox"


-- HelloWorld sample

-- Load audio file
local song = audio.loadSound("../../Media/Ride_of_the_Valkyries.mp3")

-- set volume to 50%

-- play audio file, looping forever,{ channel=1,loops=-1})

-- create text to display on screen in 72point font
local helloText = display.newText("Hello World!",0,0,native.systemFont,72)

-- center to screen
helloText.x = display.contentWidth/2
helloText.y = display.contentHeight/2

-- red

-- function to handle touch event, move helloText to the touch location
function onTouchHandler(event)
    helloText.x = event.x
    helloText.y = event.y

-- register touch function to respond to global touch events






-- Helloworld sample

-- setup our window to our 1280x800 resolution

-- Load song, cannot use relative path to parent directory since file needs to be added to project
local song ="Ride_of_the_Valkyries.mp3")

-- play audio file, looping forever
local soundChannel = song:play(0,math.huge)

-- Set song volume to 50%, not set globally

-- need to load a ttf font, size cannot specify character size in TextField
local font ="arial.ttf",72,false)

-- create text to display on screen
local helloText =,"Hello World!")

-- center to screen
        application:getLogicalWidth()/2 - helloText:getWidth()/2,
        application:getLogicalHeight()/2 + helloText:getHeight()/2)

-- set text to red, color is hex encoding

-- display text

-- function to handle touch event, move helloText to the touch location
function onTouchHandler(event)
    helloText:setPosition(event.x - helloText:getWidth()/2,event.y + helloText:getHeight()/2)

-- register touch function to respond to global touch events
-- The above doesn't work in the simulator, so handle mouse too




function love.conf(t)
    t.screen.width = 1280
    t.screen.height = 800


-- love2d works slightly different, expecting users to implement methods that will be called within the game loop
-- such as love.draw() and love.update()

-- create a 72 point font using the system default
font =
-- set the font active
-- set red as the active color,0,0,255)

-- load audio file
local song ="Ride_of_the_Valkyries.ogg")

-- we want to loop, we want to loop, we want to loop, we want t^Z

-- set volume to 50%
-- play song

-- create a variable for print coordinates to update on touch, default to screen center
-- LOVE does not have a positionable text object, so we call print each frame
local x =
local y =
local stringWidth = font:getWidth("Hello World!")
local stringHeight =  font:getHeight("Hello World!")

-- This function is called once per frame to draw the screen
function love.draw()"Hello World!",x - stringWidth/2,y-stringHeight/2)

-- called on click, move our print x,y to the click location
-- no touch handler because LOVE is desktop only
function love.mousepressed(mouse_x,mouse_y,button)
        x = mouse_x
        y = mouse_y





-- create the window, viewport and layer
MOAISim.openWindow("Window", 1280, 800)
local viewport =

local layer =

-- Let Moai know we want this layer rendered

-- Initialize the audio system

-- set volume to 50%

-- load the song
song1 =

-- play audio file, looping forever

-- save memory by only rendering the chars we need
chars = 'Helo Wrd!'

-- create a font
local font =

-- create and position text centered
local helloText =
helloText:setString('Hello World!')


-- handle mouse/touch click events
function handleClickOrTouch(x,y)

if MOAIInputMgr.device.pointer then
    -- Mouse based device
            if(isButtonDown) then
    -- Touch based device
        function(eventType,idx, x, y, tapCount)
            if eventType == MOAITouchSenser.TOUCH_DOWN then




My Opinions



First off, take these with a grain of salt, these are just my initial impressions and nothing more.  Obviously it is all very subjective.  It is also stupid to say X is best, they are all good libraries, each with their own strengths and weaknesses.  I think that is perhaps the greatest surprise, not one of these four options is bad.



Love: Not a big fan of the abstraction and it forces a design on you, but this isn’t necessarily a bad thing, especially for a beginner.  Good for beginners, so-so to slight levels of documentation but absolutely wonderful reference materials.  Only library in this group with no mobile support, which is a big deal.  Open source and free, targeted to hobbyist.  Few ( none? ) commercial games.  All told, it reminded me a lot of the Python based PyGame, which is frankly a great beginners library.  Also the name “Love” proved a gigantic handicap, as it made Googling for anything beyond the Love2D website very difficult.  This is the downside to using a very generic name for your library ( cough… GamePlay, I’m looking at you! ).  The generic name really did prove to be a pain in the butt at times.  Love is certainly a good library, but probably not for professional use, at least, as is. 



Corona: Most polished of the four.  Best documentation, good API.  Only library with published books available and good tooling support.  Also most expensive and closed.  If it isn’t part of Corona, you are hosed.  Have to pay more for native access.  Great developer backing, lots of successful companies using Corona.  Corona is certainly a great library, although thanks to the price tag, it wont appropriate for all developers.  The lack of freedom ( no source, paying for native access ) are definitely the biggest drawbacks.



Gideros: Ok-good documentation, good reference but other material is a bit too scattered.  IDE is a HUGE boon for newer developers, especially with auto-completion.  That said, the IDE got a bit flaky at times too.  API itself a bit less intuitive ( to me ).  Licensing terms reasonable ( better than Corona, worse than Love and Moai ), same for price.  Good choice for beginner who wants to support mobile, lack of major published games a bit of a deterrent for professional developers, as is the lack of source code.



Moai: Moai is certainly the most difficult of the four, and the documentation is in heavy need of updating.  The reference itself is actually very good, where it exists.  In some cases there is none and in others, it is lacking or out-dated.  The developers are aware and this is a priority for them to fix.  On the other hand, Moai is also the most flexible by a mile.  The code ( as you can see from the example above ), is a bit more verbose, but that is because the library makes less decisions for you.  This is a double edged sword of flexibility vs ease, and Moai slants heavily towards flexibility.  Supports the most targets of all the libraries, has complete source code, and more importantly, the source code is very well written and very easy to read.  Like Corona, there are some very good shipped games.



Final verdict:

For a commercial product for iOS/Android, I would select Moai.  The API is a natural fit to my coding style ( I prefer flexibility over accessibility for time critical code ) and the C++ source code is a great boon to me, but to a non-C++ programmer, this would obviously be less important.  Also of course, the price is nice.  Most importantly, the open nature means I know I will never encounter a problem that I can’t code my way out of, the biggest downside to Corona.  If it wasn’t for the open source nature of Moai, I would probably go with Corona for the sake of it’s excellent documentation and clean API.


If I was just starting out, I would be torn between Gideros and LOVE.  LOVE is certainly the most beginner friendly, but the turn-key all in one nature of Gideros… you literally install, load the studio, write some code and hit play… with full autocomplete code editing.  This really is a huge deal!  In it’s favour over LOVE is also the support for mobile platforms.  That said, if the API isn’t to your liking, or you struggle with it, Love is easily the most accessible code wise.  I will be looking a bit closer at Gideros in the future.  Ran into a few annoyances during my brief exposure, like the inability to set anchor points for TextField values ( ), forcing me to wait for the feature to be added by someone else.


This isn’t to say Corona is bad, it obviously isn’t.  It is polished, has the best documentation and a very solid/natural API.  For me though, the lack of flexibility and access to source code provides outweigh it’s advantages.  If the source isn’t a big deal to you, or you do not have access to C++ resources and are willing to pay 200$ a year or more, Corona is a very good option with a ton of developers using it.  Also, Corona is the only option with a paid support option, which can be a huge advantage.




TL;DR verdict:


For a Pro developer:  Go Moai, unless you have no in-house C++ talent, in which case, go Corona.

For a new developer: Go Gideros, especially if you want to do mobile development. If you don’t like it, Love is always a great option.

Programming Design General

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

GFS On YouTube

See More Tutorials on!

Month List