Introducing Goblins & Grottos

Goblins & Grottos is a new collaboration between Psychic Software (from Ireland) and Goblin Portal (from Sweden). We’re calling Goblins & Grottos an “inverted RPG”. You play as the goblin, trying to escape a series of dungeon levels while a team of callous adventurers lays waste to everything around them. The idea is to turn normal RPGs on their heads, and see everything from the eyes of the poor helpless cannonfodder for once.

Goblin Portal have created a clean pixel style for the game, and I’m the programmer (of course). It’s working out well under control of a 2D physics engine: we have spent a lot of time getting the core animations and interactions with the environment as good as possible; the goblin runs, jumps and climbs walls, swings from chains as he attempts to escape the numbskull adventurers .. who in turn have no respect for the goblin, seeing him only as a quick kill for 10xp which brings them along the road to their next level and unlocking their next skill.

I’m using the same core set of technologies as I have for several recent projects: it’s written using HTML5/Javascript packaged into a desktop executable using nodewebkit and with pixijs for pretty efficient WebGL rendering. Nodewebkit gives access to things such as local file reading/writing, which isn’t normally possible from a browser. I’m using the matterjs javascript physics engine to move stuff around, but other than that there’s no actual game engine to be seen. I have found this suits me well for the 2D games I have been making lately – I can construct my own architecture rather than having to learn someone else’s; and the lightweight nature of Javascript suits me.

The near-term plan for Goblins & Grottos is to make a playable one-level demo, and to engage with players while expanding this into a complete multi-level adventure, starting with the goblin’s parents being hacked down by a merciless bunch of greedy adventurers, and ending with an unexpected and heart-wrenching moral dilemma. Or something.

We’re also planning on releasing the map editor as a core part of the game, and on making an on-line repository for player-made levels. There’s plenty of creative freedom in the map editor I have been creating, including customising the skills and chat text of the adventurers.

You can sign up as a tester over at goblinsandgrottos.com, or follow us on Facebook. A playable demo should be available within the next few weeks.

“Hittin’ Worlds” Game Jam Winner

I took part in a game jam on Saturday, and we won! ;-) My main collaborator was artist Niall O’Reilly from local game art company DoomCube.

The game runs using HTML5/Canvas, with a node.js websockets server. The ‘render client’ ran on my laptop and players ran the ‘controller client’ on their phones.. this seems like a really nice way to do casual LAN-style multiplayer games, and it’s a configuration I have been thinking about for a few weeks. I just need to figure out a killer party game idea to use it with!

In “Hittin’ Worlds” Each player plays as a planet, in orbit around a sun. Asteroids are flying about, and players have to use their forcefield to deflect them. By using a virtual joystick-style controller on their phone, they orient the forcefield in specific directions.. incoming asteroids get deflected in that direction. The idea is that players fling the rocks at each other while defending themselves.

We also had a really nice piece of custom music written by a guy called Ian, from Athlone/Reading.

Raycast Car

Here’s some footage of a car driving around in the Shiva game engine, using the ‘raycast wheels’ approach. I have found that this gives much nicer results than the demo car that comes with Shiva, which treats wheels as constrained spheres. The problem with modelling wheels as spheres rotating on one axis is that this assumes rigid bodies for the wheels; actually, wheels are not rigid.

The basic idea with raycast cars is that you cast a ray from each wheel hub, and calculate the distance at which a surface is met (if at all). This defines the suspension’s extension, and then you simulate spring behaviour by applying increasingly strong forces as the suspension gets more compressed. There’s also some subtleties such as anti-roll and varying spring strength depending on whether its compressing or extending; but these are mostly tweaks applied to the core idea.

I also found that at high speed the default Shiva ‘spherical wheels’ car would suffer from occasional glitches and speed wobbles, rendering it fairly useless for most games. Sometimes it seemed to stagger sideways at high speed, presumably due to errors on the axis constraints allowing the spheres to role sideways. I assume these problems are caused by over-relying on the accuracy of the underlying physical simulation in order to obtain the required behaviour.

In the video clips shown here, the behaviour of the car in all ways other than spring response has been results-driven, i.e. the desired behaviour (skidding, drifting, tendency to roll, etc.) has been considered and this is used as a starting point for programming the calculations – rather than starting from an accurate physical simulation and expecting realistic/fun results as an emergent behaviour.

This represents very good progress towards what I’d like to have for a major new Darkwind project (Darkwind 2?) that I have started thinking about. Really the ineffective default Shiva car is what had stopped me considering this before now.

