I need some time to think if I'll continue to release on itch.io. For the moment v0.18.0 is available only on Steam.
Tazoru
Creator of
Recent community posts
Visitor is getting some much needed visual polish alongside backend code refinement in preparation for getting more logic.
What do you thing about updated look?
v0.14 will bring more interactions with those folks, that's unit recruitment (already implemented) and trade (selling unnecessary goods, getting needed ones).
I'd like to put some variation in visitor intentions, so that you'll be visited by traders, explorers, military vessels or tourists, all of them with different needs and stuff to offer.
I still can't decide how I want to tackle getting new staff, It will be bound to $$ in this way or another for sure :)
For the moment I'm postponing any bigger feature (except of save mechanism) and focussing on adding some needed polish - like teaching units to get all resources from miner, now they make a journey for each of item type separetely
Oh I remember the pain I had with restoring references between saved objects in previous game I made (Pixel Pirates 3D) :D
Just like you said, I'm making it simple and may leave it that way with a bit of storytelling:
'You're not loading the game, but moving through time and space, generating energy blast wherever you happen to appear. Everyone there stops in confusion'
Going back to progress I made - I have already saving of station grid (build modules & trusses), mining settings and units. Before releasing first version I wish to add saving of devices (with their content), planned constructions, earned cash and current cycle.
Second release will have asteroids, contracts & visitors
It's done :)
As of v0.12.11 unit will still wait, but instead of dying he will do what he must on the floor.
All units in range of 3 tiles will get disguisted by that fact and have temporary debuff to movement speed. (In the future that would be replaced with debuff to happines/morale, but that one doesn't exist yet)
Ok, so here's how they will act soon :)
So, I'll adjust units so they will not take jobs requiring them to wait for something.
Also, units will get temporary statuses affecting their stats. So, units will be able to hold IT in for longer, but they will get debufs to walking speed & device operation speed, then if they'll still not be able to relieve themselves, instead of dying, they will leave THE PACKAGE (wherever they'd be standing if inside, or filling in their suit if outside), getting massive debuff for himself (shame on you, Unit) and moderate debuff for anyone passing by what's left, untill it's cleared.
All of those debuffs will wear of with time.
In preparation for save/load (my goal for 0.13.0) I'm reworking hull & floor. Now, floors have to be on and surrounded by hull. After the changes :
- hull will be replaced with truss - not pressurized space, steel beams in fact keeping your base together.
- floor will be replaced with pressurized module - it need to be placed on truss, but that's it.
- both will get visual rework
It would allow for clean & nimble looking stations. Trusses will be still in use after introducing concepts of power & temperature to station :)
This part of code is just my prototyping/lazy programming left for later :D I've wanted to base it on event instead of leaving it in update, but forgot about it when preparing actual event :/
Adding your suggestions (with exception for foreach, just for readability sake) and moving it to be based on event it now looks and perform a lot better :)
void Start() { sectionLines = GetComponent<PanelSectionLines>(); title = transform.Find("Title").GetComponentInChildren<TextMeshProUGUI>(); StationContent.Instance.OnContentChanged += HandleStationContentChanged; } private void HandleStationContentChanged(StationContent _stationContent) { ItemContainer container = _stationContent.GetContainer(); title.text = string.Format("Items {0:0} / {1:0}", container.CapacityUsed, container.Capacity); sectionLines.RemoveAllLines(); foreach (ItemStack stack in container.Items) { sectionLines.Set(Lang.ITEM_TYPE[stack.Type], string.Format("{0} {1:##}", Lang.ITEM_TYPE[stack.Type], stack.Amount)); } }
Did you had components in two storages?
In a situation when device requires for example 10 components and you have like 5 in one storage and 5 in another transport job was not able to arrange itself (problem existed for stack less than 100 kg).
I'm adding handling of that exact situation in next update, I've stumbled upon it while building DockPort :D
For rapid prototyping those worked awesome for me :) I didn't aimed at having a lot of unit tests yet, nor did they gave me too much of a trouble so far, so I didn't invested much time into finding other solutions. Most of them (if not all) are used as a sort of API by various systems, so I need easy access to them. Do you think switching to service locator pattern will be a good enough choice? https://erdiizgi.com/avoiding-singletons-in-unity/
It seems it will allow me to use dummy classes for unit tests and have control over when they're instantiated