Cool! I remember ST recently. I hope you can finish your game and make it polished... (sometimes i think about remake, but i am too lazy and drop it too fast...)
is this game inspired by Starship Theory? cus it is pretty alike. Hope that this project won't be abandoned like it, i really like the concept of these kind of games.
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
(0.12.11) Dillema: No amount of containers is enough
There is no way right now to cap, for example, how much of minerals or ice mining lasers prospect. This always results in more container being needed all the time. I think that a list of max global resources would be better than manual "Ignore Resource" drag&drop panel. In this scenario given resources would be just be placed in ignored state every time when specific quantity is met
Please don't go overly complicated with game saving. Start small, release, expand/fix later. Don't try to save complex stuff from the start (let game lose some data); saving/loading just structures, resources and where/how many units there are - will be more than enough for now! Even just structures will be ok for first release. I say that because serialization can easily become very complicated, especially when you want to save graphs (ai planning states) or object references (guaranteed duplicates when deserialized naively) - headache^2, don't even go there right now!
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
Game is much better and stable now! :) I see no units being zombiefied for no apparent reason anymore. Truss and module building system was a good choice too
Exception: Cant remove 10 of Metal as it doesn't exist at Game.Objects.Items.ItemContainer.Remove (Game.Objects.Items.ItemType _itemType, System.Int32 _amount) [0x00092] in C:\Users\Taz\Space Architect\Assets\Scripts\Objects\Item\ItemContainer.cs:185 at Game.Objects.Items.ItemContainer.Remove (Game.Objects.Items.ItemStack stack) [0x00001] in C:\Users\Taz\Space Architect\Assets\Scripts\Objects\Item\ItemContainer.cs:167 at Game.Station.Device.DeviceBuild.HandleSupplyingFinished (System.Object sender, System.EventArgs e) [0x00037] in C:\Users\Taz\Space Architect\Assets\Scripts\Station\Device\Base\DeviceBuild.cs:118 at (wrapper delegate-invoke) <Module>.invoke_void_Job_EventArgs(Game.Jobs.Job,System.EventArgs) at Game.Jobs.Job.CallFinished () [0x00001] in C:\Users\Taz\Space Architect\Assets\Scripts\Jobs\Base\Job.cs:172 at Game.Jobs.Job.Execute (Unit _unit) [0x0009f] in C:\Users\Taz\Space Architect\Assets\Scripts\Jobs\Base\Job.cs:134 at UnitJob.Act () [0x00001] in C:\Users\Taz\Space Architect\Assets\Scripts\Station\Unit\UnitJob.cs:29 at Unit.Update () [0x0003b] in C:\Users\Taz\Space Architect\Assets\Scripts\Station\Unit\Unit.cs:85
Thats it, game over. Everyone dies of diarrhea because f****** nobody wants to clean it up anymore and prefers just to wait in line until their a** explodes :O
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.
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)
I'm almost sure unit construction problem you've experienced is bound to some item transporting logic. I've ironed out some of bugs that might have appear there, not sure if all of them. Job management also got some improvements, let's see what new will pop up :)
Exception: Cant cancel reserve free space at Game.Objects.Items.ItemContainer.CancelReserveFreeSpace (System.Single maxAmountToStore) [0x00025] in C:\Users\Taz\Space Architect\Assets\Scripts\Objects\Item\ItemContainer.cs:212 at Game.Jobs.Activities.ActivityStoreResources.Executed (Unit _unit) [0x000d8] in C:\Users\Taz\Space Architect\Assets\Scripts\Jobs\Activities\ActivityStoreResources.cs:64 at Game.Jobs.Activities.Activity.Execute (Unit _unit) [0x000c4] in C:\Users\Taz\Space Architect\Assets\Scripts\Jobs\Activities\Activity.cs:75 at Game.Jobs.Job.Execute (Unit _unit) [0x00041] in C:\Users\Taz\Space Architect\Assets\Scripts\Jobs\Base\Job.cs:109 at UnitJob.Act () [0x00001] in C:\Users\Taz\Space Architect\Assets\Scripts\Station\Unit\UnitJob.cs:29 at Unit.Update () [0x0003b] in C:\Users\Taz\Space Architect\Assets\Scripts\Station\Unit\Unit.cs:84
I've redesigned small part of code and it seems it's patched up now I didn't experienced this bug while testing up to cycle 26 (that's basically this number in top left corner of the game UI)
Planning to do more testing tomorrow, but you can already try it out in 0.12.8 :)
(0.12.6) Bug: GeneralItemPanel.Update method is allocating >10MB of garbage memory PER SECOND.
This leads to GC.Collect() calls causing this pattern of CPU spikes:
This 180KB seems like nothing... until you actually multiply it by your framerate. One probably won't even notice this bump on high-end machine but it can seriously throttle any weaker laptop or older pc. And for no valid reason really.
PS: I have no idea from where this Instantiate call is coming from but it looks like that is the biggest offender here allocation-wise (consider object pooling).
void Update ()
{
// *** - ToString allocates at least 2 bytes for every character
// **** - adding strings together with '+' operator is more or less equivalet to ***
ItemContainer container = SingletonMB<StationContent>.Instance.GetContainer();
TextMeshProUGUI title = this.title;// this does nothing - remove line
float num = container.CapacityUsed;
string str1 = num.ToString("0");// ***
num = container.Capacity;// reusing local variables is not needed for anything
string str2 = num.ToString("0");// ***
string str3 = "Items " + str1 + " / " + str2;// ****
title.text = str3;
this.sectionLines.RemoveAllLines();
foreach( ItemStack itemStack in container.Items )// unfortunately, starting 'foreach' allocates memory - in Update methods try to use simpler old 'for' iterator instead of 'foreach'
{
PanelSectionLines sectionLines = this.sectionLines;// this does nothing - remove line
ItemType type = itemStack.Type;
string _identifier = type.ToString();// ***
type = itemStack.Type;// this does nothing - remove line
string _text = type.ToString() + " " + itemStack.Amount.ToString("##");// ****
sectionLines.Set(_identifier, _text);
}
}
Downsides of ToString() calls are not that simple to get rid of in context of UI. But it's better that you're aware of it and step-by-step will be trying to avoid them in the future (strings in general).
To give you an example of how to get rid of string allocations think about creating lookup tables for your values (enum is easy and natural candidate for that). This is how you create an lookup table for enums:
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 :)
PS: Please don't over-rely on events (outside UI ofc). Those are 10x times slower and complicate future debugging considerably. If something can be just a method call - let it be just that, you will thank yourself for that later on (less time spent debugging==more productivity==happier you).
This should limit worst of this runaway allocations just some seconds after game start (once caches fill up). It's not the best solution but certainly the simplest one to implement.
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
(0.12.6) Another NullReferenceException in main menu
(that burst of asteroids I guess)
NullReferenceException: Object reference not set to an instance of an object at Game.Objects.Asteroid.AsteroidFactory.Awake () [0x00008] in C:\Users\Taz\Space Architect\Assets\Scripts\Objects\Asteroid\AsteroidFactory.cs:13 UnityEngine.GameObject:Internal_AddComponentWithType(Type) UnityEngine.GameObject:AddComponent(Type) (at C:\buildslave\unity\build\Runtime\Export\Scripting\GameObject.bindings.cs:222) UnityEngine.GameObject:AddComponent() (at C:\buildslave\unity\build\Runtime\Export\Scripting\GameObject.bindings.cs:227) SingletonMB`1:get_Instance() (at C:\Users\Taz\Space Architect\Assets\Scripts\Utils\SingletonMB.cs:34) AsteroidManager:GenerateBurstLine(Int32) (at C:\Users\Taz\Space Architect\Assets\Scripts\Managers\AsteroidManager.cs:77) Game.InputManager:Update() (at C:\Users\Taz\Space Architect\Assets\Scripts\Managers\InputManager.cs:40)
(0.12.6) Pressign keyboard keys in main menu causes NullReferenceException
NullReferenceException: Object reference not set to an instance of an object at Game.InputManager.Update () [0x0004e] in C:\Users\Taz\Space Architect\Assets\Scripts\Managers\InputManager.cs:43
Friendly tip: try not to rely on singletons. Those seems fancy at first but are more trouble than they're worth in the end. Just pre-instancing them manually in the editor and accessing them through fields isn't that hard and will make your program more resilient. Meaning just:
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
I have no idea what service locator pattern is and I'm glad for it! :T In my personal experience implementing patterns is very luring but only to become a very costly vanity work (and sometimes even deadly one to given project). Because in later stages of development everything becomes so horrendously complicated that everyone is praying for simplicity, productivity stalls. Keep it simple - this is most undervalued yet most productive pattern out there (!).
Unit tests are of some value Only when you find yourself actually testing something manually a lot and would love to automate that - in other situations it's mostly another costly vanity coding.
Exception #1: Big enterprise software, where codebase maintenance and stability is more important than change (creative work does that a lot)
Exception #2: Well staffed MATURE game projects going for stable release
NotImplementedException: The method or operation is not implemented. at Game.UI.Panel.VisitorPanel.HandleLeft (Game.Visitors.Visitor _visitor, System.EventArgs e) [0x00001] in C:\Users\Taz\Space Architect\Assets\Scripts\UI\Panels\VisitorPanel.cs:60 at (wrapper delegate-invoke) <Module>.invoke_void_Visitor_EventArgs(Game.Visitors.Visitor,System.EventArgs) at Game.Visitors.Visitor.CallLeft () [0x00001] in C:\Users\Taz\Space Architect\Assets\Scripts\Visitors\Visitor.cs:136 at Game.Visitors.Visitor.Remove () [0x00001] in C:\Users\Taz\Space Architect\Assets\Scripts\Visitors\Visitor.cs:115 at Game.Visitors.Visitor.Update () [0x00114] in C:\Users\Taz\Space Architect\Assets\Scripts\Visitors\Visitor.cs:81
Hey kimio221! For the moment there is no way to gain new units, but also, there aren't any age related limitation, so what you've experienced is most probably a bug. I've solved similar one in v0.12.5, so if you're already running it, please send me error log from "%appdata%/../LocalLow/Tazoru/SpaceArchitect"
I hope to add a way to get new units within a month, I'm also starting work on game save mechanism :)
← Return to game
Comments
Log in with itch.io to leave a comment.
The game is out on Steam :)
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.
Cool! I remember ST recently. I hope you can finish your game and make it polished... (sometimes i think about remake, but i am too lazy and drop it too fast...)
It's slowly happening :) Currently I'm less active here due to focusing on releasing it via Steam, so finger crossed there :)
As I'm back at developing the game, expect update with quest system soon-ish.
I've already have a working prototype:
Bug:
Game crashes sometimes when trading. Also sometimes trading doesnt work entirely.
ok, I'll look into first one, but I need you to elaborate a bit more about second one, what didn't worked exactly? :)
I've released new update with fix for price calculation in trade panel :)
is this game inspired by Starship Theory? cus it is pretty alike. Hope that this project won't be abandoned like it, i really like the concept of these kind of games.
Yup, a bit :D Quite sad that one is no longer developed... It's probably one of the reasons I've chosen this genre for my game :D
Game is fun, but just for simplicity you might want to make it portable.
By the way i really liked the game.
Thanks :)
I think there is a bug with the power section in build menu and we can't build fuel stations.
Actually, power section is empty, power management will come in future update :)
But you're right, I need to fix it, so it show as empty :)
You can find fuel production plant in Production (or maybe it was called Fabrication?) tab :)
Oh i didnt see that before. Thanks
Minor fix to Trade UI is coming soon, along with replacing Mining Lasers with Mining Drones
It's done, trade update is here!
I'm planning to release Trade update this weekend :)
Sneak peak of trade panel:
I'm planning on higher engagement via discord :) So please, find me there!
https://discord.gg/YFF8RYC
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.
Early preview of new item visual, using Storage device:
FINALLY ITS OUT!!! WOOOOO
What would you wish to see in it in the future? :)
well i wish for staff recruitment and trading center, oh and an expansive world so we can build like a branch in it
It's slowly coming together :)
Sneak peak of units panel with recrutation section:
Basically, you'll got recruit from visiting ships. The more units you have the more ships need to visit your station before new recruit appears.
damn, im looking forward for it
After a week of binging on Factorio I'm back :) Expect save mechanism update soon :)
First version is almost here, I need to iron out few bugs first.
(0.12.11) Idea: Ability to sell any resources to docked ships
Not only fuel. If for nothing else - just to free container space
(0.12.11) Idea: Option to recruit more staff from passing or docked ships for $
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
(0.12.11) Idea: Containers that accept only specific resource type
Visual clue would be nice too (different container color or decal of resource icon)
(0.12.11) Bug: Pausing game produce strange, looped noises
It's just annoying that those noises wont ever go away :T even when game is running in background (after alt+tab or minimized)
It'll be released in 0.13.2 :)
Game will be muted when paused, but not when alt+tabbed, in case if someone want to play in windowed mode while doing other things.
(0.12.11) Dillema: No amount of containers is enough
There is no way right now to cap, for example, how much of minerals or ice mining lasers prospect. This always results in more container being needed all the time.
I think that a list of max global resources would be better than manual "Ignore Resource" drag&drop panel. In this scenario given resources would be just be placed in ignored state every time when specific quantity is met
Glad you mentioned that, it will be added after save/load mechanism i'm currently working on :)
Also, I'll alter drag'n'drop, it's plain bad atm.
Please don't go overly complicated with game saving. Start small, release, expand/fix later. Don't try to save complex stuff from the start (let game lose some data); saving/loading just structures, resources and where/how many units there are - will be more than enough for now! Even just structures will be ok for first release.
I say that because serialization can easily become very complicated, especially when you want to save graphs (ai planning states) or object references (guaranteed duplicates when deserialized naively) - headache^2, don't even go there right now!
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
That is great I was worried you might get stuck on this one (as anyone easily can)
It's done :) You can now set limit on each minned resource
Game is much better and stable now! :) I see no units being zombiefied for no apparent reason anymore. Truss and module building system was a good choice too
Glad to hear that :)
Exception: Cant remove 10 of Metal as it doesn't exist
at Game.Objects.Items.ItemContainer.Remove (Game.Objects.Items.ItemType _itemType, System.Int32 _amount) [0x00092] in C:\Users\Taz\Space Architect\Assets\Scripts\Objects\Item\ItemContainer.cs:185
at Game.Objects.Items.ItemContainer.Remove (Game.Objects.Items.ItemStack stack) [0x00001] in C:\Users\Taz\Space Architect\Assets\Scripts\Objects\Item\ItemContainer.cs:167
at Game.Station.Device.DeviceBuild.HandleSupplyingFinished (System.Object sender, System.EventArgs e) [0x00037] in C:\Users\Taz\Space Architect\Assets\Scripts\Station\Device\Base\DeviceBuild.cs:118
at (wrapper delegate-invoke) <Module>.invoke_void_Job_EventArgs(Game.Jobs.Job,System.EventArgs)
at Game.Jobs.Job.CallFinished () [0x00001] in C:\Users\Taz\Space Architect\Assets\Scripts\Jobs\Base\Job.cs:172
at Game.Jobs.Job.Execute (Unit _unit) [0x0009f] in C:\Users\Taz\Space Architect\Assets\Scripts\Jobs\Base\Job.cs:134
at UnitJob.Act () [0x00001] in C:\Users\Taz\Space Architect\Assets\Scripts\Station\Unit\UnitJob.cs:29
at Unit.Update () [0x0003b] in C:\Users\Taz\Space Architect\Assets\Scripts\Station\Unit\Unit.cs:85
(Filename: C:/Users/Taz/Space Architect/Assets/Scripts/Objects/Item/ItemContainer.cs Line: 185)
yup this happen again
Fix done, you can find it in 0.12.10 :)
damn it look dope
(0.12.9)
BugFeature: PrioritiesHow to kill all your crew in 3 easy steps:
love it :D
I'll deal with it this week (I hope :D)
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.
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)
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 :
It would allow for clean & nimble looking stations. Trusses will be still in use after introducing concepts of power & temperature to station :)
(0.12.7) Bug: WorkManager.RevalidateJobs throws 900ms-long tantrums for reasons
Repro steps:
I'm almost sure unit construction problem you've experienced is bound to some item transporting logic. I've ironed out some of bugs that might have appear there, not sure if all of them. Job management also got some improvements, let's see what new will pop up :)
Exception: Cant cancel reserve free space
at Game.Objects.Items.ItemContainer.CancelReserveFreeSpace (System.Single maxAmountToStore) [0x00025] in C:\Users\Taz\Space Architect\Assets\Scripts\Objects\Item\ItemContainer.cs:212
at Game.Jobs.Activities.ActivityStoreResources.Executed (Unit _unit) [0x000d8] in C:\Users\Taz\Space Architect\Assets\Scripts\Jobs\Activities\ActivityStoreResources.cs:64
at Game.Jobs.Activities.Activity.Execute (Unit _unit) [0x000c4] in C:\Users\Taz\Space Architect\Assets\Scripts\Jobs\Activities\Activity.cs:75
at Game.Jobs.Job.Execute (Unit _unit) [0x00041] in C:\Users\Taz\Space Architect\Assets\Scripts\Jobs\Base\Job.cs:109
at UnitJob.Act () [0x00001] in C:\Users\Taz\Space Architect\Assets\Scripts\Station\Unit\UnitJob.cs:29
at Unit.Update () [0x0003b] in C:\Users\Taz\Space Architect\Assets\Scripts\Station\Unit\Unit.cs:84
(Filename: C:/Users/Taz/Space Architect/Assets/Scripts/Objects/Item/ItemContainer.cs Line: 212)
oh yeah and somehow the unit ignored the thing i want to build so yeah... y'know what to do (0.12.6 btw)
It slowly become my little nightmare, but I have next idea to check :D I'll keep you posted with an update tomorrow (I hope)
I've redesigned small part of code and it seems it's patched up now
I didn't experienced this bug while testing up to cycle 26 (that's basically this number in top left corner of the game UI)
Planning to do more testing tomorrow, but you can already try it out in 0.12.8 :)
thank you!!!
(0.12.6) Bug: GeneralItemPanel.Update method is allocating >10MB of garbage memory PER SECOND.
This leads to GC.Collect() calls causing this pattern of CPU spikes:
This 180KB seems like nothing... until you actually multiply it by your framerate.
One probably won't even notice this bump on high-end machine but it can seriously throttle any weaker laptop or older pc. And for no valid reason really.
PS: I have no idea from where this Instantiate call is coming from but it looks like that is the biggest offender here allocation-wise (consider object pooling).
Few words of friendly comments:
void Update () { // *** - ToString allocates at least 2 bytes for every character // **** - adding strings together with '+' operator is more or less equivalet to *** ItemContainer container = SingletonMB<StationContent>.Instance.GetContainer(); TextMeshProUGUI title = this.title;// this does nothing - remove line float num = container.CapacityUsed; string str1 = num.ToString("0");// *** num = container.Capacity;// reusing local variables is not needed for anything string str2 = num.ToString("0");// *** string str3 = "Items " + str1 + " / " + str2;// **** title.text = str3; this.sectionLines.RemoveAllLines(); foreach( ItemStack itemStack in container.Items )// unfortunately, starting 'foreach' allocates memory - in Update methods try to use simpler old 'for' iterator instead of 'foreach' { PanelSectionLines sectionLines = this.sectionLines;// this does nothing - remove line ItemType type = itemStack.Type; string _identifier = type.ToString();// *** type = itemStack.Type;// this does nothing - remove line string _text = type.ToString() + " " + itemStack.Amount.ToString("##");// **** sectionLines.Set(_identifier, _text); } }Downsides of ToString() calls are not that simple to get rid of in context of UI. But it's better that you're aware of it and step-by-step will be trying to avoid them in the future (strings in general).
After cleaning code up just a bit it can be like this (cleaner to read/understand imho):
void Update () { ItemContainer container = SingletonMB<StationContent>.Instance.GetContainer(); title.text = string.Format( "Items {0:0} / {1:0}" , container.CapacityUsed , container.Capacity ); sectionLines.RemoveAllLines(); int numContainerItems = container.Items.Count; for( int i=0 ; i<numContainerItems ; i++ ) { ItemStack itemStack = container.Items[i]; string identifier = itemStack.Type.ToString(); string text = string.Format( "{0} {1:##}" , identifier , itemStack.Amount ); sectionLines.Set( identifier , text ); } }Note that 'string.Format()' is slightly better than '"strA"+"strB"'
Also System.Text.StringBuilder would be better (string.Format uses it internally).
To give you an example of how to get rid of string allocations think about creating lookup tables for your values (enum is easy and natural candidate for that). This is how you create an lookup table for enums:
public static readonly Dictionary<ItemType,string> ItemTypeStrings = new Dictionary<ItemType,string>{ { ItemType.Metal, "Metal" } , { ItemType.Food, "Food" } , { ItemType.Water, "Water" } , { ItemType.Mineral, "Mineral" } , { ItemType.Dirt, "Dirt" } , { ItemType.WasteWater, "Waste Water" } , { ItemType.LOX, "LOX" } , { ItemType.LH2, "LH2" } , { ItemType.AsteroidaldWater, "Asteroidald Water" } , { ItemType.MetalOre, "Metal Ore" } , { ItemType.Component , "Component" } , { ItemType.None , "None" } , };And that will give you an ability to replace every:
with:
which will allocate no memory at all (==what we want)
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)); } }That's great!
PS: Please don't over-rely on events (outside UI ofc). Those are 10x times slower and complicate future debugging considerably. If something can be just a method call - let it be just that, you will thank yourself for that later on (less time spent debugging==more productivity==happier you).
Easy (but lazy) solution to most of those allocations would be to use LazyCacheStrings and change your code into something like this:
public static LazyCacheStrings<ItemType> ItemTypeStrings = new LazyCacheStrings<ItemType>( (t)=>t.ToString() ); static LazyCacheStrings<System.ValueTuple<float,float>> TitleStrings = new LazyCacheStrings<System.ValueTuple<float,float>>( (kv)=>string.Format("Items {0:0} / {1:0}",kv.Item1,kv.Item2) ); static LazyCacheStrings<System.ValueTuple<ItemType,float>> SectionStrings = new LazyCacheStrings<System.ValueTuple<ItemType,float>>( (kv)=>string.Format("{0} {1:##}",ItemTypeStrings[kv.Item1],kv.Item2) ); void Update () { ItemContainer container = SingletonMB<StationContent>.Instance.GetContainer(); title.text = TitleStrings[ ( container.CapacityUsed , container.Capacity ) ]; sectionLines.RemoveAllLines(); int numContainerItems = container.Items.Count; for( int i=0 ; i<numContainerItems ; i++ ) { ItemStack itemStack = container.Items[i]; sectionLines.Set( ItemTypeStrings[ itemStack.Type ] , SectionStrings[ ( itemStack.Type , itemStack.Amount ) ] ); } }This should limit worst of this runaway allocations just some seconds after game start (once caches fill up). It's not the best solution but certainly the simplest one to implement.
(itch.io/app) Bug: Launching game via app launches an installer instead of actual game executable.
Actually, I didn't even noticed itch.io have its own app for that, So I packed the game up myself :D I'll take a look at it later :)
(0.12.6) Bug: Build menu UI becomes stuck and unresponsive.
Repro steps:
It affected both existing devices and planned constructions, fix is done and will be released in next update :)
(0.12.6) Bug: Devices sometimes just aren't being constructed.
Workers do other things and seemingly ignore it.
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
I'll check that next time but it very well may be it!
(0.12.6) Another NullReferenceException in main menu
(that burst of asteroids I guess)
(0.12.6) Pressign keyboard keys in main menu causes NullReferenceException
Oh I see... bc these are cheats codes :)
Friendly tip: try not to rely on singletons. Those seems fancy at first but are more trouble than they're worth in the end. Just pre-instancing them manually in the editor and accessing them through fields isn't that hard and will make your program more resilient. Meaning just:
then:
instead of:
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
I have no idea what service locator pattern is and I'm glad for it! :T
In my personal experience implementing patterns is very luring but only to become a very costly vanity work (and sometimes even deadly one to given project). Because in later stages of development everything becomes so horrendously complicated that everyone is praying for simplicity, productivity stalls.
Keep it simple - this is most undervalued yet most productive pattern out there (!).
Unit tests are of some value Only when you find yourself actually testing something manually a lot and would love to automate that - in other situations it's mostly another costly vanity coding.
Exception #1: Big enterprise software, where codebase maintenance and stability is more important than change (creative work does that a lot)
Exception #2: Well staffed MATURE game projects going for stable release
Yup :D I needed a way to speed up testing and just left it there :D
Where do I send bug reports?
0.12.5 callstack:
Hi there!
Thanks for the info!
I've fixed it in v0.12.6 release. If you stumble upon any other problem, just put a comment here :)
Awesome! Thanks for all the feedback :)
It will take me a while to go through and address it
yeahhhh how to increrase the unit? i got puzzled and i cant do nothing since they will stop working when the reach age 50 - 58
Hey kimio221!
For the moment there is no way to gain new units, but also, there aren't any age related limitation, so what you've experienced is most probably a bug.
I've solved similar one in v0.12.5, so if you're already running it, please send me error log from "%appdata%/../LocalLow/Tazoru/SpaceArchitect"
I hope to add a way to get new units within a month, I'm also starting work on game save mechanism :)
Thank you i just got really panic when they stop working
Great game you deserve more btw
Thanks!
Btw. I'll have to look again into this bug, I resolved one cause but it still pops up from time to time :/