This update chiefly focuses on the development of the world-building tools that will allow planets to leverage the ease of procedural settings coupled with hand-crafting 'level design' that allows planets in FE to still have a unique flavour and possibilities for scripted behaviour. A bunch of new ship designs and ground units have been included too, as well as better visual feedback for movement throughout the solar system (principally in the form of interstellar dust). All of this is leading towards gathering resources from the planet surface, and using these resources to build base installations and units, and more complex materials/components from there, which is really at the centre of the eventual gameplay loop.
Building worlds with the bundled planet editor tool
The intention has always been to package the world and solar system tools with the finished game, but they're the very same tools that we will use to craft the included scenarios and solar systems that are part of the overarching story structure (beginning with the fleet exodus from Earth), so it makes a lot of sense to get these tools working fairly well early on. Not to mention we had reached the point where being able to gather resources and such from the planet surface was quickly becoming an important next step in moving things forward.
The new planet editor allows the user to customise settings specific to the planet type (EarthLike and Rocky, so far-- Gaseous to be added, as well as more specific variants like Lava and Ocean, etc), adjust the planet radius, turn on and off the ocean, atmosphere and planetary rings, then tweak some of the colour palette multipliers, before moving on from the procedural framework and entering the hand-crafting 'feature placement' mode.
Placing features involves choosing from the slide-in palette of surface pieces (which will hopefully grow rapidly) that can be positioned and rotated whilst aligned to the surface grid itself, with pieces able to overlap and be finely adjusted for more creative results (like mountains forming volcanic islands when placed out to sea). This ultimately turns the planet editor into an in-game 'level editor' of sorts, with the intention being that users can sculpt a particular theme or tailored environment using the features on offer, to tell a story or just force ground units to land at specific points on the surface ready for an ambush.
A later revision of this tool will include scripting placement, which will allow for scripted events to occur when certain areas of the planet are discovered, or when units move into a defined collision region. Hooks into these scripting objects will be available in the node-based scenario editor.
Filling out the fleet roles
We've added a number of new ships to the roster of possibilities, including the Strike Carrier (shown above), which carries a squadron of small strike/recon/fighter/bomber craft which can be dispatched towards other planets but have limited fuel reserves and need to meet up with the carrier again before too long to refuel. This capital vessel joins the Heavy Transporter (big cargo hold) and the Support Carrier (has a docking bay for dropships which ferry ground units to and from the surface) seen earlier.
On top of these somewhat role-based capitals, we've also added the first of the Frigate and Cruiser variants, which serve as more versatile options, having the possibility to perform a multitude of roles albeit in a less capable fashion than the capitals built with that goal in mind. Frigates are on the smaller end of the spectrum, with much more limited carrying capacity, whilst cruisers were built for more extended tours of duty and are therefore capable of resupplying themselves for a greater duration than the frigate class ships.
As well as extending the fleet options, this update also sees the inclusion of a few ground models: the Spider tank, which is a fairly slow moving unit that can traverse pretty much any ground terrain without complaint, and makes up for its slow speed with a rotate-able turret mounting (though actually shooting at stuff is yet to be implemented!)
Another starting vehicle is that of the Quad: a nifty, cheap to build vehicle ideally suited for reconnaissance and exploring worlds, but doesn't possess any means to defend itself if it were to come across any trouble.
Finally, we've also started to flesh out the 'Prefab modules', which are deployable ground base installations that can be dispatched to the surface to kickstart a ground base operation, before being picked back up (via dropship) once the expedition needs to evacuate again. This provides a way to allow such buildings to be upgraded and provide progression in a game where you'll be exploring many worlds along your journey, often building ground bases only to have to abandon or salvage them afterwards. The prefab base modules take up slots aboard the fleet much akin to the ground units/fighter craft, so there's always going to be the choice of how to make the most of the limited space you have available.
Filling the interstellar void
This won't show up particularly well in photos (check out the YouTube channel for plenty of in-game coverage) but we've also added 'interstellar dust' throughout the solar systems. The idea was to better show the movement and sense of speed when ships are travelling between worlds. A lot of space games achieve this effect in one of two ways: adding a particle effect around your ship, with the effect being influenced by the speed of the ship, and simply following it around everywhere, activating the effect when required.
The other option is to simply disperse particles throughout a large medium (i.e. the entire game area) and cull the particles that are too far away from the player ship, effectively only rendering those that are a fixed radius away from your location.
In FE, however, the player isn't tied to one specific player ship. The camera can focus on anything: planets, ships, units, it's all fair game for being a camera rotation target. So the first option is out. With such a free-roaming camera rig, it becomes a lot more difficult to work out which particles should be active at any one time. This makes the second option pretty fiddly. I've ended up with a system that works out which group of dust needs to be active depending on the camera targets location, with a network of dust patches turning on and off as required, and stretching towards the camera view as it moves with greater speed when locked onto a ship moving at higher velocities. Long story short: it works, and it looks pretty okay!
Passing one year of development
I recently celebrated reaching one year of development time by putting together a video compilation charting the progress from early prototyping to more recent developments, and I invite you to check that out if you've more recently come across Fragile Existence:
And the recently uploaded Dev Log #17 essentially recaps the main points from this article in video form: