|
Yes I need the editor code. I want to make an assembly definition, but I am having some trouble. I think it is because the editor code is nested under a folder for the asset that already has an assembly definition; it would be putting an assembly definition under another one. I am asking about it because I don't really expect that I can casually move the editor folder out without the asset exploding. Edit: After trying again this morning it seemed to actually work (?). It looks like I have some other Odin Inspector things screwing up the build that need to be marked off in code. I'll know for sure how it all went when I can actually produce output and launch it. Rocko Bonaparte fucked around with this message at 16:09 on Mar 26, 2021 |
#
?
Mar 26, 2021 15:03
|
|
|
|
| # ? May 27, 2024 00:50 |
|
|
You can nest asmdefs. Code is bundled up to the closest asmdef in the directory hierarchy above it, so when you nest, you're excluding some amount of code from the root asmdef. Usually what trips me up with them is either setting up the dependencies wrong, or forgetting to click the "Apply" button at the bottom of the inspector for the asmdef.
|
|
#
?
Mar 26, 2021 17:09
|
|
|
I got it to work fine the next morning. I think both me and Unity needed a nap. I hit a pretty novel situation with Noesis GUI and game builds. These XAML files it uses will get included as assets if I have references to them like any other thing. However, I was loading them in from code when starting up my main menu, so they wouldn't get included. Noesis GUI's Unity library doesn't have anything to work with the resources folder. Finally, I thought I'd nail it with StreamingAssets but it actually bungles up looking up that path too. It just assumes you'll reference them in your stuff. I guess I do have a question in all of that. I have a subsystem managing my main menu state. I can have these "XAML assets" added as references in there to appease the Unity build gods. However, the subsystem is still loaded as part of a global state object. That object isn't directly put in a scene. So I feel like I might still get screwed out of having the assets included. What's my chances of that? What can I do? I have some feeling more than one person has created a scene where they just dump poo poo like this, include it in the build, and never actually use it. It would at least get Unity to include them in the build, right?
|
|
#
?
Mar 28, 2021 21:23
|
|
|
Old style: put the xaml assets under the Resources folder, now they'll always be included in builds no matter what. New style: read up on and convert to using Addressable Assets. If it's a hobby project resources is fine, if you're planning to ship commercially do addressables.
|
|
#
?
Mar 28, 2021 22:46
|
|
|
I don't think I can do either (directly). There is a load call in NoesisGUI's API that is looking for a path. That path doesn't appear to be so literal. I think if I have referenced the asset then its path relative my project root works. Meanwhile, an absolute path won't. I don't think it is literally opening it up like a file but I don't know what it is doing instead. I am trying to figure that out on their forums. But yeah, sure, for the stuff I can control better I will look up the addressable method. I probably have other things like that hitting me but the title screen screwing up hit first.
|
|
#
?
Mar 28, 2021 23:31
|
|
|
Metos posted:Old style: put the xaml assets under the Resources folder, now they'll always be included in builds no matter what. I keep reading about how poo poo Resources is and how awesome everything else is. But I'm working on a planned-for-commercial-release game, and my Resources amount to all of 79MB, and they work with minimal extra effort on my part. I'm really not feeling the need to switch, or understanding why switching would be beneficial in my case.
|
|
#
?
Mar 29, 2021 02:03
|
|
|
TooMuchAbstraction posted:I keep reading about how poo poo Resources is and how awesome everything else is. But I'm working on a planned-for-commercial-release game, and my Resources amount to all of 79MB, and they work with minimal extra effort on my part. I'm really not feeling the need to switch, or understanding why switching would be beneficial in my case.
|
|
#
?
Mar 29, 2021 03:01
|
|
|
Metos posted:Are you planning to release on Switch, where you'll likely need to do some more precise memory management? The recommendation there is at a minimum asset bundles, which if you're converting from resources you may as well instead do straight to Addressables Because I've been solo devving it I've been doing a ton of triage in terms of what I work on. Switch is maybe a possibility, but my impression is it's a little underpowered so I'd be concerned about performance when there's a lot of ships (my game's an arcade naval combat game; I've done a lot of work to minimize CPU load but that only goes so far when there's a hundred ships sailing around). But OK, if I were going to do a Switch release I'd need to do a bunch of work, which would include switching away from Resources. Up until then, any other really compelling reasons to avoid Resources?
|
|
#
?
Mar 29, 2021 03:17
|
|
|
TooMuchAbstraction posted:Because I've been solo devving it I've been doing a ton of triage in terms of what I work on. Switch is maybe a possibility, but my impression is it's a little underpowered so I'd be concerned about performance when there's a lot of ships (my game's an arcade naval combat game; I've done a lot of work to minimize CPU load but that only goes so far when there's a hundred ships sailing around). It depends if you want to improve memory usage, build times, or load times of your game. If any of those things are a problem or annoying, look into addressable. If not, leave it alone.
|
|
#
?
Mar 29, 2021 04:39
|
|
|
Do Addressables feel like they'll be around as the way to go for awhile?
|
|
#
?
Mar 29, 2021 04:58
|
|
|
Bruegels Fuckbooks posted:It depends if you want to improve memory usage, build times, or load times of your game. If any of those things are a problem or annoying, look into addressable. If not, leave it alone. Gotcha. Memory can be a bit of an issue sometimes, but more because of the sheer amount of instantiated stuff I have due to how my ships work*, not so much because I have a million textures loitering about. Similarly, my load times are mostly spent in the first frame of the scene as a bunch of my code runs and says "whoops I need to create 50 new ships now". The kind of thing where I think the only realistic solution, short of a complete overhaul of how missions are stored, would be if Unity allowed multiple threads to do GameObject.Instantiate stuff. And builds aren't a major issue either. So I think I'm good to keep doing what I'm doing for the foreseeable future. Thanks! * Read a JSON file, it says "use this hull, then put this part here, that part there, this gun over here, this much armor, these secondary systems, etc. etc. etc.". It's more or less a prefab, except in JSON, which is convenient for development and modding purposes. The mission files are similarly big JSON blobs, and I just have a single "mission" scene instead of having one per level
|
|
#
?
Mar 29, 2021 05:04
|
|
|
Rocko Bonaparte posted:Do Addressables feel like they'll be around as the way to go for awhile? Addressables are built on top of asset bundles, so those are still around too. But yes, they'll be around for a while. Several services (eg https://unity.com/products/cloud-content-delivery ) are being created such that it would be inconvenient for unity to abandon them.
|
|
#
?
Mar 29, 2021 12:44
|
|
|
I figured out there was some alternative way to dynamically load the required Noesis stuff so I'm thinking it might be possible to use Addressables for it too or something. It's kind of odd since they didn't even recommend the way I figured out, but I eventually deduced it from skimming lots of unrelated posts.
|
|
#
?
Mar 29, 2021 18:59
|
|
|
Has anybody here written a custom ScriptedImporter? I'm trying to figure out how to do this right and whether or not it'll ultimately work on Resources (or Addressables?). I have scripts (custom scripting language, not MonoBehaviours) as raw text files that I need to get properly packaged with everything. I am looking into doing this more tightly than just dumping them in StreamableAssets. I create a ScriptableObject to contain the scripting data. The raw script text is in there right now but I might pre-compile at this point instead later. It looks like I do everything with the AssetImportContext. So I am making an instance of this ScriptableObject and assigning it to the context using SetMainObject(). Is that the general idea? Does this mean it'll automatically work with Resources too? The example from Unity's documentation is using File.ReadAllText on the context's asset path. I imagine that would screw up if it was trying to load from resources. Is there something else I do for that?
|
|
#
?
Mar 30, 2021 07:42
|
|
|
Addressable suck so much in ways that are both obvious and only unravel over months of loving with it. It also way slows down build testing because they love to blow up builds in dumb ways. I would highly recommend this free open source alternative which is also just another wrapper around asset bundles but has been far easier and more stable for me.
|
|
#
?
Apr 2, 2021 00:51
|
|
|
FuzzySlippers posted:Addressable suck so much in ways that are both obvious and only unravel over months of loving with it. It also way slows down build testing because they love to blow up builds in dumb ways. Ooh, this is timely. I was just thinking about getting into addressables. The one thing that make addressables really cool is the asset updating part. This way you could, in theory, create assets that are updated without needing to update the actual application. As with everything Unity does: no idea how robust this is. Edit: after reading about it some more, it seems it would support the above. Thanks for the rec. Well I'll plug my own favourite asset: If you need to do lightmaps, check out Bakery. It truly is magical compared to the builtin lightmapper and makes the whole process really smooth and actually fun to do. https://assetstore.unity.com/packages/tools/level-design/bakery-gpu-lightmapper-122218 Mr Shiny Pants fucked around with this message at 07:25 on Apr 2, 2021 |
|
#
?
Apr 2, 2021 06:59
|
|
|
On a tangentially-related note, how would y'all recommend handling modded-in 3D models? Ideally I'd like something where I can walk a directory structure inside of StreamingAssets, discover .fbx files (or whatever), and invoke a function on them to get a loaded model with its rigging, materials, vertex colors, etc. Mostly I want that because it's compatible with my current asset-loading system and having modders put stuff in StreamingAssets implies they don't need any more tools than the 3D modeling program itself. I know that asset packages are the standard for this...I'm not thrilled by that idea because asking modders to install Unity and futz around with builds seems like a lot for folks who just want to tinker a bit. It obviously makes more sense for the heavy-duty modders, but I don't have any of those yet. I'm close to dropping the $45 on this asset to see if it does what it claims to, but I'd like to hear about other opinions first.
|
|
#
?
Apr 2, 2021 23:34
|
|
|
I don't think just a model importer will be enough to satiate modders. If the game gets popular it will take about 20 minutes for someone to figure out what dll to modify so they can rewrite your asset loading routine and import whatever code they can dream up. People needing to install unity won't really be an impediment, if someone knows how to generate an fbx (they'll be using blender so the learning curve is steep) they won't think twice about installing unity. It happens so easily with Unity games you might as well design for it and earn some goodwill. If you really want to serve people who have zero asset creation skills you'll want to do it in game, some kind of in game browser to pick new assets from, installing them automatically.
|
|
#
?
Apr 2, 2021 23:49
|
|
|
Well, the planets must be maligned in whatever way again that prevents me from debugging my external libraries attached to Unity. Let's hope the Visual Studio update kicks it in the pants.
|
|
#
?
Apr 3, 2021 19:48
|
|
|
xzzy posted:I don't think just a model importer will be enough to satiate modders. If the game gets popular it will take about 20 minutes for someone to figure out what dll to modify so they can rewrite your asset loading routine and import whatever code they can dream up. People needing to install unity won't really be an impediment, if someone knows how to generate an fbx (they'll be using blender so the learning curve is steep) they won't think twice about installing unity. It happens so easily with Unity games you might as well design for it and earn some goodwill. How popular is "popular" here? Are we talking Minecraft popular or "small indie game" popular? I don't feel like I can realistically hope for any more than the latter, so I'm trying to cultivate a mod scene without being able to expect any particularly large amount of determination on the modder's part. Keeping the friction level as low as possible feels like a smart thing to do here. That means minimizing the amount of stuff the modder has to install, and shortening feedback loops. "Export model to StreamingAssets -> run game -> navigate UI to look at new model" is a slightly nicer loop than "Export model -> make build to StreamingAssets (or wherever) -> run game -> navigate UI"...or am I missing something about how the asset packaging system works? I freely admit I have not looked at it yet. The specific things I'm looking to have modding for here are basically more player designs. My game has customizable warships, comprising of a ship hull, a bunch of parts added to that hull, and custom flags, decals, and paint jobs. The last three are trivially moddable -- just drop a PNG into StreamingAssets and away we go. The first two are trickier: the stats are easier to mod (just text in a JSON file) but the models are not, at least not yet. My expectation is that I can get ~80% of the modding that I can reasonably expect to attract, if I just add support for loading custom 3D models. Hence my interest in focusing on that particular aspect of modding.
|
|
#
?
Apr 3, 2021 20:02
|
|
|
Is the term "asset" getting overloaded here? If they are picking stuff even from some walled garden, I would assume it would still have to go into StreamingAssets to be recognizeable. I was getting a vibe there was something else from the conversation.
|
|
#
?
Apr 3, 2021 23:23
|
|
|
TooMuchAbstraction posted:How popular is "popular" here? Are we talking Minecraft popular or "small indie game" popular? I'm not an industry insider so I can't give any usable estimate on the thresholds, but just look at the number of games that have been modded on the steam workshop or mod.io. Or nexusmods if you want to find out how many people like boobs in games. But regardless, people love to mod games. You definitely can't go wrong by supporting them.
|
|
#
?
Apr 3, 2021 23:34
|
|
|
OK, let me provide a little more detail about where things stand currently, and what I think is a reasonable goal to shoot for. Currently, my StreamingAssets has:
The goal I'm shooting for is to add just the 3D models for ships and parts to this list. Notably, this would not include adding any of the following:
If/when I were to add support for the last three above, asset packages would almost certainly be the way to go. I certainly can't imagine trying to write my own custom wrapper for generating Unity particle systems, for example. Sound effects should be doable from StreamingAssets though, they just haven't been a priority. xzzy posted:I'm not an industry insider so I can't give any usable estimate on the thresholds, but just look at the number of games that have been modded on the steam workshop or mod.io. Or nexusmods if you want to find out how many people like boobs in games. Oh yeah, I'm trying to support mods! I feel like the question here is should I do more work to make modding certain things easier, vs. just saying "everything has to go in an asset package". Either way, internally I'll just be hooking all this stuff into my AssetDB class, which handles loading and organizing assets for everything else. So my internals shouldn't need to change, aside from the bit that does the initial asset discovery.
|
|
#
?
Apr 3, 2021 23:49
|
|
|
xzzy posted:I'm not an industry insider so I can't give any usable estimate on the thresholds, but just look at the number of games that have been modded on the steam workshop or mod.io. Or nexusmods if you want to find out how many people like boobs in games. How relevant is that to tiny team indie games? Yes someone will spend hours figuring it out for open world AAA games, AA stuff like Kingmaker, or successful indies like Noita but when I see your average tiny team indie games I barely ever see their mod tools used much less elaborate dll hacking. Modding is a powerful success multiplier but I don't know how much it actually helps to get those critical sales that make a game visible. I don't think it turns around a release buried on Steam with a couple dozen reviews. I don't know how much modding matters but I don't think the success of hit games that added modding later is a good barometer.
|
|
#
?
Apr 4, 2021 11:58
|
|
|
I figured out how to attach to me Unity code from external projects: 1. I had to delete old .mdb files from my References directory. 2. I had to set the Debugging Information type from "Full" to "Portable." I thought this was kind of superstitious, but I had one project set to Portable and my other ones were Full. Only the Portable one's breakpoints could be found. I still cannot step into my external code from Unity. If I try to go to the definition, I just get the metadata. Sometimes I want to debug this way because I'm invoking my external code specific ways at specific points, and it's much easier to hit it from one of those contexts. Otherwise, I have to filter them out when I'm debugging from the external project itself. Does anybody have an ideas on this one?
|
|
#
?
Apr 4, 2021 16:53
|
|
|
Rocko Bonaparte posted:I figured out how to attach to me Unity code from external projects: you've tried putting the pdb files are in same directory as the dll unity is loading, right?
|
|
#
?
Apr 4, 2021 17:02
|
|
|
Bruegels Fuckbooks posted:you've tried putting the pdb files are in same directory as the dll unity is loading, right? Oh yeah, dlls and pdbs are all getting shoved in my Assets\References directory under the project root as a flat pile.
|
|
#
?
Apr 4, 2021 18:37
|
|
|
Rocko Bonaparte posted:Oh yeah, dlls and pdbs are all getting shoved in my Assets\References directory under the project root as a flat pile. Does it break if you put System.Diagnostics.Debugger.Break() in the method you want to debug? Did you disable "just my code" in visual studio options?
|
|
#
?
Apr 4, 2021 18:41
|
|
|
Bruegels Fuckbooks posted:Does it break if you put System.Diagnostics.Debugger.Break() in the method you want to debug? Did you disable "just my code" in visual studio options? I had "Just My Code" enabled in VS2019. Good catch there. Also, I had to restart VS2019 and Unity before I could step into anything. Regarding setting Break(): I had not tried that specifically, but I had tried detecting System.Diagnostics.Debugger.IsAttached and trying to hit code inside the conditional. It was a goofy recommendation on the Unity forums that I didn't think would work. It didn't work. Do you want me to kind of revert and see if I can make it happen that way? It isn't a thing I'd do for trying to step into the code from my Unity project so I got confused about what you wanted me to do with it.
|
|
#
?
Apr 5, 2021 01:16
|
|
|
Rocko Bonaparte posted:Regarding setting Break(): I had not tried that specifically, but I had tried detecting System.Diagnostics.Debugger.IsAttached and trying to hit code inside the conditional. It was a goofy recommendation on the Unity forums that I didn't think would work. It didn't work. Do you want me to kind of revert and see if I can make it happen that way? It isn't a thing I'd do for trying to step into the code from my Unity project so I got confused about what you wanted me to do with it. Break() just makes it so the program asks to attach the debugger, and breaks at that specific line of code - it's an alternative to actually putting the red dots in the visual studio debugger. I probably should've asked about "just my code" before adding that as a troubleshooting step. If you're at the point where putting the red dot in the debugger works, no need to screw with Break().
|
|
#
?
Apr 5, 2021 02:08
|
|
|
Well I just had a hell of a time compiling stuff in Unity, taking upwards of 20 minutes to build something for Android. Turns out Windows Defender decided to scan everything every time. Excluded the Unity.exe, the unity folder and my project folder and now everything is snappy again. Just a heads up.
|
|
#
?
Apr 6, 2021 10:10
|
|
|
Mr Shiny Pants posted:Well I just had a hell of a time compiling stuff in Unity, taking upwards of 20 minutes to build something for Android. Thanks foe the tip, gonna do the same
|
|
#
?
Apr 6, 2021 17:52
|
|
|
Does anybody have any cool scheduler-related stuff in Unity they've liked? I'm talking about setting up events to kick off after a certain amount of real or game time elapses. There aren't many assets out there for it in the asset store. I also have a peculiar case with scheduling that has to do with serialization and scene management. When I change back and forth between scenes, I have to rebind scheduled items to the recreated objects representing whatever made the original scheduled reservations.
|
|
#
?
Apr 6, 2021 19:43
|
|
|
Rocko Bonaparte posted:Does anybody have any cool scheduler-related stuff in Unity they've liked? I'm talking about setting up events to kick off after a certain amount of real or game time elapses. There aren't many assets out there for it in the asset store. I also have a peculiar case with scheduling that has to do with serialization and scene management. When I change back and forth between scenes, I have to rebind scheduled items to the recreated objects representing whatever made the original scheduled reservations. I wouldn't have that stuff live in Unity land. Not much reason for it to be connected to scene management at all. I wrote a task system modeled off Unity's coroutines for that sort of thing. I found it especially useful to have them completely separate from Unity control so I can run them in the editor for testing (like testing animations or tweens without having to start the game) and they don't create any garbage. I don't serialize them since they shouldn't persist on save/load/new game as I don't want to have to figure out which ones should and shouldn't. Anything with that much state should be a System in my code and not a task. This is an old example of a task. Other scheduling related code is connected to an event bus so it's easier to log and I don't connect that to Unity land at all. I run an ECS + events framework since I found it better debugging to have an explicit event bus rather than do the awkward temporary component shuffling I've seen in most ECS setups. Though I also aim to create the absolute minimum of gameobjects possible since I find them too much of a source of headaches. If I want lazy editor debugging I'll have a ScriptableObject that shows whatever is going on in the non-Unity code I care about rather than juggle GOs.
|
|
#
?
Apr 6, 2021 23:43
|
|
|
I just use Task and migrate back to the main thread using a task scheduler preserved from the main thread. No reason to couple any scheduling stuff to unity callbacks.
|
|
#
?
Apr 7, 2021 00:58
|
|
|
Anyone here done much VR dev / have advice? I made a relatively small game using a Quest 1 via link (and made for Steam VR for the platform) last Summer and Fall. This next year and a half or so I'm planning on making a bigger game, ideally for the actual Quest store, and I'm trying to think of what to do for the development device part. Because the thing is, in my experience anyway, Quest 1 via Link was a colossal pain in the rear end to develop on. When playing games it's been great, but when trying to playtest my buggy Unity poo poo it would disconnect all the drat time, and sometimes it got really hard to tell if it was my problem or Link / my motherboard or whatever. I love VR so I'm fairly happy to pick up another headset just for developing on really and I was thinking of getting a wired one to hopefully avoid my perceived issue, but then I've also been hearing great things about Quest 2, so I'm wondering if 1. Link works better for it / better in general since last Fall (or perhaps I should develop on Virtual Desktop instead of Link?) or 2. I should just suck it up (once I figured out a few tricks, it did get less temperamental on the Quest 1) since it seems to make sense to develop on the platform I'm wanting to release on? For a while I was thinking about getting a Rift S just for the wiredness but it seems like a shame to get a platform that's already basically obsolete; and then going for a non-Oculus also seems like not the best idea when I'm wanting to release on Oculus. Or are there other people that have worked on Quest that didn't have a problem? I did all my testing etc via Link (and my last game wouldn't have run well on Quest), but maybe I should be playtesting on Quest as a standalone each time or something instead? Also kind of just curious about how worthwhile owners of Quest 1 think a Quest 2 is to them? The performance bump is really appealing. e: For that matter, any VR theory books people would recommend would also be welcome. I did that Oculus + Unity course a bit back which goes into common stuff like avoiding motion sickness, FOV goals etc; read some from Brenda Laurel (Computers as Theatre, some lectures) but her work is mostly concerned with pre-2010s stuff, and I just recently started Jason Jeral's The VR Book which looks relatively comprehensive but is still from 2015. Curious if there's anything more recent people'd recommend?
|
|
#
?
Apr 7, 2021 02:44
|
|
|
FuzzySlippers posted:I wouldn't have that stuff live in Unity land. Not much reason for it to be connected to scene management at all. It's technically an independent project, and so the game save/load serialization stuff, but it's all triggered by scene changes. Change scene, change levels. It saves the previous level's state in the save cache and will load from there when going back. Saving the whole cache with the currently-loaded level's snapshot is the same as creating a full game save. However, now I have a gotcha when something from the old level wanted to do something by I changed levels. I'm thinking I need to give some policy to allow some flexibility to handle it, but one of those will include "call me back when you come back to my level and we'll pick up from there." I guess I'm opening myself to a larger simulation that could continue in the background but I don't want to go there for once. But for what I have, I get to deal with the previous level haven't been completely heaved out of memory and I'm instead talking to equivalent dopplegangers that got disassociated with the scheduler when the originals get wrecked. I guess for you and leper khan: consider this situation. Say I have something in level A that wants to run every 5 seconds of game time. You go to level B after 2 seconds passed, saved and quit. You reload to level B and go back to level A. How do you ensure level A's thing happens 3 seconds later?
|
|
#
?
Apr 7, 2021 06:59
|
|
|
I use a Quest 2, it is pretty great and the amount of stuff it can push is really surprising. Too bad it's from FB. As for debugging, I just build to the headset and debug from there it takes some time and makes tinkering a pain but I haven't really found a better way.
|
|
#
?
Apr 7, 2021 07:02
|
|
|
Rocko Bonaparte posted:I guess for you and leper khan: consider this situation. Say I have something in level A that wants to run every 5 seconds of game time. You go to level B after 2 seconds passed, saved and quit. You reload to level B and go back to level A. How do you ensure level A's thing happens 3 seconds later? That doesn't seem like something that should live in a task system. That sounds more like something handled by an explicit System or FSM for the levels. Those should be managing the state they care about instead of a global state save of endless irrelevant things. There's a reason Unity has always pushed back on people wishing for a generic runtime serialization system. In particular that example sounds like the kind of thing that is often visual (tweening or whatever) that I'd rather just restart then try to hold its state so it can resume the tween. Even in AAA games you can see a lot of things that get restarted on load rather than have their state saved.
|
|
#
?
Apr 7, 2021 08:17
|
|
|
|
| # ? May 27, 2024 00:50 |
|
|
Rocko Bonaparte posted:It's technically an independent project, and so the game save/load serialization stuff, but it's all triggered by scene changes. Change scene, change levels. It saves the previous level's state in the save cache and will load from there when going back. Saving the whole cache with the currently-loaded level's snapshot is the same as creating a full game save. However, now I have a gotcha when something from the old level wanted to do something by I changed levels. What fuzzy slippers said about restarting makes sense to me. I wouldn't have this thing triggered by scene change though. At least not from the context of the thing itself. While for your current use case/project having a driver that utilizes scene change may make sense, scene changes are very much not the same thing as level loads in unity. It feels like you're making some very specific assumptions around your current workflows being generalizable that don't hold and would limit applicability of your library. Doesn't really matter unless you're planning on releasing/selling the thing though. Just sounds like it wouldn't work with additive scene workflows/etc. It also sounds like you're serializing out a bunch of physical state rather than your logical state. IMO this is a Bad Idea, and every system I've seen that tried to do that doesn't do the things I want. Especially across versions. I've found it's much better to serialize out the logical state, and rebuild all the physical stuff. That is: my logical state has nothing to do really with Unity or any Unity component. E: to answer your explicit question, the timer sounds like part of the logical state of that level. So I'd serialize out the timer (seconds elapsed since last trigger or something) and load it back in on load. leper khan fucked around with this message at 09:22 on Apr 7, 2021 |
|
#
?
Apr 7, 2021 09:18
|
|