Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
24. November 2012


Looking for the perfect gift for the geek who has everything?  Well, Learn Lua for iOS Game Development is coming out just before Christmas , plus it’s on sale for 25 bucks.  ( What’s with pre-release books already being on sale??? ).



Alright, hundreds of computer texts are released every year, dozens of them about game programming… so why the interest in this particular book?  You may remember a while back I put together  Battle of the Lua Game Engines: Corona vs. Gideros vs. Love vs. Moai and I actually enjoyed working with all three technologies.  Well this book covers using all three SDKs as well as Codea which I hadn’t heard of until this point.



Obviously the book isn’t going to cover any of those technologies in detail, each one could probably merit it’s own book.  It should however teach you the required bits of Lua and expose you to a little more detail than my comparison.  Lua is a wonderful little language, one you should certainly look into if you haven’t already.  This book may just be the right introduction, it releases on December 17th.


Here is the Table of Contents of Learn Lua for iOS Game Development:

Part 1 – Lua

1. Introduction to Lua
2. System Libraries
3. File IO
4. Math
5. Strings
6. Threading
7. Tips and Tricks   

Part 2 - Frameworks

8. CoronaSDK
9. Gideros Studio
10. MoaiSDK
11. Löve
12. Codea

Part 3 - Libraries
13. Libraries
14. 3rd Party Apps   


Most APress books end up on Safari Books Online, so expect a review shortly after this book is released.  It does strike me a bit odd that they would limit the title to iOS games, when Corona, Gideros and Moai all support Android as well ( without change in most cases ) and I don’t believe Love supports iOS at all…?  So if you are interested in Android development, don’t let the title put you off.


9. November 2012

I recently hosted a guest tutorial post on using Moscrif, a new Javascript based cross platform, game focused development environment.  Thing is, I myself haven't really had a chance to check out Moscrif myself.  In the past I did try out a Moscrif Logosimilar environment Appcelerator Titanium, which for a couple of reasons, I chose not to keep using, many of which aren't actually Appcelerator's fault (the no other word for it, complete crap Android emulator, was the biggest drawback). 


Moscrif on the other hand is a bit different.  Like Appcelerator, it's cross platform, mobile focused, JavaScript based and comes with it's own IDE.  Unlike Appcelerator it ships with a simulator you can use for stage 1 debugging, removing the biggest headache.  Perhaps most important of all for readers of this site, Moscrif is also game focused while Titanium is not ( yet ).


So, I've decided to take a bit closer look at Moscrif, over a couple of posts.  First off, this is *not* a review.  I certainly haven't put enough time in with Moscrif to even consider reviewing it.  Consider it instead a tour of features available as well as my initial impressions.


So, what then is Moscrif anyways?

The above description is pretty much accurate.  Moscrif is a cross platform JavaScript based IDE/language/library for creating mobile applications with a focus on games.  If you've ever used Appcelerator Titanium, you've got a pretty good idea of what you are getting here, just with a more game oriented focus.  The tools run on Windows, Mac and Linux, while you can target iOS, Android and oddly enough… Bada, with a single code base.


Installation process

Moscrif install was easy enough, but theres a catch.  You need to create an account (which you can do here), and like the Corona SDK and Appcelerator, you will need to log in to do anything, making an always on connection pretty much a much.  Unfortunately this login process is required even if you are just using the basic version.

Otherwise the install process is pretty much a no-brainer.  In my case I am using Mac OS.  You simply download the package and run a pair of installs.  Moscrif depends on a particular version of the Mono framework, which you need to install first.  It is included in the downloaded package, so simply download, run the Mono installer then the Moscrif installer, that's about it.  You can download (and register) right here.

Once you've finished installing, the first time you run Moscrif you will have to log in with your Moscif account.


A first look at the IDE

Load up and log in to Moscrif and you will be greeted by the screen:

IDE Screenshot


