Games Fragile Existence - Space-based RTS/Fleet survival

Hi,

Having made the move from UE4 to Unity this year (the workflow seems more straightforward to me), and having an abundance of free time I never quite expected, I figured I'd start a little passion project that I'm calling Fragile Existence.

The original idea was to make a 4X space game with some slight leaning towards realistic space physics and an emphasis on direct building of colonies on the planets below (as opposed to doing it all through UI screens), but the idea grew into a bit of a Battlestar Galactia-inspired pursuit across the stars instead, with each ship in your fleet becoming vital to your survival as supplies start to dwindle and everyone in the galaxy seems out to get you (or at least stop you exploiting their resources). But of course your most precious resource is the last of humankind themselves, and as you struggle ever onward that number can only go down...

It's early days (about 2 months in), but I've got an orbital movement system working, with deterministic waypoint handling, fixed frame interpolation, and a heavy use of component-based architecture so that ships can literally be made up from scripts that describe each of the functions/abilities that ship should possess. The camera system relies heavily on Cinemachines Freelook components, with a zoom-to-cursor function implemented through the use of layered rigs.

I would be delighted to get some feedback about the concept, the implementation and anything else you fancy putting my way =)

Thanks for reading!

 

Hi,

I've added a ship view camera so you can get more intimate with the ships you're commanding, with full camera rotation and multiple zoom levels achieved through Cinemachine FreeLook components and a bit of transition magic. I've decided I like the realistic (read: very dark) shadows that the planets have and will be aiming to make that more of a design choice that leads to some interesting game mechanics centred around the use of the dark side of planets/moons/etc. So then I got to researching aircraft/boat navigation/collision lights, and I implemented something akin to that...

Made some progress with the UI, I have the solar system/fleet inspector window working pretty nicely (though my system currently only has one planet at a time, WIP!) Very much enjoying this project at the moment, looking forward to having enough of the framework in place to get to the actual 'game' of this game

 

Hi,

This week has seen the addition of a ScriptableObject-based item database, with item sub-types inheriting from the base Item ScriptableObject, and a centralised Item Manager that stores all of the references. I've introduced Inventory components to each of the ships, so they have their own storage capacity and a total volume that is calculated from existing ship components, as well as going ahead and making a 'fleet-wide inventory' that functions somewhat like the combined inventory from Eve Online. I now also have a window design to reuse going forward with the myriad other menu screens I'm likely to need for this sort of game...

I feel like I've had to get quite intimate with Unity's UI-constructing functionality this past week- it's concerning just how many gameobjects you need to have to make even a modest UI layout, and avoiding pixel redraw is tricky when composition seems almost the intended design choice. But I've been sub-canvasing as much as possible and avoiding layout handlers where I can and I think It's efficient enough for now. Looking forward to playing around with the next incarnation of the UI system once it has matured enough, though.

I've also planned out (and this is more game design than Unity-specific) what resources will be available on the planets you'll encounter, and what these resources can be refined into. These materials can then be used to manufacture more useful parts/ships/tools/etc that the fleet needs to continue. I've gone for a bit of an old 'Settlers' style system, where you mine basic ores and combine them to make other things, which you need for another process, and so forth. The next stage here will be to implement some basic planet-based activities that lets us actually mine and refine these materials rather than just pressing a key and making them appear in the respective inventories

