Does anyone actually care about serialization and hot reload?

Does anyone actually care about data serialization and retaining ability to hot reload?

I mean, the engine has a hot reload ability which allows you to continue the game after a small change and recompilation, IF you ensured that all the data is serializable and has been serialized properly.

However, maintaining "serializability" of everything is incompatible with coroutines, as they break. And over time keeping everything else serializable while coroutines break becomes kind of pointless.

So, does anyone still care about maintaining ability to hot reload?

 

Make game data driven, and hot reload will be much simpler.
Depending which part of the game you reloading.
You can design game without using coorutines.
I practically never use them.

 

Does "daa" mean "data oriented" i.e. dots?

"You can" does not mean "you should".

Coroutines allow natural control of transitions, multi screen UIs and so on. Also AI without behavior trees.

"yield return showMessageBox()";

Basically, they provide an equivalent of green thread and allow you to create a control "thread" without actually making an OS thread.

 

Sorry, should be daTa driven.
I don't mean DOTS.

But I just realized, when you mentioned hot reloading, do you mean scripts reloading at runtime?
Or just game assets, like textures, meshes, properties etc.?

 

I mean that in unity it is possible to start play mode, pause, edit a script and then continue without restarting play mode from where you left it off. If the components were carefully designed to serialize properly. This mechanism breaks coroutines and certain classes, becuase those do not serialize properly.

 

If we're talking about the editor hot reload (Recompile And Continue Playing setting), then I don't care about that anymore, not the slightest. Since I develop everything without domain reload, exiting and entering play mode is super-fast. I also save my blackboards and other status data into SO assets, so they remain intact unless I choose to enter play mode with the intention to clear them out. So basically I can continue playing where I left off last time.

Edit: and BTW, I use a hidden gem from the Asset Store. It's called MEC. It is very simple, but very fast (and less garbage too) implementation of coroutines. With a simple extension you can even put them on separate threads (if the workload is big enough obviously).

 

Curious about what 'Blackboards' are here. Just not a term I've come across yet.

Though I also heavily use Scriptable Objects, so I can tune small things on the fly without having to pause or reload the game. Inventories, dialogue, even quests.

Similarly I've been using UniTask to use async functions like you would Coroutines.

 

My game runs the main simulation on a separate thread and it seems like whenever I pause and try to resume it breaks, so I don't use hot reload. I wasn't even aware it was a thing.

It's critical for UWP of course, and nice for WPF.

 

The object we're storing values for gameplay like "the door ID 2233678 open" = true / false or "bad guy ID 84736 is killed" = true / false. That sort of things. If something is happening in the world, you write it on the blackboard and then everyone can access it. https://en.wikipedia.org/wiki/Blackboard_(design_pattern)
You can choose how seriously implement it, but basically they are a bunch of Dictionaries with control mechanism for writing and reading.

 

Well that's quite interesting. Definitely another subject for me to look into, though it seems well high-end for my knowledge at the moment. Still, thanks for the titbit.

 

The pattern appears in AI/behavior trees. It is usually a sort of local/global key-value dictionary that AI agents can read and write into.

 

Making stuff work with hot reloads is so much more work than its worth.

I've been using rider, which doesn't even let unity attempt it by default, it prevents hot reload until you exit playmode which is a godsend honestly.

 

I'm just a hobbyist but this never even occurred to me to try. I don't think I would find it useful.

 

You need to limit yourself to serializable Unity types for everything. That's far too limiting for most projects. No Dictionaries, no HashSets, no Queues, no Stacks, etc. Are Unity's own packages like Input, SRPs, Addressables, etc. even compatible with this?

 

You actually can work around that by creating your "SerialDictionary" which implements ISerializationCallbackReceiver and thus saves data. Same goes for sets and so on.

The deal breakers are Coroutines and multiple references to the same objects.

 

Also: C# delegates, static variables, and native collections. Forget about singletons.

Far too much work for little gain, specially when you consider having to go through third party code to ensure compliance.

The time spent making the codebase compliant with hot reload and will easily negate the time gained by using it. Good luck enforcing this in a large team.

Also remember that Unity serialization is not free: the more objects with serializable fields your have, the longer it will take to enter play mode, load scenes, and instantiate prefabs.

 

* I believe static variables persist through reload unless you're using the new "fancy slow like hell play mode" which specifically wipes them out.
* There's UnityAction which is serializable.
* Singleton can be made to work if it is based off MoneBehavior. Basically you'd need to override OnEnable/OnDisable to set/unset the singleton. Then it will survive the reload.

You have to understand that I'm not promoting serializable codebases, though.[/QUOTE]

 

It's a lot of work to maintain, that's for sure. I wouldn't call maintaining game state through a reload "little gain", though.

