Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

21. August 2013


I have been a big fan of the Moai game engine for a long time, going back to when I created a tutorial series about using it.  Lately though, things got quite, really really really quite.  The forum activity really dropped off, and new commits weren’t being added to the github.  I had personally written it off as a promising but dead end technology.  I decided to take a look at the forums after a few months off and found this interesting post from Patrick at Zipline games a couple days back:


Thoughts on the future of Moai


Marko Pukari sent me an email yesterday asking for a comment on what's going on (or not) with Moai SDK from Zipline's perspective. As you know we've been heads down on internal projects for quite a few months now. It's been ages since I've looked at the forums or our pull requests - I just haven't had the time. Looking at them this morning I saw a lot of high quality pull requests and bug fixes (thank you!) but was a bit surprised that they hadn't already been merged in to develop. I went ahead and grabbed the obvious ones and will try to close out the rest when I have time to get back to the SDK.

The specific question Marko wanted me to address is whether or not Moai SDK is a 'dead engine.' It isn't (and it won't be) for a few reasons. The first is that we are actively using it to develop our own games and will continue to do so. The second is that Moai SDK started life as my personal code base and I intend to keep working on it no matter what happens. Third, there is a community branch so even if I get hit by a bus the project will continue.

As of this writing nobody has productized the engine, so if you are a less experienced developer and not prepared to fully maintain the engine yourself then think seriously about going with a commercial engine or authoring tool instead. Open source is great because you won't get boxed in by a missing feature or a bug... but you have to be experienced enough to implement the feature or fix the bug yourself, or rich enough to hire someone to do it.

Regarding Zipline, our games are paying us right now but developing them takes up our every working moment. This should ease up in a month or three, but nobody should sit around waiting for us. The big project for me personally is going to be to merge our 'studio' branch back into develop. From that point I will continue to work on the SDK. In fact, I can hardly wait!

I can confirm that we do plan to offer products and services around Moai in the future. Moai Cloud didn't work out, but there are some other things I'm hoping to announce later this year. None of them involve taking Moai closed source.

I'm also glad to see there is a community branch; I'll keep an eye on it and pull features and fixes from time to time. Alternatively, I've asked before and I'll ask again: if anyone wants to volunteer to maintain Zipline's branch and CI then I would welcome them to do so. This extends to all aspects of community and project maintenance. Just contact me directly via email.



Later in the comments was this interesting tidbit:

3) Sure. The moment someone wants to pay me to do that, I will. Until then I cannot take time away from studio work. Every hour I spend not doing studio work I am losing money. Me personally. As in out of my pocket. Bread off my table. Etc. Don't get me wrong - I appreciate everyone's interest and contributions. But so far to date Moai SDK has paid me exactly $0.00. In spite of it being used to develop flagship titles by companies that received over $10m in venture capital. Just sayin'.


And no, Patrick isn’t whining, I get 100% where he was coming from.  He published Moai and certain studios certainly benefited majorly from it and that didn’t trickle back.  This of course is one of the joys of open source software.  It’s a bummer, but to me not surprising, that the Moai cloud efforts didn’t turn into a revenue stream.  There is no need to contribute upstream to the success of Moai… but karma’s a bitch!


What I did and do find incredible disappointing is the complete lack of contribution I have seen from studios other than Zipline.  Harebrained Schemes made Crimson Steam Pirates and StrikeFleet Omega using Moai and must have made pretty extensive changes… but did they contribute anything back to the engine?  There was some early promises, but I haven’t personally seen a damned thing.   And that is a gigantic shame.


At the very least though, we will be getting Ziplines internal copy pushed to the git repository, so that is good news.  I hope others decide to get more involved in the community and make Moai a success.

News, Programming

blog comments powered by Disqus

Month List

Popular Comments

JavaScript Toddler Game Part 1: Hosting a cocos2D app in Node.js
Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

13. July 2012


This is the first part of my adventure creating a simple game for my daughter


One of the catches with a JavaScript game, as you saw from this earlier tutorial, to take full advantage you need a client and a server.  However, once you want the server to start doing “stuff”, you want as much control over it as possible.  The advice “write your own!” is normally remarkably stupid, but with Node, it actually isn’t!  In fact, you can create a fully functioning server in only a couple lines of code.  If you are looking for a way to deploy an advanced JavaScript application, read on.