Any comments about my intended resource system (and even how it isn't as accurate as it possibly could be without over-complicating things) are most definitely welcome!

Thanks for reading!

 

Hi,

I clearly have some way to go when it comes to putting together 3D assets, but an early version of the Destroyer-class military vessel is working now (albeit without actual weapons, but we'll get there!)



I've also completely re-worked my earlier camera system - still using Cinemachine FreeLook camera's coupled together for each of the set zoom levels and target types. I'm basically now alternating between two world view and two ship view camera rigs (with 3-4 zoom levels per rig), and should now have unlimited freedom to control the blend transitions between viewpoints as required.

My ultimate goal was to be able to have multiple planets in the solar system, and with free ship movement between them, so with the camera system adapted for that goal I then built a Sciptable-object based framework for loading in pre-built solar system layouts with data presets setting the properties of each planet type (prefabs). So I can just drop in a 'level' per se, or later allow for dynamic random planet properties/locations/etc.

I'm currently just 'moving' to other planets via clicking in the system inspector UI component, but the camera will also follow ships en route to planets once movement between worlds has been added in. I'm hopeful that a floating origin system won't be required, although shifting things around whenever a planet is selected wouldn't be too difficult to put together. I'm leaning towards a bit of trickery to show ships moving faster/further than they really are when moving between planets, but I guess we'll see how that pans out.



I've also updated the project to 2019.4 LTS, which was a pretty straightforward process in this case! Next steps include getting some ground installations/interactions working, planet-to-planet movement, early weapon target systems, rotating cloud layers and hooking up the ship UI so that they actually start to use resources.

 

Hi again,

There has been a few other distractions, but I've still found time to refine the game design and come to the realization that I kinda really need to work upwards from the planets themselves... so I spent a not inconsiderable time looking into spherical-based procedural generation for planet surface detailing. I've landed on the use of a quad sphere, which is modified by layers of tailored simplex noise for continent shapes of varying density and complexity. I've included a lower resolution mesh to represent the sea level, and that could easily be modified during the game should I find use for it Pretty happy with the results so far.

I actually knew next to nothing about serialization prior to building the planet generation system, and apparently I can now save and load different planet configurations (ready to be imported into Fragile Existence proper), so that's a plus

​

 

Hi again,

This past month I've been reconsidering how I'd like the procedural planets to look and feel-- and although I reached a point where combinations of 3D simplex noise was starting to look fairly decent, and I could allocate biomes based on slightly differing heights and still keep things relatively flat-looking and semi-realistic-- I couldn't shake the feeling that the uniformity and generic-ness wasn't going to go away, even with textures applied...

So I spent a good while researching various other methods that developers have played with to get some nice looking planets-- there's some great stuff out there from Planetary Annihilation, and even Spore, but perhaps the most inspiring was a blog post from someone who had developed a nice looking hex(ish)-based planet with climate model, tectonic plates and continent shapes that looked pretty impressive.

Since then I've been rebuilding the planet generator system to work with 3D voronoi noise, which stemmed from replicating some ideas from another old blog post from the developers of KSP which suggested a way to make crater shapes in the mesh itself.



This works by applying an AnimationCurve to the distance from the voronoi centre, and cutting off the contribution to elevation at a required crater radius. They still need additional noise to look realistic, but ultimately this springboarded out to me using voronoi for tectonic plate structures (exaggerated below)



For now my thinking is that this contributes elevation to the continent itself, with the edges of the plates curving upwards (again as a result of a distance function and associated curve). Islands should naturally occur on these boundaries through a result of the added height too.

The common next step seems to be to allocate these plates as either land or ocean plates, but I figured that was probably unnecessary and simply added another voronoi diagram on top of this at a much finer resolution that could be populated with land or ocean 'tiles' as per requirements. The algorithm intends to match the land/sea ratio exactly by populating tiles starting with several starting points randomly assigned around the globe. From these starting cells, a random number of neighbours are found (closest centre points to the current cell) and these are set to land tiles, before a random one from this pool is chosen for the next iteration. The algorithm then passes to the next starting point and repeats. With a low enough land/sea ratio these starting points will each represent their own continent (and is thus the maximum continents setting), but will meet and form more complicated landmasses if enough land is desired. Even at ratios similar to Earth, fairly realistic continents are arising. I've biased the starting point generation by latitude, so it's less likely to pick a spot in the arctic circle region too, that certainly helps with realism (though I wonder if we just expect planets to look like that given we only have the way Earth looks to go on in terms of terrestrial worlds).

From here I just went ahead and implemented a (very) basic model of climate, using some of the suggestions provided by the aforementioned blog post: moisture is generated from ocean tiles depending on temperature, and moves along a flow field that roughly represents the direction and speed of the wind (speed is only dependent on planet rotation speed for now, which isn't really implemented anyway..) Precipitation is deposited on tiles along the direction of the wind until the initial cells' moisture contribution is reduced to zero. I haven't actually finished implementing the movement of temperature along the wind directions as well, but I'm just reading up on how that works here on Earth before I make another super crude approximation for that..

The image below shows what this is all looking like currently, with cell colours indicating temperature (surface and air temp are just combined into one value for simplicity) and cell height showing precipitation falling on that cell (note that black cells are where the oceans lie):



As you can perhaps see, we do get a good deposit of rain where we would expect, with most of it in the equatorial region and some in the temperature regions, with flatter regions more in-land and towards the poles. I should note that I figured a true flow field with voronoi cells wasn't a particularly easy proposition, so instead I'm actually rotating vectors around the globe starting with the current cell, and an algorithm determines the movement of the 'wind vector' based on latitude and temperature. It does crudely manage to replicate the 'wind cells' of Earth, with wind direction varying with latitude and shifting polewards or towards the equator within certain temperature limits. Unfortunately this means I don't get a nice flow field to illustrate the wind patterns, but I can simulate exo-climates without it being tied specifically to Earth-based values:





So I think a simplex-based implementation is looking pretty uninteresting compared to what might be possible with voronoi diagrams. Textures can be mapped to cells, and ideally would use virtual texturing (but I'm using URP, so...) I'd also like to get some constructive solid geometry working so I can etch out some interesting shapes on the planet surface akin to what was done with Planetary Annihilation.

I'm going to continue to flesh out this climate-based model, get biomes allocated as per the final temperature and precipitation values, then get to work on being able to port planets to the main project file for integration with the orbital-based systems (it feels like a long time since I've even opened the main FE project file!)

Thanks for reading, any suggestions always welcome

(Edit: Seems like we can't link to gifs on this forum any more..?)

 

Hey Lee,
I watched the videos and I'm very interested in your process and progress. The game concept sounds fun and interesting to me.

Some random thoughts:
Do you know the game "XO"? There you also control a fleet which is followed by an enemy. Maybe look at it for inspiration and to avoid plagiarism .

And maybe you want to consider "The Expanse" (book and Amazon Prime TV series) as additional inspiration as beside there is an external enemy there is still enough conflict going on between humans themselves. But in battlestar galactica the "heterogeneity" is also covered (fe elections, sabotage, riots). So it would be good to have some kind of "politics" or at least some kind of "evaluation" of the player by his subordinates. So when the player looses many ships fe or leaves ground expeditions behind some ships may revolt and/or desert.

Have you considered asteroids and their exploitation? Especially for large amounts of materials its easier to get them from asteroids than to pull them up from a gravity well of a planet. How is this transport handled? Shuttles which use fuel? What about moons? There could also be other POI's in the solar systems like shipwrecks, a comet, an "anomaly" and such stuff.
How are "violent" environment conditions handled (heat, pressure, acid)? Is there research to broaden the spectrum of available planets like fe some better space suits which allow a higher pressure and radiation? It would also be interesting if the player cannot explore certain planets because of such inherent risks and hazards.

I'm not sure about your "each ship it's own UI" approach. I find it much easier to just have for example an production overview and select there what to be built instead of selecting the constructor ship and tell it. This is especially important with many resources and their distribution. It would be a hassle to be unable to built something because it lacks 5 tons of steel and you first have to carry it there manually. So a generalzized overview of all available resources and what can be built out of them would probably be helpfull. Or at least have the fleet inventory allow for automatic transportation of goods. For example if a ship requires said 5 tons of steel it can be dragged from another unit onto it or it is obtained automatically via shuttles.

Are there some kind of "events" planned? For example the crew finds some derelict spaceship which gives some technology. Or some people get buried in a collapsed tunnel and the player has to "sacrifice" some resources to dig them up? This would go along with the roguelike nature. And the events could have different skill based or random outcomes. So they could also find some valueable resources in the tunnel. Or the "strength" of a certain skill decides the outcome. When there are 30 miners aboard with a mining strength of 3.2 each the result is 96 and the tunnel collapses. If it were 100 or above by more miners or a better mining strength (research, perks) the resources could be aquired. But this is probably hard to balance. So there should be at least a hint to the player how save a certain operation is.

Regarding the ground units: It seems that you assign one role/class to a single unit. I would find it more interesting if you would call it an "expedition" and the player could assemble, upgrade and reinforce different units. For example he could have a mining expedition with 30 miners, 3 vehicles and 20 soldiers for defense. Those could mine a certain amount of resources per time. If the player has the resources he could built 2 more vehicles which allows to mine more materials. And he also could upgrade the drills to allow for more resources and/or harder to reach resources. And he could research defense turrets so he could use less soldiers and more miners. Or he could put some prospectors on it to find more resources. Those expeditions must not be fixed units but could just be templates or blueprints the player could define. So he could create another of these "mining expeditions" on another planet.

I also tried procedural planet generation some years ago. What shape is your sphere based on? How do you avoid singularities at the poles?
Are you aware that the craters in your last post look odd when they overlap? There is a straight line as "border" between two craters when they overlap. Usually craters are created one AFTER the other so the wall of the old one is "overwritten" by the new one and you only see the the unaffected part of the old crater. Just have a look at some images from the moon surface.

Anyway. Pretty nice and interesting project. I wish you good luck with it and I'm looking foward to new devlogs.

 

Hi exiguous,

Well, that's a fairly substantial comment there, I only hope I can provide a reply that'll do it justice--

I was not aware of XO, but upon investigation I can see some overlaps in theme I'd say that game is a purer rogue-like than I had in mind, I'm leaning more towards Homeworld-esque atmospherics and real time exploration/combat as the hooks. I had originally pictured a completely procedural universe, but I think in recent months I'm leaning more towards hand-crafted solar systems and a bit more story, because the danger is that every world ends up bland and uninteresting without a personal touch...

At the moment, I quite like the idea of a more dark souls vibe (if that comparison is remotely valid), where at the beginning you choose a warp direction away from Earth which selects a 'chapter' of sorts, with prescribed solar systems along that particular route offering a differing challenge that you're not necessarily expected to be able to overcome at the outset of the game-- and that something strange is happening to the fabric of spacetime such that when your fleet is destroyed you snap back to the moment that Earth is destroyed and get to choose another route or attempt the same one again, with certain artifacts or such allowing for permanent improvement of aspects of the fleet,aka soul upgrades. Just some thoughts I've been entertaining, it might not really fit. But the full story of what has/is happening could be uncovered by completing all of the individual chapters, with extra challenges like completing all chapters in one run or such. I like the idea of most of these solar systems being or having been recently populated too, so the first chapter could see the fleet limping through once human owned planets and colonies, filled with derelict vessels and half destroyed cities, with plenty of salvage available-- another could see the fleet travelling through the realm of alien species, with technology to be studied and adapted for use, etc.

Oh, I love the Expanse, I'd say the grim tone is a considerable influence here (though BSG remains my principle inspiration) and I definitely like the idea of inter-ship politics and leadership challenges and the like, perhaps some of that could be scripted with 'main characters' of some sort (think WC/SC?) but I think there could be a lot of reaction-based events such as you describe, where quick decisions made during tense moments can lead to problems with various groups. That kinda thing makes a lot of sense here, though from a game design perspective it probably means 'reputation' bars with certain factions or groups so you can actively see when you're a decision away from rebellion, and can take action to fix things up. I'm not sure I'm inclined towards random 'event popups' with some text and multiple choice responses, I'd prefer to keep it gameplay-centric if possible.

I'm happy to consider using any space-based phenomena I can think of, I've no particular need to limit it to planets, though Ideally it'll be POI that I can put an orbital navigation sphere around to remain consistent with the planet orbiting system, and I'm aware that makes asteroid belts a little trickier to incorporate. They might require a more traditional 2D navigation structure, with part of the belt in that plane. That, or have a larger rock as the orbital focus and 'less interesting' rocks sweeping away in either direction as a visual effect. Moons can work too, but I still need to decide whether I'm going to be using floating origin or not (moving current camera target to the origin) or using fake distances between stellar objects, which could end up influencing whether moons become a burden to maintaining enough distance between planets. I definitely want to do planets with inhospitable climates, you're supposed to feel that the universe is out to put you down at any opportunity it gets. Research is my intention, with individual trees for each category of technology once physically discovered (or starting the game with, think X-com coupled with talent trees), so it seems highly likely that's where you'd develop the means to survive better on such worlds.

As per shuttles, the current thinking was that the 'capital ships' generally have docking bays with a variable number of (unfuelled) 'shuttles' that automatically go about moving items around depending on each ships import/export requirements. The intention was to be able to flag each item on each ship as being available to export or to retain current stock levels, and that shuttling between ships should occur automatically when that ship is within a required distance. I was thinking of something akin to the Settlers, where the 'workers' automatically distribute goods to the required places with connected to a city hub/warehouse. I appreciate this sounds a bit fussy, and that's why I made the fleet inventory window as well, but I too am aware that separate ship inventories have the potential to be more trouble than they're worth. Something for the playtesting phase, I guess

To be fair, units in real time strategy games always have their own UI of sorts, it's just usually made up of attack/move/follow type orders, so I'm not necessarily going that far from the mold. I guess I think of each ship type as being a bit like a 'class' in an RPG, with their own flavour and abilities based on what components the ship has, with each ship upgrade-able and such. There was an old Team 17 game called Cannon Fodder where your soldiers would rank up after every mission and you'd desperately want them to survive once they ranked up because they got increased fire rate and range-- I guess I'd like to encourage some of that degree of familiarity, where the loss of a ship you've been keeping alive for a long time and has got you through so many scrapes is something you really notice ?

I've been internally referring to ground excursions as expeditions already But yes, I admit that the design is a bit loose where ground units are concerned so far-- it's a pretty vital part of the overall game structure so I think I'll need to try out a number of different approaches. I'm torn between something like what you describe and something a little more 'heroes of might and magic' inspired, with 'hero characters' encapsulating an expeditionary force of varying composition.... but the vehicle aspect is tricky because my current thinking was that one unit model would represent the entire expedition (similar to Heroes), but it's possible that thinking is in error and that I should be comfortable letting everything split as required. The only issue with that is having to deal with representing non-vehicled units if workers can be split from the vehicles themselves-- I'm not convinced that little human models are going to look right :d

As for the sphere mesh of choice, I went with the trusty cube-sphere, so I don't believe I have polar singularities per se? I have some uneven quad sizes due to the stretching of the cube faces, but I'm not sure that's much of a problem at large vertex resolutions. Haha, in truth I quickly moved on from the crater work once I realised I could use voronoi cells for the biome organisation, but I hadn't actually noticed what you elude to! Achieving a realistic look would be tricky, I think KSP just kept the craters further apart to avoid the hassle. I'm sure it could be done when I next look at it

Thanks for the comments and interest!

 

I see, we have both almost played the same games .
Thanks for the explanations of how you plan the systems to work. I think it's natural for such a complex game that many things must be tried out and cannot be designed right from the beginning. And there is always competing "inspiration" from other games which do things differently. In the end the mix of concepts and mechanics must feel consistent.

As for the sphere. How do you texture the cube? Do you have one rectangular texture for it (basically lat/long texture) or is split into the quads of the underlying cube (some cubemap format)?

 

I often try to remind myself that complex systems are rarely ideal-- the makers of FTL originally wanted to have fleets of ships with complex internal systems that needed to be repaired and such, but I doubt that version of the game would have been the success they ended up with by simplifying everything. And on paper I should love Stellaris, but I find it rather over-complicated, and a daunting prospect to truly get in to...

Ah, yes, the texturing, well, that's a whole different story as I suspect you're aware

Disclaimer: what you see above is just using vertex colours. I did try creating UV's for the entire sphere through trig functions, but it always ended up with a strange distortion at where I imagine the seam would be, and I never really figured out how to improve upon it. Plus I guess such a method would lead to issues at the poles anyhow. I definitely think some custom cube map, as you put it, would be the way forward. I can map UV's to the six faces already, but I'm not making further use of that so far, because it'll depend on how exactly I implement some kind of virtual texturing system, and I think I've got a lot of research to do before I'm ready to tackle that one. (Or i wait for unity's virtual texturing solution to support urp; or I switch to hdrp and gain the use of decals and virtual texturing...)

What conclusions did you come to with your own experimentation with proc gen spheres?

 

I better leave it be . My issue was how to map the points on the sphere (3d space) to the uv coordinates of a more complicated (non lat/long) setup. In case of a "cubemap" where each cubeface is mapped to a quadratic part of the texture the mapping is not so easy any more like with lat long. And I wanted to do it in both directions. I thought about calculating the mapping once and then use the float values in a texture as coordinates in 3d space as kind of a lookup table.
Then there were some assets in the store, namely Etherea by imerso and Planetary Terrain by Henry V. So I decided to use them instead of rolling my own stuff (but it was an interesting learning experience). Unfortunately in the meantime both assets are not supported any more. Now there is a planets extension for Space Graphics Toolkit by Carlos Wilkes but I have not tried it yet.

Did you double the vertices at the seam? You need one with uv.x 0 and one with uv.x 1 at the same position to avoid seeing the entire texture in a small strip which is mapped from uv.x 0.99 back to zero. It's hard to explain. Let me know if I should put more effort in it . Or if you understand what I mean already.
Some other points to consider with a sphere is how the 3d noise is generated to "wrap around" but it looks like you already have this sorted out. And for lighting the tangents are important which is also not trivial AFAIK.

 

Well, the best I can offer here in terms of discussion is to highlight how other games have achieved the planetary results they were aiming for, and I imagine we all want something a little different from our procedural planets so the guidance can only really be a starting point for conversation (which I'm happy to encourage )

http://www.cs.cmu.edu/~ajw/s2007/0251-SphericalWorlds.pdf
Here's a general outline of how Spore achieved their planetary generation, whereby they intended to use a generated heightmap built from 'brushes' (basically decals, afaik) that is 'painted' onto the planet at design time. Nullpointer (http://www.nullpointer.co.uk/content/procedural-planets/) has a Unity-based run-through of how they probably achieved this effect in practice, but I presume camera.rendertocubemap would serve a similar purpose?

http://mavorsrants.blogspot.com/2013/02/planetary-annihilation-engine.html
This is a great read from Mavor about the technical details of the system used for PA, who (from other posts that I've read on their forums) also derived from a quad sphere, albeit broken down further into separate plates with a closed geometry. He talks mostly about his use of CSG, but I suspect that texturing is also achieved through a decal-like system not too dissimilar from that used by the Spore developers. My evidence for this is the link posted by one of their developers on the PA forum: http://acko.net/blog/making-worlds-1-of-spheres-and-cubes/ , which is a pretty fantastic read in its own right.

I'm pretty sure that I want a decal-based projection system too, with the exception that I want to create positioned texture detailing rather than a height map (though that could be interesting too). My train of thought is: 'brushes' will be placed depending on the biome centres (the voronoi features have coordinates in world space), and a texture mapping produced through the perspective method which aligns to the six faces of the underlying cube. I'm not sure I need to know how a position on the sphere maps to a position on the cube directly, but would some kind of ray cast work? Pretty sure I've heard of a method where a modeled sphere with UV's can be used as a template for the UV's of a procedural mesh by casting rays towards an origin through both meshes and copying the UV's between the two, but I admit I'm not entirely clear on the exact implementation. Apologies if I've crossed several tangents in my attempt to connect the dots here

As for the spherical UV mapping, I don't see it panning out regardless, but each of my cube meshes are separate with distinct vertices at each edge, so I figure that means I do have doubled up vertices along the seams, but the fact that each mesh is distinct possibly introduces other considerations that I may have missed.

 

Do you mean "cube map" instead of "cube"? I refer to the texture map and how to convert it to 3d positions and vice versa.

Do you aim for a "fix" mesh for the entire planet or do you need some dynamic level of detail, which increases resolution of quads you approach? And how often do this "raycasting" need to happen?

This is what I meant with

A possible use case for 3d coordinates to map (texture) coordinates would be for example to flatten the heightmap at a certain position the player wants to construct a building. Or display a map of the planet with POI's on it. And you could also calculate the (player)height from the heightmap itself rather than raycasting which could be more expensive.
But as I said. With cubemaps that got too complicated for me and I "gave up".

Also note, that the example cubemap textures in the Spore document waste half of the texture space by layouting the faces in an "unwrapped" manner. I had them packed together to have no emtpy space in the texture. But this made mapping even more complicated.

What I want to say with this: There are many approaches, many ideas and inspirations and many time to sink in. My advise is you should not get lost in the planet generation and make some gameplay too. Otherwise you have beautiful planets after 1 or 2 years but still no game. It's an interesting topic from an academic standpoint. But it's also not THAT much important to the player in the end. But on the other hand as you said you also need the planets for example for pathfinding. So it would be good to have this in place already. Seems like a dilemma to me .

I did not know that resource yet. Thanks.
Most people seem to use cube based spheres. Spheres based on Icosaeder or Octaeder also have some advantages (and disadvantages, obviously).

Do you mean "cube faces" instead of "cube meshes"? Or do you have a separate mesh (with it's own texture) for each face?

Anyway. I don't want to "molest" you or steal your time. I find procedural planet generation an interesting topic. But I also understand when you "have better things to do" or want to keep your secrets . Or we could continue in a private conversation to don't "derail" the thread too much.

 

Hey again

Yeah, I think I may have misinterpreted your specific requirements a little (well, from back when you had them, I presume you're not planning on going back to it?), and it's quite possible I'm using cube/cube map and mesh/face interchangeably more than I should be! My implementation uses six separate meshes, one for each face of a cube, and each point projected outwards on a unit circle before being multiplied by the required radius/height. Only using a single shared material at present, using a barebones vertex shader, though this will have to change once textures are added in. I think in my mind I'm drawn to solutions that would avoid what I think you were trying to do-- like modifying the vertices of the mesh directly and having the shader work out what should be shown at the new elevation. Decal brushes could also be used to flatten a particular area if we presume that the height map that is generated from the brushes is capable of being refreshed at runtime. A POI map would depend on the way you wanted the map to be displayed (presumably we don't want it to look like an unfolded dice) but I figure 'placed' items could project some unique identifier (a colour perhaps?) onto a map much akin to the way the height map is made from brush decals, then you have two such maps that you could just multiply each point together or some such. Of course, I'm talking about things I haven't tried out-- I'm sure there are tons of more specific issues involved here

Anyhow, I had originally planned just to get the biomes working and the nav mesh, then get it ported over to the main project (and not get lost in the abyss that is proc gen, as you say!), but I think this conversation has helped me realise that I could prototype some basic texturing before I move on to other things, so thanks for the chance to talk it through

It might be interesting to talk later once I've actually got a bit further with my own model, because otherwise I'm just offering untested ideas, and I prefer to talk from experience where possible

 

If I would get into procedural planet generation again I probably would start over. My old project is 7 years or so old and Unity has changed much. But since this is lots of work I think I would more likely try out the ready Assets I have and see if I can modify them.
Currently I try my luck with ECS and see if I can get a prototype of a space game together. Detailed planets are not so important for me so I will leave this topic for later (when probably more tools/resources are available).

I'm not too familiar with such shaders. But when the geometry is only in the shader how can you for example perform pathfinding on it? I refer to things like slopes, terrain types (swamp, sea, lava), obstacles like rocks etc. . Or do you have another representation of that data specifically for pathfinding?

Sure. But I'm by no means an expert. More an interested layman. And I'm glad our discussion made you aware of some things to consider.
So I'm looking forward to new infos and videos. Your project is a source of inspiration for me .

 

Hi again,

I probably should have better documented the challenges of the last six weeks, but suffice to say I feel like some of the tougher aspects of the planned FE framework might be behind me now! In short: I now have height mapped planets based on procedural voronoi cells, and a four colour splat mapping implementation that places the relevant brushes around the planet based on the biome generated. And perhaps even better (for me), I now have planet-wide pathfinding working, using a fairly optimised A* algorithm, which can build a navigation grid for each of the movement types (ground, sea and air).

So, where to begin! After the last discussions posted here I was keen to try out the rendertocubemap method, which I originally thought to implement through a rendertexture, generally just imitating games like Spore in their planetary texturing efforts. It turns out that cube maps in shader graph force the use of environment mapping (if that's the right term?) so the captured maps were behaving as if they were reflections, and it took me far too long to realise that you can get around this by feeding the normal vector into the view direction, so that didn't bode well...

I then built a grid of brushes at unit distance from the central camera which could be informed by the generated biome data at the same positions (this may seem like overkill, but it works well enough). I actually do this twice, in a sense, generating a height map by placing brushes on ocean positions with the edges leading to a more natural looking coast line. The second iteration then places RGB coloured brushes based on the biome regions themselves, and I nudge the brushes forward or backward to help provide more variation. The shader also has detail mapping, and the whole texturing process can redraw the planet based on new data in a few seconds. Real time updating is unlikely, and perhaps not even desired, but the option for some change in planet surface conditions is definitely possible.

Ok, so in the meantime, I also had to deal with the way cube maps are generated through rendertocubemap. I actually moved away from using a rendertexture and just saved a cube map instead, which is a little slower but allows me to easily save the maps for each planet independently rather than risk overwriting the wrong planet once we move to generating multiple planets in sequence. I found what I thought was the correct cube mapping orientation (horizontal cross), and redesigned my planet mesh generation to accommodate this layout (with the needs of the nav mesh in mind too)... but this ended up being a serious headache... textured faces were being drawn all over the place in all sorts of orientations. It turns out that Unity was defaulting to the environment mapping orientation (which you might think I'd have suspected after seeing how it behaved in the shader), but I only worked this out through days of investigation :\

But I finally got this figured out, and had every mesh oriented sensibly, and also accounted for as much of the distortion in the mesh as I could, with the result of all this faffing about displayed below (going from the rough layout using vertex colours to show each biome, to the final textured planet)







Alongside this, I was also building the planetary navigation system, which uses a navigation grid paired with an A* implementation. The challenge here was to work out how to find the 8 nearest neighbours for each node on the planet (which corresponds to the underlying mesh collider for each face mesh). Since each of the 6 faces has its own mesh, that meant working out the relevant calculations at each face edge, and ideally making this generalised so that I can freely change the resolution as required (though it needs to match the vertex arrangement of the mesh). Finding the vertex clicked through a raycast isn't too difficult, with the (non-unique) vertex number fed back from the hit (but no information of which face in particular was selected: tags to the rescue!). This can be mapped to an array of unique nodes, with the node data filled in during planet generation, with elevation providing which points are on continents and which are below the sea, which then informs the relevant navigation grid for ground, sea or air units. With the nearest neighbour calculations figured out (lots of paper) I went on to implement the pathfinding algorithm itself, optimising the open set with a binary heap, and hoping it was all going to work out as intended





And as this lovely debug line suggests, it does! Calculation time is between 5ms and 150ms depending on distance, which is pretty decent considering I'm working with nearly 400k nodes per planet at present (as stated earlier, ideally the navigation grid matches the collision mesh which itself is a copy of the mesh data, so lowering resolution risks less planet detail at larger radii). The game isn't really focused on lots of units, so I figure this should be fine. I've also implemented a region system, whereby the planet is carved up into arbitrary sections with nodes assigned to a region. I can then easily find out which regions are used by a generated path, which means I could work towards a flow field solution using only those regions-- but I'm not convinced that it would be something I really need (might be useful for bigger groups of things like fighter craft though?)

As a side note, I also managed to implement an intersection shader for the ocean so that I get a different colour around the coastline. It turns out this is pretty tricky to pull off on a sphere using a depth texture; took about ten different attempts both in and out of shader graph before I got something I'm mostly happy with.

Also, I've made a start on the ground features system: this allows for the placement of gameobjects on the planet surface, which then automatically update the relevant navigation grids with inaccessibility flags and such. I want to gravitate towards a brush-like procedural system here, with trees, mountains, points of interest, etc placed in groups depending on the biomes and such. A current issue is flagging all of the nodes covered by the placed object, since nodes themselves are not gameobjects so I can't just use collider/physics methods to find all the occluded points...

Anyhow, I'll shush now, thanks for taking the time to read Looking forward to getting units moving around planets and building things!

 

Hi again,

Nearing six months into this potentially gargantuan project; a lot has been individually prototyped by this point, and it was time to bring most of it together into one cohesive structure before moving forward. This past month has seen the development of the front-end, with the workflow of creation via the planet editor allowing for planets to be serialized, inserted into solar systems, and then further incorporated into 'scenarios' (which describe the settings of that particular game). I did struggle with the seemingly bizarre implementation of toggle controls and with providing unique filenames (I originally made the mistake of just saving everything with planet or system names, oops), but I now have a fairly snazzy load/save dialog that allows for effortless organisation of the potentially vast amounts of planets and systems we can eventually have.

​

I then decided to rework my existing planetary generation code to work asynchronously (just via co-routines at this point). Prior to this I was seeing 5-10 second freezes whilst the planets were generated, which is relatively fine whilst in the planet editor (but not really), but certainly wasn't ideal for the game itself. At first I was intending to go with a regular static loading screen whilst planets in the current system were generated from the raw settings, but with everything generating smoothly (except for the slightly stutter during collision mesh allocation, I still need to multi-thread that, or at the very least reduce the complexity) I figured I might as well make something more interactive, and I landed on the idea of using a warp conduit to show your fleet en route to the system, allowing for interaction with the ships and other management panels in a kind of 'staging area' ahead of arrival. This was my first real exposure to Unity's visual effect graph (I had no idea it was gpu-based, I've been using particles for everything all this time!) Possibly bears some small resemblance to the star wars hyperspace effect -.-

​

My next tasks are to get the 'solar system editor' scene in to development, which allows for the created planets to be placed relative to one-another. This will allow system-wide ship movement to be implemented based on the required connections between planets (a bit like a game board of sorts, I don't want ships to be free to move around the solar system entirely freely, I don't think that works for the strategy part of the game...). System-wide travel will be a bit of a deception, since all planets will be/are computed and rendered at the unity origin -- they're just placed on to different layers. Ships will be added to the relevant layers as they near another planet, so there's just a bit of initialization needed to work out what directions each planet is supposed to be from one-another and construct that illusion alongside the camera system and skybox (and probably some warp-like effect encircling ships moving between planets).

I should probably also add some other planet generation templates such as rocky and gas types, though I don't imagine they'll be as tricky as the Earth-like planet generation was. I've left the ground-based development alone for a while, I'd like to get the solar system/fleet movement stuff sorted before I get stuck into unit movement and building construction.

Thanks for reading

 

Hi again,

To begin with, I recently 'celebrated' reaching six months of development by putting together a video that summarizes the progress made so far if anyone would appreciate a whistle-stop catch up:

In more recent progress, I've got a much larger chunk of the solar system creation process in place: from adding and customising planets in the planet editor scene, through to placing these planets and the associated star in the solar system editor scene. Saved as part of a scenario, these systems can be loaded, and planets will be generated and placed relative to one-another as per the created solar system map.

​

Note that I'm using the full version of MK Glow for all my star post-processing needs, which I figured provided a more exhaustive selection of effects than I was reasonably prepared to develop independently (and the glare is pretty awesome).

I finally added a second planet type (at a very early stage of development) in the form of the 'rocky' variant (yes, yes, I know earth-like planets are rocky planets, shhhh). This gave me the opportunity to finally play around with the voronoi cell based craters, which places quad-based brushes over the cell centres, with these brushes contributing to a cubemap-based height map which deforms the base mesh. This was when I learnt that sampling a cubemap via script doesn't sample through a vector sampling (as it does in a shader) because the craters were stretching quite visibly... I put together my own vector sampler, but it wasn't playing nicely with my cubemap arrangement for some reason, so I ended up just mapping to a manually adjusted animation curve graph to virtually eliminate the stretching..

​

It may be apparent from the first image that I also incorporated a lightweight Rayleigh/Mei scattering model for the planet atmospheres that works pretty well. It's pretty much stitched together from a number of ideas presented online, and it still needs some adjustment, but it's a lot better looking than the previous solution.

With solar systems now emerging in a more coherent fashion, I'm about to begin work on the fleet movement system, so that ships can move between planets and enter orbits as they near the planets themselves. This will be the first real test of the planet 'bubble' system-- each planet sits at the origin with the system generated around it as required. Time will tell how seamlessly I can move ships from one bubble to another without the player noticing!

Thanks for reading

​

 

Hi again,

Despite the festive period, I did manage to get a fair bit of work done on the solar system-wide fleet movement mechanics. A lot of that is framework stuff that isn't too exciting to talk about (managers, controllers, managers for managers, you get the idea...), but the two notable additions since my last post here include a spline-based node-to-node pathing system and the accompanying system map which features seamless zooming from the detailed planet view level all the way out to the current system overview.

Tactical map view: AKA "That Homeworld zooming out thing"

​

So the map view actually started life as a simple 2D representation of the in-game solar system editor layout, with icons positioned over objects that could be clicked on and so forth. It worked okay, and I spent some time trying to design suitable icons for planets and ships and such, but it seemed cluttered, and I couldn't help but worry that this view was probably going to the most commonly used way to keep track of everything and it really didn't fit as well with the planet view as I'd have liked.

But that's okay, I've got time to go down a few wrong roads if it leads to better design decisions. And a Homeworld-esque map display is definitely working better. There are quite a few tricks involved in getting this effect to look right-- it would be easy if everything could just be placed relative to each other even at large distances but that would lead to floating point issues (and floating origin doesn't really work so well for rts games). So despite appearances, the system map is actually a tiny scaled down representation at the Unity origin, much smaller than one of the normal sized planets, and cameras are paired such that the view direction of the normal sized planet matches the tiny low poly version when required, and then we switch between the cameras when zooming in or out (with zooming in ironically resulting in zooming out, and vice versa). It's virtually seamless, doesn't require alternate models/icons for everything, and 3D objects (such as ships) can be effortlessly represented exactly where they should be. Personally, I think that's the tactical display we always need!

​

Spline based ship movement

You may have noticed the strange lightsaber-like things hanging around the planets in the images above: these are the current 'debug' visualizations of the paths that ships will be able to take to move from planet to planet and to all other points of interest in the system (including moons). I don't believe that total freedom amounts to a decent strategy game, so my vision of a space strategy title includes the kind of choke points that are easy to incorporate when you're fighting amongst mountains, trees and buildings and the like. Space lacks any of these natural obstructions, so I'm arguing that ships would generally always travel in straight lines from point to point, and move in the orbital sphere when near a planet that they intend to interact with in some manner (sending units and supplies down, receiving resources, attacking installations, defending ground units, etc).

With this posited, I can build a node network between planets, moons, etc, that can inform a system-wide path-finding system for space vessels, and using splines makes sense since we can draw a path (linear or curved) for each ship that follows each of the paths provided by the path-finding system whenever a move/attack order is given. Not only that but ships can have an offset to the direction of the spline, can animate independently of heading, and things like evasive maneuvers can be achieved through manipulation of the local spline path itself.

In order to reach this lofty goal, however, I started by introducing the placement of these 'space lanes' into the solar system editor, including branching points which allow for some intricate design of routes between nodes/objects.

​

Going forward I'll be dealing with the final obstacles to a full system-wide movement system: connecting to planetary orbits and moving in spline-guided great circles around the orbital layer (I have a non-spline system already, but it makes sense to switch over completely to splines at this point).

As always, thanks for reading, and stay safe

 

Hi again

Finally moving on from shaping out the procedural world-building and system-building tools, I've since been developing the necessary framework to support the movement of the players' fleets and ground units around and atop of these numerous planets. It's certainly fair to say that my primary inspiration has been Homeworld throughout, but there's more than a touch of Sins of a Solar Empire in here too, with a system explorer that helps the player keep track of their units, and the star lanes between planet hubs.

​

Modular units

Ships belonging to your fledgling fleet in Fragile Existence are a somewhat more personal affair, with designations, Hero-style captains (who can gain experience and new abilities, etc) and their own crew complement and storage capacity. Beyond this, the functions of a unit are completely dependent on the individual modules added to it, which visually slot into the overall structure shape (picture the structure like the chassis/frame of a car before anything else is added to it) and provide the unit with specific actions to perform or tasks for the crew to undertake, where the obvious example is the engine room which provides the movement action to a vessel, and the weapons deck which manages weapon targeting and firing.

Modules need crew to function, operating at a limited capacity when sufficient crew aren't available, or when the module itself is damaged (modules can be targeted by enemy units, and you can similarly target their modules to try to disable certain functions you find the most threatening..) Furthermore, modules can be assigned tasks or production items, featuring their own action queues which can be paused and continued as the module allows, using resources to upgrade components and provide additional capabilities.

I like to think of units in FE a little like cities in Civilisation VI, where the total population ultimately enables additional possibilities, and each specialised module is a little like the districts, in that you can only have as many modules as there is space within the hull structure, so the strategy can come from making choices about what your fleet needs to survive, and balancing external action abilities against more passive options as the situation allows. The key difference, of course, is that resources aren't auto generated from nearby land tiles, but have to be actively gathered from planets by sending your 'troops' out to gather them. Ground units and even ground bases function in a similar way, with modules added to outposts representing additional buildings that visually extend outwards from the central hub, with production buildings functioning somewhat like those in the Settlers, combining base resources at a certain rate to make more useful items, which eventually lead to replacement parts for the fleet, ammunition and enough fuel to even make the next warp jump..

​

Establishing the fundamentals of an RTS

So I recently had a great excuse to replay some of my favorite RTS games, but it was just for research purposes, honest... Having added orbital movement to the game, the next stage was to supplement this movement with all of the trimmings expected of a modern RTS these days. So in went group selection, implemented by a distance check of all units under the box region, and discarding those on the opposite side of the planet. Eventually I'll need to allow for easy distinguishing of space or ground selections, but that's easy enough, and it works pretty well so far.

Another thing that seemed sorely needed was orbital waypoint highlighting. This is shown in the image above, with descending waypoint targets showing the point on the planet surface relative to the orbital position above. Arcs are drawn between waypoints to show the route that the ship will take to move from point to point, and unlimited actions can be queued up (through the ships' engine room in this case).

Taking a leaf from Sins of a Solar Empire, the aforementioned system inspector (top left) lists each of the currently discovered planets in the system (planets aren't discovered until you've sent a ship or scout to investigate it). Units are then categorised by the planet they are present at, with notifications alerting the players' attention to any unit that needs attention, and easy camera shifting achieved through selection of the relevant unit or planet in the list itself.

​

Ships also display their 'organisation' allegiance, which represents a kind of preordained grouping of units into logical organisational units. This replaces the usual number grouping found in RTS titles, so fleets can be assembled into squads that can automatically follow and support a 'lead' unit, or serve as a 'home' location if they encounter trouble whilst separated. Such groupings can also automatically pool resources, and offer certain potential for future modding purposes (so W40K fans could have all their tech-savvy units be part of the Adeptus Mechanicus...) For the purposes of the plot, the default organisations represent whatever nationalities or company's a particular ship was aligned to prior to the invasion of Earth and subsequent exodus of the fleet. Getting these 'sub-factions' to work together will be part of the ongoing story.

And this almost sounds like an afterthought putting this here, but ground units are now using the long ago developed A* pathfinding to move around on the continents of the planet surface beneath the orbital sphere (and boats will work just fine on water too when I bother to add that).

​

Oh, and there have been a few visual upgrades and tweaks along the way too.

Going forward I'll be implementing ground resources, allowing construction units to build ground outposts, and getting these outposts churning out more refined goods from these base resources to realllly get into the game play cycle of FE. I'm also due to finish off ship movement from planet to planet, since that's a pretty core component of the game, but it felt like a good idea to get orbital movement working well before branching out further than that.

Thanks for reading, any suggestions always welcome

 

Hi again,

So lately I've been fleshing out some of the core gameplay components, chief of which is the Hero-like character-driven skill system that provides starships and units with their functionality.

​

Character Profile

Starships carry the remnants of humanity in the form of 'passengers' and 'crew', where passengers generally act as the everyday workers, mining, farming, fabricating, soldiering and the like; whilst the crew are those trained to perform more specialist roles such as research, engineering and officer duties.

Overseeing this civilian population is the player-assigned 'hero' characters, that fill the 'captain' and senior officer slots (think chief engineer, tactical officer, chief medical officer, etc, hi Star Trek!). Once assigned to a position, leader characters can select from a bank of skills - spending Skill Points (SP) which are gained at the end of each day cycle (a day in game will be around 10 minutes real time), and through certain types of planet-based scavenging. SP is a pooled resource, so you'll have to make decisions based on the current needs of the fleet, dividing it up among your leaders.

Skills forms the backbone of everything that your fleet is capable of. No skills, no possibilities. The engine room holds the Cascade Core (think Warp Drive) but your ship can't move anywhere until an engineer character with the necessary training is placed in that department. Want to use evasive maneuvers? You'll need a pilot character with the relevant skill equipped at the helm in the bridge room. The rooms (and technology within) ultimately provide the means, but the characters make it all possible.

​

Skill categories

There are seven broad categories of skills: Command, Engineering, Construction, Science, Medicine, Aviation and Warfare, which map to the seven specialisations that both your leader characters and your crew can take on. Certain ship/unit modules possess an inherent specialisation, so the bridge houses command crew, the engine room supports engineers, the flight deck raises aviators and so forth. Matching that specialisation to the leader based in that department proffers extra bonuses.

Skills themselves come in a range of types, with Action skills mapping to the more traditional actions seen in RTS games, such as assigning movement waypoints, targeting enemy starships, directing a scan at something, etc. Blueprint skills provide the information to build new structures or units, modification skills add new features to existing modules, and enhancements allow for these modifications to be adapted to specific needs.

Other types of skills require an understanding of the task queue! Each module allows for tasks to be assigned based on the learnt skills of the leader character present there. As tasks are added, they are visually displayed in order of processing (much like a traditional 4X build queue), but certain skills can override this natural order, with Orders used to jump the queue (evacuate a department, go to battle stations, etc), whilst Projects sit at the end of the queue and use only the allocated resources until completion (with research being an easy example of a project). Finally, Abilities are the more general tasks that can be queued up, providing a temporary buff or negating some other effect (evasive maneuvers, provide first aid, fortify position, etc).

​

Crew and Power as resources

In order to make use of leader skills in a module, crew need to be trained up in that department. Tasks queued up generally require crew to be allocated whilst active, with crew assigned to blueprint fabrication, modification installation and projects often allocated for a great period of time. The number of available crew can thus be considered a resource of sorts, with more elaborate tasks only possible once enough crew have been trained in a department. You might then think-- well, I'll just train everybody! Welllll, maybe don't, because then you won't have enough basic workers to mine and refine things on the planet surface, and produce things like fuel and ammo, food and building materials. Striking the right balance between available workers and trained crew is part of your responsibility as the fleet commander.

Another resource will be that of power. Power is produced in the core of a starship (and generators on the surface), providing a fixed output of power that you can allocate, FTL-style, to each module on the ship. Un-powered modules can't do much of anything! Modifications installed in a module also draw power, and can be individually turned on or off, so you can tactically choose which modifications will be active at a given time depending on your needs.

Okay, that's probably a lot to take in already, I'll leave it there The video form of these development diaries probably makes things a little clearer, so please take a look if you're interested in learning more, and I'd be happy to accommodate any queries or requests if you have any of those to share too.

Thanks for reading!

​

 

Hey Lee,
good to see you make good progress.
I like the character art alot. Have you done it yourself or do you use a package for it? Or do you have an artist at hand?

 

Hey again Exi,

I had the good sense not to inflict too much of my own artwork on the world and visited graphicriver to license a set of 40 sci-fi character portraits (and I'm hopeful the artist is reachable if I wanted more at some point). I'm not afraid to utilise assets where my own skills are lacking or it just makes 'time economic' sense-- my spline-based ship movement is all built on the excellent CurvySplines asset for example.

How fares the descent into the world of ECS/DOTS?

 

That's nothing to be ashamed of . Programmer art is usually not what people want to see. So it's perfectly fine to reach out to artists who know what they do. Nobody can master all skills. And I also have purchased lots of assets over the years which I thought may be useful sometime.

I have put the project on halt for the moment. ECS is a great technology, but at the moment too unfinished for my taste. Especially the documentation lacks alot and one is supposed to reverse engineer "outdated" example projects to study how things work. And many things are not implemented at all yet (especially UI is missing for me).
And the "responsiveness" to questions is not great either yet as there are only few people with experience active in the forums.
But I keep eyes open, read the forum and articles and try to learn as much as I can in the meantime. When things have matured a bit I will try a new run. But currently it appears to me more like a prototype than a useable (and user friendly) product.

So keep up your journey. Your Blogposts inspire me alot. And don't forget to have fun .

 

Haha, just weighing up the pro's and con's of moving the project up to 2020 LTS when it arrives (soonish?) is stressful enough, I don't think I'm ready to factor in an entirely different paradigm as well :d Rumor has it that Dyson Sphere Project is using some kind of ECS to pull off the impressive number of well, entities, it seems to make use of without slowing down at all, but I don't know whether they actually used Unity's own implementation or not (or if that's even remotely true)...

Thanks for checking in, though, still a long way to go (for us both, perhaps?)

 

Hi again,

This update is largely to celebrate the introduction of interplanetary travel between planets, which I realise doesn't sound too exotic when I put it like that, but is nonetheless a truly fundamental aspect of a game set across multiple solar systems!

​

One of the biggest stumbling blocks for many a space game developer is dealing with large distances and replicating the sense of scale proffered by something so vast as space. More than just a mere game design consideration, off the shelf game engines aren't particularly well suited to dealing with objects placed so far apart, so you generally have to find a way to compromise and/or conceal some fancy tricks to pull it off. A common solution is the so-called 'floating origin' where you essentially move the world in the opposite direction to that of the player entity instead of the player themselves, which is afaik used in games like Kerbal Space Program.

Floating origin is somewhat harder to adapt for a strategy game that allows the player to focus on multiple 'player' entities (though certainly not impossible), and my solution was to instead place the surrounding region of space around each planet into its own 'celestial bubble'. These bubbles of space exist on top of one-another at the Unity origin point, and we essentially only render the objects on the relevant layer whilst calculating everything that is happening everywhere in the solar system regardless of whether it is being rendered or not. In practice, this works fine, though there is a hard limit on the number of 'bubbles' that can be maintained in this manner, but there was a lot of groundwork that needed to be put in place before we could approach something akin to seamless transitions between planet-centered layers.

​

With most of this work now done, I started to double down on the 'hud' indicators which show relevant information about player ships/units and celestial objects in the solar system. There are actually four separate layers in use now, two for static celestial objects in the layer and map views, and similarly for player entities, which can each have their own configuration and display information depending on the distances to other entities, etc.

​

Another essential component of this update was the expanded focus cam controls, with everything in the solar system capable of being a 'focus' target which locks the freely rotating and zooming camera onto a point which can be used to zoom to and from the solar system map as required. Hopping from entities to planets is as easy as double-clicking a target object, and the system automatically calculates the correct orbit and zoom radii based on the object focused. I feel this degree of camera movement (coupled with the hud-style indicators) is crucial for being able to quickly keep track of player entities across the entire system.

​

This update also sees the evolution of the spline-based ship movement tech to include the calculation of orbital entry and departure curves depending on insertion direction, offset from the central 'space lane' thread (which will be useful for programming formations) and current position on a particular orbital sphere. There's probably a very good reason that space games generally stay well away from having units moving on a sphere, but until I figure what that reason is I'll keep believing it can work

On top of this a solar system-wide pathfinding algorithm can calculate the shortest route between planets when such a route is requested by a ship, and splines are calculated to path around subsequent orbits along the interplanetary route as required automatically (and I choose to force ships to traverse directly between planets to avoid having battles in the middle of nowhere, and because I believe you need some form of bottlenecks to inject real strategy into proceedings).

​

I also reworked the warp conduit 'loading screen' so that the conduit is placed correctly (as directed by the solar system editor) and has some fancy distortion effects to boot. Going forward I'm probably going to be turning my attention back to the planet surfaces, adding obstacles, resources and the ability to build some simple bases to mine and refine and ship supplies back up to the ships waiting in orbit.

As ever, thanks for checking in

 

Hi again,

This update marks a real shift from focusing on core underlying technical hurdles that needed to be overcome in order to reach this point, as well as a much needed aesthetic overhaul for the UI, ship models and audio design. Key features introduced include the surface scanning mechanic and embark-able ground units which need to be deployed via support drop ships.

​

The visual overhaul

First off, I finally got around to removing those ugly un-textured (!) ship models I had been using as placeholders since the beginning of the project, replacing them shinier versions representing the Support Carrier class, which... err.. carries support units, and the Heavy Transporter class, which has a lot of inventory/cargo space to make use of, but not much in the way of offensive capacity. I've upgraded the engine nozzle effects to make use of some nicer HDR particle/trail FX and even added in sound effects for the engine 'idling', speed changes and some clever use of 'cinematic' sound FX to enhance the system loading/warp-in sequence.

​

One of the more time-consuming processes of the past month has been a rethinking of the entity user interface. I had originally tried to minimise screen space use to a rather extreme amount, but I began to realise that this wasn't a particularly smart approach to a strategy game. Information needs to be clearer and easy to get to, and tiny little numbers in the corner of the screen felt like a bad design choice. Lesson hopefully learnt.

Coupled with the new ship model imagery, I could now build a modular UI that allowed entity modules to be visually shown where they were located, and to introduce a sleeker futuristic design that kept things simple and adhered a little closer to the games that inspired it (i.e. Homeworld, let's be honest).

Gone is the strict character ability focus -- I've shifted the attention to installing components in each of the 'areas' (modules) aboard the ship/unit, with each component performing a specific role, such as the Ion Drive allowing orbital movement, the Sensor Array providing access to surface scans on the Command Deck, and the Docking Control facility allowing for a certain number of ships to be docked and maintained in the Docking Bay module. Components can have crew members assigned to them, with the number of crew assigned directly impacting the efficiency with which that skill/ability is performed. Furthermore, each component can register 'stats' with the parent ship/unit, such as Ion Acceleration or Scanning Range, with those registered stats modifiable by other components, leading to compound efficiency boosts through careful consideration of components chosen and crew allocated. Components take up valuable space and have power requirements, so you'll need to plan your loadout as the fleet evolves over time to make the most of these limitations (these volume and power requirements are themselves a stat which can be modified too!)

​

Scan for life signs, Harry

I had been delaying this one a bit because it meant I had to learn how to project images on to the surface of a sphere and for a long time I wasn't sure about the best way to proceed. Alas, this is now sorted, and the green glowing circle you can see in the image above is indicative of the type of surface scans you'll be able to perform on the planets you come across.

In this case, the Sensor Array on the Command Deck provides the functionality to scan for biological organisms on the ground below. This is a continual scan, internally performed as 'raycasts' in a cone downwards with a search radius equal to that displayed by the ring itself. Unlike traditional RTS where things that move close to your units are automatically discovered, the idea here is that you have to direct your scans to discover things, with the scan dimensions adjustable depending on your requirements. Components can also upgrade the scan rate and/or search radius; and having multiple ships scanning the same area of ground actually does make a difference -- you will increase your chances of pinging against an object!

Beyond organic search scans, there will also be technology-based scans and resource scans, with differing scan types requiring different unit-based components to perform.

​

Do you want to live forever ??

Up until now I had been simply pressing a key to place a ground unit on a planet surface, which worked great for debugging purposes, but obviously didn't represent the intended goals: a fleet that has to carry everything that they need from system to system. So as part of the UI revamp, I've also added 'slots' for ground units to occupy on board ships, and further slots for what I'm describing as 'support ships'.

Ground units (and support ships) take up valuable space on your ships, with the Support Carrier principally designed with this prerequisite in mind. The Docking Bay module allows units to be stored, with the Docking Control component providing 4 such spaces, as well as the means to repair and rearm vehicles upon their return. It also allows 2 support ships to be moored as well, which is handy since one of the support vehicles is a Dropship.

The drop ship does what the name suggests: it allows ground units to be deployed to a planet surface (and to bring them back up again, but I guess that could be considered optional depending on your play style..). The docking bay maintains an internal scheduling system that allocates support ships as they are requested (the player doesn't directly control support units), so if you only have 1 drop ship and 4 ground units docked, you'll need to wait for each unit to be carried down to the surface and return empty, get refueled and prepared for the next drop mission before taking down the next one.

Other support ships that will be introduced will be the Shuttle (for moving passengers and Leader characters from ship to ship), the Cargo Freighter (for moving cargo between ships in the fleet), the Repair Drone (which repairs external damage) and probably some kind of Scanning Drone which can do remote scanning sweeps.

​

Needless to say I'm pretty happy with how things are shaping up!

Always happy to hear any comments you may have (and suggestions for improvement)!

Thanks for dropping in

​

 

I may have neglected to post an update here for a little while, but Fragile Existence is still very much in development. In fact, there's finally a Reveal Trailer for you to check out, which I put together as an indie partner to the ongoing Gamescom 2021.

The game also now has a Steam store presence if you'd like to find out more: Fragile Existence on Steam (steampowered.com)

Thanks for dropping in

 

That trailer looks very professional. And you made huge steps with the game. Kudos. If you need a Beta tester count me in.

Edit: Would it be possible for you to provide a native Linux build?

 

Hey Lee,
it's been a while since your last post. Are you still working on the game? Would love to hear some life sign, news or what issues you encountered.
Regards.
Henry

 

Hi Henry,
I have been very remiss in posting development updates in threads such as these since the Gamescom reveal (mostly transitioned updates to discord), but FE is still in full-time development and going well! There is actually another trailer coming out soon, so I'll give this thread a nudge when that happens, and you can see for yourself how things have progressed

 

The new trailer for Fragile Existence is out, over on IGN's channel =)

Coupled with that, we can announce that we're all partnered up with Hooded Horse, the publisher of other eagerly-awaited games in the strategy genre such as Terra Invicta, Falling Frontier & Alliance of the Sacred Suns! This ultimately frees me up from all the other things involved with games development beyond the project itself, and I may even be expanding beyond it being a solo developed venture in the immediate future, so that's certainly a step forward as well

Thanks as ever to Unity for providing such a great toolset! I actually upgraded the project to 2021.2 for the URP improvements, and will be looking forward to the upcoming LTS to cement the version being used going forwards.

 

Congratulations on your publisher deal. And the trailer looks awesome. Especially I like the ships and details. The project has come a long way. Well done and kudos! I can't wait to play it.