Question on stable & consistent performance without version control

I started using LTS many months after using the non-LTS version. I struggled and learned how to use version control, starting with the most basic built-in given by Unity and now I'm using a much better one.

My scenario is I encountered 2 projects that got corrupted. In the first case, it corrupted after I finished my tutorial. My project worked perfectly and I was able to not just create the .apk file but run it and it worked well. I was very happy. Sadly, it suddenly got corrupted where the points suddenly could not display properly and later, it just refused to work for no reason.

In scenario 2, the project got corrupted when i completed 95% of the tutorial. I spent a few days / weeks and was finally forced to re-do the entir project.

So my question is : Is version control a compulsory practice here. Do experienced people feel their project can suddenly be corrupted if they do not use version control? Is this a common problem with Unity - whether LTS or non-LTS?

 

"Sudden Corruption" of the project is not something I've ever experienced on any non-experimental version of Unity. The only time I've had projects become irreversibly damaged is during Unity version upgrades. Often times when people complain about their projects "suddenly" breaking, it can be traced back to a change that they made themselves.

But version control is, as you say "compulsory", for many other reasons besides "sudden corruption":

• It saves you in case of hard drive failure or your computer getting hit by an asteroid or whatever (this includes 'sudden corruption').
• It allows you to collaborate with other people
• It allows you to experiment with dramatic changes to the game on branches with the ability to easily go back to the stable version of your game if things don't work out.
• If your users get errors in production, you can get your project into the exact state it was in when you built the version of the game that the user was playing when they got the error. This is essential to fixing these errors.

Experienced people don't ever find themselves in a situation where they are not using version control.

 

OK what you have given me is what I already found out in internet searches. However, a general backup is always good in case of a hard disk crash. I rarely hear that kind of problem but you never know. Anyway, I will rebuild my project and monitor it carefully. Version control already helped me find out and solve strange unknown errors.

 

I would make an effort to define what "corruption" means, in your case. You keep saying that your project was corrupted, but you haven't explained what that means specifically. I've certainly never experienced what I'd call "corruption" of any files in any of my projects. I've definitely experienced plenty of cases where things behave strangely after upgrading to a new version of Unity or of a package, which requires a bit of work to overcome. But, anyway, what's "corruption"? Without seeing specific errors or problems, it's hard to say what you're experiencing.

 

Corruption means that after you close the project, some things suddenly just don't work. In my case, there are no error messages. So if disabling game objects don't help, I don't have much choice but to re-do everything. I have in the past tried to repair parts of the project. Some worked, some didn't. I got fed up and deleted and re-did the entire project. I observed strange things when it did work.

 

"suddenly just don't work" is a very vague thing to say. In what way do they not work? There's always a reason for a failure, and there's always ways to diagnose problems. Are the ways that things suddenly don't work consistent?

I'm not trying to challenge you. I'm trying to understand if maybe there's just some practices that you perform that are not intended, and you're accidentally breaking your project. Unity has lots of "magic" to it. That is, there are things you're just not supposed to do lest you break things, though you won't know that until you run into the problem enough times and finally understand it. Some examples: Renaming scripts is a landmine - if the class name doesn't exactly match the file name, it won't work; A single script file can contain only one MonoBehaviour class - Any additional MonoBehaviours won't be visible to Unity.

Anyway, my experience has been that there are lots of ways you can accidentally break things and create a huge mystery for yourself. And that's happened to me a fair bit. But in basically every case, I've tracked down the reason for the problem, and identified it either as a reproducible bug, or as something I clearly did without realizing the impact. I've never experienced a single event I'd call "corruption", or that wasn't explainable, and that's having probably spent somewhere around 5,000-10,000 hours working in Unity. Next time you experience "corruption", it's probably worth digging a bit deeper into the cause, rather than writing it off as a random, irrecoverable failure. Maybe even seek help on the forums with specifics.

This is getting this thread a bit off-topic. Sorry about that.

 

Relax. I know you aren't trying to challenge me. I'm not trying to be difficult either. Check below what I have. The description is short & simple:

The project works perfectly without any error messages. In edit mode, no errors / compilation of any kind is detected. I close it and create the .apk. It runs on my device very well and I'm pleased with it. A few weeks later, suddenly, the points system just doesn't work. I did not modify anything or change the script names in any way. Absolutely nothing is changed. The only thing I didn't do is to save it under a version control app. This is what I mean. So how do you explain this? I'm aware that script names must be exactly the name. I get errors immediately. So do you have any idea why my project would suddenly fail like this?

 

Again, you're being kind of vague. I don't know what it means for "the points system just doesn't work". In what way does it not work, specifically? There's just so many reasons that some part of a game can break.

 

The scripts contain the codes and the scores are calculated properly & displayed. All of a sudden, the scores just remain at 0 and refuse to be displayed. Next, after trying out many different things, the score goes behind the background and doesn't even show on the screen. As I stated, I did not change anything at all - it suddenly just doesn't work. So what might have happened here? I'm re-writing the app as we speak. It would take me a few more days of constructing, testing and monitoring before I might have some idea what had happened. Bear in mind that everything already worked perfectly and I was able to load it on my device.

 

