Friday, March 16, 2018

Gameplay Concepts

Over the last 6 months I've been working almost exclusively on new adding gameplay elements to enrich the overall game environment.  Some are general concepts, applicable to the main universal sandbox.   Others are more specific and fill out the lore of the gameworld.   Others such as missions, factions etc. are still to come.

Here are the last 6 months worth of gameplay concepts, in alphabetical order.

Air Resistance

When ships enter/leave atmospheres they encounter air resistance.   This is imparted as a drag on the physics of the ships, with the primary effects being reduction of top speed, and dampening of flight controls.

Ships may or may not come with wings, be careful flying into a planetary atmosphere without wings!

The intention is to impart air resistance to the damage model, causing ships entering an atmosphere too fast to burn up and be destroyed.

Target speed is set at 1000 km/h, but due to air resistance, it is currently maxed out at around 400


All game objects, be they ships, debris, asteroids, all have a bounty associated.   Destroy something and you will be awarded credits automatically.   There is no need to claim them manually.   Bounty is paid in the primary currency of the system.

60 credit bounty for destroying Aopate Hele's ship!


Your ship's computer has variable detection and customisable output of communications.   Communications sent by other ships may be intercepted if they are in your vicinity.   Shipyards, Docks, Planet HQ will communicate directly with your ship as you enter or leave.  Pirates taunt you when they approach, victims scream as they die.

Comms won't look like this in the end, but this demonstrates some of the chatter


There are 6 major currencies in use throughout the galaxy, and while they can be universally and instantly exchanged, you will incur exchange costs if you transact in a currency that is not in primary use in a solar system.

Additionally, currency markets fluctuate providing trading and arbitrage opportunities to the savvy space traveller.   In order from most to least used currencies :

  • Credits - the oldest universal currency, still in use in the majority of systems.
  • Spektra - the first-ever fork of Credits, Spektra was the first to utilise galaxy-wide blockchain technology is available for native use by most medium to high-tech systems.
  • Odaeon - introduced primarily as a rival to Spektra, Odaeon has the same features, but less market penetration
  • Numero - this was the first-ever privacy-related currency introduced and is still used in the majority of anarchic systems.   Pirates will often deal exclusively in Numero.   Missions from the less-than-reputable will most likely pay you in Numero.
  • Elysium - not just a currency, but a universal computer, Elysium provides the basis for all interstellar communications and economic transactions.
  • Magga - Magga is a brand new and mysterious currency, invented by an anonymous person or group, which claims to possess the holy trinity of features - totally anonymous, instantaneous transactions and zero cost.   Some speculate that Magga is the first ever currency to work between universes, indeed it is assumed that Magga was invented outside of ours in the first place.  Magga is incredibly difficult to track down, and just one Magga will set you back somewhere in the vicinity of 1,000,000 credits.

Damage Model

Damage to game objects is applied internally as a 'damage packet', which gets processed by any of the receiving systems that wish to handle it.   For example, while ships intrinsically have hulls and a hull-strength, you can buy extra armour plating to bolster it (at the cost of adding weight).   Additionally, shield generators can be installed which take damage first, and regenerate via power.   Other future, more exotic damage-reduction/absorption systems will be available in future.


Exploding objects create showers of debris (literally showers, if the explosion occurs within a gravity well).   If you frag a spaceship, all the ship's systems will be part of the debris field, some will be damaged, others will be collectable for reuse or sale. Currently unimplemented, but the idea will be to make a cargo-scoop system allowing the attacker to harvest debris and sell it off later.

Debris field - aftermath of a battle.  Plenty of ship systems to scoop

Docking is relatively fast, easy and seamless and it allows you to easily fly to and land in/on any space dock, platform, shipyard, moon or planet surface.   Docking locations are allocated based on your ship size.   Each docking location has its own facilities.  Currently there are two separate facilities, with many more to come :

Docks in orbit around planets provide marketplaces to buy/sell goods and currencies.

