How do you program a “level”?<\/p>\n
This is not usually a problem in a\u00a0game engine, but Unity requires you to isolate each “level” as a Scene. And Unity’s Scenes have some strange design choices (bugs?) – IMHO they were designed for toy projects, not for production games.<\/p>\n
Here’s a stream-of-consciousness on what works, what doesn’t, and how I can workaround \/ do it better within Unity… it’s not carefully researched, mostly it’s from memory \/ off the top of my head. So … it might not all be true :).<\/p>\n
When I switch to Unreal4, I’ll be using posts like this as a baseline to compare where Unity failed, and how badly – or vice versa.<\/p>\n
UPDATE: added some more approaches and ideas\/commentary<\/p>\n
<\/p>\n
For example:<\/p>\n
Unity’s scene-loading SUCKS.<\/p>\n
You can load one Scene, and then load another over-the-top. This has long existed in Unity Pro to some extent (allowing “level loader” Scenes etc), but U5 upgrades\/extends it a bit.<\/p>\n
As I understand it, Unity5 does NOT fix the problems, but it does mitigate them. In particular, I’ve looked at Editor changes to improve handling for loading multiple scenes at once. I haven’t experimented with this yet myself (I’m still on U4). From the videos I’ve seen, it looks like a definite improvement, but still quite a long way behind what I’d call “standard” in game-engines.<\/p>\n
If you’re able to use U5, I’d start with this, and see how far you can get with it. And then post \/ tweet about your tips and tricks, please.<\/p>\n
You can mark any number of GameObjects as “Hey, Unity! When you delete everything (which is stupid, but OK), don’t delete THIS one!”<\/p>\n
In theory, that means you can write your own mini game-engine (um, why are you using Unity again? Because you want to re-invent the wheel all the time, right? \/sarcasm) that stores all the game-data in a “don’t destroy” object, and then parses and loads it after the new Scene has finished loading.<\/p>\n
This doesn’t solve anything – it shifts the problems to a new place, but at least they’re now in YOUR code, instead of in Unity’s. You end up writing your own mini game-engine. You get almost zero help from Unity, and … to make it harder … you have to remain compatible with Unity’s proprietary data-handing: Initialization protocols, crappy Serialization, etc.<\/p>\n
This is the “real” way of doing DontDestroyOnLoad, the standard approach that is built-in to the programming language. It always struck me as bizarre that Unity added DontDestroyOnLoad when there’s a more standard approach already in place. Was it a junior programmer who didn’t know how to use the “static” keyword? Or is there something nasty buried in Unity’s core engine that breaks on statics? (hint: I can almost guarantee it would be a bug somewhere in the Serialization system, which I detest, in case you hadn’t noticed already ;). Almost everything nasty in Unity’s architecture comes back to that monster!)<\/p>\n
It has always seemed to work fine for me. But it’s scary: when will it stop working? How will you know? What Unity bugs are lurking here?<\/p>\n
Take all the game-logic that WOULD have handed data to your Scene as parameters (in any normal engine) … and embed that INSIDE the Scene, instead.<\/p>\n
When the Scene loads, it runs this logic, and goes “Oh! I seem to be missing lots of core data. I’d better recreate it on the fly!”.<\/p>\n
It’s a tortuous kind of logic, and it can be very confusing for new devs joining your team (and for yourself, if you take a break from the project and return later). But it has some significant benefits:<\/p>\n
Well, I’ve met people who claim to do it this way – make your Scene in Editor, then convert everything to Prefabs, then load the Prefabs when Scene loads, passing in a different list of “names of prefabs to load”.<\/p>\n
Oh man, please, no!<\/p>\n
Firstly: Prefabs in Unity are badly broken for anything complex like this. They don’t work, you should be avoiding them as much as possible – except for the simplest of use cases (non-nested, simple, small prefabs).<\/p>\n
Secondly: wow, this is tortuous. You’re abusing the “templated object system” to get around design-bugs in the “data layer” and “scene-loader”. It may be genius – but it’s the kind of genius that’s so unusual it’s prone to get broken in a future update to the engine, and Unity could legitimately say: “Wat? Why were you even doing that?”.<\/p>\n
If it works for you, great! But for me, this was always a mind-**** too far. Possibly I’m missing out, and this is a much better route than I realised. Mostly, it’s the fact that Unity can’t handle Prefabs that puts me off. U5 allegedly fixes some prefab bugs, so … I’ll re-consider this at some point. However, the history of Prefabs in Unity is ugly, and I’ll be very cautious about trusting them.<\/p>\n
This is an enormous stinking problem (throughout Unity!).<\/p>\n
It changes the balance of pros\/cons in the above workarounds. You cannot simply add named parameters to your static \/ DontDestroyOnLoad \/ etc – because Unity will piss all over the programming language and delete\/destroy\/corrupt them.<\/p>\n
(did I say I hate Unity’s broken-from-day-1 Serialization system yet? Yeah, well: I do)<\/p>\n
In the end, I’ve found that the most attractive part of DontDestroyOnLoad is that you can use:<\/p>\n
[csharp]
\nGameObject param1 = … ;
\nGameObject persistentObject = … ;<\/p>\n
param1.transform.parent = persistentObject.transform;<\/p>\n
\/\/param1.tag = … oh, no – can’t do this. Unity’s tags are hardcoded (that is NOT what Tag means, guys!)<\/p>\n
param1.name = "Parameter 1";
\n[\/csharp]<\/p>\n
You can then retrieve it later using something like:<\/p>\n
[csharp]
\nGameObject persistentObject = … ;
\nGameObject param1 = persistentObject.Find( "Parameter 1" );
\n[\/csharp]<\/p>\n
(assuming you get a reference to the persistent object somehow … e.g. make it a Singleton)<\/p>\n
I believe you can do this with static objects too (?) but … having a whole object graph hiding in a static member variable is getting into the realm of “this will probably expose bugs in Unity Serialization”. Best to avoid it: life is too short to debug Unity.<\/p>\n
We come back to the recurring flaw in Unity that undermines so much of the engine: Unity refuses to acknowledge that “data” is “data”. It keeps insisting: “No, no! Data is code and objects and graphics and a physics object and … and … and … and …”.<\/p>\n
(Let’s be clear: experienced programmers look down on Unity’s approach and are generally scathing. This isn’t fanboism – the Unity approach to programming largely died in the 1980s, for good reasons. It’s unhelpfully restrictive, and quickly proved very difficult to create complex programs. e.g. Video Games)<\/p>\n
Ideally, we would store our game’s Data as data, and hand that data to the Scene when it loads. Unity blocks us from doing that. Everything we do to emulate this (e.g. embedding a JSON (de-)serializer) is a workaround for Unity’s road-blocks.<\/p>\n
I’ve tried most of the above approaches with previous Unity projects, and none have worked out particularly well.<\/p>\n
What to try this time?<\/p>\n
Here’s my current needs:<\/p>\n
I’ve given up: I’m writing my own mini-engine to workaround Unity’s awful scene-management. Looking back over my many Unity projects, I’ve lost many days, probably more than a week, on having to constantly re-implement this core feature because Unity’s version is so FUBAR.<\/p>\n
It’s one of those bugs that makes me think Unity’s tech leadership never write games themselves; if they did, they’d refuse to put up with crud like this.<\/p>\n
Short story:<\/p>\n
This would be fantastically useful. It would make many of the workarounds above much easier<\/p>\n
It also exists, built-in to Unity. We know this: the Serialization system relies upon it.<\/p>\n
But they don’t allow us access (as far as I can tell: I’ve not seen a public API call \/ set of calls for this?)<\/p>\n
All Objects in an OOP language (C# included) keep track of the Class that created them.<\/p>\n
If Unity would do the same thing with “clone object1 to create object2” … again, that would make many of the above approaches easier and less error-prone.<\/p>\n","protected":false},"excerpt":{"rendered":"
How do you program a “level”? This is not usually a problem in a\u00a0game engine, but Unity requires you to isolate each “level” as a Scene. And Unity’s Scenes have some strange design choices (bugs?) – IMHO they were designed for toy projects, not for production games. Here’s a stream-of-consciousness on what works, what doesn’t, […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,67],"tags":[],"_links":{"self":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts\/3518"}],"collection":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/comments?post=3518"}],"version-history":[{"count":4,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts\/3518\/revisions"}],"predecessor-version":[{"id":3522,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts\/3518\/revisions\/3522"}],"wp:attachment":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/media?parent=3518"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/categories?post=3518"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/tags?post=3518"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}