In the Loop: CasinoRPG – A Virtual World Casino Game Built on Node.js

Every week or two we spread the word of Node.js and the incredible things it can do by profiling creative, interesting and fun uses of Node.js in various products and projects. We call it “In the Loop.”

This time around we are chatting with GoldFire Studios, who recently launched a beta version of CasinoRPG – “a vast, persistent virtual world that goes far beyond your average casino game.”  Keep reading to learn more about CasinoRPG, web game platforms, the joy of Node.js, and future plans for GoldFire Studios.


Can you tell us about CasinoRPG? What was your inspiration and goal for the game?

GoldFire Studios: CasinoRPG was inspired by a previous game of ours called PokerRPG. We wanted to do a new casino-themed game, but we wanted it to be unique. The idea has been mulling around for close to 2 years, but about a year ago it finally got to a point that was ambitious yet feasible – RPG, tycoon, and gambling. Our ultimate goal for the game is to help prove that the web can be a legitimate game platform.

CasinoRPG brings together two things the StrongLoop crew finds full of potential: Node.js and a successful Kickstarter campaign. What made you decide to go with both of these things?

GoldFire Studios: We’ve actually been using Node.js on our game platform for over a year now. Node.js has been a joy to work with, and even more-so when paired with JS on the front-end. We went with Kickstarter because we wanted our current community of gamers to be able to participate in making the game a reality.

CasinoRPG 2

At what point in the development of this game did you decide to utilize Node.js?

GoldFire Studios: Early in 2012 we had gotten very comfortable with Node.js and have now moved all operations from now forward over to Node.js. We decided very early on that CasinoRPG would be 100% Javascript.

We know using Node.js allows a lot of opportunities, but did it provide any challenges?

GoldFire Studios: Most of our challenges have actually been on the client-side, though we are well aware of the scaling issues that we will face after launch.

Anything else cooking for GoldFire Studios in the Node.js realm?

GoldFire Studios: Right now our focus is squarely on CasinoRPG, but we have some pretty big expansion plans for our game platform (which is also all Node.js), and hope to open it up to other game developers later this year. We can’t wait for people to get their hands on this game!


Thanks to GoldFire Studios for telling us about CasinoRPG.

You can visit their home page to check out their introductory video and request access to the CasinoRPG Beta.

If you have a cool Node.js project or product you think we should profile, reach out to us at and we’d be happy to get you In the Loop.

What’s next?

Developing a Mobile Backend Using StrongNode – Part 2


In part 1 of this blog series we discussed the technologies that we will be using to create an SMS aware mobile application with a node.js backend: StrongNode, MongoDB, Titanium, and Twilio.  We also created our first StrongNode application called mobilebackend and deployed the application to our local running slnode server.  In this blog post, we will take a deeper look at the source code and create a REST API for storing and retrieving information for our mobile application.  We will also learn how to create a MongoDB datastore using the popular MongoLab service which provides free MongoDB hosting in the public cloud.

Signing up for MongoLab

Given the vastly different ways to install MongoDB on different operating systems, which is beyond the scope of a this blog series, we will be using a quick and easy way to have our own private MongoDB instance in the cloud.  We will be using a service provided by MongoLab.

MongoLab provides the ability to create a MongoDB datastore that is publicly accessible for no cost.  They offer this no cost database as a way to try out their database hosting service to ensure that it meets your needs as your application grows.  MongoLab is a very robust and stable service and I use them on a daily basis.

For the purposes of the application that we are writing for this blog series, the free tier that they provide will meet our needs as we do not need replication or sharding and fall within the 512mb file system size they provide for the free plan.

 Signing up is free and easy.  Simply point your browser over to their website and enter in your username, email, and password that you want to use.  Once you have completed the signup process, you will be presented with the following screen:

Click on the create new database button and select the hosting provider and location for your MongoDB database.  I will be using AWS in the East region but you should use whichever location makes sense for your deployment.  Name your databases mobilebackend and click create on the bottom right hand side of the screen.

After your database has been created, click on the database name and you will be prompted to create a user that can authenticate and use the newly created database.