Shipyards in orbit around moons provide maintenance capacity and a marketplace to buy / install ship systems, tune and boost your engine and apply weight reductions.   It is now possible, if you have the money, to build a ship up with extra power units, thrusters and lasers - however it's incredibly easy when you have a super-fast ship to accidentally fly into moons and planets and die in a ball of fire.

Coming in to dock above a planet


Each planet has a planetary economy consisting of inflation, a political stability profile, primary currency, a population and an economic type.   Current types are Agricultural, Industrial and High-tech, these influence the supply and demand of various goods you can buy at docking locations, as well as the availability of ship systems and upgrades.


Each solar system has a government, which determines the type of inhabitants and visitors.   Democracies are the safest to visit when you are loaded up with cargo to sell, but also the prices will be stable and moderate.

On the other end of the spectrum, Anarchies are the least safe.   However load up your ship until it is bristling with armour, shields and weapons and you can make a killing on bounties in an Anarchic system.


This is a fundamental part of space travel, and you have to watch out!   All major bodies have an associated gravity well.   Fly even remotely close to a sun and you'll start getting pulled by 100s and 1000s of G's to your demise.

Gravity leads to all sorts of emergent gameplay behaviour.   You can now blow asteroids out of orbit around a planet, and watch it fall to the planet surface, creating large explosions and destroying planetary objects in the area.   This can be used on purpose to harm an enemy's infrastructure and resources.   Later on there will be tractor beams, these, if powerful enough, can be used to drag space objects into planetary orbits and drop them on cities as powerful space-based kinetic weapons.


Each ship was built by a manufacturer, manufacturers possess inherent pros and cons.   Galaxy-wide there are 8 main manufacturers of spaceships and spaceship parts, each one has their own combination of the following statistical multipliers

- cost premium
- boost
- reliability
- efficiency

For example, Subarishu produce relatively cheap and popular sports ships, with a 15% engine boost in a fairly reliable but slightly inefficient way.   Copperhead Manufacturing Inc. mass-produce parts with average cost, standard engine boosts, with normal efficiency and reliability.   P.R.I.S.M ships are extremely rare, cost 10x the normal cost, are often unreliable, but nobody comes even close to the boost they produce, with efficiency ratings off the chart.

A P.R.I.S.M Crow, 25% boost at 500% efficiency!  And massively unreliable...


Cargo goods, shipyard parts and currencies are all examples of markets.   Markets ebb and flow over time, based on the enconomy's primary inflation level.   Supply and Demand have been implemented, so with enough cash you can deplete a market's stocks, driving up the price.   However,  each good also has an intrinsic price elasticity that determines how much the price changes in response to changes in supply and demand.

Spaceships have a cargo capacity, allowing you to only carry as much as the ship can handle.

Prototype UI for goods marketplace


The player's empire is grown by planets that they claim, and the size of the space fleet they accumulate.   Each planet has a set of resources, and when you claim a planet, these resources become harvestable.   The resources are automatically harvested at a given rate, generating an empire-wide annual production rate for each resource type.   Resources thus produced can then be sold on the market, or used in manufacturing spaceships and components.

The resources a planet has can be inferred visually from a quick visit and orbit.   By looking out the cockpit window at the colours on a planet or moon's surface, the pilot can usually tell what kind of resources are on it, and whether or not the planet is worth claiming as part of their empire.

Prototype Empire UI, with planetary production rates


Aside from the real-time aspect of the game, a universal timeline exists to run the markets and economies of the entire galaxy, as well as providing the framework for distinct time-based game events.

The player's pilot will grow old over time, and die.  There is a natural end to a pilot's life in Pegwars.

Warp speed travel, due to relativistic effects, will speed up time for everything except the player.   So if you have your empire set up nicely, and you have a lot of fuel, you can burn around the galaxy on warp-drive, ticking over accelerated time and eliminating the hassle of waiting for the annual production of planetary resources.

Be careful though, because any relativistic time travel applies to enemy empires too, you don't want to be caught off guard.

