Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
12. March 2013

This is part 3, the following are links for part one and part two in this series.


Alright, we've installed the tools, got an editor up and going and now how to run the generated code, both on our computers and on device ( well… Android anyways… I don't currently have an iOS developer license from Apple ), so now the obvious next step is to take a look at code.


Let's get one thing clear right away…  I know nothing about ActionScript, never used it, and I didn't bother taking the time to learn how.  As unfair as that sounds, frankly when it comes to scripting languages, I rarely bother learning them in advance… I jump in with both feet and if they are good scripting languages, you can generally puzzle them out with minimal effort.  This is frankly the entire point of using a scripting language.  So today is no different.  This may mean I do some stupid stuff, or get impressed by stuff that makes you go… well duh.  Just making that clear before we continue… now, lets continue...





Apparently LoomScript is ActionScript with a mashup of C# and a smattering of CSS.  ActionScript is itself derived or based on JavaScript.  I know and like JavaScript and know and like C#, so we should get along fabulously.


Let's look at the specific changes from ActionScript.


First are delegates, a wonderful feature of C#.  What exactly is a delegate?  In simple terms it's a function object, or in C++ terms, a function pointer.  It's basically a variable that is also a function.  This allows you to easily create dynamic event handlers or even call multiple functions at once.

Next was type inference, think the var keyword in C# or auto keyword in C++ 11. 

They added support for the struct data type.  This is a pre-initialized and copy by value (as opposed to reference) class.  I am assuming this is to work around an annoyance in ActionScript programming that I've never encountered.

They also added C# style Reflection libraries.  I assume this is confined to the System.Reflection namespaces.  If you are unfamiliar with Reflection in C# land, it's a darned handy feature.  In a nutshell, it lets you know a heck of a lot about objects at runtime, allowing you to query information about what "object" you are currently working with and what it can do.  It also enables you load assemblies and execute code at runtime.  Some incredibly powerful coding techniques are enabled using reflection.  If you come from a C++ background, it's kinda like RTTI, just far better with less of an overall performance hit. 

Finally they added operator overloading.  Some people absolutely love this feature…  I am not one of those people.  I understand the appeal, I just think it's abused more often than used well.  This is an old argument and I generally am in the minority on this one.


Hello World



Now let's take a look at creating the iconic Hello World example.