You should include some screenshots of the problem, including how you've set up your UI in the Hierarchy view, as well as the code you're using. It just sounds like you're dealing with bugs that aren't as easy to track down as you'd like. In which case, you'll either need to attach the debugger to determine what the state of the data is while the game is running, or add some Debug.Log statements to try to track things down. For example, if the score isn't updating, it could be cause the code that adds values to the total score isn't adding it, or that code is never being called for some reason, or the code that takes that total and applies it to the actual UI text might not be getting called for some reason. You'll need to add some diagnostics to nail it down. And usually, in doing so, you'll discover that the bug actually was related to some other change you made that you never expected would have caused this problem.

But anyway, this thread is completely derailed here, and probably few others on the forums here will wade too deep into it assisting you with specific issues. So, I'd start a new thread for the specific UI issue you're having, with screenshots and the code that you feel should be working. Feed free to @ mention me and I'll come take a look as well.

 

thank you. In another unrelated thread, someone really gave some nasty reply and made me very angry. To be frank, this thread is really what I think to be a useful thread of real concrete information i can use. I will take perhaps a week or more to re-do my app. I expect I should discover the real cause of the bug later. Then I'll be more than happy to update you on what I found.

 

Anyway, I'm giving you the screenshot of the actual situation so you can think what might have happened. In the meantime, a new app using a stable LTS version is being built. I'm sure I can find out what might have gone wrong - it happened to other projects before. In other cases, they were not surprisingly some rare stupid bug which I don't normally come across.

See my screenshot.

 

I looked at your project. The problem you're experiencing is 100% not a bug, and it's extremely simple to prevent the behavior you're experiencing.

The problem is that you have multiple different 2D/UI objects with the same "Order in Layer" value. The "Blue Rocket Background" and the Canvas that holds the "scoretext" TMP object both have an Order in Layer of "0". That means you haven't explicitly stated which should be on top of which, and you should expect potentially inconsistent results.

The "fix" for this is just to clearly use Order in Layer to control the order. For example, setting the scoretext's canvas's Order in Layer to "1" immediately puts that text on top of the background.

There's an full page in the Unity docs that talks about 2D sorting and this kind of thing: https://docs.unity3d.com/Manual/2DSorting.html The main take-away is that if you don't take some actions to strongly control the relative sorting order of two objects, they'll fall back on using what Unity calls a "Tiebreaker", of which the docs state: "Because this is an internal process that you have no control over, you should use the sorting options". Basically, if you're falling back on a tiebreak, you should expect inconsistent results. And notice how all of the other conditions listed on that page, such as distance from camera, could easily cause unexpected changes to the sorting order just by moving some other things around. The take away is: Use sorting order.

At a higher level, these are exactly the kinds of issues you're just going to run into a lot when building a game. You'll find that you think you understand how something works, or you'll find that something just seems broken, but it turns out there's merely some rules you don't know about yet. Unless Unity is literally crashing, you should assume your project isn't "correct". You just need to dig in a bit to debug things and learn what strange convention is causing the results you're seeing. Starting a project over from the beginning every time you encounter a bug in your own implementation is not feasible. (Notice I said "a bug in your own implementation", and not "a bug in Unity".)

Anyway, good luck with your future projects. I think you're just finding that Unity is a pretty complex piece of software with a lot of non-obvious things going on. It will just take some time before you develop the experience in instincts on how to approach problems like this.

 

yes I found that out in my other thread. Maybe you didn't see it yet. I did mention i will start another thread.
https://forum.unity.com/threads/cause-of-damage-found-followup-from-previous-thread.896975/

But now the scores still don't work. That's the next mystery for me to work on.

 

Well, there are two main take-aways here: The canvas sorting order issue shouldn't be considered a bug. It's expected that if you haven't explicitly set sort order (or controlled sort order via the other means listed on the docs) you should expect inconsistent results, potentially with each new Unity release. So the sort order issue in your project isn't at all surprising, and it's squarely your responsibility to fix. In all likelihood, the score failing to update is also due to a bug in your own code, not a bug in Unity.

The bigger take-away is that you've presented kind of an attitude that everything you're doing is correct, and any problems are bugs in Unity, or represent "corruption". So far, you haven't demonstrated anything like that. My advice is to first assume that you're simply doing something wrong, and get better at diagnosing bugs in your own code. When I think I've found a bug in Unity, I spend a non-trivial amount of time creating a sample project that clearly reproduces the issue. In most cases, when I do that, I discover that it wasn't actually a bug in Unity, and it was just a gap in my understanding. There's a lot to learn, much of it non-obvious. So I'd recommend assuming your own knowledge is flawed before assuming something is a bug in Unity. You'll learn more that way, and make better progress.

 

ok. thank you. I'll check back with the tutorials I have. I won't disturb you anymore.