Ship Dashboards

Here's a quick look at a prototype dashboard for spaceships.   Like everything else in the game so far, the artwork is 100% prototype.  In Pegwars, spaceships are like future cars, so I've modeled the prototype from an 80's classic sports car.   The 80's really was the bomb, I love it how car designers tried to get so futuristic for a period of time.

The gauges, from left to right :

- Hull Integrity
- Shields
- Engine Revs
- (Top) Set Speed
- (Bottom) Actual Speed
- Current Gravity Forces
- Power Usage
- Power Available

Left and right of the dash will be a couple of MFD's (multi-function displays) that the pilot can customise to display whatever info they like.

Beneath the speed readouts are a couple of icons that I haven't used yet, but the idea is they will function as 'check engine' lights much like in cars today.  Expect that when you are under heavy fire and damage to see a whole row of bright red icons indicating your ship is about to be well-and-truly stuffed.

Eventually I hope to have a customised dashboard to fit each cockpit, with car-based dashes for the smaller ships and totally different setups for the carriers and larger capital ships.

Saturday, August 19, 2017

Space Truckin'

One of the central tenets of the Pegwars universe is that the future is not so dissimilar to what we are familiar with now.   Spaceships are not outlandish things, they are merely futuristic cars.  Most are low-cost, practical and plain people-movers, most people just need transportation and will pay the lowest amount they can get away with for a vehicle that ticks the right boxes.

Some spaceships are enthusiasts' vehicles - sportships, where the fun of flying them outweighs the practicalities or the cost.  Modded ships.   Ships with cusom paintjobs.   Ships that should never have had spaceturbos installed but do.  Ships that are loved and adored by their owners.

And similar to future cars, businesses must truck on as well. Space trucks are the evolution into space of ordinary trucks - long distance haulers, flown by truckers and contractors.  A big powerful cab owned by a trucker, behind which cargo and trailers can be towed.

There was an awesome game called I-War 2  that had the best space trucks in any game I've ever seen.  These freighters were ungainly, ugly ships and you could see the shipping containers attached to the outside of the ship.   Deciding on the risk/reward, you could attack the freighters, and after killing any fighter escort they may have, they'd usually surrender and release all their cargo as a last resort to avoid death.  You could then radio in for someone to collect the cargo, as the frighter pilot warps away with their life intact, but their cargo lost.  'Popping a freighter' in I-War2 was one of the most rewarding gameplay concepts I've ever come across, and one that I'd love to incorporate into Pegwars.

Thus I've set to work on some new programmer art so I can add an example of the Spacetruck class of ships, to implement gameplay around cargo and 'popping freighters', and also to refresh my knowledge of the modelling and texturing process.

The first step is to model the ship.   Firstly, I start by only modelling one half of the ship - later I will mirror + copy + weld.  This aids building a symmetrical model, and cuts down on the workload.   I start with geometric shapes - boxes, cylinders etc.  Then I extrude and bevel the box into different shapes.  Once the main shape is blocked out, then the refinement process begins.  This involves chamfering edges, applying smoothing groups, tweaking vertices etc.   Once the shape is finished, I mirror the mesh along the Z-Axis and weld any co-positional vertices together.

The Basic Mesh

After I'm happy with the mesh, comes the painful process of uv mapping.  The goal of uv mapping is to create uv coordinates for the entire ship such that it all fits on a single texture map, and the texture map is used in an efficient way.  The uv map should have a fairly constant texel - world-size ratio, meaning there are no areas on the ship that are blurrier or more detailed than any other.   While there are plugins for Max that you can pay for that unwrap a model for you, in a low-budget (no-budget) game such as this, I have to manually unwrap my models.

The unwrapping process starts by planning which surfaces of the ship should go together on the texture map (sharing edges), and how much texture should be allocated to each area of the ship.  Then sets of faces are selected, UVMapped using an appropriate modifier (face, box or cylinder mostly). Then the UnwrapUV modifier is applied.  This allows you to manually move the UV coordinates around, overlayed on the texutre map :