Once you have a user created, make a note of the connection settings that are provided to you at the top of the screen.  We will be using this information to configure our StrongNode application to allow it to communicate with the database.

Configuring our application for MongoDB

 If you recall from part 1 of this series, the db directory inside of your mobilebackend application is where we place database configuration settings.  Edit the mobilebackend/db/config.js file and enter in the connection settings for your database that you created using MongoLab.  As a reference, the config.js file for my database looks like the following:

Make sure to change the values to the correct ones for your database.

Testing the Database Connection

Before we move any further, we should verify that everything went smoothly by running the application using the slc command. To start the application, change to the application directory and start the server using the following command from a terminal prompt:

Once you start the server and your application, you should see the following message on your terminal prompt:

Signing up for Twilio

During part 1 of this series, we introduced Twilio and discussed how we will be using it to provide SMS capabilities to our application. The first thing we need to do is signup for an account at their website. Head on over to and click the sign up button and enter in your information.

Once you create an account and click the validation link, Twilio will want to verify that you are a human being that is signing up for their service. They will send you a text message to your mobile phone with a verification code that you need to enter to confirm your account creation. Once you receive this message, enter it in via the dialog provided on their website.

Once you confirm your account, you will be assigned a twilio number.

Click on the Get Started link and then Numbers at the top of the screen.  At this point, you can manage the endpoints, or URL(s), that will get called when someone calls or sends a SMS message to the phone number that Twilio assigned to you.

Update the Messaging Request URL parameter with the publicly available URL for your application. For instance, if your domain name is, you could use the following URL:

Note: We have been using the localhost system for this blog post. When you are integrating your application with Twilio, you will need to ensure that your application is available via a public URL. If you do not have one accessible, it is suggested that you chose a PaaS for your application deployment. For tips on which PaaS to use, please refer to this blog post which compares Node.js support among different providers.

That’s all there is to it to configure Twilio to communicate with our application. From now on, whenever your phone number receives an SMS message, the message will be forwarded to the /rest/smsmessage URL that you provided. Now we need to create the REST endpoint to handle the message.

Creating our REST services

Now that we have our application stubbed out, the connection to our database working properly, and our twilio account and number created, we can begin to create our REST based web services. The first service that we want to create is the ability to write SMS messages that we receive to our phone number to our MongoDB database.  Create a new file called sms.js under the models directory and enter in the following code:

Given the information we covered in the previous blog post, we learned that by default, StrongNode creates all of the CRUD operations for our model objects.  Because of this, we do not need to create an additional function that will communicate with the MongoDB database to save our incoming SMS message.

Now that we have the REST web service to save an incoming SMS message to our MongoDB database, we need an endpoint that will allow us to retrieve a list of all the SMS messages that we have saved.  Fortunately, the code to achieve this is also provided by the default CRUD operations provide by StrongNode.

Save and then restart your node application using the following command:

Testing our REST services

To test that our SMS messages are being saved to the database, pull out your mobile phone and send an SMS message to the provided twilio number.

Once you have sent an SMS message, point your browser to the following URL, replacing with the correct domain name for your application.

You should see all of the SMS messages that you sent to your twilio number.


In this blog post we signed up for a Twilio account, configured our phone number, and pointed the phone number to call an endpoint when it receives an SMS message.  We also created a Mongoose Model object that defines the data we want to store for any incoming SMS message.  We used the provided CRUD operations from StrongNode to create and read incoming messages.  In the next post we will write a mobile application for both Android and iOS that will display all incoming message to our Twilio number.

What’s next?

What’s New in Node.js and libuv – Aug 29, 2013

Welcome to this week’s wrap up of the week in Node and libuv covering August 14 through August 27. The purpose of this blog is to recap a subset of the non-documentation related commits to Node.js, plus give a little color and commentary to the ongoing development of Node.

Node v0.10 branch highlights

v0.10.17 has been released

Read the official release notes here.

npm has been upgraded to 1.3.8

http: Handle hex/base64 encodings properly

