next »

[marcgfx]

Interesting read/watch, I did skip quite a few parts but I think I get the overall gist of what you are making. What I am not so clear on is how the game will play. You first mentioned that you have a fleet of ships that are escaping and rebuilding. I expected this to mean rebuilding a mobile force, meaning more ships. So I wonder how the ground-army idea actually comes into play. As soon as you have a ground army and a base, do you start defending that? Is the goal to get away as long as you have to and then start recolonizing a planet? If the chasing army is just out to destroy you, wouldn't it be easier for them as soon as you are planet based? I guess in FTL the final stage is actually facing the army, so maybe that is where you are headed too.

[leeharris]

Hi Marc,

I guess I've only really started to get a concrete idea of what my core game-play loop is in the last few months, so it's understandable that I haven't conveyed that very well...

Whatever fleet you start the game with is essentially what ships you will have throughout, though you might find derelict vessels that you can repair or steal ships from some of the minor races you encounter on your journey. So the core idea is that we need to keep this fleet maintained, fueled, ammo needs to be manufactured, etc, and there is a fixed number of people that you start with that need to be fed and kept happy lest they rebel and ships end up choosing to go their own way, or falling foul of diseases, etc. So the way to maintain this fleet will involve doing 'away missions' to the grounds of the planets you encounter in each solar system, which will have natural resources or remains of colonies or even alien settlements. Many planets will have dangerous 'wildlife' or other things that make them dangerous and/or inhospitable, so the strategy comes from making a choice about where to devote your limited resources.

Maybe the most mineral rich planet is right next to the warp in point, and you reallllly need that Titanium to manufacture some new hull plating for the cargo ship that has been limping through space for the last few systems, but that planet has hordes of alien creatures that don't look too inviting-- and from the moment you enter that solar system the clock is ticking until the invasion fleet catches up with you from that very same warp in point, and that's the planet they'll check out first... Do you have time to send a small military force down, establish a perimeter and a small mining operation? Do you do this whilst sending the rest of the fleet further into the system looking for other planetary prospects? Do you split the fleet and leave some ships to support the ground operation? Do you pass up the opportunity and hope easier mining chances will exist on planets that look much friendlier? How do you weigh up the expenditure of fuel, ammo and manpower devoted to each ground mission along the way? How long until you just run out of the things you need to keep going...?