Unwrapped UVs
Once the Mesh and the Texture Coordinates are done, comes the texturing part.   I've worked with some awesome texture artists in the past, and that only serves to highlight how rubbish I am at texturing.   My skills consist of badly applying repeating surface patterns as a base, then putting lines on my ships.   As well as the base diffuse map, the specular amount is stored in the alpha channel, and I also create a separate RGB emission map - areas of self illumination.   Additionally one would create a normal map as well but I haven't bothered to do this yet for the programmer / prototype set of artwork.   Currently the texture maps for the space truck look like this :

Diffuse (left) Emissive (right)
So obviously there's a lot of texture work to be done here, but I'm satisfied with the mesh and the unwrapping and have a good basic texture.  Here's how the ship looks in-game

Spacetruck heading for a dock

Saturday, July 29, 2017

Atmosphere Rendering, part 2

Still doing work on my Atmosphere Shader, however it's proven to be quite the resource hog!

The current implementation is a fairly typical screen-space shader.  It ray-traces the light from the sun through the atmosphere until it hits the current pixel fragment, calculating the sun transmittance along this ray.  Then it marches that ray towards the camera, blending it over the background performing in and out-scattering again until it reaches the final fragment colour.

Incorporating Mie and Rayleigh scattering in the ray-tracing gives the following results :

Adding the clouds into the mix (as a prototype) gives results with I think outstanding potential.  However the added number of calculations in the shader pretty much takes it to breaking point, so much that I can't even prototype what it will finally look like, because I have to reduce the number of ray-marching steps in the shader.   Put simply, the shader is brute-force ray-tracing with no real optimisations and has reached its limit.

So my next step will be to split apart the atmposphere rendering into two steps.  Firstly, I plan to precompute a 3D Volume Texture containing the results of the light transmittance from the sun to each visible point.   This 3D Volume Texture only needs to cover the sunward-facing side of the planet, and I plan to parameterise the volume as a set of concentric hemispherical shells.

Once the precomputed volume texture is available, the screen-space atmosphere shader only has to do the ray-trace from the fragment surface to the eye, and for each point along this ray, it can simply look up the sun-fragment transmittance, rather than calculate it on the fly.

This will vastly speed up the shader by removing its costly inner-loop.  And in doing so, it will vastly increase the quality of results, because I will now be able to step at a higher frequency, and incorporate better algorithms for the scattering phase functions.

I'm still planning more optimisations, and think that a 3D Air Density volume texture can be precomputed also.  This will aid both calculating the sunlight transmittance volume, and the realtime raymarching algorithm.

I can't wait to see what the atmospheres look like after the optimisations :)   It's worth mentioning that this method of shading the atmosphere allows for fully dynamic clouds, which I intend to run as either a particle system, or cellular automata on the GPU, or a combination of both.  With fully dynamic lighting and seamless volume rendering, it's going to be a real asset to the game.

Tuesday, June 14, 2016

Screenshot Progress Update!

I've made a lot of progress recently focusing on refining my procedural planets and atmospheres.  Added into the mix are multi-core particle systems, procedural nebula and AI.  I'm almost ready to post videos but am excited that I have now fully tied in the galaxy to the rest of the engine, meaning totally seamless travel between every star in the galaxy all the way from warp-drive-speeds down to landing on and running around planets in first-person.

Enough talk, here are some screenshots of my recent explorations :

Some kind of desert planet, looks a little bit like Australia!

Here's a shot of my prototype cloud system.  The clouds are image based, the idea being to use a particle system or maybe cellular automata on the GPU to create procedural cloud maps for each planet.  The clouds are incorporated into the atmosphere scattering shader, meaning that they get nice sunset lighting and they also cast shadows into the atmostphere.  Plus you can place objects in, and fly through the clouds seamlessly.

Flying down to and then crash-landing on a planet somewhere

