Splody showing at GitHub / Ludum Dare GDC Party

Last night I attended the Ludum Dare / GitHub GDC party in San Francisco at the fantastic offices of GitHub.  I have no idea where their employees work (perhaps another floor?) but their gathering space was fantastic, and they even had a nice big TV with a dangling HDMI cable set up which I was able to snag for an hour or two of showing off my game, Splody.  I turned the TV over to Shnipers for the latter half of the night, as that was also a fantastic local multiplayer game, and had a chance to play a bunch of other indie games around the room as well.

The showing of Splody went quite well, often had 6 or more people playing at once, everyone seemed to be having fun, and quite a few were really excited about the game.  It was great to have so much positive feedback!  Everyone unanimously enjoyed my simultaneous multiplayer character customization/control test screen.

Simultaneous multiplayer character customization and control test screen

Now, I just need to channel as much attention as possible into getting Greenlit on Steam, so, if you have a Steam account, please go vote on my Steam Greenlight Campaign, every vote helps!

I did learn a few things that hadn’t came up with my previous demos – as this demo was to a bunch of random people at varying frequencies, and most of my previous demos have been to larger captive audiences.  I need a good way to show the game to just a single demoer – playing a 1v1 match against me, a tournament-winning Bomberman player, either doesn’t go well for them, or feels like I’m just committing suicide.  I think I’ll throw in an option to pad out a match to a fixed number with AIs, so if there’s just one person demoing, AIs can fill in so there is at least 4-6 players on screen for a better feeling of what a party game can be, though obviously playing against AIs isn’t as fun as stomping your friends.  The other thing was with one particular game mode, Mount Control, which currently has a bit of randomness in it which can lead to rather long matches, and I think I can do a little tuning so that the expected match time is a lot more constrained which would lead to much better conference-floor demo experiences.

Oh, and the other thing I learned, or, rather, already knew, but keep forgetting, is that I really shouldn’t play against a set of people and win 3 to 0 to 0 to 0 to 0 to 0… but some people playing the demo get really competitive and I have to give it my all to give them a fair fight, and the I forget to tone it down a notch for the next group.  Best solution is probably to continue talking about the game constantly, as me paying half attention is probably the right skill level for most people ;).

The horrible things people’s routers do to my packets!

Auto-updating software

So, over the years, I’ve released a few programs (all native C/C++) which have included automatic version checking, so they can let the user know when a new version is available. I’ve always done this by making a socket connection to my web server (previously Apache, now entirely Node.js) and asking for a file which just contains a version number. Pretty simple, right? Sure!

SOCKET s = socket(AF_INET, SOCK_STREAM, 0);
connect(s, ...);
char cmd[] = "GET http://www.bigscreensmallgames.com/BestBombermanEver/version.txt HTTP/1.0\r\n\r\n";
send(s, cmd, sizeof(cmd), 0);
recv(s, ...);

And that’s about it.  Note:

  • This sends a single packet, and no router’s MTU is small enough that this packet would ever be fragmented, so it is, in theory, at least according to how TCP/IP is supposed to work, guaranteed to arrive as a single packet. Not that most web servers would care…
  • I don’t bother sending any headers, specifically the Host header. Why would I if this works?
  • There’s a bug in the code, it’s writing the NULL character into the packet after the final line feed.

Continue reading “The horrible things people’s routers do to my packets!”

It’s Node.js All the Way Down

Summary

Node.js can be pretty simple, but things get a bit more complicated when using Node.js to combine serving virtual hosts, some static sites, WebSockets (socket.io) used everywhere, some proxying to other apps, and some with request rewriting for hosting apps in a subdirectories.

The problem

I have a host running collection of websites and web apps, on various hostnames, running under various users, using various technologies.  I often forget exactly how all of these things work, how they work together, and they have some subtle problems I don’t want to bother with having to resolve.

The proposed solution

It’s Node.js Apps all the way down!

It's Turtles All the Way Down

Continue reading “It’s Node.js All the Way Down”

Efficient Load Balancing and SSL Termination for WebSockets and Node.js

Original Post: 2013/09/30 on the (no longer running) Cloud Party Blog.  Some notes added in-line while re-posting.

Goals, Background, and Requirements

At Cloud Party (repost note: no longer running after we were acquired by the Yahoo Games team), we have built a platform for users to create, discover, and share massive amounts of 3D content in a multi-user, social environment.  When I was starting to configure our live servers, we needed a front-end load balancer (or “reverse proxy”) setup which met a lot of requirements:
Continue reading “Efficient Load Balancing and SSL Termination for WebSockets and Node.js”