Isaac fixed sending hex and base64 encoded strings with http.ServerResponse#write() in 255650f.  The commit log mentions it’s a back-port from the master branch, but points to the wrong commit, the correct one is ce3d184. Non-bug report fix on this one. It was found while going over the http code.

crypto: fix memory leak in randomBytes() error path

Ben fixed a memory leak in the error path of crypto.randomBytes() in f55aca6. No bug report either, found while going over the crypto code.

readline: pause stdin before turning off terminal raw mode

Daniel Chatfield fixed the readline module’s raw/cooked mode switching logic in 5453619. Only applicable to Windows 8 and Windows Server 2012, other platforms are not affected.

dgram: fix assertion on bad send() arguments

Ben fixed a C++ assert in 0c2960e that got triggered when you passed bad arguments to dgram.Socket#send(). This commit introduces a small change in behavior: before, negative port numbers were silently accepted, but ignored (meaning datagrams were sent to a random port). Now they are rejected with an exception.

stream: Throw on ‘error’ if listeners removed

Isaac fixed an edge case where streams sometimes silently “swallowed” the ‘error’ event 5458079. The commit log has an example.

fs: use correct self reference for autoClose test

Gil Pedersen fixed a gnarly bug in e04c8a8 where a fs.ReadStream didn’t destroy itself properly when it failed to open the file. Essentially, it stalled.

tls: fix assertion when ssl is destroyed at read

Fedor fixed a C++ assert that was triggered by an edge case in the tls module in af6a233. Fixes #5756.

deps: upgrade http_parser to 303c4e4

Ben upgraded the bundled http_parser library in 8d42c63. The single change is that invalid request methods are now rejected. Before, some were accidentally let through (i.e. GEM was interpreted as GET – pretty trivial but the Internet rabble was up in arms about it.) The initial patch by Chris Dickinson, was fortified by Ben some more in
303c4e4. That probably concludes this year’s changelog for http_parser.

You can view the complete Nodev0.10 commit history on GitHub.

Node master branch highlights

v0.11.6 is out

Read the official release notes here.

dgram: don’t call into js when send cb is omitted

Ben sped up dgram.Socket#send() a little in 1449739 by not calling into JS land when the user hasn’t provide a callback.

build: don’t auto-destroy existing configuration

Ben removed a “feature” from the Makefile in c75251c where it would blindly re-run configure when the configure script had been touched, effectively destroying the current configuration. This particular “feature” had Ben cursing one time too many…

build: make ninja build respect V=

Ninja builds respect the V= (verbose) flag as of d046e9d.

build: disable SSLv2 by default

SSLv2 is now disabled by default (commit 39aa894.) In the deeply unlikely event that you need v2 support, you can enable it again with the –with-sslv2 configure switch.

crypto: add TLS 1.1 and 1.2 to secureProtocol list

Matthias Bartelmeß added TLS v1.1 and v1.2 to the secureProtocol list in 4ac6912.  Both protocols were already supported, but they weren’t easily selectable.

tls: handle errors on socket before releasing it

Fedor fixed how the tls module deals with TCP-level socket errors in c50750e. If you got ECONNRESET errors that were impossible to catch – that should be fixed now.

doc: http rawHeaders/rawTrailers

Isaac added a new API for accessing the raw HTTP headers in e6c81bd
(documentation in 7304a62). Fixes #4844.

http: Add write()/end() callbacks

http.ServerResponse#write() and end() take (optional) callbacks as of da93d6a.

http: Consistent ‘finish’ event semantics

Isaac changed the semantics of the ‘finish’ event on http streams in 7c9b607, it’s now more like the ‘finish’ event with regular streams. Not sure if that affects many people but if does, consider this a heads up.

http: Prefer ‘binary’ over ‘ascii’

HTTP headers as of 1f9f863 are now encoded from string to buffer with the ‘binary’ encoding rather than ‘ascii’.  If you relied on Node.js to strip the high bits off your HTTP headers, then now would be a good time to update your code.

tls, crypto: deduplicate code