Last year I also wrote Musclecar Online. In this the car was entirely results-based, having no accurate underlying physical simulation from which the behaviour emerged. Musclecar Online is actually a 2D driving simulation with 3D models (hence, no hills or bridges) – and it was therefore entirely possible to define the behaviour I wanted first and then to write code to directly produce that behaviour.

Making an efficient gameserver with node.js and mysql (Musclecar Online)

Last year, when one of my games went a bit viral, I discovered first-hand about the alarming inefficiency of Apache (webserver), especially when running PHP which forces you to accept a process-per-request approach. It became pretty clear that something much more lightweight would be required if I wanted to build gameservers with large player-bases in mind.

After some research I have settled on node.js as a good solution. It’s very well regarded, largely due to its non-blocking, asynchronous model. This essentially means that anytime a resource is required (such as a database recordset) the request goes into a queue, to be called back when the resource is retrieved. In Apache, the model is blocking – the process sits and waits for the resource, thereby stopping any other activity.. this is why Apache needs all those independent processes, so that it can serve multiple clients simultaneously.

speedracer The game I have been working on is ‘Musclecar Online’ – a top-down racer in which players build their own tracks, vote on them, and then everyone in the world races on the same track-of-the-day. Rather than being real-time, you race against the ‘ghost lap’ recordings of other players; kinda like Speed Racer ;-)

Cache stuff in RAM

Linux has a server’s approach to the file system, of course, which means it uses all available RAM for caching disk files and such, but I figured it would be even better to make liberal use of Javascript arrays (which are really hash tables.. excellent for key-based lookups). So the server packs up canned responses into strings, as much as possible, ready for delivering over the interweb with no fuss or processing. This includes:

    a 5-day pack of track layouts, allowing the players to see what’s coming up over the next few days;
    per-cartype, per-second frequency bins, succinctly providing the data needed by the client to display a histogram of worldwide laptimes and point out where the player stands versus these;
    a temporary array of ghost lap recordings, hashed by user ID for easy over-writing when they improve. This is only used up until 40 players have recorded laps for that car type on that day’s track, and allows random ‘unclassified’ packs of ghost laps to be delivered to players without the need to bother MySql about it;
    more long-term packs of ghost lap recordings, separated into 6 divisions (F thru A) – the idea is that the player starts off racing against poor ghosts, labelled as division F, and if they beat these they are allowed to progress to division E, and so on. These longer-term packs are re-generated periodically, but not for the first time until 40 recordings are available for the car type.

Don’t fall into the ORDER BY RAND() trap

I have done some pretty naive stuff in MySql in the past, but running Darkwind for the past 7 years has helped me understand efficient database design and querying. With the characters, vehicles and weapons tables running into the millions, I was forced to. One of the newbie gotchas in MySql is to avoid doing a massive SELECT statement with ORDER BY RAND() LIMIT 1 in order to get a random record. If you do this, you’re basically asking the database server to load an entire table into memory, apply a random number to each record, sort the whole damn thing, and return one row. There’s a few obvious solutions, depending on how well distributed the data in your index fields is. One simple way is just to find your data range (e.g. laptimes min and max), generate a random number in this range, and then SELECT the first row greater than or equal to this laptime, LIMIT 1. Assuming laptimes is an index field, and also assuming there are enough records to make a reasonably even distribution across the data range, this works nicely.

Interesting asynchronous design solutions

Now, I love callbacks as much as the next man, but it can be an old-fashioned PITA sometimes trying to work with asynchronous coding. In a nutshell, anytime you want a resource that may be delayed (database query, file read etc.) you can’t use a traditional flow of control, can’t use loops for multiple accesses, etc. One of the things I have to do in the ‘Musclecar Online’ server is build packs of typical ghost lap recordings, in order to pack them into strings ready for dispatch to the clients. This means querying for each row with a separate SELECT statement, and therefore means 11 car types x 6 divisions x 5 different packs x 4 ghosts per pack = 1320 queries. Embedding each query inside the callback of the previous one certainly isn’t an option, but with a little thought I settled on recursion; a perfect way to unravel the asynchronous tangle. This works nice and efficiently, while still operating in serial (and therefore not choking up any server resources) and allowing nice tidy code. It’s kind of strange I didn’t see recursion mentioned as a solution anywhere on the web while researching node.js. Well, maybe I didn’t look for too long.