As you can see, it's a pretty complete and traditional IDE.  Your project management window is on the left, your console and debug windows are across the bottom and the remains of the window is for code editing.  You can use the icons at the top right to toggle sections of the IDE on and off.  I do have one immediate annoyance though, I am running on MacOS and there is no ability to maximize the window, or whatever that feature is called.  Considering that single feature is what makes Mac tolerable to me, hopefully support is added soon!


Hello World

To get a feel for the application, let's create an extremely simple Hello World project.

To get started, select File->New->New Project.

In the resulting dialog, choose 2D Game and name your project, I went with Hello World. Like so:



Now in the next dialog, keep Game2D selected and choose Finish.


It will have created a project for you like the one pictured to the left. is the file we are most interest in, it is the main entry point of your project.









Now replace the code in with the following:

include "lib://game2d/"


class HelloWorld : Game {

    function start()



        this.paint = new Paint();

        this.paint.textSize = 72;



    function draw(canvas)



        canvas.color = 0x000000ff;

        var (w,h) = this.paint.measureText("Hello world")


        canvas.drawText("Hello world",System.width/2 -w/2,System.height/2 -h/2, this.paint);





new HelloWorld().run();


As you can see, Moscrif is very similar to JavaScript with some obvious extensions, such as class or multiple return values.

Now let's run our new application, which brings us to...


The Simulator

Across the top of our screen are the simulator controls:



Simply click Run, and the iPhone4 simulator will run.  Voila:



You can control the Simulator with the following hotkeys, although the rotation keys don't work if you don't support landscape changes in code.  I also had a bit of a fight getting F11 and F12 working on Mac, but that is more an OS issue than a Moscrif issue.


Operation Mac OS Linux Windows Moscrif symbol
Take screenshot F12 coming soon F12  
Rotate left F11 F11  
Rotate right F11 F11  
Left functional key F1 F1 #left
Right functional key F2 F2 #right
Send / Green / Talk F3 F3 #send
End / Red F4 F4 #end
Back Backspace Backspace #back
Ok / Centre key / Confirm Return Return #ok
Volume Up F6   #volumeUp
Volume Down F7   #volumeDown
Camera F5   #camera
Power     #power
Menu F8   #menu
Home F9   #home
Zoom In Cmd + (=) Ctrl I, Ctrl +  
Zoom Out Cms - Ctrl O, Ctrl -  


As you can see from the display options, there is a decent number of profiles pre-configured.



I did run in to a few issues, when I switched from Iphone3 to iPad, then implemented screen rotation, only a 480x320 portion of the screen was rendered.  That said, having a simulator layer massively improves turn around time, especially when working on Android where the emulator is pure garbage.



The simulator is nice, but at the end of the day you are going to want to run on an actual device.  That process is actually quite simple.

Simply select the menu Project->Publish

The following dialog will appear:

Publish Dialog



Select your OS as a tab at the top, click a checkbox beside a skin and click the Publish button.  You can totally tell a programmer wrote this dialog… Reset Matrix?  Really? ;)  Coincidentally Reset Matrix is simply De-select, if you are curious.

After clicking Publish, Moscrif will churn away for a little bit and a Finder/Explorer window will pop up with your APK file ready for deployment.  I have to admit, this process is quite impressive, as it doesn't require you to install the Android tools, mess with any environment variables or any of the typical fun.  If you are just starting out, this is about the easiest way to generate an APK file I've ever seen.  Coincidentally, the APK was about 4MB in size, which is pretty impressive.  When using Titanium, a Hello World measured in closer to 10MB.

There is however a downside (one Appcelerator Titanium shares), you can't currently debug on device, which sucks.  You can log/trace back to the IDE as your program runs, but that's it. There are a whole class of bugs, especially on Android, that only express themselves on an actual device, so this can get a bit annoying.  Let's hope the simulator does a very good job of, well, Simulating.  Fortunately, on device debugging is a very near term item on the roadmap of features.  Even more confusing, it doesn't appear you can debug in the simulator either, other than debug logging.  I have become so used to being able to set breakpoints and step through code, it feels like a major omission when I cant. Hopefully this functionality gets added, at least to the simulator. Or perhaps I simply overlooked the functionality somewhere.