(So ground units can embark/disembark onto/from the ships, they don't just get stuck on the ground; but any buildings you construct will probably just be abandoned unless you can strip them of any vital resources)

That describes the scenario mode, at least-- the story mode will be a bit more pre-ordained with ship captains and prominent figures trying to have their own say and influencing the direction of the exodus, with scripted encounters and specific arcs set across hand-crafted solar systems. And at some point I guess, yeah, humanity might need to decide to stop running and turn and fight...

I hope that clarifies things a bit!

[JobLeonard]

Lovely summary!

[marcgfx]

Thanks! Sounds really cool and also like a really complex balancing nightmare for you

[leeharris]

Hi again, hope we're all staying safe

So, I've finally 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. It might seem a little odd to concentrate so heavily on the 'creation' tool-set rather than actual gameplay mechanics, but when your game is almost entirely dynamically-created, it made sense to me to start at the beginning of the process and work downwards. I've revamped and standardised the creation UI, and I'm designing the third and final piece of the creation suite at present: the node-based scripting system (think Bolt/Blueprints) as part of the scenario editor, where chains of solar systems can be pieced together and events triggered as required, etc.

The solar system editor map display doubles up as a Homeworld-esque zoomed out solar system map in-game too, though that's still in a very preliminary form... In other developments I finally added a second a planet type in the form of the 'rocky' planet type, complete with voronoi cell based crater mesh deformation. Turned out that I had to spend the best part of a week reworking my script-based cubemap sampling since the Unity method doesn't sample by vector outside of a shader -- which led to very stretched craters, but after playing with several implementations, and toying with various easing functions, the best solution just ended up being remapping input via an animation curve graph... so yay! Still yet to apply procedural splat-mapping here, but I think it might work pretty well (plus the navigation mesh is intelligent enough to route around crater positions too)

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

[Alain]

Hi leeharris, that's some really cool dynamic generation. I'm excited to see the ships traverse your solar system and how the player can interact with it!

[vdapps]

Weee, space and Solar System, definitely interested! Following the thread!

And great procedural generation of planets!

[leeharris]

Hi again, and thanks for the positive comments vdapps and Alain

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 gifs 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

[Alain]

I just watched your DevLog #12 with my coffee. In the beginning, I thought the video might be a bit long, but I like the way you talk and watching space is always nice. Zooming in and out looks satisfying and I enjoyed the behind the scenes view.

[JobLeonard]

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

Heh, that reminds me of a GameJam game a group of friends and I made about a decade ago, which was a puzzle game set in space where you basically had to build trade-routes between planets until every planet had their economic needs met (which would then result in the trade-routes looking like a constellation). We also had a zooming in/out feature, and some funky floating point issues. So IIRC we handled that by applying a raw scaling multiplier to every relevant value.. except that we initially forgot to apply said scaling multiplier to the player's ship speed, which resulted in it being faster the more you zoomed out. But that turned out to feel really nice and not conflict with the gameplay, so we decided it was a feature, not a bug

[leeharris]

I just watched your DevLog #12 with my coffee. In the beginning, I thought the video might be a bit long, but I like the way you talk and watching space is always nice. Zooming in and out looks satisfying and I enjoyed the behind the scenes view.

Pretty sure that being worthy of watching over a coffee break is an extremely high honour of some kind I'm definitely guilty of rambling on a bit, and try to keep my time spend editing down to like half an hour at most, so thanks for sticking with it (maybe a more rapid-fire succession of updates in a snazzy video is the future?)

Heh, that reminds me of a GameJam game a group of friends and I made about a decade ago, which was a puzzle game set in space where you basically had to build trade-routes between planets until every planet had their economic needs met (which would then result in the trade-routes looking like a constellation). We also had a zooming in/out feature, and some funky floating point issues. So IIRC we handled that by applying a raw scaling multiplier to every relevant value.. except that we initially forgot to apply said scaling multiplier to the player's ship speed, which resulted in it being faster the more you zoomed out. But that turned out to feel really nice and not conflict with the gameplay, so we decided it was a feature, not a bug

Aw hell, see, I somehow had you pegged as like a secret alias of Jonathan Blow or some such, but I guess you're as prone to mistakes as the rest of us after all :p (and if its okay, I won't borrow that particular feature from you... I think...)

[Alain]

(maybe a more rapid-fire succession of updates in a snazzy video is the future?)

I'd watch it for sure! But I totally get that you have to budget your time carefully.

[JobLeonard]

Hahahaha, the only thing Jonathan Blow and I have in common is that we both have a vaporware programming language as a side project. The difference is that mine is a esolang variant on brainfuck and completely useless

(and if its okay, I won't borrow that particular feature from you... I think...)

Heh, no, it wasn't a suggestion

[leeharris]

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

[JobLeonard]

That's a lot of progress!

[Alain]

Great update! I love the detail that there is a portrait for the captain of a ship. It adds a lot of personality, which is something I as a player enjoy a lot when playing games that are played on a "zoomed out scale" as yours.

[leeharris]

Hi again,

Well, Alain, I certainly took your comment about the character portraits to heart... decided to license some appropriate imagery so that I could go one step further and actually visualise the entire senior staff rather than just the captain. I think it definitely helps, so cheers for that

---

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!

[Alain]

Well, Alain, I certainly took your comment about the character portraits to heart... decided to license some appropriate imagery so that I could go one step further and actually visualise the entire senior staff rather than just the captain. I think it definitely helps, so cheers for that

That's great! And from the screenshots I feel that through the portraits the ships become a real thing in a real universe! I'll watch the whole devlog tomorrow

[vivaladav]

This is definitely a project I am going to follow!

Are you planning to have a Linux build at some point?

[leeharris]

Hi again,

@vivaladav: I'm developing in Unity, so I see no reason why a Linux version isn't a distinct possibility! I'm one of those strange people that has never even played around with Linux, though, so I can't say it's super high on my list of priorities :|


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