Fedor removed a lot of duplicated code in the crypto and tls modules in b9a0eb0 (mostly because Ben kept yelling at him to fix it. We are talking about ~1,000 lines of duplicated code here.) Fixes #6024.

http: removed headers stay removed

James Halliday changed the http module’s removeHeader() method in 5555318.  Node’s sometimes adds headers automatically (when it has to) – you can now remove those.

events: have events module exports EventEmitter

`var EventEmitter = require(‘events’)` now works – the module object is the EventEmitter class.  Saves a few keystrokes. Commit 6ed861d, courtesy of Jake Verbaten a.k.a. Raynos.

net: family option in net.connect

Vsevolod Strukchinsky added a ‘family’ option to net.connect() in edd2fcc. Node prefers IPv4 over IPv6 when resolving hostnames, the family flag lets you override that. Some follow-up work to make it work for http.request() etc. is expected.

vm, core, module: re-do vm to fix known issues

The new vm module landed in 7afdba6, courtesy of Domenic Denicola. This is basically the contextify module that everyone and his dog uses.

util: pass opts to custom inspect functions

Commit 546ae2e by TJ Fontaine makes it so that the optional options object (+3 advanced alliteration application) to util.inspect() now gets passed on to custom .inspect() methods.  Fixes #5822 and #6098.

buffer: fix regression in Buffer(buf) constructor

Ben fixed a regression in the Buffer(buf) constructor (the constructor that makes a copy of an existing buffer) in bc28acd. It copied from the new to the old buffer instead of the other way around. As you can imagine, hilarity often ensued!

domain: move error handling directly into instance

Error handling is pluggable as of 467e00e (by Trevor Norris.) What this effectively means is that domains error handling is now configurable by user-land modules, meaning they can set their own error handler. This was requested by New Relic and many others.

src: remove –max-stack-size option

Ben removed the –max-stack-size option in 3a87b31.  It was duplicating the functionality of V8’s built-in –stack-size option so no point in keeping it around.

fs: Expose birthtime on stat objects

The st_birthtime field from struct stat is exposed through the fs.Stat object as of 645418e. It’s the creation time of a file. (“Isn’t that the ctime field?” Nope, ctime stands for _change_ time.) It’s only set on platforms that support it natively, currently OS X and the BSDs. Windows and Solaris may follow. Linux doesn’t really have a concept of creation times.

domains: deprecate domain.dispose().

As of d86814a, domain.dispose() is officially deprecated.

You can view the complete Node master commit history on GitHub.

libuv v0.10 branch highlights

unix: retry waitpid() on EINTR

Ben fixed a (probably hypothetical) bug in b2ac4d3 where EINTR wasn’t handled correctly when calling waitpid(). Ben says ‘hypothetical’ because no major platform raises EINTR when the WNOHANG flag is set.

darwin: create fsevents thread on demand

The FSEvents watchdog thread (the thing that watches for file notifications when you call in node on OS X) is now created on-demand rather than at start-up. Commit 9bae606 by yours truly.

fsevents: FSEvents is most likely not thread-safe

Fedor fixed a thread-safety issue in same-said FSEvents code in ea4cb77 and worked around a resource limit issue in 684e212. Fixes joyent/node#5463. If you get “FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-21)” error messages a lot when watching files, you will want to upgrade to the upcoming Node.js v0.10.18.

windows: make uv_fs_chmod() report errors correctly

uv_fs_chmod() on Windows now reports errors correctly. Commit 851a662 by Bert.

You can view the complete libuv v0.10 commit history on GitHub.

libuv master branch highlights

build: disable parallel automake tests

Ben disabled automake’s parallel test runner feature in 35ea88c, added a version check in a97685e, fixed the version check in e4c1483 and fixed it AGAIN in acf1310. Ben would like to thank automake maintainers, for making complicated what should be easy! The motivation for disabling it is that the parallel test runner tends to hide the output until the test has completed – which is supremely annoying because it means you don’t see anything until libuv’s own test runner has completed (which takes minutes.)

build: fix string comparisons in

Ben fixed a bug in the script in 0e4fa70. If your shell complained about an invalid statement, please upgrade. (Libuv, not your shell.)