First is the loom.config file, it was created for us:


  "sdk_version": "1.0.782",

  "executable": "Main.loom",

  "display": {

    "width": 480,

    "height": 320,

    "title": "Hello Loom",

    "stats": true,

    "orientation": "landscape"


  "app_id": "com.gamefromscratch.HelloLoom",

  "app_name": "HelloWorld"



This is basically the run characteristics of your application.  This is where you set application dimensions, the title, the application name, etc.  Initially you don't really even have to touch this file, but it's good to know where it is and to understand where the app details are set.


Pretty much every application has a main function of some sort, the entry point of your application and Loom is no exception.  Here is ours in



    import cocos2d.Cocos2DApplication;


    static class Main extends Cocos2DApplication


        protected static var game:HelloWorld = new HelloWorld();


        public static function main()




            onStart +=;





Here we are creating a Cocos2DApplication class Main, with one member, our (soon to be created) Cocos2DGame derived class HelloWorld.

We have one function, main(), which is our app entry point, and is called when the application is started.  Here you can see the first use of a delegate in LoomScript, where you assign the function to the delegate onStart, which is a property of Cocos2DApplication.  In a nutshell, this is the function that is going to be called when our app is run.  We will look at HelloWorld's run() function now.

Speaking of HelloWorld, lets take a look at



    import cocos2d.Cocos2DGame;

    import cocos2d.Cocos2D;

    import UI.Label;



    public class HelloWorld extends Cocos2DGame


        override public function run():void




            var label = new Label("assets/Curse-hd.fnt");

            label.text = "Hello World";

            label.x = Cocos2D.getDisplayWidth()/2;

            label.y = Cocos2D.getDisplayHeight()/2;


            System.Console.print("Hello World! printed to console");


            //Gratuitous delegate example!

            layer.onTouchEnded += function(){

                label.text = "Touched";








We start off with a series of imports… these tell Loom what libaries/namespaces we need to access.  We added cocos2d.Cocos2D to have access to Cocos2D.getDisplayWidth() and Cocos2D.getDisplayHeight().  Without this import, these methods would fail.  We similarly import UI.Label to have access to the label control.


Remember about 20 seconds ago ( if no btw… you may wish to get that looked into… ) when we assigned to the Cocos2DApplications onStart delegate?  Will, this is where we define the run method.


The very first thing it does is calls the parent's run() method to perform the default behaviour.  Next we create a Label widget using the font file Curse-hd.fnt (that was automatically added to our project when it was created ).  We set the text to "Hello World" and (mostly) centre the label to the screen by setting its x and y properties.  You may notice something odd here, depending on your background…  the coordinate system.  When working with Cocos2D, there are a couple things to keep in mind.  First, things are positioned relative to the bottom left corner of the screen/window/layer by default, not the top left.  Second, nodes within the world are by default positioned relative to their centre.  It takes a bit of getting used to, and can be overridden if needed.

Next we print "Hello World was printed to the console" to demonstrate how to print to the console.  Then we follow with another bit of demonstrative code.  This is wiring a delegate to the layer.onTouchEnded property.  This function is going to be called when the screen is released, as you can see, this is an anonymous function, unlike run we used earlier.  When a touch happens, we simply change the label's text to Touched.  Finally we add the label to our layer, inherited from Cocos2DGame.


Run the code and you will see:



While if you check out your terminal window, you will see:



As you can see, Hello world is also displayed to the terminal.


Now lets take a look at one of the cool features of Loom.  Simply edit an .ls file in your text editor of choice and if you are currently running your project, if you flip back to the terminal window you will see:




Loom is automatically updating the code live as you make changes.  This is very cool feature.  Ironically though, in this particular case, it's a useless one as all of our code runs only when the application is first started.  However in more complicated apps, this will be a massive time saver.


On top, this is also how you can easily detect errors… let's go about creating one right now.  Instead of label.Text, we are going to make an error, label.Txt.  Save your code and see what happened in the Terminal window:




As you can see the error and line number are reported live in the Terminal without you having to stop and run your application again.



Pretty cool over all.  In the next part, we will look at more real world code examples.


You can read the next part dealing with graphics right here.

22. February 2013


Monotouch and Monodroid ( long since renamed ) are two products that I have *almost* purchased half a hundred times.  If you’ve not heard of them, they are a native port of C# and most of the .NET libraries to iOS and Android.  They have been having a good run and are the underpinnings of a number of very successful projects, such as PlayStation Mobile and Unity3D.  I really like .NET too but… and there is always a BUT.


It was 400$ for the basic version.  That’s 400$ for each platform too by the way.  That’s a pretty hard pill to swallow, especially when most of the competing products are free.  Or frankly, you could pick up the full Unity package for less than that!  Monotouch always offered a trial version, but it was limited to the emulator/simulator and if you have ever used the Android emulator on Windows, you know how vile that is!


Well, great news! 


First off, there is now a free version available that lets you deploy to device!  That said, you can’t p/Invoke to 3rd party code.  I honestly am not sure how much of a limitation that is.  Generally that means you can’t run native code, but still can run .NET assemblies.  If that’s the limitation, it isn’t a huge one.  If it means no libraries though… well, that’s a bit more painful.  I wonder if you can run Monogame, libGDX or PlayN in the free version?  Will look into that and get back to you.


Second, there has been a price drop.  It’s now 299$ per platform, per year.  Somehow, that 100$ makes a huge difference for me.  I don’t really like annual subscriptions though, I really wish people would move back towards version releases…  All the same, cheaper is always nice.


Third, there’s a new IDE, Xamarin Studio.


A little too XCode for my tastes, but I’ll be sure to check it out.  MonoDevelop is nice enough, but never really felt… comfortable if that makes sense.


Fourth, and this one is a biggie to many people.  You can build for iOS from Visual Studio on Windows.  Don’t get too excited, you still need a networked Mac to run the native toolchain, but you can do 99% of your work, debugging and testing in Visual Studio.



Very cool developments!  You can read more about it here.




A few points of clarification.

First is regarding the 299/year.  It’s not as bad as it sounds, the tools continue to work after a year is up, just no more updates.  That is much more reasonable and developer friendly.

Second is more details on the free version:

Xamarin Starter allows developer to build and publish simple apps, which contain no more than 32k of compiled user code (IL), and which do not call out to native third party libraries (i.e., developers may not P/Invoke into C/C++/Objective-C/Java.

Still not sure where that would leave Monogame, as it isn’t a native library, but it does no doubt make pInvoke calls to OpenGL.

General News Programming

27. January 2013


LibGDX is a popular Java based open source cross platform game programming library that supports desktop, Android, HTML5 and now… iOS.


Other details about this release:


  • Minor changes to the Livewallpaper API. Note that the LWP support is still a little buggy. It’s a contribution, and while i did quite a bit of clean-up it’s still not entirely where it should be. I’d be super happy if someone took on that backend!
  • If you want to deploy to HTML5 you now need to use GWT 2.5!
  • We have rudimentary Maven support. Thanks a ton to Team Gemserk for libgdx mavenizer and all their help with this!.
  • Android Daydream support, a contribution by talklittle! This one is stable.
  • Gdx controllers extension, for Android/Ouya and desktop. HTML5 could be an option too! Volunteers? (looking at you Nex) Some notes on the current stub backend for HTML5
  • The gdx-net API is now part of core. Fetching things via HTTP should work on all backends. Here’s a little test. Big thanks to Noblemaster and Gemserk who led this effort!
  • Not exactly part of the release, but here’s a quick rundown on how to make your libgdx game work with Ouya!
  • Again, not exactly part of the release, but here’s an awesome guide by Swarm on how to integrate Swarm with your libgdx app! Note that you should probably interface the Swarm API so your desktop project continues to work.
  • First release of the iOS backend



The iOS release does have some caveats though.  You need a Mac, XCode and ( here’s the stickler ) a MonoTouch license, just like the PlayN project’s iOS port.  Unfortunately, MonoTouch costs 400$, so this is one of those things you should be aware of upfront.


That said, iOS is often the biggest market place, so being able to port your game could be easily worth the 400$ price tag. 


The following features are in the queue for the 0.9.9 release:



You can read the entire release notes here, and access the source code here.


Nice work LIBGDX team.


21. January 2013


This one is a big one.  If you have never heard of it, monoGame started life as a way to port XNA applications to the various Mono targets (including iOS and Android), built on top of OpenGL.  With Microsoft basically retiring XNA, monoGame has basically become the future of XNA.

The biggest and most obvious addition in this release is 3D support, but there are a number of other great new features:image


What's New?
  • 3D (many thanks to Infinite Flight Studios for the code and Sickhead Games in taking the time to merge the code in)
  • New platforms: Windows 8, Windows Phone 8, OUYA, PlayStation Mobile (including Vita).
  • Custom Effects.
  • PVRTC support for iOS.
  • iOS supports compressed Songs.
  • Skinned Meshs
  • VS2012 templates.
  • New Windows Installer
  • New MonoDevelop Package/AddIn
  • A LOT of bug fixes
  • Closer XNA 4 compatibility

    The also added a new installer that will install a binary release of Monogame on Windows for use with Visual Studio.  MonoDevelop users can update with the Add-in Manager.

    Head on over here for the release announcement.


    Nice work Monogame team!


    7. December 2012


    Yesterday the cocos2d community announced the first coordinated release of the cocos2d products.  What products comprise this family?


    • CocosBuilder v3.0-alpha0
    • cocos2d-html5 v2.1
    • cocos2d-iphone v2.1-beta4
    • cocos2d-x v2.1beta3-x–2.1.0


    So what is the relationship between these products?  Well, this gets a bit confusing…  cocos2d is the original library, an Objective-C port of the original cocos2D Python library.  cocos2d-x is the C++ port of this library.  cocos2d-html5 is the JavaScript (HTML5) port, while CocosBuilder is… well, its new.



    CocosBuilder is, in their own words:


    CocosBuilder is a free tool (released under MIT-licence) for rapidly developing games and apps. CocosBuilder is built for Cocos2d’s Javascript bindings, which means that your code, animations, and interfaces will run unmodified on iPhone, Android and HTML 5. If you prefer to go native all the way, there are readers available for cocos2d-iphone and cocos2d-x.

    Testing your game on a mobile device has never been quicker or easier, just install CocosPlayer on your device (or in Simulator) and CocosBuilder will push your code over wifi in just a few seconds. Hit the publish button and your game will be saved instantly to a html5 web page. CocosBuilder has a rich set of functions, including boned animations, nestling of interface files, support for multiple resolutions and automatic scaling of your assets.



    Basically, they’ve bundled all the various products together into a standardized release.  I’ve not had a chance to sit down with CocosBuilder, but it sounds like a cool idea.  We have a number of Cocos2D HTML tutorials on this site if you are interested in seeing a cocos2D application in action.


    AppGameKit Studio

    See More Tutorials on!

    Month List