The number of times that I've spent an hour plus debugging / fixing / testing something because it happens minutes into a play is much higher than I'd like. Being able to make a code change and just test it in-situ would be fantastic and a significant time saver in some cases. Being able to experiment and iterate on stuff without starting play runs from the start every time would be neat, too.

So yes, I care. But despite that...

No, it's not something I maintain compatibility with, because of the restrictions it comes with. I always like the idea of maintaining it, but don't bother because in the course of a significant project I feel there's a significant risk it'll end up broken anyway. Especially if there are 3rd party assets involved.

I would love it if Unity's serialization handled more stuff in general. Not just for this particular use, of course.

 

A domain reload wipes out all statics. It's the new "disable domain reload on enter play" mode which keeps them around, by not doing a domain reload on enter play. But any code changes would still require a domain reload: Unity is basically saving all objects in the active scenes, tearing all C# down, bringing them up, then reloading the saved state.

Anyway, if the onDisable and onEnable events are fired singletons can be reassigned, but on the flip side now you have something else to be aware depending on what you're doing in your onEnable/onDisable methods.

 

#HotReloadForLife. Even though I use a ton of coroutines, I use hot reload all the time. Yes, it does require you to know serialization well but eventually, a lot of those things may need to be structured for serialization anyway. After all, a lot of games require a save feature.

Prototyping without hot reload isn't really prototyping IMO. No hot reload would probably be fine if you a just following an existing script for your project, but when being creative and innovative I'd recommend making the effort and switching your mindset.

 

This is madness.

 

I see these things as something where it seems good to implement at an engine level at first, but quickly spirals out of control unless there's a lot of fine grain control. To get that control, I actually implement my own system based on scriptable objects since those persist data and allow for editing at runtime. I've basically built my Unity dev framework stuff around this.

 

Many people I've worked with, myself included, tend to find slow feedback cycles to be madness actually. Hot reload often provides the fastest possible feedback cycle. Additionally, I actually find that supporting hot reload has tangential benefits. It tends to lead to better Class design, and better portability of data and steers you towards good modularity.

 

Can you show me examples of your published creative/innovative work that includes support of hotreload post release?

I've gotten a little burned out on pure theorycrafting in these sorts of discussions. I'm more interested in things like the scope of the projects where you used this approach, the amount of man power and budget you had to devote to the required functionality, etc.

 

Any recommended resources on this topic?

 

It sounds nice in theory, but in practice I maybe use hot reload once per year. If not once per several years.

It sounded like an incredibly important and amazing feature early on when I was starting with unity 5, I admit that.

Hot reload would see more use if it was tied with some sort of serialization system, where serialization would mean serializing to disk. But unity doesn't really include such system by default. It does include systems that can be used for saving game state, yes, but not really a "save system". Unless there's another hidden and poorly advertised module somewhere.

 

That's a fair and astute thought. I certainly have too many examples to name, but they aren't in the Unity or gaming space, so your skepticism is healthy. (Skepticism is always) (Here's my story.)

This notion is definitely not anywhere close to "theorycrafting" though. Just compare Apple's UI Kit and Apple's SwiftUI. It's plain to see one of the greatest design companies in the world understands this notion.

Many tools for JavaScript have been built for this notion as well. You could also look at Google's work with Flutter. Check out the rise of PHP during the early 2000. Follow the progression of Android Studio. Between Xcode, Android Studio, and Chrome Developer Tools, it's categorically apparent that hot reload is a clear and present dev experience tool.

I think everyone can agree that seeking the fastest possible feedback cycle is apparent in many types of real-world production as well.

It probably could go without saying, do what works for you and your team. Strive for the fastest feedback cycle possible for your situation. For instance, I find Lurking-Ninja's comments above very interesting. Does hot reload work for 100% of my Unity project? No, but it's a great tool for certain assemblies and in certain places.

The provocative nature of my earlier comment stems from the fact that I believe it would be a travesty if Unity Editor were to abandon hot reload development. The concept is definitely where development, in general, is and has been headed.

 

Would say it depends on the usecase. For visual stuff it's useful. Hence why the UI Toolkit supports it in Unity as well as JS frontend systems.
But do you really want to hot reload game logic? The code-flow behavior of objects? That bears quite the risk of introducing bugs or getting frustrated when things don't work after all when restarted.
Unity has the inspector where you can modify input data any time at development-runtime. What are the cases where that does not suffice?

Edit: I should add: My inspector based workflow improved significantly after installing one of the several assets for selective runtime-persisting of game objects.
ScriptableObjects are an option too of course, as others said. Personally Inonly use them when the data they contain is needed in more than one place or there is an architecture reason to have multiple sets of data.

 

None of those are videogames.
Additionally, hot reload capability may incur overhead, depending on language used and implementation.

 

Not that I'm aware of, I went (... am going...) trial and error mostly. But if you have any concrete questions, I can describe what I'm doing and what are the effects so far. I'm too lazy (and don't have too much time) to write an article.

 