unix, windows: allow NULL async callback

It’s now possible to pass NULL as the callback to uv_async_send(). Commit 1510ce8. Motivation: for when you want to wake up the event loop in another thread but don’t care about getting notified of that.

darwin: reduce fsevents thread stack size

The FSEvents watchdog thread now uses < 32 kB stack. Saves a few megabytes of address space on 32 bits machines. (On 64 bits machines too, of course, but it’s less pressing there.)  Commit c82e703. This should make the Rust people happy.

windows: omit stdint.h, fix msvc 2008 build error

Ben fixed the MSVC 2008 build in 8531046.  Apparently people still use that 🙂

windows: make uv_spawn() failure more predictable

uv_spawn() on Windows now behaves more like its Unix counterpart under error conditions.  That is, it returns mostly the same errors in mostly the same way.  Commit ed82eae by Bert.

process: make the ‘status’ parameter for exit_cb an int64_t

The ‘status’ argument to uv_spawn()’s exit_cb argument is an int64_t rather than an int as of commit 66ae0ff (once again by Bert.)  It allows Windows-specific exit codes to get through unmolested.

linux: fix setsockopt(SO_REUSEPORT) error handling

Ben fixed setsockopt(SO_REUSEPORT) error handling on Linux in 17452cd, then decided against it and removed that option altogether (on Linux) in 9d60f1e. The rationale for fixing it is that only recent (>= 3.9) kernels support the socket option. When you compiled libuv against 3.9 kernel headers but ran it on a 3.8 or older kernel, it would panic because the system call failed unexpectedly. Easy to fix, of course. After sleeping on it for a night, Ben came to the conclusion that the SO_REUSEPORT behavior is too different from what older kernels or other platforms do, so he backed it out altogether.  The commit log goes into more detail.

windows: reimplement uv_fs_stat using NT syscalls

uv_fs_stat() on Windows is now implemented with native NT system calls rather than the CRT wrapper. That means that the st_blocks, st_blksize, st_ctime, st_dev and st_ino fields now have meaningful and/or correct values.  Commit 20a8e58 by Bert.

build: make autotools build system work with mingw

The autotools build now works with MingGW on Windows. Commit e52aa6c by Keno Fischer of Harvard University. Keno works on the Julia language project, libuv powers part of the standard library.

build: remove mingw makefile

Ben then removed the Makefile.mingw in 8f3621e but restored it again in d5ab1c1 after a request from the Rust people. (Another programming language that uses libuv.)

unix, windows: add thread-local storage API

Ben added a thread-local storage API in 5d2434b.  If you’re familiar with pthread_getspecific() and friends, you’ll feel right at home.

windows: tweak Makefile.mingw for easier usage

Alex Crichton made the Makefile.mingw a little easier to drive from
a top-level project in a9b3fe2.  Notably, it now extends rather than
overrides the CFLAGS directive.

windows: make it possible to use NtQueryVolumeInformationFile

Bert broke the MinGW build in 315d7001 which Alex Crichton subsequently fixed in b647c27. 🙂

build: remove _GNU_SOURCE macro definition

Not sure if anyone cares but it’s no longer required for projects
that include uv.h to compile with -D_GNU_SOURCE on Linux.  (No longer
required, it’s still possible and allowed, of course.)

You can view the complete libuv master commit history on GitHub.

What’s next?

Node.js and Mobile News Round-up – August 27, 2013

Welcome to this week’s summary of the week in Node.js and Mobile news covering August 20 through August 26. Every week this time we will look at some of the Node.js-related news, tutorials and commentaries we’ve seen online.

That Wibbly Wobbly Real-Timey Wimey stuff

Courtney Couch speaks about how Moot uses Node.js for its instant notifications.

Hacker Turns Google Glass into Drone Controller

DNA reports how Node.js was used to turn this hardware into a remote control.

Video Talk: What Node.js is All About

A video showing Niall O’Higgins speak about Node.js at Share This in Palo Alto.

Intro to MongoDB on Node.js

