• Register
Post news RSS Mixing procedural with hand-crafted design

With the solar system editor added to my creation toolset, I break down how scenarios will be built and pieced together in my RTS/pausable space game.

Posted by on

Hi again,

With the six months of development time milestone now passed, I'm looking forward to finally implementing the gameplay mechanics that I've been slowly working towards by fleshing out my creation toolset. When a game is so reliant on dynamic content, it just felt smarter to work from the bottom and work towards the juicer stuff that developers often like to dive into first, but I guess time will tell!

I'm going to keep these articles fairly light, and link to my more extensive development diaries on Youtube below-- please check those out if you're interested.


But for today I thought I'd outline the creation process that both I as a developer/designer will be using to flesh out the scenarios and eventual story mode of FE, and also the players who will get the same tools provided at release. At present two of the three main creation editors are in place: the planet editor has been around for a while, and now the solar system editor has been added to that cohort. The third system will be the scenario editor, which pieces multiple solar systems together through a node-based in-game scripting system.

1. The planet editor

PlanetEditor

The planet editor hosts a generator system paired with a management system for the various generated features, which amounts to an interface between UI sliders which provide input values and the generating code itself. Long story short, voronoi cells are distributed across the surface of a quad sphere (cube morphed into a sphere for easier texturing) and these cells can be attributed to a range of biomes which tell the system what the ground type is like and what textures to splat there, etc.

Different planet types are free to use whatever generation systems they like as long as they provide the management system with some specific final values, so the EarthLike type, for example, uses a procedural climate model which actually transfers water from the oceans to other cells via a series of wind cells that is dependent on the planet rotation speed and overall quantity of water available. If it sounds over the top, you might be right, but everything is generated during a solar system load, so it's fiiiiine.

A navigation grid is also created at this stage, intelligently determining which classes of units will be able to move across a certain part of the mesh, be it water units only being able to move on water regions or ground units only being able to move on continents (which is generally worked out from the mesh height).

So far, so very procedural. But I don't believe a full procedural solution will get me the diverse experiences that I want our fleets to have to overcome, so the next step involves the placement of 'features' on the surface of the planet. Whilst still in a preliminary form at present, trees, ruins, cities, mountains and other points of interest can be applied to the surface, automatically updating the relevant navigation grid locations, and providing hooks into further interact-ability with locations of interest. Resources can also be added here, as well as minor race starting points and other planetary hazards. Most of these features will include scriptable components that can be driven from the later scenario editor for triggerable events.

Until recently I was only working with the EarthLike planet type, but I've now included an early version of the 'rocky' planet type, which will likely be the most common planet type encountered in FE. This type is intended to embody moon-like and mars-like celestial bodies, with configurable pattern variation, cratering and polar ice regions, as well as the option of a thin atmosphere.

RockyType

And the navigation grid already knows to route units around the craters, so that's handy!


2. The solar system editor

SystemMap

With planets part procedurally-sculpted, touched up by hand, and then designated to a system, we can switch over to the solar system editor to position these celestial bodies relevant to one-another and to their parent star. Stars come in a range of options, from dwarves, main sequence and giants, through to eventual binaries, black holes, neutron stars and the like (I studied physics, I'm contractually obligated to include as much of this as possible!). Temperature can be varied from 2k Kelvin to 32k Kelvin, with the colour of the star adjusting as required (from red to blue, shown with scrumptious bloom). The planet list updates dynamically as new planets are added, with the system identification region updating the user with what processes still need to be performed for each planet (be it generation or placement).

Distances are provided in AU, and distance from the parent star (or equivalent) determines the intensity of light received at the planet surface. In game indicators show the distances to other planets as per pretty much any space simulation game, and the star is positioned (for each planet) at a sensible distance, so it's bigger when viewing a planet at 0.5 AU as opposed to out at 15 AU (where light intensity is pretty low-- you're gonna need to place lots of light sources on the ground to get anything done!).

This system map also doubles as the in-game Homeworld-esque zoomed-out map view. I've been working on this, but it's not quite there yet. Ultimately this will allow for rapid movement around the solar system, zooming out from one point and quickly zooming in on another, with UI indicators around each planet showing what's located there and what's going on.

With planets placed and a star type chosen, we're up to the present development situation. But there's a third creation component yet to be implemented...


3. The scenario editor

So, a scenario is a collection of multiple solar systems linked together and orchestrated by whatever settings oversee the overall flow of the game type. A scenario can begin with warping in, being in orbit around a planet, or even with a settlement on the ground, and all of this is determined by the scripting system encapsulated by a user-friendly node framework. If you're used Unreal's blueprints or Unity's Bolt then you'll have a clear impression of the design intention-- ultimately, it will feature system nodes that can be connected together to show which warp in/out points lead to other systems. Within these higher-level nodes, planet nodes can be combined with functional nodes to indicate triggers or events that will happen when the player does something or goes to a certain location.

I'm not sure I've seen another game attempt to add a script-like system through a node interface, so it's entirely possible its a hideous idea, but someone has to give it a go...

I'll go into more detail about the scenario editor when it actually exists :)

But what does exist is the 'creation organiser'; a file-directory-like system that lists all scenarios, all systems within these scenarios, and all planets within each system, and everything that is built is saved in the relevant structure, and to the users game files where applicable for future sharing. Icons help the user to see what has been added to each system/scenario, and at which stage in the creation process you are with each planet/system.

CreationOrg


And this article has gone on far longer than I intended, sorry! I also have a public FE on Trello if anyone is interested in the future road-map. Thanks for the taking the time to check this out!


Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

News
Browse
News
New
Post news
Share
Related Games
Fragile Existence
Fragile Existence Real Time Strategy
Related Engines
Unity
Unity Commercial