Dev Blog
Hi, this is the Stranded III development blog (see also Forum Thread, Comment Thread).
Entry 85 - Update Madness & Stacking - May 22, 2019
Unity 2019 & Lightweight Render Pipeline
Sooo... I upgraded from Unity 2018 to the lately released Unity 2019 and of course all my materials looked and behaved differently afterwards. Fun.
I took that as an opportunity to also switch to the Lightweight Render Pipeline! Maybe it makes rendering a bit faster!?
This step of course resulted in... more broken stuff.
I had to fix most materials manually. There's an "automatic" conversion but it didn't do a good job even though I only used original materials provided by Unity. More fun.
Afterwards I noticed that the LWRP (Lightweight Render Pipeline) isn't good at z-sorting alpha stuff:
I have to admit though that the LWRP makes the game look much more like Stranded II (which had comparable z-fighting issues)
What you can't see in that Gif is that the terrain material exploded as well which made the entire terrain become invisible.
Another issue I experienced: OnPostRender doesn't work anymore with LWRP (or in fact any scripted render pipeline).
That's not even mentioned in the OnPostRender documentation though. Thanks Unity!
This broke my little real time debug stuff rendering library (I'm using Unity's low level graphics API for that).
I found out how to fix this but it requires some more changes.
Overall this is a massively frustrating experience and I wish back the good old days of Blitz3D - the engine I used for Stranded I and II.
Blitz3D was very limited but straightforward. The API was super simple, super clean and things just worked the way you expected them to work.
All that isn't true for Unity. They shove in tons of new stuff with every update. It feels like they have thousands of different systems for everything you want to do and none of them works flawlessly or is documented properly.
Come on Unity! Stop adding new stuff and making feature breaking changes and start fixing and documenting the existing stuff you have.
You are forcing developers (who want to stay up to date) to waste huge amounts of time with migrating to new systems. That's time they should spend working on gameplay and content.
I'm already very afraid of the new input system and the next entirely new UI system. This is going to be a huge mess!
Maybe I should stick to making 2D games or give Godot a try.
Stacking
Item stacking is nearly as much fun as updating Unity. Earlier I decided that "real" item stacking (merging equal items and just giving them a count value) is too complicated. Instead there should only be visual stacking which would mean that items are displayed as stacks but when you click at a stack you see all of the individual items with their attributes.
(missed a "1x" there but you get the idea)
Visual-only-stacks are cool and maybe I will keep this in the game but there's a technical problem with this: Tiny items that you get in big numbers and which all have equal attributes. Think of ammunition.
These would consume a lot of memory and take a lot of network traffic to sync. It's only a theoretical problem at this point but it feels horribly wasteful and I don't want to handle things that way.
My old "solution" to this was to simply declare that all items are very precious in Stranded III and that it rarely happens that you have a big amount of the same item type.
This is not a real solution at all and it limits the game a lot.
So I thought about stacking again and came up with something.
Stacking entirely equal items is relatively trivial. But how to handle items which have different attributes? E.g. one item burns and the other one doesn't. Should both be stacked and then both burn? Or none burns? Or they can't be stacked because the fire makes them different?
Or what about sizes and weights? Can 3 rocks with different sizes become a single rock stack with a little counter saying it is actually 3? Should they get the average size then? Wouldn't that allow people to modify items by letting them stack in smart ways?
For most cases the answer is: If items have different attributes they can't be stacked. The attributes are different for reasons and should stay the way they are.
In some cases however an attribute might not be important for inventory items at all. We could just remove it or take the minimum/maximum/average to allow stacking anyway.
For example an internal attribute which is used to store a state which is only relevant for items outside your inventory. This shouldn't prevent stacking.
Because of this you will be able to define different crazy merging strategies for each attribute:
The default behavior will be that stacking won't work if the stack candidates have different values for an attribute.
You could also just tell the game to remove the attribute during stacking (ignoring the values)
Or tell it to not stack at all as soon as the attribute is present on at least one stack candidate (ignoring the values as well)
And if you're completely crazy you keep the attribute but you calculate the minimum/maximum/average value across all stack candidates
Aaand if you think the previous thing wasn't insane enough you could also let people implement methods in Lua to allow them handling the stacking logic their own way
Whenever a new item is stored somewhere (e.g. in your inventory) Stranded III will run a pairwise check for all items of that type and try to stack them by checking all their attributes and the merging strategies of these attributes.
When stacks are found the new attribute values for each stack are calculated. Depending on the merging strategy attributes can be discarded or recalculated based on attributes of the related stack candidates. Rocket science!
Sooo... I upgraded from Unity 2018 to the lately released Unity 2019 and of course all my materials looked and behaved differently afterwards. Fun.
I took that as an opportunity to also switch to the Lightweight Render Pipeline! Maybe it makes rendering a bit faster!?
This step of course resulted in... more broken stuff.
I had to fix most materials manually. There's an "automatic" conversion but it didn't do a good job even though I only used original materials provided by Unity. More fun.
Afterwards I noticed that the LWRP (Lightweight Render Pipeline) isn't good at z-sorting alpha stuff:
I have to admit though that the LWRP makes the game look much more like Stranded II (which had comparable z-fighting issues)
What you can't see in that Gif is that the terrain material exploded as well which made the entire terrain become invisible.
Another issue I experienced: OnPostRender doesn't work anymore with LWRP (or in fact any scripted render pipeline).
That's not even mentioned in the OnPostRender documentation though. Thanks Unity!
This broke my little real time debug stuff rendering library (I'm using Unity's low level graphics API for that).
I found out how to fix this but it requires some more changes.
Overall this is a massively frustrating experience and I wish back the good old days of Blitz3D - the engine I used for Stranded I and II.
Blitz3D was very limited but straightforward. The API was super simple, super clean and things just worked the way you expected them to work.
All that isn't true for Unity. They shove in tons of new stuff with every update. It feels like they have thousands of different systems for everything you want to do and none of them works flawlessly or is documented properly.
Come on Unity! Stop adding new stuff and making feature breaking changes and start fixing and documenting the existing stuff you have.
You are forcing developers (who want to stay up to date) to waste huge amounts of time with migrating to new systems. That's time they should spend working on gameplay and content.
I'm already very afraid of the new input system and the next entirely new UI system. This is going to be a huge mess!
Maybe I should stick to making 2D games or give Godot a try.
Stacking
Item stacking is nearly as much fun as updating Unity. Earlier I decided that "real" item stacking (merging equal items and just giving them a count value) is too complicated. Instead there should only be visual stacking which would mean that items are displayed as stacks but when you click at a stack you see all of the individual items with their attributes.
(missed a "1x" there but you get the idea)
Visual-only-stacks are cool and maybe I will keep this in the game but there's a technical problem with this: Tiny items that you get in big numbers and which all have equal attributes. Think of ammunition.
These would consume a lot of memory and take a lot of network traffic to sync. It's only a theoretical problem at this point but it feels horribly wasteful and I don't want to handle things that way.
My old "solution" to this was to simply declare that all items are very precious in Stranded III and that it rarely happens that you have a big amount of the same item type.
This is not a real solution at all and it limits the game a lot.
So I thought about stacking again and came up with something.
Stacking entirely equal items is relatively trivial. But how to handle items which have different attributes? E.g. one item burns and the other one doesn't. Should both be stacked and then both burn? Or none burns? Or they can't be stacked because the fire makes them different?
Or what about sizes and weights? Can 3 rocks with different sizes become a single rock stack with a little counter saying it is actually 3? Should they get the average size then? Wouldn't that allow people to modify items by letting them stack in smart ways?
For most cases the answer is: If items have different attributes they can't be stacked. The attributes are different for reasons and should stay the way they are.
In some cases however an attribute might not be important for inventory items at all. We could just remove it or take the minimum/maximum/average to allow stacking anyway.
For example an internal attribute which is used to store a state which is only relevant for items outside your inventory. This shouldn't prevent stacking.
Because of this you will be able to define different crazy merging strategies for each attribute:
The default behavior will be that stacking won't work if the stack candidates have different values for an attribute. You could also just tell the game to remove the attribute during stacking (ignoring the values) Or tell it to not stack at all as soon as the attribute is present on at least one stack candidate (ignoring the values as well) And if you're completely crazy you keep the attribute but you calculate the minimum/maximum/average value across all stack candidates Aaand if you think the previous thing wasn't insane enough you could also let people implement methods in Lua to allow them handling the stacking logic their own wayWhenever a new item is stored somewhere (e.g. in your inventory) Stranded III will run a pairwise check for all items of that type and try to stack them by checking all their attributes and the merging strategies of these attributes.
When stacks are found the new attribute values for each stack are calculated. Depending on the merging strategy attributes can be discarded or recalculated based on attributes of the related stack candidates. Rocket science!