Other stuff and closing thoughts

The IDE is fairly easy to come to terms with.  What you see is pretty much what you get, there aren't a hundred menu items or nested dialogs, and there really doesn't have to be.  The code editing tools are pretty impressive, with good legible errors displayed in realtime.  There is code completion, it's quick and appears to work exactly as you would expect it to. Otherwise it's a fairly barebones but functional code editor.  There is smart tabbing, find/replace, code suggestions/completion, hover-over code tips and code folding and thats about it. For more advanced editing, such as refactoring, you need to move to a more dedicated text editor.  Truth is, in 99% of occasions, the IDE is a perfectly capable and even enjoyable place to edit your code.

Next is the area of support and community.  Let me start with the bad, community.  I am not saying the community is bad, more… missing.  One of the downsides of being a fairly new product is the lack of information online.  When you run in to a problem on Moscrif, there isn't yet a large community to turn to and Google won't come to save you.

Now, the good.  Moscrif's documentation ROCKS.  It staggers me how good of a job they have done.  Theres a pretty good step by step documentation that walk you through many of the features with code examples.  Where Moscrif really shines though is the reference materials. It's comprehensive, complete, timely and almost always comes with a code sample.  The reference material goes a long way to minimizing the lack of community…  you don't have as many people out there to answer your questions… but you have such great documentation that you don't really have any questions in the first place!  If you are middleware publisher and want to know how to do documentation… look no further!

I haven't really gotten the chance to really dive in and code.  That said, what I saw in my initial inspection certainly have my interest piqued, so I will be looking at the code side of things shortly.  So stay tuned for a more detailed hands on with the code in the future.  I am impressed by what I've seen so far.



  • it's JavaScript based
  • no external dependencies. No need to install other tools or SDKs. Fastest way I've seen to build an Android app yet
  • small executable size for the type of tool it is
  • EXCELLENT reference materials
  • all in one, easy to get started, reasonably complete
  • simulator makes for fast dev turn around times
  • JavaScript language enhancements that fix some of JavaScript's warts
  • Fast OpenGL based performance


  • it's JavaScript based 
  • lack of online presence, forum software is terrible and finding information not in the documentation is difficult
  • internet connection required
  • debugger needs improvement and basic debugging features ( breakpoints, inspection, etc ) added
  • it's young and relatively unproven 


Stay tuned for a later post when I look at Moscrif from a coding perspective.


General Programming

24. October 2012


Zipline just announced a new release of the Moai SDK, 1.3r2.  This release is mostly due to the release of iOS 6 and is a bit of a double edged sword.  What’s the catch you say?


Most importantly, we have updated the Moai Xcode project to support Apple's latest Xcode version 4.5 and the iOS 6 SDK. What does this mean for you? The biggest change is that Xcode 4.5 adds support for armv7s and the iPhone 5, but drops support for older armv6 iOS devices, and requires a minimum of iOS 4.3. Apple's armv6 devices include the iPhone 3G and earlier iPhones, and the first two generations of iPod touch devices. The Moai codebase on github can still be used to build to armv6 with previous Xcode versions, but your build flags will need to be reverted to support this.


So basically if you are supporting the most popular iPhone (3g), Apple just forked your world up.  You of course can still do it, but you will need to support two toolchains to do so, which sucks.


Other details of the release:

-iOS 6 and armv7s support added

-Dropped armv6 support on iOS

-Added setFailOnError method to MOAIHTTPTask to allow getting information from 400+ codes

-Modified MOAITextDesigner's layout behaviour to snap the layout cursor's Y-Coordinate to integer boundaries between lines of text

-Modifed MOAITextDesigner's layout method to snap lines of text to integer boundaries to prevent blurring

