Nebulaz.io - another io game about ship fleets

[asyncrobot]

Hi everyone,

I have been working on another io game, and the first version was completed almost two weeks ago. Here is the link http://nebulaz.io

Features:

• The game is based on mining resources and creating a fleet with the points you collect.
• Ships auto shoot nearby resources or other ships.
• Players can buy ships with the resources.
• On the map, there are 4 health regen areas marked as green on the minimap.

Development Notes:

• I used pixi.js and shockwave filter for explosions
• Howler.js for spatial audio
• Communication is in a binary format.
• The game also works on mobile devices, thanks to pixi.js. 
• There is no client side prediction, everything is calculated on the server.
• The web server uses node.js for static content.
• The game server is written in C++ using uWebSockets.

Here is a video on my twitter.
https://twitter.com/asyncrobot/status/976192042215923715

I would like to hear what you think about this,
Thanks!

 

 

[Capitaine Herlock]

gg thx, it takes a little bit of time to understand how to buy ships and create a fleet, then it is really funny when the other players comes and destroy all your fleet while you try to escape

https://youtu.be/7VNW2FQ44Z4

 

 

[mehmetegemen]

Nice SFX choice and a cool game, would love to hear more about technical details. Why node wasn't enough for sockets ?

[asyncrobot]

@Capitaine Herlock thanks

[asyncrobot]

Hi @mehmetegemen

I was expecting a harsh response when I pointed that server was written in C++ Sorry for the long post. 

Ship movements are based on a model called boids. Here is the original link, if you are curious about it. Here is an explanatory video (which is not mine).

I wanted to simulate as many boids as possible, I implemented a simple boids model using javascript. Implementation was quite simple and it was not optimized as you can guess. On my laptop (with an i5 CPU), I could simulate around 600-800 of them with good framerates. The bad part is my implementation complexity was O(n^2) and I was greedy about simulating more boids So I decided to write one with C++ and using a more optimized approach.

I was full of hope when I started the first implementation, I started with a multithreaded design that can support many online players but the complexity of the project increased a lot, so I concede to change my design to a single threaded one. (Basically, two threads that share a single mutex)

I implemented a grid (basically a 2D bucket list) to quickly test my boids with each other. It was based on this tutorial.

Everything was defined as serializable entities with poor names (FleetEntity, FoodEntity, HealerEntity, ShipEntity, and ObstacleEntity). On every tick, all object are updated according to their update method.

Server tick count is 20 per second and updates are sent 10 times a second. Every update is prepared for each player but meta-data updates are shared between all players. Meta-data update contains information like player scores, minimap data etc. In order to create player updates, the server queries all entities in the view rectangle (400 by 400 units), serializes it into a binary array and pushes it to clients. So clients receive only the part they are allowed to see.

I only tested the server with g++ and on Linux. It should compile on Windows too. For production, I don't create releases. I have a separate branch in git for my production code, and it is compiled on the server. The client is compiled with google closure tool.

The client works as a terminal. It sends mouse position to the server and draws what is received. I spent most of my time on animations and visuals. Apart from the shockwave filter, those trail effect is implemented by swapping two offscreen render targets. On every frame, a particle image (smoke) is drawn for every ship. When it is rendered in sequence, trail effect is achieved. It is quite similar to this example .

When it was almost ready, I wrote a simple bot and spawned 200 of them on the remote server to check CPU/ram/bandwidth usage. I was happy with the results. 200 players (4 ships each) uses 10% of the CPU and only 10MB of ram Bandwith usage is usually quite low (1k-5k), but it can peak to 30kb/s if the screen is full of ships. If a client's queue starts to pile up, the server stops sending unimportant messages. If the client can't receive a certain amount of messages, the server closes that connection.

I test it with OVH's "VPS SSD 1", and I am impressed by the value. Currently, the site uses that plan.
https://www.ovh.ie/vps/vps-ssd.xml

I think I neglected the gameplay part of the game and mostly dealt with technical stuff. I wanted to make a game that can support 100 - 200 concurrent players with 10-20 ships. I think all time high was around 30 online players and that isn't a common thing  

My previous game (spaceblast.io) had some performance issues. It was written in JavaScript and can host 70 concurrent players on the same server. Most of the CPU was used by physics simulation. I also made that open-source afterward. That also motivated me to write it with C++. If you want to check that out, here is the GitHub link. But next time, I will probably use NodeJS again.

https://github.com/ercang/simple-physics-js

Again, sorry for the long post
 

[Umz]

Nice game, took a little long to start building a few extra ships at the beginning though. Perhaps make the dots die a little sooner so growth is a little easier in the beginning and stretch it out towards the end.
Enjoyed moving around in a swarm though, really fun to play.

[Marius]

wow. great effects and amazing animations! You have only to find more players

[Marius]

my 2 cent: when you can buy a new ship... buy it automatically (no Press 1 requiered). So it will be playable also on mobile easily.

[asyncrobot]

Thanks @Marius. I am planning to add different ship types (if I could find some time), that's why I added "buy ship" button.

[RagingPixel]

@asyncrobot the game is fun to play I reached max level  it works really smooth can't wait to see updates on it