psychicsoftware

Orbs.it — an “agar.io” style game

Agar.io and Orbs.it

A couple of years ago, agar.io was released as a browser game, and caused quite a sensation. It has subsequently spawned an entire genre of games — lightweight, massively multiplayer browser games with simple graphics and gameplay. This type of no-nonsense, easy-access multiplayer game appeals to many people, and naturally suits lone developers (especially when their art skills are not great).

So late last year, and early this year, I developed orbs.it

Orbs is a simple to play game, yet is very skillful. It’s about fast and accurate control of your “guns”. Eight players start the game, and each initially control a single orb which is part of a set of 24 orbs encircling a central “sun”. You shoot from your orbs, and when you hit another orb you take control of it. The winner is whoever is left last in the game. It’s a very satisfying mechanic, especially when you get in the flow and claim orb after orb in rapid succession.

Lots of users

In May I released orbs.it on iogames.space which is the main portal for “agario-style” games. I was pleasantly surprised with the amount of players that clearly seek out this type of game — within a couple of days, my server was starting up 5-10 game sessions per minute, each with typically 4 or 5 humans in (the rest being bots). As of right now, there are nearly 90,000 player accounts in the game’s database.

Server architecture

Orbs proved to be a nice test-bed for the nodejs-based gameserver cluster I had developed. The central masterserver looks after player logins and communicates with gameservers which run the actual game sessions. It monitors the number of games running on each server, and dynamically starts/stops server instances as required, to deal with varying loads. There’s also some interesting requirements around things like gameserver hot-patching, so again this has involved developing useful techniques which I’m sure I will use again. I have done this sort of thing before in Darkwind of course, but the system in Orbs is generally much slicker and didn’t suffer from the horrible nightmares of blocked sockets which afflicted Darkwind on its opening weekend on Steam.

Networking

High-speed networked gaming is always a challenge to develop, and a particular challenge for “agario-style” games is that they are generally limited to using websockets for their communications. Websockets provide really handy bidirectional communication between browser and webserver, so are far better than plain-old Ajax.. however, they are still based on TCP, and that means guaranteed, ordered delivery of packets. This is the main cause of sudden spikes in latency which most Websocket games suffer from. The latency is basically unavoidable – it happens when a packet fails to deliver and has to be re-delivered, and all subsequent packets are cached on the receiver until such time as the missing packet arrives, so that they can be delivered to the receiving application in the correct order. This makes TCP fundamentally unsuitable for fast-moving data, especially when the nature of the data is that late packets are irrelevant. If your application knows where a player’s orb is at time 20 in a game, it really doesn’t care to know where it was at time 19, yet TCP doesn’t allow your application to see the data from time 20 until the data from time 19 is received.

Deterministic positioning of orbs

I wanted orbs.it to be, as far as possible, immune to the latency problems caused by TCP. I didn’t want the field of orbs to jump around and glitch on the screen, like the player-controlled entities in most agario-style game do. The solution was to remove player-control of the orbs altogether – this also fitted the design requirement of simplicity. The orbs move around in orbits, based on elliptical paths with continually changing parameters (and ultimately controlled by Sin and Cos, of course). The real trick is that these paths, although interesting and varied (leading to a continually-shifting playfield) are entirely deterministic. At any specific time after the game has started, the game server and game clients can all calculate and precisely agree on where each orb is. This vastly simplifies things and gets rid of many of the difficulties associated with everything a game client knowing about everyone else being out of date by the time they know it.

If you’re interested to read more about fast-paced multiplayer networking, this is an excellent overview.

You can play orbs straight from your browser here: orbs.it and it’s also available on the Android and iOS app-stores, although has not seen much traction there.

Faking Shadows and Lights in a 2D ‘isometric’ Game

For the past few months, I have been working on Godkin, a pixel-art online co-op combat RPG. This is a collaboration between Psychic Software and Goblin Portal (our second collaboration, in fact, following up on last year’s release Goblins & Grottos).

Godkin takes a “faked 3D” view (this style is often referred to as isometric, although actually we’re not adhering correctly to the strict viewpoint that would make the game isometric.) Getting the lighting and shadows looking good in this style is somewhat challenging, since there’s no real 3D geometry for the game engine to work with. I’m having a lot of fun programming this game in Unity (it’s my first Unity game) and figured a blog post about shadows and lights was in order!

At the core of my shadowing system are the FakeShadowCaster and LightAnimator components.

LightAnimator

A LightAnimator component is attached to any objects that have lights – camp fires, torches, explosions, etc. These search for nearby objects which have FakeShadowCaster components, and register with them. They also notify the FakeShadowCaster objects whenever changes happen (e.g. the light moving, flickering, brightening, dimming, turning off).

FakeShadowCaster

A FakeShadowCaster component is attached to any objects that we need to cast shadows – basically, anything that should appear to have some 3D ‘height’ – characters, monsters, rocks, trees. This component maintains a list of nearby light sources, and creates a fake shadow sprite to associate with each of them. Whenever a light notifies a change, or if the FakeShadowCaster itself moves, its list of shadows are re-calculated. Each shadow is rotated to face away from the associated light source, and its opacity is set based on distance from the light (plus other variables). I also wrote a ‘shadow skew’ shader which spreads apart the vertices of the shadow sprite which are further away from Tree Shadow the light source – with a stronger effect the closer it is to the light; this adds quite well to the overall feeling of 3D. Another nice touch is that we can use whatever sprites we like for the shadows – so trees, for example, can have their shape baked into their file.