-Fixed a buffer overrun issue in Visual Studio 2010

-Fixed 'setLength' function on MOAIBOX2DDistanceJoint

-Fixed a bug with Curl HTTP task resetting on certain calls

-Fixed offscreen buffer ( MOAIFrameBuffer ) clipping bug

-Fixed issue with MOAICpBody not registering MOAITransformBase functions

-Fixed issue with MOAISerializer not handling escaped quotes

-Fixing bug causing '.fnt' file to fail to load if not in the current directory

-Added MOAIBox2DRopeJoint to global Lua class registration

-Added a fill method to MOAIGrid

-Fixed issue with MOAIParticleEmmiter so that it uses the proper location and apply transforms in the correct order

-Fixed a bug with 3d picking

-Added sort modes to propListForRay


As I said, mostly all about iOS6.


Don’t blame Moai for the lack of Arm6 support, that’s Apple’s boneheaded decision.  If you are willing to forgo iOS6 SDK goodies, there appears to be a way to support arm6 devices in XCode 4.5.  Your actual mileage may vary!


22. October 2012

This post is going to look at getting your Moai app to run under NaCL, which is Google’s mechanism for allowing you to execute C++ code within Chrome.  There are a number of restrictions, but fortunately Zipline have done most of the hard work for us.


Like any other platform, your code is run within a host.  If you are working from the binary ( non-GitHub ) distribution, the host is already built for you and you can skip ahead until you encounter the text “STOP SKIPPING AHEAD!”.  If you are working from Github sources, you need to build the host first.  That is what we are going to do next.


Building the Chrome Host


First is a matter of locating it.  The source for the NaCL host is located at moai-install-dir/scons/

There are a few things you are going to need to continue…


First off, if you haven’t already installed Cygwin, I highly recommend that you do.  The Android  build process basically requires it, so I am going to assume you already have it.  If you don’t, refer to the Android installation guide Cygwin section for details.

You also need to have Python 2.6 or 2.7 installed.  To check, fire up Cygwin terminal and type:

python –V

If you get an error that the command wasn’t found, Python isn’t installed so let’s install it.  The easiest way is to run the Cygwin setup application, then click Next next next until you get to the Select Packages screen.  In the search box enter Python, in the results expand Python and select python: Python language interpreter.


Make sure you don’t have any Cygwin Terminal windows open, then click Next and let Cygwin do it’s thing.


Now that you have Python installed, we need to download the native client SDK. (That’s the direct download link btw… )

Save it somewhere you can remember.  Open the archive and extract the folder nacl_sdk.  I went with c:\dev\nacl_sdk, but choose whatever you want, just be sure to update your paths accordingly.

Now open a Cygwin terminal window and change in to the nacl sdk directory, which in my case is:

cd /cygdrive/c/dev/nacl_sdk/

Now we want to run the installer/downloader.  In the terminal window type:

./naclsdk update pepper_17

Even though the current version is 22, you need to install 17, as it ships with developer tools Moai depends on.  For some reason, Scons has been removed from future versions.  That is what the above command does, gets and attempts to install pepper version 17.



OK, here’s the thing, we are dealing with Google developer tools, and Google developer tools are always broken in some way, especially on Windows, naclsdk is of course no exception.  After running the above command you will be greeted with the following error:


Updating bundle pepper_17 to version 17, revision 112997
Traceback (most recent call last):
  File "/cygdrive/c/dev/nacl_sdk/sdk_tools/", line 759, in <module>
  File "/cygdrive/c/dev/nacl_sdk/sdk_tools/", line 752, in main
  File "/cygdrive/c/dev/nacl_sdk/sdk_tools/", line 741, in InvokeCommand
    command(options, args[1:], config)
  File "/cygdrive/c/dev/nacl_sdk/sdk_tools/", line 583, in Update
  File "/cygdrive/c/dev/nacl_sdk/sdk_tools/", line 564, in UpdateBundle
    RenameDir(bundle_move_path, bundle_path)
  File "/cygdrive/c/dev/nacl_sdk/sdk_tools/", line 56, in RenameDir
    shutil.move(srcdir, destdir)
  File "/usr/lib/python2.6/", line 260, in move
    copy2(src, real_dst)
  File "/usr/lib/python2.6/", line 95, in copy2
    copyfile(src, dst)
  File "/usr/lib/python2.6/", line 50, in copyfile
    with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: u'/cygdrive/c/dev/nacl_sdk/pepper_17_update'

