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