‘3D’ Object Shader

The standard Unity sprite shaders look great for terrain, and sprites which don’t have much ‘height’ – however, since the amount that each of their pixels is lit is simply based on the distance they are from light sources, this starts to look strange for objects that are supposed to be tall. The problem is that the top pixels and bottom pixels of the object will be at quite a different distance from the light – but to look like a proper object with height, the vertical position of all pixels should be considered the same, for lighting purposes. So here we have a shader that attentuates light to all pixels based on the position of the vertically lowest ones. This shader also reduces the brightness of any object which is in front of lights (since in this case the majority of the light should be cast on the non-visible ‘back’ of the objects).

If you’d like to follow the progress of Godkin’s development, here’s our blog. Or why not join us for a chat in Discord?

Goblins & Grottos – launch day lessons

We launched Goblins & Grottos on Steam last Thursday. The next couple of days were pretty hectic, as expected, and involved some late nights and early mornings. But overall we’re pleased with how things went and how the game has been received. I wanted to capture here some of the highlights and lessons learned, as these may be useful to other developers.

Reddit AMA

We ran a launch-day AMA (‘Ask Me Anything’) thread on reddit which went really well, and I’d recommend this approach to anyone releasing a game. I was very impressed by the very varied and thoughtful questions posed by the /r/pcgaming subreddit community, and we received a nice amount of traffic to our Steam page from this. Our thread sat high up on the first page of the subreddit for the full 24 hour period that it was live, and undoubtedly contributed to the ‘legitimacy’ of our game. In the longer term, it serves as an excellent repository of information nuggets about us and the game – I noticed that the RPS article, for example, used it as a source of info.

Local Game Dev Community = Awesome

We received an awesome amount of support from the Galway Game Development community, and also from some of the wider Irish community. My good friends from Galway rallied round, posting and tweeting about the game over the launch period. If you don’t have a local community of mutually supportive game developers, then you’re missing out. In Galway, our community has built up from pretty much nothing to a situation where 10+ studios are actively developing games, running events, meeting socially, and generally helping each other out. If you don’t have a community like this, then make one; that’s what we did.

Youtubers

We received enquiries about the game from two very large youtubers. They haven’t yet confirmed whether they will be covering us, but communication lines are open, which is half the battle.

Rock Paper Shotgun

We got a nice mention in Rock Paper Shotgun. This lead to a substantial spike in traffic to our page, and was followed 20 minutes later by one of the two youtuber contacts mentioned above. I’m not sure whether RPS noticed us directly on Steam, or whether they saw our press release or tweets that we had tagged them in; possibly all of these. As mentioned above, they made use of information from the Reddit thread, and may indeed have been influenced by it to cover us at all.

Mistakes

Someone with my amount of experience at game dev should have known better, but despite ourselves we made some small (insignificant, we thought) tweaks to the game in the last couple of days before launch. One of these (removing the ‘black movie bars’ from the top/bottom of the screen during cutscenes on smaller screens) lead to a game breaking bug which I ended up troubleshooting in the middle of the night.

Another mistake was not getting really detailed with the testing of game controls. We had assumed that the early access players (or ourselves) would notice/report unintuitive things, but actually they didn’t. I suppose the lesson is that early access players are fans who expect glitches and don’t necessarily report them, so you can’t expect to treat early access as a rigorous playtesting process, even if hundreds of players are involved. When you have left early access, your userbase switches to being the general public, and if anything doesn’t work exactly how they expect it, their assumption is that the game is ‘broken’ – and they may well give a scathing/damaging review on that basis. Again, this lead to some middle-of-the-night coding

Here’s our launch trailer, which was unveiled at the time of launch:

Goblins & Grottos Nears Full Release

It has been a while since my last update on Goblins & Grottos. In the last 2 months we have taken on a new team member, Logan – who will be taking over the bulk of our marketing and promotion activities. It’s critical that each role in the development and release of the game is headed up by a ‘champion’ who has commitment and ownership for it. Marketing was an area that we needed someone extra in, to fill that role. Logan has fitted into the team really well and I’m sure he’ll add great value to our publicity!

There have been lots of cool things added since my last post here. The four ‘regions’ are now complete (dungeon, forest, village, mountain/castle) along with appropriate decorations, interactive items, environmental effects and traps. The main bulk of the game’s development is now complete. We have held back some new features to announce on full release, including a fully configurable boss battle editor for final showdowns with the Paladin, as well as a neat minecart system for Indiana-Jones type shenanigans. Apart from this, I have been doing lots of tweaking and clearing up of bugs, and polishing of the user interface and map-making tools… all the glamorous stuff us programmers get up to, y’know. The game’s Official campaign is nearly complete.. kudos to the fantastic creativity of Jonas and Bjorn, who take the map elements I provide and twist and combine them in all sorts of fun ways.

Ian, Bjorn and Jonas have also been making a really slick cinematic trailer which will be unveiled on full release day.. I’m really excited about that!