YAY!  Don’t worry, it’s pretty easy to work around.  The installer is trying to execute a program that doesn’t exist, but the installer was downloaded as part of the above process.  Go in to the folder sdk_cache and locate the file naclsdk_win.exe and run it.  When prompted for an install path, install it to your NACL_SDK folder/pepper_17.  In my case that means C:\dev\nacl_sdk\pepper_17

Now we need to set an environment variable with the path to the NACL SDK.

setx NACL_SDK_ROOT /cygdrive/c/dev/nacl_sdk

Keep in mind, the setx command requires administrator rights, so be sure to run your cygwin terminal as administrator if you aren’t already.

Now the bummer part, exit and restart Cygwin terminal, system level environment variables don’t take immediate effect.


Are we there yet? Nope… it’s FMOD install time

Close… one more dependency left… FMOD.  FMOD is a commercial audio system ( AKA, if you ship a product, you’ve got to pay to use it ).  With most of Moai, you can get by using the free Untz audio system, but with NaCL, FMOD is required.  So you either have to gut the FMOD library from the build dependencies or download and configure FMOD.  I’ve opted for the second ( audio is after all, kind of nice! ), but either option is open to you.

Head on over to the FMOD download page and download the archive for FMOD for Google Native Client. Unfortunately you need to download a version that supports the same Chrome version as Moai (17).  The following direct link will download the correct version. (Direct linkIT IS VERY IMPORTANT YOU DOWNLOAD THIS VERSION…. just so you know.

Save and extract that archive somewhere.  This file is a tar.gz, so if you are using a program such as 7zip, you need to extract it, then extract the file you just extracted.  I took the resulting folder, renamed it fmodchrome and copied it to c:\dev\.  The resulting directory should look like:


Now we need to set yet another environment variable, one named FMOD_CHROME_SDK_ROOT and pointing at this new directory.  Once again in Cygwin terminal type:

setx FMOD_CHROME_SDK_ROOT /cygdrive/c/dev/fmodchrome

Once again, you need to exit and restart Cygwin terminal for this variable to take effect.


It’s building time!


At this point in time, there seems to be a problem with the scons build script so that the paths ../3rdparty and ../src aren’t working, at least, not on Windows.  The following is a brutal hack, and I will post a better solution when I come up with it.  For now, we simply copy all the source into the scons folder.  Copy the contents of [moaifolder]/src, [moaifolder]/3rdParty and [moaifolder]/scons/src to the scons directory.

Now cd in to the maoi scons directory, on my pc /cygdrive/c/dev/moai-dev/scons and run


Hopefully all went well.  If you get errors… something didn’t go so well… if you want, just skip ahead and download the version I compiled.  You only really need the build process working if you intend to alter the host.


Now copy the following files to a new folder:





This is your Moai Host ready to go. 


If for some reason you couldn’t get your host to build, you can download mine.




Packaging your app to run in Chrome

Now you need to package your application up into Chrome friendly goodness.  The steps are fairly straight forward

In the folder you copied the .nmf and .nexe files, create a new file called manifest.json here is what I put in mine:


    "app": {
        "launch": {
          "local_path": "moai.html"

Now you need an html file to actually host your application. As you probably guessed by the manifest file, I called mine moai.html:


<!DOCTYPE html>

  <title>Hello Moai!</title>
    <embed name="nacl_module"
           width=480 height=320
           type="application/x-nacl" />


Finally you need your Moai application ( the lua bits ).  Just copy your project sources into the same directory, just be sure a file is called main.lua, this is your app entry point and will automatically be called the the host.  Here for example is my folder:


I simply grabbed the sources from this tutorial.



Configure Chrome to run your app

Now you need to let Chrome know you want to enable NaCL applications.  In Chromes location bar enter chrome://flags, the following window should appear.


Scroll down and enable Native Client as shown by the arrow. You need to restart Chrome for this to take effect!

So, um, restart Chrome.


Now you need to add your application.  To do this, in Chrome, drop down the Menu and select Tools->Extensions.



In the resulting window, enable Developer Mode, then click Load unpacked extension…


In the browse dialog, navigate to the folder you’ve saved everything in then click OK.



Your extension should now be installed.  Launch a new tab ( CTRL+N ) in Chrome, and at the bottom of the screen, select Apps



Your app icon should appear on the page:



Click it.


Voila, a Moai application running in Chrome:





12. October 2012


I have been following RIM’s Gameplay 3d engine for some time now and they have been improving it at a pretty impressive rate.  Well, they just announced the release of version 1.5.  If you’ve never heard of Gameplay, it is a cross platform mobile game development kit written in C++, but scriptable in Lua.


Gameplay3d currently supports the following targets:

  • BlackBerry 10 and PlayBook 2.0 (using BlackBerry Native SDK)
  • Apple iOS 5.1 (using Apple XCode 4.3.2)
  • Google Android 2.3+ (using Google Android NDK, SDK API level 9+)


And can be developed using the following platforms/compilers:

  • Microsoft Windows 7 (using Microsoft Visual Studio 2010)
  • Apple MacOS X (using Apple XCode 4.3.2)
  • Linux (using CMake or CodeBlocks 10)


As to what’s new in 1.5:

  • Linux support. (tested on Ubuntu 12)
  • CMake support for makefile generation for Linux.
  • CodeBlocks 10 IDE support for Linux.
  • Gamepad controllers support for desktops.
  • Touch gesture support for tap, swipe and pinch.
  • Vehicle phyics support via new PhysicsVehicle and PhysicsVehicleWheel classes.
  • Adds new racer sample (sample06-racer).
  • Adds gameplay-tests project as a test app for various basic engine features with some initial tests.
  • Adds support for Scene files for wildcard identifiers.
  • Adds Visual Studio Plug-in support for BlackBerry PlayBook and BlackBerry 10.
  • Adds configurable multi-sampling anti-aliasing support.
  • Adds updates to latest FBX SDK 2013.3.
  • Adds file formats documenation for game.config .scene, .material, .animation, .physics, .particle
  • Adds Game/Platform::canExit for testing device capabilities to quit. (only ios)
  • Web community forums at
  • Changed keyTimes from unsigned long[] to unsigned int[]. (breaks compat. in AnimationTarget and Animation::Channel)
  • Fixed inconsistencies from Bundle::getObjectID() to Bundle::getObjectId() (breaks compat. in Bundle)
  • Fixes the texture coordinates of Mesh::createQuad(float x, float y, float width, float height).
  • Fixes line-wise distortion when loading RGB png's into texture that are non-power of two.
  • Fixes inconsitencies in createXXXX methods. (breaks compat. in Scene)
  • Fixes Rectanngle::contains.
  • Fixes Lua print logging.
  • Fixes Lua errors to be treated as runtime warnings.
  • Fixes setVertexData to pointers instead of constant data.
  • Fixed AudioSource so that it doesn't loop by default.
  • Fixes minor UI scrolling issues.


And what’s in the works:

  • AI Pathfinding
  • Terrain and Water
  • Asset Pipeline improvements


You can download Gameplay on Github.  For a quick guide on getting started check here, it’s a bit old but should still be mostly relevant.


Good work Gameplay team!


AppGameKit Studio

See More Tutorials on!

Month List