next »

[leeharris]

Fragile Existence - Real time space strategy/fleet management/survival
=================================================

Steam store: https://store.steampowered.com/app/1672320/Fragile_Existence/

Official FE Discord community: https://discord.gg/ZhyKev2R7X

Website: Fragile Continuum

Development logs on: Youtube
Social media: Twitter


Links to posts within this thread:

01. Ship movement & UI (see below)
02. Items & Inventories
03. Procedural Worlds
04. Procedural Climate
05. A* Pathfinding & Splat maps
06. Hyperspace & Serialization
07. Six months of development!
08. Building solar systems
09. Tactical solar system map view
10. Orbital/ground movement & selection
11. Character Profile & Skills
12. Interplanetary movement
13. Visual overhaul, scanning & dropships
14. Planet features, fleet comp & ground units
15. Gamescom 2021, Reveal Trailer, Steam store launch


----------------------------------------
Original first post:

Hi,

Fragile Existence is a 3D space strategy (with tactical pause!) fleet survival game which springs from memories of watching the new Battlestar Galactica and feeling oddly drawn to the whole fleet-on-the-run-whilst-rebuilding-society-and-scavenging-for-resources thing they had going on there.

I had initially planned to make a more straightforward 4X with interact-able planets (rather than endless menu screens), but then I thought I'd just twist it around a bit and make it so you're an empire on the run, equipped with ships that can research, build and expand on the go. And every time you reach the next system you've got to wait for the jump drives to cool down and compute the next jump, so you make the most of whatever resources you can find. Ok, ok, it's a bit Homeworld too, but with random star systems and encounters throughout...

Plot aside, I'm developing in Unity after making the switch from UE4 earlier this year. I'm modelling in Blender, but I'm a programmer first and foremost, so a lot of the basic mechanics are set up (chiefly apart from combat and resource management):

• Planetary cameras and ship cameras that rotate and zoom freely
• Fixed-frame interpolation (so possibly multiplayer friendly much further down the road)
• Orbital dynamics (ships even fire little thrusters to rotate!)
• Planet and ring shaders; particle thrust effects
• Deterministic waypoint handling
• Component-based architecture: ships are literally made up of things that provide functionality
  
• Oh, and some neat ship running/navigation lights for the civilian ships

UI is coming along nicely too, with the recent addition of a starsystem/fleet overview window that makes finding ships in your fleet a whole lot easier.

As of writing I've been working on Fragile Existence for just shy of three months, and I've recently started a series of development diaries on YouTube, so I figured posting a DevLog here was the next big step

YouTube DevLog series:

Thanks for reading!

[leeharris]

Hi,

I've spent this past week developing an inventory system for the ships in your fleet, alongside a combined 'fleet inventory' that collectively lists all items stored in the cargo holds throughout the fleet. This turned out to be quite the rabbit hole adventure, because I quickly realized that I needed a good idea of what items I was even interested in my ships carrying before I could comfortably think about how best to visualize the containing UI.