The atmosphere shader now shades the sun very nicely at sunrise, giving it that deep red glow!

Some random exploration screenshots

Showing off the procedural moons as well as planets

Taking a cruise early in the morning

This solar system has a dark sun, making everything gloomy and spooky

Looking up at the sun from a crater on a moon

Taking off from some kind of pink-crystals planet

This planet has a huge crater lake on it

A valley of forest in a grove of crystals

Just exploring some more planets

Now that I have AI spaceships and have implemented combat, the game is starting to feel like a real game more than a space sandbox!

Friday, November 27, 2015

Procedural Planets

I've started work on the procedural planets, here are some initial screenshots.  Like everything in Pegwars, it all has to be seamless, from flying in outerspace to orbiting planet and moon surfaces to landing and running around.

Each planet's geometry is formed by tessellating an icosahedron.  This shape was chosen to help make each vertex as equidistant as possible in the final mesh; tessellated icosahedra perform better in this regard than tessellated cubes or parametric spheres, and have the added bonus of having triangular faces, making it easy to tessellate and render.

Each triangle face of the icosahedron is recursively split at the edge midpoints to generate the next level of detail of geometry, as needed.  For performance reasons, as you don't want to be allocating GPU resources at runtime, Pegwars has a fixed set of vertex and index buffers for planets and moons - meaning a maximum of 10 planets at once, each with up to 3 orbiting moons.  Once I improve the level of detail algorithms, these restrictions will be able to be lifted.

The surface parameterisation for planet metadata and texture mapping is the cube map.  Each planet has generated for it a cubic height/slope map, texture map, object map and normal map.  Later on I will add cubic sub-surface mineral maps for resource extraction as well.

The reason for generating cube-maps for objects (and later minerals) is that the player will be able to customise any planets they have control over, to terraform, build structures and mine resources.  These will be updated in the underlying cubemaps and persisted to the game save storage.

Currently each planet has 9 levels of detail for the basic tessellation.  This provides decent enough resolution down to planet flight, but not enough to generate a convincing on-surface tessellation.

Because the topology of the planet meshes never changes, one level-of-detail index buffer is generated at startup and reused for every planet and moon.

Procedurally generating the heights for millions of vertices as well as calculating diffuse maps, normal maps and object maps takes a lot of CPU time, it is definitely not a real-time task.  So in order to achieve this during gameplay a brand new multi-core job system was created.

The job system allows arbitrary tasks to be run in the background in parallel across multiple threads; in addition there are 2 dedicated task threads that run on the main (rendering) thread - these are for final DX resource allocation tasks, as well as general main-thread tasks that are amortized over time to avoid frame-rate impact.

When a player travels near enough to a solar system, the background jobs start generating the solar system's planets and moons.  By the time the player travels anywhere near a planet or moon, its levels of detail will have been created, along with all associated cube map metadata.  This allows for seamless traversal from outer-solar-system flight all the way down to the planet surface.

In addition to the planet itself, I've also started work on procedural ground objects.  These objects are generated based on the underlying diffuse map (as the diffuse map for the planet is really just a hack to describe the make up of its actual surface detail), with other inputs such as the slope and relative slope.  I'll also add to this an equatorial value (colder at the poles) and once ocean and river systems are added, proximity to water.


A seamless universe is important to the Pegwars experience, and that means procedural atmospheres you can see from outer-space all the way down to the ground.

The Pegwars atmosphere shader is drawn in screen-space, and composited over the screen using the depth information from both near and far depth textures.  The shader itself simulates Rayleigh and Mie Scattering by ray tracing through and integrating against the atmosphere volume, taking into account the air density at any point based on altitude and what's in the depth buffers, the relevant ratios of gases and particulates, as well as other procedural variables.

As well as drawing to the screen, the atmosphere is also drawn into the near cube-map for reflections, ambient lighting and the all-important SSDO.  This way objects fit in the scene nicely, no matter what planet you are flying around.