Ryan Jarvinen gets you started with MongoDB and Node.js.

An Absolute Beginner’s Guide to Node.js

Brandon Cannaday explains how to get started with Node.js from the very beginning.

Why The Hell Would I Use Node.js? A Case-by-Case Introduction

Tomislav Capan provides examples showing why you should – or should not – use Node.js.

Incredibly convenient testing of front-end Javascript with Node.js

Boris Staal makes sure you have automated testing for your front-end JS application, library or framework.

What’s next?

Setting Up and Monitoring Node.js Apps on Elastic Beanstalk with StrongOps

There has been a lot of talk in the news lately about Amazon Web Services and AWS Elastic Beanstalk. The ability to use this deployment agent for Node.js means it is simple to get your Node.js product in the AWS Cloud. Since we like simplicity and we fully encourage you to monitor Node.js from the start, we wanted to test installing the StrongOps agent to monitor a Node.js product on Beanstalk. Luckily, StrongLoop’s Andrew Martens was on scene to walk us through.

To monitor your product, you first need to install it. And we found that setting up on Elastic Beanstalk was straightforward. You can do so through Git, or through the Eb command line interface.

Note that while we are covering some of the steps for set-up here, it is a general overview. Please refer to the AWS documentation for complete details.

The first thing you will want to do is sign up for AWS. Sign into AWS when you are done signing up, or if you have already created an account.

Go to the Security Credentials page:

Create an Access Key (or maybe make a new one for managing your EB)

You will be given your Access Key ID, which you will need during the install process. The Access key is available in the Security Credentials section on the left hand side of the screen.

eb 1

Download the dev tools and add them to your path. You will find them here:

We also liked the command line tool available here:

Now unzip somewhere. We chose to do so here: ~/aws

Create a new git repository:

Run the AWS dev tools in that directory:

Is everything going well? Good. Let’s keep going.

Put some code together. We’re providing a simple example by installing Express. You can use that, or some other app. Ensure that it’s up-to-date and use best practices.

Install ‘express’ with npm and then run it.

Now put the StrongOps header at the top of app.js:

Don’t forget to update your package.json, add the dependency:

“strong-agent”: “latest”

And then let npm pull down all of our dependencies:

This is a good time to test things locally just to make sure you didn’t screw up.  Open up http://localhost:3000/ in your browser.

You can also then go and check out the StrongOps console to see if your new app is showing up. As you can see below, our Express app has a heartbeat.

eb 2

Now, add the next three lines to your .gitignore file to skip things we don’t need to store in git:

You can also add the platform-specific eb path to your $PATH

Run eb:

Remember the AWS Access Key ID and Secret Access Key you got earlier? If you forget, just pop on back to:

Enter your AWS Access Key ID.

Enter your AWS Secret Access Key.

Select an AWS Elastic Beanstalk service region (you will see a list of 8 available service regions).

Enter an AWS Elastic Beanstalk application name (auto-generated value is “aws-test”).

Enter an AWS Elastic Beanstalk environment name (auto-generated value is “aws-test-env”).

Select a solution stack (you will see a list of 18 available solution stacks).

Create an RDS DB Instance? [y/n]: n

Updated AWS Credential file at “/Users/[username]/.elasticbeanstalk/aws_credential_file”.

This deploys the pretty default node.js app to EB.

Let’s check out the console:

There’s also a handy button to go and see the default EB app that’s been installed:

eb 3

Let’s take a look at that:

eb 4

Now, let’s upload our own express app that we added StrongOps to:

Go back to the Eb console and monitor your application’s status there:

It will take a few minutes to deploy and restart.

Once it’s up, check out your application again via the “View Running Version” button.

eb 5

Hooray, it’s the default Express app!

Now let’s go back to our StrongOps screen and see the data coming in from our application:

eb final

VICTORY! We’ve gotten our app – Express, in this case – on Elastic Beanstalk.  We’ve also installed the StrongOps agent and can now monitor Express’s performance. We have the visibility we want to monitor, profile and improve our app, and were able to get it online quite easily with Elastic Beanstalk.

What’s next?