The brief
Make a networked android game
As briefs go, it was pretty skimpy. I knew I wanted to avoid on-screen analogue sticks at all costs (is there anything more clunky?) and I had been enamoured with the looting mechanics in survival/battle royale genres for a while, so I wanted to see how far, how bare-bones I could go with that while still making a game.
I would use Unity3D, C# and GitKraken for source control.
The game
After a lengthy brainstorm, and a whole side of A2, I landed on One Must Remain, an isometric looter set on a collapsing spaceship where all the players are attempting to find components and tools to repair their assigned escape pods. Players would have a choice of three characters (the fast one, the big one and the armoured one) each with their own drawbacks and strengths. The last player left behind on the ship would meet their igneous end, while those that escaped first would be able to somewhat influence the destruction on the ship.
They would need a certain amount of unique components and tools but could only carry so many, meaning they would have to hide them around the ship in the hopes none of the others would find them.
In addition, the layout of the spaceship was always different, with just the Escape Pod room and the adjacent engine room always in the same location. The loot would also be spawned randomly in containers and loot locations unique to each room type.
Procedural Layout
To give maximum flexibility I wanted to make use of CSV files to make adding additional content super simple. In its current state the game draws from just one layout but the system is easily extensible and could draw from many different layouts. A CSV file such as the one below is used to tell the type of room to spawn in each room slot. This is possible because I’ve arranged the whole level in a neat grid.
r,0,0,0,cr cr,er,pr,cr,r r,cr,cr,r,0 r,cr,r,cr,r cr,r,cr,r,0
“r” tells the layout manager that a random room type should be spawned there; “0” means nothing is to be spawned there; “er” and “pr” define the locations of the engine room and pod room respectively; and “cr” means a crossroad room should be spawned.
Rooms prefabs (the saved version of the rooms to be spawned) can also have a maximum amount and can be flagged as “must have”. Any “must haves” are spawned in random slots after the crossroads are spawned and before the rest are filled procedurally.
Before any rooms are spawned the level only contains the pod room, the engine room and corridors Then all the slots are field with room prefabs:
Random Loot
Equally for the loot I wanted to use CSVs for the pickups in the game. Also, because all my friends are much funnier than me, I used my buddies in my D&D game to add to the spreadsheets for Tools and Components that would become the CSVs.
The pickups just needed a name and a rarity, with 10 being most common and 1 being the rarest items. The pickup spawner would then spawn twice as many of each type of pickup than would be required for all player characters to make it off the ship (this is of course a value that could be tweaked, but I imagine any lower and there would be a really boring shortage of loot).
The spawner is passed a list of all the available loot spots and containers after the rooms are spawned, and divvies out all the pickups to these at random, assigning each a unique serial number by which they can be distinguished. The whole process is pretty interesting so if you’d like to try and follow along have a look here.
In Hindsight
Though the game is playable it is by no means fun (luckily that’s not a criterion for passing this module) and if I were to try and make this a real game there are a few things I’d have to fundamentally change:
- Map size & encumbrance: with the encumbrance mechanic (if carrying more than a threshold amount of pickups, the player would walk more slowly). As a result the level always felt much too big and the player character too slow – BORING. A fix would be to make the overall grid smaller and use no crossroads at all – they felt like filler anyway.
- Player interaction: though I avoided using combat as a mechanic there needs to be more interaction between the players, perhaps traps could be laid or rooms made impassable by removing the oxygen. Something!
- Repetitive: the grid layout was chosen as this was my first foray into procedural anything but if I were to make this fo real, I’d want the layout to feel much less repetitive, with rooms of different sizes etc. This would need a major overhaul of the current room spawning system in order to include an algorithm that ensures each spawned room is accessible from the starting location
- Levelution ™©®: over time the spaceship should be falling apart with fires spreading across and between rooms, the oxygen being depleted and whole rooms becoming impassable or being destroyed
Despite all this I’m pretty pleased with it and look forward to playing with procedural stuff some more in the near future
johannes 