Gotia.io is a fast phased IO game that combines some elements of agar.io with medieval combat.
There are 3 basic classes that you can play as: Viking, Knight and Spartan. The choice of class has no impact of the gameplay, it is just a visual feature. Similar to Agario you collect coins to grow larger and this will also make you hit harder. There are powerups on the map in this game, shields and horses. The shield makes you take less damage and the horses increases your speed by 50 percent.
Gameplay
There are a number of different scenarios that you find yourself in while playing this game depending how big you are. When you are small you will have to flee from the bigger players because they can cause a lot of damage with only one strike. Fight with players that are about the same size as you are and remember to grab a shield to gain a competitive advantage in the fight. The shield will reduce the damage taken by 50% so it can really impact the outcome of the fight.
You need to grow to a size that is somewhat in the range of the bigger players in order to challenge them in a fight. I fsomeone is a lot bigger than everyone else on the map it is a good idea to cooperate with other players in order to take down the biggest player.
The controlls in this game are very simple, you use your mouse to steer and you click to attack, the space bar can also be used to attack.
Since slither.io is pretty much the biggest IO-game out there, you might actually have tried it even though you are not a pathetic loser with nothing better to do. In this exciting snake game your job is to get as big as possible and slaughter those opponents who were foolish enough to come near you. Use the pointer to steer, left click to boost and enjoy an epic game. In order to climb to the top, muster your skills and face off against your opponents in a struggle for life and death, absorbing what remains of them after you are done.
Just make sure that your own head does not collide with someone or you will have to start again from the beginning. As you get bigger, it will be possible to, like an anaconda, encircle your opponent, leaving him no chance to escape. Make sure not to boost for too long at a time since boosting reduces your mass.
You are of course given the opportunity to pick your own nickname and it is also possible to unlock skins through sharing the game. You length and current rank is visible on the bottom left corner of the screen. Struggle to reach eternal fame and glory.. or well.. at least to get the biggest snake in the room.
Agar.io is not a very complicated game, quite the opposite! Basically all there is to it is a bunch of circles trying to eat each other. Use your pointer to control your own circle, farm the tiny dots until you are big enough to go on the offensive and start swallowing opponents smaller than yourself.
Be on your watch though, you never know where there is a massive giant waiting to devour you and end your hopes for victory and greatness. If you are small enough, it is possible to hide behind the green circles but as soon as you exceed it in size your former protector will blow you to pieces instead. As your size increases your speed will decrease slightly, making it harder to catch other players.
Is he getting away? Don’t worry, as long as he is considerably smaller than you are you can split up in two circles using space, throwing one after him in the process, and make the unsuspecting fool disappear for good.
Think twice before you do it though, as uniting your two circles again is not the easiest thing in the world, leaving you vulnerable to the mightier players. There is also a possibility to pick a skin of your own for your circle. Do you have what it takes to make it to the top, creating the biggest circle this world has ever seen?
Throw yourself into the action in superhex.io, a strategic struggle for map domination. Use the pointer to control your character in a game which first appears to be a kind of snake game, but with a dramatically different gameplay. You start off with a tiny area belonging to yourself and it is your job to expand it.
In order to do so you need to encircle an area on the map and bring your character back to that which already were in your possession. Expand your area, perhaps with small journeys outside of your territory, perhaps with more daring expeditions further away. Watch out though, the nearest enemy is never far away, waiting to steal your area from you and make it his own, or worse, cut off your tail and finish you.
You earn points in two ways. The first is of course through increasing your domain, points which you may lose if you are unable to defend it from others. In addition to that it is also possible to earn points by taking down other players.
Experience the frustration when someone is eating off your territory and the indescribable satisfaction when you find the fool and manage to stop him in his track. Join the fight and see if you have the qualities required for wrecking the opposition and conquering the map, painting it in your beautiful colors.
There are a number of ways to port you IO game to mobile. I will cover the most popular methods pros and cons. The simplest alternative is to port it directly from javascript using CocoonJS which is based on cordova. This allows you to export you IO game to mobile devices without having to change much of the code. However, in my experience the app produced by Cocoon is somewhat laggy and it can not handle many texrures on the screen as well as some native solutions.
If you want your game to be a flawless mobile experience and you think that a significant portion of you users will be using mobile phones, then I would recommend making a native version for your game in Java or Swift. The game engine that I would recommend is LibGDX since it is the most used mobile game engine and it provides everything that you need to make a great mobile game. There are also tons of examples and tutorials on how to use LibGDX. There is also support for using Socket IO through a java library that can communicate with any socket io backend, so it is not necessary to change anything on the backend to make the mobile version work.
Making a flawless mobile game will require you to rewrite the entire client side of your program, this may not be as time consuming as it sound since JavaScript and Java are quite similar and a lot of the code from the web version can be copied and you only have to change "var" to "float" or whatever variable is suitable. The more painful part of porting your game this way is that he rendering method is quite different. In Javascript, atleast if you are using Phaser, you only add the texture once to the game and the game manages the rendering of the texure behind the scenes and you dont have to cary about it unless you change the texture position or any other property of the texture. In LibGDX however, you have to draw all textures to the frame every time you go through the game loop so the procedure of adding textures to the screen will be a little different.
I have tried both methods and I would recommend you to use the CocoonJS if your game is a quite small project and you want to release a mobile version of the game to complement the web version. If you really want a well made mobile version I recommend taking the time to rewrite the code in java. LibGDX can also be exported to IOS using Multi OS engine or a fork from RoboVm.
Backend servers are used to store data that otherwise would be lost after a game session since the game server removes the player from memory as soon as the player dies or leaves the game.
I would suggest using MongoDB and Mongoose since it works really great with the NodeJS framework. The web server itself will use Express to handle events and send results to the client.
Log in with Google or login with Facebook are great technologies to use to avoid storing passwords on your server. There are many tutorioals on how to validate a user on the backend using a token. You will then have to store the user in your own database using their google ID.
When all the basics is set up you can add any features that you want to you backend. A common feature would be to store the users highscore, this can be done by having the client send a message to the backend server after each game with it most recent score. The server will then find the client in the database and compare the new score to the old highscore, if the new score is higher it will be stored to the database. The database can also store highscore of the data or total highscore and send it to the players to display it in the top right corner, this is used a lot by IO games.
If your backend server also manages callbacks from transactions you will probably need to have a SSL certificate on the server. There are many different providers of SSL certificates but I would recommend using LetsEncrypt since it has many tutorials on the internet. The certificate is valid for 90 days and it wil then have to be renewed, this can be made easier by using crontab which can update the SSL certificate automaticall when there are less than 7 days left.
Apart from using something like GULP to check simple bugs such as functions that return the wrong value, I would recommend to create a simple bot when testing your IO Game. This enables you to fully test how the game will play with many players connected. Multiplayer games are notoriously hard to test since there are so many thing going on at the same time in a very dynamic environment, there is a high chance that you have missed to think of some scenario that happens when many players are connected.
The bot can be as simple as sending a message every second to change angle. Running many of these bots simultaneously will simulate what the game will be like when there are many players conneced. I would suggest making a simple web browser application that can start any number of bots. You may experience being limited by you router when reaching upwards of 100 connected bots from the same network.
I would also suggest using a npm library like microtime or nanotime to minitor the time each part of the function takes. Especially checking collision to other players, keep track of how it scales when increasing the amount of players. If the time to determine whether the players are colliding is increasing in a quadratic manner, then you may have optimize your code. You want to achieve a increase that is as linear as possible.
It is also a good idea to have a backup URL that you use to test new versions of the game before your changes or bugfixes go live on th main server. Sometimes it is also necessary to have a seperate backend server for testing in case you send some weird data from the new client that crashes the server. It doesn't have to be a real domain, it can just be your IP or the IP of a server that you rent.
There are thousands of ways to reduce lag in a multiplayer game, far too many for me to cover every single on.: I will cover the most commonly used techniques that are used and that have the most significant effect on reducing lag.
To remove the stutter everytime the servr sends an update to the client about the player position, the client will update the position of the player in its own inbetween it receives info from the server.
The best way to do this in a 2D environment would be to have the server send a position and also an angle that the player is moving in. The client which is running at 30 or 60 frames per second can then use this angle and take the cos and sin values to change the position in the mean time in a way that is mirroring what is happening on the server.
Another approach that would complement this method would be to have a server position and a "visual" positiopn for each player that the client keeps track of. The server position is the real position of the player, this is what changes when a mesages is received from the server. The "visual" position is what is displayed to the player, this position is then dragged towards the server position. The purpose of this is to reduce the not so smoothj motion that occurs everythime a new position is received from the server while still representing the client position as it is on the server.
To reduce the amount of data that is sent from the server, it would be wise to only send a position update once every three seconds in order to save some bandwidth. Only send updates about when the angle is changing. Send the angle change immediately and let the clients that are connected mirror what is happening on the server by using the techniques that I described previously.
This will result in very smooth movement of the players. You may add similar systems to reduce lag for the angle as well depending on the mechanics that you whant your game to have. The player could have a visual angle and a "real" angle. The real angle is what is fed to the cos and sin functions for managing movement while the visual angle is used when drawing the player to the screen. Drag the visual angle towards the real angle to avoid a laggy motion when the new angle is received. I would suggest using some sort of linear scaling for the speed that the visual angle is approaching the real angle, the speed can be the difference between the angles. This will make sure that the angle goes faster to the real angle if the difference is greater, reducing the time which the player is pointing in the wrong direction while making the game more smooth.
Most IO Game require some sort of collision detection, this can be from players that collide with each other, projectiles that are fired or any other elements that you want in your game. Collisions is often critical to the gameplay of your game and therefor it is incredible important to get it right.
You will have to iterate through ecery other player in the game and check collsion unless you use a quadtree or some other clever way to filter what players you are going to check collsion to.
Collision is in most cases calculated by comparing two points and seeing if the distance between them is less than their radius combined. Compare the sides squared and avoid to take the square root of the squared sides since square root is a very heavy calculation for the computer, square the raduis instead in order to get the same result.
It is common to use a datastrucure called QuadTree to increase server performance and avaid maiing unecessary comparisons between players that are far from each other on the map and there is no chance that they would be colliding. QuadTrees divides the map into squares and only checkes collsion to the players and gems that are in the same square. Suppose that the map is divided into 100 squares and the players are evenly distributed, this will enable the server to make 100 times less comparisons compared to if it had to compare it to everone on the map. This in turn enables the server to have 100 more players playing simultaneously with the same amount of lag as if the less efficient version of collision detection was used.
When a collsion occurs different things will occur depending on how you want you game to be. If the players are supposed to bounce away from each other you will then have to calculate the direction which they will bounce away. If there is collsion with gems you might want to increase the score of the player that collided with the coin.
The client contains everything that you users are able to see when they play your game. The client has three main tasks, to take input from the player, receive data from the server and display the game to the player.
Taking input
Taking input varies a little depending on what game engine you are using but the basic concept remains the same.
When deciding what angle the player will go, the client checks the position of the mouse on the screen and then calculates the angle between the centre of the screen and the mouse and then it sends that angle to the server.
Receiving data from the server
Receiving data from the server is what makes the client see the result of the input that it has sent to the server, the client will also receive information about every other client that is connected. this will then be assembled by the client program to present the player with a full iamge of what is going on at the server.
Examples of data that is received can be, new position for a certain player, create a bullet at this position, remove this gem or player joined.
Displaying data to the player
This part can be done very simple or extremely advanced depending on how fancy you whant the game to look. Basically what you need to do is draw the players to the screen on their positions that you have received from the server.
Consider adding systems for managing particle effects on the client in order to give the game more life. This will be completely disconnected from the server and will appear slightly different on eahc client if the particles have some random movement. A basic rule of thumb would be to not involve the server in anything that does not have a significant effect on the game play and isolate those parts of teh program to the client side. Remember that the client does not have to be as carefully optimized as the server since most computers can handle a lot more than a 2D game. It is still good to have efficient code on the client, just remember that it can be worth adding more calculations to make the game look better instead of saving computer power.
The basics of making the client correspond to the server messages is to receive the data, send it to the player manager on the client side and apply the position or whatever data was received to the player object. This will then cause the player texture position to change accordingly.
I will go further into detail on how to make the players move smoothly while not using a lot of bandwidth in future blog posts.
An IO game (like every other multiplayer game) consists of two main parts, a client and a server, More advanced games can have several servers involved for storing highscores and user statistics etc. But I am going to keep it simple here and only focus on the main server that handles the actual game.
The servers main purpose is to handle movement and collision while the client is displaying it to the users(and adding fancy effects that the server doesn't care about).
Almost every IO game uses the MEAN stack on the server side, m,ore precisely NodeJS and Express. As always with Node JS there are thousands of modules available through the node package manager (NPM). You can use npm for pretty much anything you can think of that would require a third party program, the main thing that we will be using it for is to get a package called Socker.io which will handle our websocket connection with out players (clients).
There are two main parts of the server, one that manages the connection with all the connected clients and listens to events from the clients and the other part updates the game physics. The part that updates the game is strucured similar to the way that a regular game is structured, meaning that it uses a whileloop that is running forever to update the players and other entities that are in the game. This while loop is responsible for moving the players in the correct direction, checking collision to other players as well as checking collision to gems that are scattered on the map.
To make a complete game some more funtionality is needed, for example a loop that runs less often that balances the amount of gems that are on the map.
The time it takes between runs of the physics loop is known as the server tick, it is reasonable to have a tick between 10 and 30 times per second depending on your game. A game with a lot of fast movenent and quick gameplay mey need a higher tick while slower phased games can deal with a relatively low tick without any noticable difference.
The main cause of lag on the server is when the physics loop takes to long causing the players to be stuck in their previous position and moving with a noticable delay. This will happen on everyserevr no matter how well it is made, the question is only how many players it can handle. The point where the game has noticable lag may come at 10 players or 1000 players depending on how well the code is written and how powerful the servers are. Slither.io manages over 500 players on each server which is impressive consider that every snake has to check collsion to every other snake as well as all the gems on the map.
I will go into more detail on how to check collsion between players and other players as well as players and objects and also going into detail on how to make the server more efficient.
A game engine is note really necessary when creating an IO game, you make a decent game by only using the html canvas and drawing textures or just lines/shapes to it.
A game engine is necessary if you want to use more advanced graphical effectis such as blendmodes or tweens. Blendmodes is what enables the gems in Slither.io to glow with a nice shine.
I use Phaser game engine for this purpose because it is the most widely used game engine for the web and it has a great supportive community, not to mention the outstanding documentation with hundreds of code examples. The main purpose of the game engine is to display the textures to the screen and take input from the mouse/keyboard. There are a number of other features built into phaser that you may not use like for exxample their own collsion/physics system since most of the physics is handled on the server and the collision that you use on the client will likely be somthing that you write yourself tomae it match what your server looks like.
A benefit of making a game withouty a game engine and only draw shapes to the canvas would be that the loading time of the site is reduced since since no textures have to be fetched when loading the page. There would also never be any issues with scaling and blurry textures. Agario is a great example of when shape drawing us used to benefit the game, the edge of the cell never appears blurry even if the character has grown to twice the size of the screen.
I recommend that you consider how you want your game to look and if you have any previous experience using any of the methods. Both Canvas and Phaser have a lot of documentation on the internet so it is unlikely that you will get stuck on something related to the game engine. There is no right or wrong when it comes to if you shall use an game enginge or not, maybe you are better of with something inbetween like for example Pixi.JS which is a library that provides rendering textures to the screen like Phaser and not the other features that are included in a gameengine. In fact Phaser uses Pixi to hande it's rendering of textures and then it wrapps it with it's own functions.
To conclude:
Choose the alternative that you think suits your game best now that you know what each alternatives pros and cons are.
There are a lot of different thing to consider when creating an IO game from scratch. I will start by describing the basic structure of the program that every IO game share.
I decided to do a quick blog series on how to make an IO game, describing the different techniques that are involved. This blog series will not descibe a specific game but rather the general strucure that is needed by every IO game since different games share most of the code with each other. There are minor changes with the texture and the game mechanics that needed to create a different IO game.
Apart from reading this blog series I would highly recommend search the web (especially Github) for other IO games to get a better understanding of how these games are made. I myself started by looking at an Agario clone that I found on Github and changed it into my own game using the basic structure from their game. I can't stress enough how helpful it was to be able to use someone elses game as a base since it gives you a general sence of how the game is suppose to be structured and what third party programs to use. By the end of the project almost every line of code in the program was changed and many more classes was added.
Before we get into the actual game, here are some useful skills when making IO games:
HTML
CSS
Javascript
Drawing (Photoshop/GIMP)
Search algorithms (when optimizing)
Asyncronous programs
Game programming
Asyncronous programming is a very useful skill since it it used so often in modern API:s. For example when receiving messages from the client you want to change a value on the server while ther server is doing something else like for example updating the player positions. This can be quite difficult since a program can crash if for example a value is removed from an array while another part of the program is iterating thorugh it, so you always have to be careful when dealing with parallel programming.
The main part of game programming that will be useful when making IO games is to have a good understanding of the endless while-loop that the game takes place in. For those of you who don't know, a game is run on the computer by updating the screen with a new image roughly 60 times per second and each time a new image is sent to the screen the computer has to calculate the new position of everything that is visible on the screen.
This way of structuring a program will also be used on the server side to update the players or projectiles and just ignoring the part when the textures are drawn to the screen.
I will go a lot deeper into the details on the techniques that are used on the server and the client later in this blog series.