Right, but I think the point is being slightly missed there. The question isn't "is hot reload valuable in general?" The question is "is hot reload compatibility worth the implementation and maintenance costs while developing complex games in Unity?"

A few thoughts on the matter, which aren't intended to convince anyone one way or the other:
- A bunch of stuff that's super valuable to be able to change in real time does not need hot reload. Anything which can be implemented as scene content rather than code (in reference to the given examples, this includes almost everything about our UIs thanks to in-scene editing and serializable events) does not need hot reload to reach immediate iteration time.
- Anything which can be exposed as a variable also does not need hot reload for immediate iteration time, because that's already supported via other systems.
- When we do need to change the behaviour of something, i.e. where changes do need to involve code modification, the scope of what we can do with hot reloaded code is often limited by other factors anyway.

With all of that in mind, my personal feeling is that hot reload is probably far more useful in prototyping / early design stages of a project than in the later phases. I have no evidence to back that because I've not bothered maintaining it in general. Whether or not that has been the right choice, I don't know.

 

I don't mean to be offensive about this - but this is what I mean by theorycrafting.

The question of hotreload isn't a question of "is having a faster feedback cycle good or bad?" the questions are about the costs and benefits.

Is hotreload worth giving up stuff like iterator methods, worry free use of functional stuff like curry and closure? What about exposing tons and tons of potential private state for serialization , what about static state? What about if you require large amounts of data in order to guarantee stuff like AI, or world modification.

It's possible to workaround all of this, to custom serialize a bunch of other stuff, to avoid the use of certain types of structures, etc. To build out more and more serialization infrastructure to cover more and more edge cases.

But all that costs time, and perhaps most importantly it's going to require constant maintenance. When something in the hotreload process breaks, are you really going to stop working on x, switch gears and hunt down the obscure cause of the problem?

For me, it was that exact maintenance that first caused me to ditch hotreload support the first time. I wrote something that broke the process and just said "Enough, F--- it". After that I never looked back.

Sometimes when prototyping or something I'll keep support for hotreload but not on anything more complicated. Nopeee.

_____

Damnit I didn't see @angrypenguin beat me to the punch

 

Thanks for sharing the insights.

Sort of to the point @angrypenguin made, I do find myself doing a lot more outside of play mode and right within the scene, but still via code; using custom inspectors. And that usually is when I am dealing with coroutine stuff.

Private stuff can be handled quite easily:

Code (CSharp):

1. [SerializeField, HideInInspector]
2. private int myInt;

Unless something else was meant by that?

Something to consider, doesn't all innovation involve theorycrafting? Isn't it by definition theorycrafting? I like the word, but I tend to have a different connotation from it. All the things I mention are proven ways to develop software. I guess it's a theory for me in the realm of Unity and Unity's version of play mode hot reload. It's worked for me some places so far. I like the push to consider the trade-offs.

There are definitely places where I've shifted tactics, but I keep hotreload as a tool and the workarounds to keep it running have made my project better organized and able to be pushed to new limits.

 

During my years of interaction with unity this feature has never worked for me. (Always got some kind of exceptions after a hot reload)
And frankly speaking I cannot imagine myself designing a game code just to support this feature.

Do you know if the source is divided into multiple assemblies with assembly definition, will hot reload reload only the ones that have changed ?
This may make it more useful.

 

Does not work this way unfortunatelly ... but see my later point you can create externally compiled assemblies in a standalone c# project and load them at runtime.

In my case I never aimed to leverage Unity c# hot reload, I guess here are the following reasons :
- Was more thinking of prototyping my game than this. When you are just refactoring around every hour it's totally not helpfull.
- It would have been helpful NOW, by now I mean several years later, when I'm iterating on balancing, adding content and really atomic features.

Yet I actually do not need it because,
- We leverage a lot the asset reload capabilities (UI, Texture, 3D models, ...)
- We use a lot of Json files for configuration (that can be reloaded and deserialized again at runtime )
- We could, but are not yet, manually reloading "Plugin" assemblies that are actually implementing game rules (just a bunch of classes you know). This would also allow for "modding" of game rules.
- Now I know what I need to iterate on and fix in the client, I just put on Scriptable object where necessary. Recently just created SOs so I can iterate on Templating while in game (we use mustache). I have a lot of SOs that actually enclose game content, such as units, attached models, sounds, animations etc ...

So basically, not sure if implementing and maintaining Unity all round hot reload is any feasible nor useful. Better think of an architecture that leverage the points I stated, you'll have way more control.