So I turned to an all too familiar friend: Powerpoint (I used to teach, possibly badly), and spent several hours plotting out what resources I wanted to be able to obtain from planets (both rocky and gaseous types - each of the planets in our solar systems needs to offer something if we're to have any reason to travel to them). This actually required a ton of research in to current and projected-future trends related to mined ores and common materials used for things related to space today. Ultimately, I wanted to find a handful of real ore types that let me recreate something akin to 'The Settlers' of old, where a relatively logical combination of items leads to a further material that can go on to be a requirement in a more complex fabrication process.

What I landed on involved raw resources being mined from rocky planets and a gas mixture being obtained from planetary atmospheres. These resources can then be refined through the relevant buildings and with any catalyzing ores (commonly carbon) to produce 'materials', which then can be combined with other materials in manufacturing processes (be it through ground-based facilities or ship-based components). Gases can instead be distilled in to four useful gases (for our purposes, that is) including Xenon which is the initial source of power for ships in the fleet (being futuristic versions of present day ion thrusters).

I then needed to outline the manufacturing processes themselves; to block out which materials lead to which parts/tools/weapons/apparel/etc. This led to a fairly tidy development tree that has antimatter-based spiked fusion as the principle power core supply, and all ore types are ultimately required in the continued production of that fuel supply. As long as the fleet has some basic iron/carbon, it can eventually grow to develop everything else in the starting technology line-up.

I've also considered water and food factors, with the planting of crops on the surface (farming) or growing aboard ships being required in order to keep all of the people in your fleet fed. Water can actually be produced through the Sabatier process, and isn't something I'm anticipating to be micro-managed as long as hydrogen and oxygen ratios are high enough to accommodate the number of people on each ship. Likewise, I'm not expecting oxygen-management to be a gameplay element, it's presumed that life support can regulate that just fine.

With all of this laid out, I started to implement the ScriptableObject-based item database. This works with a parent Item ScriptableObject class, with the sub-types inheriting from this. There is a singleton item database manager that stores references to each of the items as they are created. The biggest time sink here was actually organising the UI and making the graphical elements that corresponds to each visible section without overdoing the pixel redraw (not that I'm planning to release on mobile, but I know I intend to have a whole bunch of window panels and it can all add up). I eventually came up with a window design that I quite liked, and set about creating all the prefab elements required. This can be incredibly fiddly, I won't lie, especially when you're trying pretty hard to keep everything free from dependencies. This is ultimately solved by using a lot of static-declared event handling in this case, but the fleet inventory was particularly tricky to set up: the order of items varies when compared to an individual ship in the fleet, so I couldn't just compare the index of a List to the children of the layout panel as I did with the ship inventory. Cue quite a few headaches, but I managed to overcome

I think it looks pretty snazzy, and paves the way for new UI elements based on the same window design. I also learnt how to make skyboxes in Blender and added a subtle star background. My next ship design (Destroyer) is coming along pretty well, but is still in the modelling stage.

[leeharris]

Hi again,

I'm still fleshing out various systems and getting a clearer idea of how everything is supposed to work together in an interesting way -- but I did come to the realization that I should be designing from the planets themselves upwards, which led me down the rabbit hole that is procedural generation...

Many many tutorials and sprawling tangents later, and I think I've got myself a nice framework to build upon. I've gone for a quad sphere approach, using overlapping simplex noise patterns to carve out the relevant terrain features, and masks of previous layers (i.e. continents) to help lay out the following noise layers. My initial prototype was based on scriptable object settings, and that didn't seem to be very scale-able, so I'm now rebuilding everything as an 'in-game' planet generator with sliders that combine basic properties into more distinguishable settings (land density, sea level, land complexity, etc). I decided a separate quad sphere would work best for the sea itself, which can also let me dynamically adjust sea level in game, which could prove interesting.

Planets can be saved and re-loaded through the in-game editor, so the next steps are passing these planets into FE proper and getting some units moving around the planets themselves. I'm thinking that each vertex can potentially provide a navigation mesh of sorts (A* perhaps?), so that's the plan going forwards. Looking forward to moving units around on continents, building colonies and such, maybe then it'll start feeling like an actual game rather than the space simulation it is presently 

I also intend to extend the planet generator system to allow for the manual placement of gameobject-based terrain and obstacles, existing cities, alien ruins, etc, to allow for a nice mix of procedural and hand-crafting of more interesting planets. Ultimately, I'd like to be able to build solar systems with an entire backstory of sorts, but this is thinking wayyyyy down the line

Thanks for reading!

Plus, Destroyer class ship with some slightly iffy texturing:

[JobLeonard]

I'm sorry, did you say procgen Homeworld + Settlers hybrid? 

[leeharris]

I guess I kinda did, yeah :D (Maybe I should change the thread title to reflect this..)

I'm not sure I'll be having idle workers stood between path intersections waiting for the next fuel cell to be carried around, though, missed opportunity perhaps..

[JobLeonard]

You can have small drones that orbit the ships that automatically move cargo between them

[leeharris]

Hi again,

So I decided that a purely noise-based procedural planet - even just where used as a template to build up on - is somewhat lacking in character. Sure, most things can be parameterized, but it's tricky to take away the inherent uniformity that it is all built upon. I just wasn't particularly happy with it.

But that's ok, because it was a great excuse to switch to a 3D voronoi based system, complete with approximations of plate tectonics (shown exaggerated below) which functions as a mask for the resulting height data (so mountains should end up near the edges of plates and islands should pop up similarly!)

Then on top of the tectonic layer, I figured voronoi noise would work great for biome placement as well. After reading around the internet and finding a few hex-based procedural implementations, I was even inspired to go all in and apply a functioning climate model as well...

So whilst these images may look a little errr 'wacky', it's just a way of showing two sets of data at once -- color represents temperature (red is hotter, blue is colder), whilst tile height represents the amount of precipitation falling on that tile. This is a planet with Earth-like settings, at aslightly higher land/sea ratio (oh, and black is the ocean btw):

You may be thinking: oh, okay, that looks kinda cool, I think, but is this just random or something...? Well, not really. I've got a flow field-like system that transfers moisture from ocean tiles along a wind direction which is determined by both latitude and temperature of that region. The amount of moisture is also determined by the air temperature of that particular tile too. Wind speed is determined by planet rotation speed, but that isn't technically implemented yet. I've also got an upwards/downwards trend which maps to the wind cells that we have on Earth, with wind direction ultimately changing depending on latitude as well. I realise it's quite a simplification, but it seems to do okay, with moisture generally ending up near the equatorial band and the temperate regions, with in-land tiles generally receiving far less. Yet to add in the movement of temperature, but it works reasonably well with potential exo-climates, be it too hot (lots of rain, but lots of desert too!) or too cold (very little water to land movement, frozen continents):

The next steps would be too get the temperature transport added, let land move some moisture too (rivers and lakes are a thing), then select the correct biome for each tile based on the temperature and precipitation-- and maybe add in some exotic alien ones too to spice things up. Barren planets and moon can be generated from this system with a low enough temperature and lack of atmosphere, and I learnt how to make some nice voronoi-based crater mesh deformation too (thanks Kerbal!)

[Schrompf]

This looks really nice. I love these debug-style rendering, but I guess you'll replace that by some more planet-y visuals?

[JobLeonard]

Yeah, it does have its own charm to it for sure!

[leeharris]

Yeah, sadly they probably do need to be turned into real planets at some point :\

That said, I can see some real potential for planet-sized engineered structures using visuals something like this that units can still move around on the exterior of-- like big fortress worlds with opposing armies occupying the surface trying to learn the secrets of these ancient monstrosities... could be something akin to a boss level of sorts...

[JobLeonard]

How about tactical overlays for the micro-optimizers out there?

[leeharris]

You can have small drones that orbit the ships that automatically move cargo between them

How about tactical overlays for the micro-optimizers out there?

I'm just gonna steal these ideas, btw

[JobLeonard]

Having random suggestions taken seriously is the highest honor for any commenter on the devlogs

[leeharris]

Hi again

Been a slightly more grueling six weeks, if I'm honest, but I've finally moved on from the more superfluous climate modelling and onto the more meaty stuff, taking the biome partitioning and building a height map and splat map which can in turn be projected onto the individual faces of a cube map.

It turns out that this isn't the easiest thing to achieve in Unity, but I managed to work around a few hitches and ultimately produce something that works pretty well, giving me a nicer looking coast line region and reasonably placed splat brushes which lead to the relevant selection of textures in the shader based on the biome at that location: so procedural texturing is a go, and can be customised for any range of planet types with or without biome/climate detailing.

Whilst this took some work in itself, I've also finally implemented a fairly optimised A* pathfinding algorithm which takes in data produced about the planet surface to decide which movement types are possible at each vertex position (be it ground, sea or air unit types) and constructs a navigation grid across the entire sphere. This was another technical hurdle that took some time to figure out (and work through the math for) since each face of the quad sphere is a distinct mesh and you need to consider the rules to apply to find the nearest neighbours in each of the 8 directions around each node. Tricky stuff, but it's done, and I'm very happy with the results. Only working with debug paths at present, but shouldn't be too much harder to get units moving along those same paths once I move everything over into FE proper.

And, finally, as seen in the image above, I've just started working on the ground features system. This will allow trees, mountains, buildings, points of interest, etc to be hand-placed on the surface (with the navigation grid responding to these changes on the fly) which allows for a more hand-crafted appearance to be produced. I'm going to have brush settings that allow for a more procedural placement of objects, and have rivers which start at mountains using the A* algorithm to produce somewhat realistic paths that end in oceans.

I feel like some of the more challenging components of the game design are now more or less in place, so maybe some solid gameplay isn't too far way

Thanks for reading!

[JobLeonard]

This looks sooo good

Quality technical write-up/video too

I guess you're not going to have so many units that flow field pathfinding is the better alternative?

[leeharris]

Aww thanks, you're too kind, it's still super early days

Just started a Trello roadmap type thing if anyone is interested in seeing what my current plans going forward are: https://trello.com/b/fzeGlvbN/

As for flow fields, that was my original intention (I'm pretty much just scavenging through the old Planetary Annihilation development videos for tips about planet gen stuff, and that's what they went with). I've actually already got a system in place where nodes are placed into regions on a lower resolution grid, so I can pick out the associated regions for an A* path which could be populated with field data without trying to flesh out the entire planet for each group of units (again, pretty much how PA achieved it)

I actually quite like the idea of things like drones and fighter craft using a flow field, so I think I'll at least experiment with it at some point. Ships are just using vector projection to move around in orbit and I don't think I'll change that (I feel like it's quite important that ships move in straight lines...) so I probably won't be doing flow fields in space at any rate. I suspect once I implement it for ground units I'll end up preferring it, but I'm moving on to other things for now

[JobLeonard]

Knowing how and what to prioritize is probably the most important skill of indy dev, sound like you got it down

[leeharris]

Hi again,

So four weeks have passed since the last update, and I'm apparently approaching six months in to the project! I know I've picked a relatively tricky game type to work on solo, and most of my time has been spent on foundational aspects, but it feels like things are moving along pretty much as expected...

As for the last month, I've managed to consolidate a lot of the prototype stuff into one cohesive structure, connected via the main menu screen. I've implemented a serialization system that operates on the hierarchy of planets -> which are part of solar systems -> which are part of scenarios (where relevant game settings are applied, such as starting ships, etc). I had to figure out all the unique ID stuff, and distinguish between editor-time creation (to be added to asset bundles later) and build-time creation (saved to users' save files, to be shared with other players), and try to make it look snazzy to boot, and it took a lot longer than expected to iron out all the bugs tbh...

Moving on from the creation side of things, I then needed to be able to load these pre-built solar systems (packaged into a scenario) in to the main game itself. I figured what I really needed was to have planets being generated in the background whilst I showed a loading screen of some sort. Prior to this point planet generation with procedural splat-mapping was locking up the game for around 5-10 seconds depending on complexity (and could certainly be reduced with some optimization and reduction in visual fidelity) so I set about making everything generate asynchronously. This turned out to be a bit of a job in itself, and collision mesh allocation still causes some small hiccups when registering with the physics system, but I've read that can be multi-threaded, so I'll dig in to that at some later point.

So with planets generating in the background, it seemed logical to make an interactive loading screen. And I figured what would be better than a hyperspace/warp sequence, which allows for ship management tasks to be carried out during warp in a kind of 'staging area' ahead of reaching the initial solar system. So I installed Unity's visual effect graph, and played around a bit, not entirely realising I'd kinda mimicked the star wars hyperspace effect...

Planets and ships orbiting them are automatically added to separate layers, I now need to build the 'solar system editor' which allows us to define how the planets are arranged, and how ships can move between them, and set out to get ships moving throughout these constructed systems (and then warp to others). Obviously I've put aside ground movement for the moment, but I think it makes sense to get the solar systems fleshed out before I worry too much about that. Plus I could do with a few more planet generation templates (rocky, gas, at least) because currently I'm positing that all planets in the universe are in the Goldilocks zone....

As ever, thanks for reading; hoping to have some early gameplay to show off by christmas  

[JobLeonard]

I freaking love that hyperspace loading screen

[leeharris]

Hi again,

Just a small update to mark the first six months of development of FE! It has mostly just been lots of prototyping and pretending that my art design skills are right up there, and probably three months of that time was spent on the procedural planets branch alone, but I'm happy enough

But I did finally get some Rayleigh/Mie atmospheric scattering working (and in shader graph, even!) after discarding probably five different attempts in the last few months. Not sure I can really take credit because it's an amalgamation of various ideas I found around the internet, but I've adapted it to a slightly more cartoon-y look (i.e. not to scale) since I expect that my scale-defying ground units will look better if they're actually beneath the top of the atmosphere ?

Andddd I made a little compilation video to mark reaching six months and not yet running out of steam!

I know I don't really ask for much in the way of feedback yet (I'd probably need to have some actual gameplay for that  ), but thanks for stopping by, and I'm sure I'll have lots of queries to throw your way eventually