Difficult design direction decisions (Part 3)

Finally, I’m gonna go through the areas that I’m hoping will build on the basic sandbox and actually make it into a game:-

Game modes

I have a couple of ideas for game modes that could build on the core construction experience:-

  • Challenge mode.  This would be something a bit like Junkyard Wars / Scrapheap Challenge, where each player (or team of players) is given a set allocation of parts and they have to build something to achieve an objective (e.g. build a car then race to a checkpoint, or build a tank then try and destroy the opposing teams tank, or make a catapult and see who can fling stuff the furthest, and so on).  I think this could be a lot of fun, but would work best as a multi-player experience.  I don’t want to go down the route of implementing a complex AI that replicates a human player, so in single-player I think only objectives with simple outcomes (that could be measured in terms of times, distances etc.) would work.  This would be OK but not as fun.
  • Survival & exploration mode.  This would be along the lines of Minecraft and other similar games, where you would gather resources, craft parts, and then build with them.  The beauty of this is that it is still a really compelling experience in single-player, and is just made even better in multi-player.  It gives the player a whole level of strategy (which resources to gather, and how to allocate them to craft parts) that just isn’t there if the game simply randomly gives out parts to the player as they progress.  It also gives the player a reason to keep exploring the environment and to keep building new constructions.

At the moment I’m not sure if I’ll go with one or both of these options, or maybe something else.  As I mentioned before, this is the big design decision that I’ve be wrestling with of late.

Crafting mechanic

If I do go for the survival / explore game mode, a crafting mechanic would need to be added.  I’ve only just started digging into this, but this is what I’m thinking so far:-

  • Ability to harvest raw materials from the environment (trees, vegetation, rocks, etc.)
  • Then you can craft raw materials into parts that you have blueprints for.
  • Inventory size would be limited, but you can perhaps store raw materials and parts in storage boxes (which can be attached to constructions – buildings, vehicles etc.)
  • You can find data-sticks and download new blueprints to allow creation of new part types.
  • Ability to add your construction designs to your inventory, and then spawn these complete constructions later (if you have the required parts).

World / environment

Also required for the survival & exploration mode, are a bunch of improvements to the terrain and environment:-

  • Extend procedural terrain generation to create various biomes, with rocks, trees and vegetation, partly this is to make the environment more interesting, but it’s also necessary so as to provide different resource types in different areas for harvesting.
  • Dynamically re-spawn resources (e.g. rocks, trees and vegetation) as they get harvested for crafting.
  • Dynamically spawn creatures / animals, which can be killed for resources, but can also attack the player and can damage construction parts.  This would bring about interesting scenarios where you have to defend yourself and your resources by building a base with armaments or build a vehicle to simply outrun your enemies.
  • Dynamic time of day – simple to do, and as well adding life to the environment, it forces the player to use lights if they want to keep building and exploring at night, and creature behaviours could change based on time of day.
  • Expand terrain size, currently it’s 4km x 4km, I’d like to take it up to 16km x 16km.  This requires breaking up the terrain into tiles and procedurally generating only the tiles that are local to the player in a streaming fashion, a little tricky but not too hard to do.  The real problem is the insufficient floating point precision at world co-ordinates beyond about 2 or 3km from the origin, I think I’d need to shift the whole world so that the terrain tile the player is currently occupying is always centered at the origin.  This gets gnarly with multi-player though because the network server has to deal with players in potentially totally different locations on the map.

Well, that’s it for now.  I need to continue refining the design / plan further, but I’m hoping this pretty much covers everything I need to consider for the game.  Any suggestions or comments are always welcome!

Difficult design direction decisions (Part 2)

OK, I’ll now try and expand on each of the game areas I outlined in the previous post, first let’s look at the core sandbox stuff:-

Construction mechanic

This is the absolute meat of the game experience, and if it isn’t right, the rest doesn’t really matter.  I’m happy with the way you build by putting parts together in the first person view, I do think it feels natural and intuitive.  So I’m definitely going to stay with this approach, but there are many problems with it currently, such as (among others):-

  • Positioning parts is awkward, it’s hard to tell where a part will attach, and hard to make small adjustments to positioning.
  • Orientating parts is difficult – the rotation controls are tricky, and the orientation auto-snapping can go crazy and flip awkwardly, particularly if there are multiple contacted parts.
  • Once a part is attached, you can’t adjust it’s position without detaching it and reattaching.
  • When detaching a part, it breaks all connections to that part, i.e. you can’t choose to break only one connection.
  • When attaching parts that connect with joints rather than rigidly (e.g. blocks to axles), and if there are multiple attachment points, then you have to put the parts together in a certain order otherwise not all joints will be created.
  • It’s possible to attach parts which results in them inter-penetrating.

My plan is to scrap the current implementation which uses contact points calculated when the player touches one part to another to determine attachment positioning and orientation.  Instead, I think I’ll use the contacts only initially to determine which two parts to consider for attachment and then switch over to a different control scheme to actually position the part.  The details of this I still need to work out.

Player controls and behaviour

This area considers all aspects of the player interaction other than the core construction mechanic.  As such it is secondary to the construction mechanic, but still very important.  Specifically, we’re talking about the following:-

  • Controls (walking, running, crouching), these have to feel “right”, things like weighting, speed and acceleration are important here.
  • First person camera (response to impact, jumping, camera bob / sway, mouse smoothing and acceleration), the current FP camera is very basic and “dry”, it doesn’t have the organic feel you’d expect in a decent FPS.
  • Interaction with physics – players should move things when they bump into them, and player weight when standing on objects should have an effect.
  • Construction tool.  Currently there is nothing to give a sense of agency for the player, of course in an FPS you’d typically have an arm holding a gun in front of the camera, I need some equivalent of this.  It would be difficult to make the players arms convincingly appear to directly hold the parts they pick up, so in place of the usual FPS gun I think I need some kind of beam effect manipulator tool (much like the physics gun in Garry’s Mod).
  • Health / death state, in sandbox mode this isn’t strictly necessary but will be needed later to support other game modes.

Networked multi-player

Although you could certainly conceive of a single-player only construction game, I consider networked multi-player to be key to the basic sandbox experience because this type of game is so ideally suited to player collaboration and competition.  An open world game without linear goals or story led game-play really benefits from multi-player I think, where the players can essentially create their own stories within the game.  The main things left to do are client side prediction for player position, and improvements to reduce network bandwidth (as I discussed in a previous post).  I also need to make a dedicated server build as I’m thinking rented servers are the way to go to allow for larger numbers of players.  There’s also other minor stuff to do including having better player animations, and an improved chat interface.

Construction parts

This area covers the implementation of all the different types of parts you can build with, along with their behaviours.  There are some improvements and bug fixes that need to be made to the existing parts, but mainly I just need to add more part types to expand the scope of what you can build.  The good thing is that I don’t need to add all of these right away, I can keep adding them throughout the lifetime of the game.  My hope is to eventually open up the game for modding so that players can add their own parts too.

If I can get all this done, I should end up with a really solid multi-player sandbox experience, but it still won’t truly be a game.  This is were the other areas come in, next up in part 3…

Difficult design direction decisions (Part 1)

Recently I have been thinking a lot about where to take this game.  There are many things that need attention, primarily the construction mechanic, but also the player controls, networking etc.  However, the main problem I’ve been wrestling with for a while now is how to take this sandbox “toy” and turn it into an actual game with purpose and progression that compels you to keep playing.  Right now you can construct whatever you want but there is no direction, or reason to keep building stuff.  One of the key motivations I had from the very start was to make an experience that was as open as possible, allowing players to be totally creative, and not constraining them to only be able to build certain things.  The problem with this openness is that it’s difficult to directly measure the players progress, or to even define what it means to progress through the game.

In order to get some traction on all of this, I have attempted to break the game up into the several broad areas, and list out what would be required for each of them.

The first few areas are crucial to the core sandbox experience, it doesn’t matter what else gets layered on top, these fundamentals have to be right regardless:-

  • Construction mechanic.
  • Player controls and behaviour.
  • Networked multi-player.
  • Construction parts (i.e. the bits you actually build with).

Then I can look at layering on stuff that would turn the sandbox experience into a fully fledged game:-

  • Game modes.
  • Crafting mechanic.
  • World / environment.

In the next post(s) I’ll expand on each of these areas in turn, coming very soon!