next »

[Mischawake]

(Formerly, Hoom, and before that Murmuration)

Background

Hi! I've been working on this prototype on-and-off the past few months. I was working at thatgamecompany up until the end of last year and when I left I decided it would be cool to try applying some of the TGC design aesthetics I picked up with a multiplayer browser game along the lines of Slither.io. I wound up focusing on flocking mechanics using Craig Reynolds good old "Boid" models (http://www.red3d.com/cwr/boids/) (I've gotten used to referring to things that flock as boids so I'm gonna continue doing that here). I was originally calling the game Murmuration,  a murmuration is a specific kind of flocking behavior in birds that looks like this:

What's in a name?
(Updated 7/19/17)

After trying to find a .io domain name for the project I switched first to Hoom.io, and then to HyperBoid.io. I'm not sure what i was thinking with Hoom. In retrospect is sounds like an Ikea product or startup (maybe the Uber of vacuum cleaners?). HyperBoid sounds like an old arcade game to me, also rings of metroid, asteroid, bolide, and hyperboloids - all good mental references. So it's HYPERBOID.IO for now!

Design

The current game operates a lot like Slither.io, but instead of eating to grow longer, you pick up free boids and add them to your flock. You guide your flock indirectly by controlling a leader boid that all of your flock members try to follow. You can take out other players by getting your follower boids to collide with his/her leader. When someone is eliminated their flock is free for the taking. I'm still tuning the flocking trying to find the right balance of control and chaos, I need to do some more playtesting to really determine if the feel is right.

The game was originally everyone for themselves (like Slither.io), but, because there is a finite number of boids in the game what would happen is one player would eventually have almost all the boids in their flock and everyone else would be left with none. In some of my playtests new players couldn't join because there were no boids free. So I changed direction and am currently experimenting with a team based mechanic where one team wins by collecting half of the boids in the game. I'm not sure yet what should happen at the end of each round. I like the idea of rebalancing the teams based on how many boids everyone collected, so that if there are a few dominant players they might wind up out numbered. I'm also liking the idea of doing rounds that end rather than an infinite play mode like in Slither.io. I currently have bots in the game so that I can test it on my own. They're pretty dumb, but it's still pretty fun playing against them. I'm not sure whether the final version of the game will have bots or not, I sort of like the idea of filling every game with bots that get kicked out any time a human joins - that's basically how it works now.

Development Challenges / Next Steps

My current version supports 64 players, but that number is pretty arbitrary. The "right" number of players will depend on how many boids I can support - currently its around 1000, so that's about 15 boids for each player on average. I think the game would be better with double that, so either less players per game (lame) or more boids (hard). Generally the more boids the better!

The biggest challenges I'm facing now have to do with networking and performance in general. All of the logic and state of the game runs server side with player clients acting as basically just a renderer for the game's state and a controller. The only data passed from client to server is the input position. The server is sending the positions, orientations, and state for every boid to the client around 10 times a second. With 1000 boids that winds up being enough data that if I were to launch the game today I'd wind up with a hefty AWS bill. So I'll be seeing what I can do to cut down on the bandwidth requirements through compression or other means. I'm interested in seeing if I can send each client only the data relevant to their view of the game.

General performance for running all the boids is another issue. The flocking logic involves testing distances between each boid and every other boid in its vicinity. The performance here was greatly improved by using a hashmap to determine which boids are close enough to each other to require a real distance check. I think the game is viable with 1000 boids, but it would be definitely improve the experience if I can make it work for even more.

The last next thing for this prototype is my figuring out some of the ins-and-outs of hosting a browser game. The current prototype is running on AWS but I'm not sure that's the best long term solution. I also need to figure out how to integrate ads (annoying I know, but I need a way to at least try to cover the server costs). My plan is to have short ad show at the end of each game round, I'm hoping it won't be too annoying. I'm definitely open to hearing other monetization ideas if people have feelings about that.

If you're interested in playtesting let me know, I'm going to be organizing some larger (64 players would be awesome) playtests soon. Feedback and ideas are very welcome.

Thanks for checking out Murmuration! I mean Hyperboid!

[Mischawake]

OPTIMIZING FOR BANDWIDTH

Spent the last few days working on optimizing the bandwidth for this game. I also bought the domain hoom.io - where I'll eventually be hosting it. I'm not sure what Hoom or Hoomio means - but it's a 4 letter url that's not too hard to spell so that's good.

Networking optimization wise I ran the numbers a few days ago and realized with my current performance I'd be paying almost $20 a month PER PLAYER on AWS . The bandwidth per player was around 150kb/s. To be viable with ad revenue, I need this to be much much lower, like 10kb/s or less on average.

The current version of the game has 1000 boids, and up until this last set of updates I was sending the state for each boid to every player on each server update (10/s). Instead what I'm doing now is having the client broadcast it's camera position and frustum size to the server, and having the server send back only the boids that the player can "see." This is accomplished using a hashmap of the boid positions. It's basically server side frustum culling. It cuts down on bandwidth and has client side perfomance benefits since I don't need to do any frustum checks. This improvement brought the bandwidth per player down to around 20 kb/s. It could spike much higher if there are a high concentration of boids in a player's view, but even with that possibility this is a big improvement.

I also implemented a "slow channel" between the server and client where I'm sending data like the player names and scores. This data doesn't need to be updated 10 times per second, so that's an additional savings.

Lastly I hooked up LZ4 compression, but it didn't really do much. My data is pretty random (boids flocking around) and I don't think there were any patterns in the data for the compression algorithm to take advantage of. The boids are the bulk of the data and I'm already manually packing the bits for them, so really nothing to compress.

That's all for now.

[wizered67]

The game looks cool and your post on optimizing for bandwidth was very interesting! Following, and I hope you keep making posts about the technical aspects of the game!

[Mischawake]

I've been having a major identity crisis trying to pick a domain name for this project. Finally settled on Hyperboid.io which I think has the right ring to it. Updated the original post to reflect the change, hope that's  kosher But wait is it HyperBoid or Hyperboid. I should really go back to programming now.

[leonidax]

Looks interesting but I tried to access buy seems like the web site is down. 

[Mischawake]

The game isn't live yet, still have a lot of work to do. I'll post a link when it is!

[whistlerat]

Unf yes, I've loved the idea of playing with a flock of something for a while now. Seems like the sort of thing which would be really satisfying to just toy with! I actually really like your old name Murmuration, but the 'bird -> boid' similarity is very appealing...

Good luck, and I'd be interested in testing if and when you need any

[Mischawake]

Just recorded some cleaned up gameplay, here are some highlights:

[kinnas]

These are mesmerizing to watch