The Spatials V3 devblog 2015-11-02

Internal development notes, very slightly cleaned up and commented a week later.

TL;DR: more code cleanups, some systems for of planet resource extraction are now implemented (resource nodes, extraction objects, simplified logistics, automatic ship cargo transfers), the UI color can now be customized, and fixing a bad programming pattern before it is too late.

- another massive removal / commenting commit
    Surface, Skill, Avatar, Agent*, Mission are out, plus minor related stuff
    and their UIs

44913 lines deleted

Another week, another huge amount of code deleted from V2. This is the biggest one, and it affected very core areas of V2, including the entire model for map surfaces, the skill and combat system, and the AI for anything that moved on screen. Part of those tasks are already being handled by new V3 code, and the missing ones, like the skills and combat, need to be rewritten anyway to use the ECS framework in V3.

- resource extraction
    an in-world system counts nodes within extractor range
        model in scheme side for Body
            key based on X-Y, data contains resource, room for more
    another system persists some entities (extractors for now) into model
        key based on X-Y, data contains a hint in the planet-persist-component
        obj model has the hint, reverse map built during gen
- filter by the correct resource kind in planet-resource-system-post-processSystem
    add to extractor obj model
    also add radius
- resource tick generation
    model for resource gathering, in scheme
        c++ Body::tick does hook call
    each tick increases the (body 'stock) resource -> amount map prop to the amount of covered resource nodes
        logic is out of ECS, works without ECS sim
    hardcode speed and max capacity for now, will depend on more constructions later on
- resource+ship galaxy logistics
    model for galaxy+ship resource transfer logistics
        need model ship inventory of some sort
- fix: resource list in ship view makes following UI disappear
    as usual, no intrisic sizing
    add support for parent widgets inheriting explicit sizing from their children
        use -1 for width or height
- try to re-enable resource filter for galaxy view
    scheme re-populates C++ side data when needed
- planet: logistics mini system for extractors
    pallet-like object
    adds to global planet capacity, not per-extractor
        extractors also provide a small capacity

The big task of the last week was to start the new resource gathering system. Just like in V2 resources are gathered from planets. But in V3 those resources are represented by node objects on the surface of the planet, instead of abstract icons in the galaxy planet window. Your officers must now build resource extractors: automatic machines that slowly extract resources from nearby resource nodes. Here's an anotated video on how it works:

For starters the resource system from V2 has been ported to V3, and each resource has been assigned a few categories, to be matched by the correct extractors (fluid, biological, mineral). The model and systems to support this new gameplay were implemented, as well as new V3 concept: being able to build persistent structures on planets, that will still be here if you land on them again in the future (unless a pirate decided he didn't like them, of course).

Some basic code for planet and ship logistics is now place. For now logistics in planets are meant to be simplified. Only pallets have to be built, which increase an abstract inventory capacity stat in the planet (similar to how the V2 station warehouse worked). Ships will also have limited cargo capacity, but for now there are no gameplay systems in place for it.

- make UI colors re-definable
- options section for UI colors
    store in options model

The GUI subsystem was already fully based on symbolic colors for most of the user interface, so it was easy to fix the few hardcoded values and make it possible for the user to pick a different color for the UI.

44913 lines deleted

- fix now before it's too late: way too much model lazy initialization is creeping into scheme code
    body stocks, storage, persists
    ship stocks
    find a pattern for init and use it
        constructor-like on ::create: NO, it will be stomped by deserialization, which overrides the hasthable as a whole
        manual init on ::init: deserialization wont affect it, but NO: it's not forward compatible like C++ constructors, will still need defensive programming
        constructor-like but passing current value: much better since it allows merge, but still difficult to find the right moment in deserialization
            try call on Registry::create -> BridgeCPPOwned::unserialize
            try call on Persisting::afterLoad -> BridgeCPPOwned::unserialize
    then stop doing so much defensive (and predicate ...) and (or assumed-accesor default)

Dynamically typed programming languages like Scheme make it very easy and fast to model your data as you go. While this is good for iterating fast over a feature, it can lead to brittle code. A usual anti-pattern is to include guards before you access some bit of state that may or may be not be there:

(display (or (table member:) "default"))

This will print default when member: is not a key in table. While this may fine for user provided data (a config file, a file downloaded from a third party, the input from a UI control), accessing fully internal data and structures like this is a very strong indicator of the code being in a bad shape.

A constructor-like pattern was implemented for the Scheme-side dictionary that C++ objects provide. This way, when a C++ object is created, there's a chance for a Scheme-side proc to also initialize its dictionary.