If you’ve never experienced Node before, basically it is a server side implementation of Google’s V8 Javascript engine, and a whole TON of plugins to do just about everything.  Perhaps the biggest selling point is, it allows you to work in both Javascript on the client and server.  It is also easy to deploy, massively asynchronous, scalable and frankly, kinda cool.  The first thing you are going to need to do is install it on your computer.  The install process is remarkably simple, although when you are done I would suggest adding node to your PATH environment variable if you are working on Windows.


Now that you have Node installed, let’s create a simple server.  Create a file called server.js like this:


var express = require('express'), server = express.createServer(); 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') ); server.get('/', function(req,res){ res.sendfile('index.html'); console.log('Sent index.html'); }); server.get('/api/hello', function(req,res){ res.send('Hello Cruel World'); }); server.listen(process.env.PORT || 3000);


And… that’s it, a fully functioning web server.


That first line is the key, where we require(‘express’).  Express is the module that is doing the heavy lifting on the server side.


There is however a small amount of configuration you need to do.  You need to tell node to install the express module.  This is pretty simply done though, open a command prompt and navigate to your project directory, then type:

npm install express


npm is the node package manager, and it will download and configure your project to work with express.  Now that we are configured, lets get back to code.


The next four lines are defining a series of static routes.  Essentially, if a web request comes in to any of these paths  ( for example  http://localhost/cocos2d ), node will simply serve the files back to the requesting browser, just like IIS or Apache would.  These four lines will result in /cocos2d, /cocosDenshion, /classes and /resources folders having their files served, so when your HTML file requests /classes/cocos2d.js, the file will be returned.  This is how we will allow our user to download our scripts and resources.  In this particular, I am porting the class from this tutorial to run from Node, which is why we require a resources and cocosDenshion folder.


Next is a GET request handler for “/”.  In HTTP, there are two kinds of requests, GET ( urls ) and POST ( form submissions ).  In this line we are saying if someone requests our web root, our function is called, which simply sends the file index.html back.


A moment later, we set up another GET handler for the route (URL) /api/hello, which simply returns the string “Hello Cruel World”.  This is a very simple web service, and we will see it in action shortly.


Finally we start our server listening on port 3000, or whatever port the running environment forces us on, in case our host has such limitations.  At this point, we have a fully functioning web server. 


However, I made a few alterations to the last tutorial’s file layout to better be served by Node.  Our folder structure now looks like:



Don’t worry if you are missing a few folders ( .git and .idea for example ) or files ( package.json or Procfile ), we will covers those later.


I altered all the paths in cocos.js and MyFourthApp.js because cocos2d was moved to the classes folder.  Otherwise the code is pretty much unchanged from the last tutorial.  You can download the full source at the end of this post if you want to see the complete changes.


I did make a few small alterations though, beyond changing paths.  I added a reference to jQuery in index.html, like this:

<script src=""></script> <script src="classes/cocos2d.js"></script>


I also added the following line to cocos2d.js:

else { cc.setup("gameCanvas"); jQuery.get("/api/hello", function(data,textStatus,jqXHR){ cc.Log(data); });


So what exactly is this line of code doing?


Remember earlier in server.js where we added a route handler for /api/hello?  Well this is about as simple a REST based web request as you can make.  This uses jQuery to make an AJAX call to our server, which returns the string “Hello Cruel World”, which we log to the console.   


Why?  Well, absolutely no reason… yet.  But this is a very primitive example of something we are going to do in more complexity later on.  We can do processing on our node based server, and handle it in our cocos2D client.  Through this mechanism we can make up for the limitations of client side Javascript, or enable server side functionality.  You can easily request data from a server without having to reload your page.



Now you can run your server.  Open a command prompt, navigate to your project directory and type node server.js.  If all went well, there should be no error messages.  Now open up a web browser and navigate to http://localhost:3000 like this:



Here is your cocos2D application hosted in a custom Node server viewed in a browser, and if you look at the JavaScript console, you will see the “Hello Cruel World” message logged by cocos, but returned asynchronously from the server.  To shut down your server, simply press CTRL + C.



At this point we have a working web server, capable of hosting a cocos2D application ( and replacing the need for WAMP completely ), making successful, if simple, web services calls between the client and server.


You can download the full project right here.


Next up, we will look into a problem many web developers face… where the heck am I going to put this thing???


EDIT:  Next part is now up.

Programming , , ,

blog comments powered by Disqus

Month List

Popular Comments