Drama Royal

[Dasein Fiasco]

Hi all,

i've released an early production build of my latest game, Drama Royal. If you ever played Sissy Fight 2k, Drama Royal is a reboot of SF's core mechanics, but modernized a bit, hosted on Facebook, and with some new game elements.

If you aren't familiar, then it's best described as a multiplayer, simultaneous action selection fighting game in a chartroom where you play schoolgirls trying to ruin each other's self esteem. Games take place while chatting with other players, who you try to convince to attack each other, leaving everyone humiliated but you. The actions you perform - tease, scratch, grab, tattle, cower, or medicating - are entirely dependent on the actions taken by others, so the general strategy is to manipulate players into attacking each other until you can finish them off yourself. Lots of teamwork and treachery! A game requires 3-6 players, and 0-2 players can win.

Sadly, the graphics are still largely absent, UI incomplete, features missing, and bugs lurking in the nooks and crannies of the code. And even worse, because I've no traffic to speak of at the moment, you end up waiting a while for minimum players to show up; it's best to coordinate with friends. *If* that all doesn't turn you off, though, I'd be grateful for any indirect QA showing up in my logs.


https://apps.facebook.com/dramaroyal

If you stumble over any bugs and have the time, comment on the app's wall so other players are made aware and I can comment back when fixed. It's a poor man's bugtracker, but it works for now.

https://www.facebook.com/apps/application.php?id=153494728049768&sk=wall

I've also been keeping a fairly active twitter feed of development.:

https://twitter.com/dramaroyal

I put this game together because, well, I love the gameplay so it scratches a personal itch, but also as a bit of a testbed for various technology.

The backend is a node.js web server built from scratch, with socket.io handling the comet layer, usually with websockets or xhr-polling. Node was a nice fit because the game is really just a glorified chartroom, and massive concurrent connections is where the platform excels thanks to JS and V8. For a database I'm using MongoDB, whose document format works well for the transitory and relatively self-contained nature of most of the game data, and which has a non-blocking driver that makes it natural for calling in node.js, to say nothing of the json portability. Mongo's cache also means I don't need to run a separate cache layer.

There's a global lobby socket which can theoretically support 1000s of users, while each game is part of a multicast socket private to the players. Authorization is simply done via the browser session, and then a secure socket connection over https.

The whole stack is hosted on a single Amazon EC2 micro instance (you can get these free, btw) at the moment, on a 64bit ubuntu image I customized. I just use a single-user git server hosted on the machine for handling deployment, and a combination of upstart and monit scripts to keep it all running.

The frontend is JQuery, but otherwise nothing special. It's obviously a Facebook canvas app, and I created a number of Facebook test users for initial testing; I should note that I haven't used the test users for awhile since they used to not work with half the APIs, but the feature appears fully integrated now and I was able to do everything a normal user could. Facebook mandates ssl, so I had to install a certificate on the server to even begin live testing on Facebook, so that was rather annoying if unavoidable. I'm calling the new Facebook game scores and achievement APIs, so I'll see if that turns out interesting. Facebook has had a habit of killing its game-specific APIs in the past. I'm also prepared to use Facebook Credits. I haven't finished the game mechanics to make it worthwhile yet, but so far the credits API will do everything required by the game, so that's a relief; Facebook recently mandated Facebook Credits on canvas apps, so this wasn't really a choice.

Anyway, check it out if you're interested in that sort of thing. That's my BBG development status update for the time being.

[hiigara]

What is a multicast socket? I am always interested in learning new networking technologies.

[Dasein Fiasco]

What is a multicast socket? I am always interested in learning new networking technologies.

The socket is just a regular socket server that accepts listeners, and multicast just means that the listeners are grouped, exactly like chatrooms, so that messages can be selectively broadcast.

[hiigara]

What is a multicast socket? I am always interested in learning new networking technologies.

The socket is just a regular socket server that accepts listeners, and multicast just means that the listeners are grouped, exactly like chatrooms, so that messages can be selectively broadcast.

Where is the selective broadcast implemented? Is it in the raw socket system calls, or in node.js code or your code?

[Dasein Fiasco]

The socket is just a regular socket server that accepts listeners, and multicast just means that the listeners are grouped, exactly like chatrooms, so that messages can be selectively broadcast.

Where is the selective broadcast implemented? Is it in the raw socket system calls, or in node.js code or your code?

Node provides access to the raw sockets, but I use a library called "socket.io" that abstracts some of that work away. The broadcasting is handled in my code, where I've setup a basic pub/sub system for various events such as chat messages and, of course, gameplay.

[hiigara]

Thanks for the technical details, and good luck with your game. I never tried node myself.
I do the server side with C++ and implement broadcast in my code.
I call any group of sockets a channel.
Basically for each new notification I loop over all the sockets which belong to a channel and send the data to it.
When I read your post I thought there was something built-in in the socket API that could do this for you.
I know you can broadcast the same packet to several IPs in UDP with a single send() call, but probably it doesn't work with TCP sockets.
By the way your links are broken. You forgot the double //

[Dasein Fiasco]

Thanks for the technical details, and good luck with your game. I never tried node myself.
I do the server side with C++ and implement broadcast in my code.
I call any group of sockets a channel.
Basically for each new notification I loop over all the sockets which belong to a channel and send the data to it.
When I read your post I thought there was something built-in in the socket API that could do this for you.
I know you can broadcast the same packet to several IPs in UDP with a single send() call, but probably it doesn't work with TCP sockets.
By the way your links are broken. You forgot the double //

Yeah, I don't think there is any way out of wrapping the raw socket lib with some sort of controller that must loop through the listeners. You can be clever in how you do lookups of your listeners, but you still must track them yourself. In my case, the socket.io lib for node.js handles a little of this on my behalf, though.

I'm running a TCP server because I need the reliability and can't be bothered to customize a UDP envelope for a game that isn't low-latency in the first place. Handling multicasting yourself is still much less work than custom UDP, though, and I want to spend time writing a game, not socket servers.

Anyway, node is a complete joy and extremely productive to work in. The instrumentation and tooling needs some work, but otherwise from what I've seen nobody should have problems running production apps on node. Javascript may not be your thing, but the evented nature of the language is really a natural style for node apps. I use C++ in my day job - I work for a game company, and since we publish to XBox, PS3, PC, and mobile, portability and performance are king. I strongly dislike the language, though, unless chosen expressly for the control it gives you over memory; by every other metric imaginable I think it's a broken language.

Do you use boost::asio? I will say that it's an extremely nice framework, much cleaner and logical than the other 3rd party C++ APIs I've had to work with.

[hiigara]

Anyway, node is a complete joy and extremely productive to work in. The instrumentation and tooling needs some work, but otherwise from what I've seen nobody should have problems running production apps on node. Javascript may not be your thing, but the evented nature of the language is really a natural style for node apps. I use C++ in my day job - I work for a game company, and since we publish to XBox, PS3, PC, and mobile, portability and performance are king. I strongly dislike the language, though, unless chosen expressly for the control it gives you over memory; by every other metric imaginable I think it's a broken language.

Do you use boost::asio? I will say that it's an extremely nice framework, much cleaner and logical than the other 3rd party C++ APIs I've had to work with.

I like C++. I code all core features in C++, then I use python in parts of the code which change frequently. I have heard good things about boost, but being a programmer who likes to control everything, I try to avoid 3rd party libraries as much as possible. I specially dislike libraries which use C++ templates heavily.
I have coded my own network code from scratch. If I were to use boost::asio I would have to spend time studying the source code anyway, because I like to know what is going on under the wood.