Slow down the process? If you build code that’s so fragile so it needs to be run exactly at the right time in your frame life cycle, that will surely slow down development time when requirements change etc. Or a new team member is introduced to the code base etc.
MonoBehavior api should not be looked at like some god like manual how to make game domain APIs
We’re game developers not enterprise developers. Outside of projects with indefinite lifespans like MMOs if your requirements are changing during the main development of the game you likely did something wrong during the prototyping stages.
While this may sound great in theory in reality unless you limit yourself to hiring enterprise developers you will be hard pressed to find a game developer that won’t struggle with enterprise methodologies.
Hey, at least the code will not have random bugs from machine to machine depending on whether or not script A randomly decided to run before Script B.
But yeah sure, let all the scripts update in a random order. 
1 out of a 100 players should have a fun time playing your game if they get lucky. 
What you describe is called waterfall development model, that’s not how most well organised teams work. Software development is a agile business, things change, you might need to pivot because of some other game releases which changes things etc
Well internal changes between unity versions could very well change in which order components execute
Haaaaaaahhaahahahahahaaa… good joke. 
And that’s why we have Script Execution Order settings in case we need it.
Game development is not software development. Outside of edge cases where content is expected to be added on a constant basis what you describe here is not how this industry behaves. We make them with the expectation that they will have a finite amount of content and for the most part this content is planned ahead of time.
Gonna be honest, did not expect this post to become the clash of the Unity Titans.
I feel like a kid at thanksgiving listening to adults argue politics.
No idea what everyone is talking about, but also intrigued by the passion.
Gamasutra used to have post-mortems of games. Some explained how they had extensive late changes since they game wasn’t fun, or the client needed a change. Ideally you play-test with the crudest possible thing, only building textures, models, fancy scripts… when you’re sure you need them. but that seems to rarely happen. People I knew in the business were all about the Agile model – make enough to playtest, change plans based on that, make more … and plan to have at least 2 unexpected random changes.
I don’t think I’ve ever used script execution order. Sure, it matters for set-up, but Awake/Start handle most of that, or else a “manager”. Otherwise, take my Move/Attack example. Whichever order they run in will still give you Move, Attack, Move, Attack, Move, Attack … alternating. Script order won’t change gameplay, just maybe a small visual difference. I feel like it’s mostly for 3+ stage initializing in multiple scripts for old-style game designers who prefer letting scripts run on their own.
I always wanted to be the hideous but friendly hippie uncle at thanksgivings, but probably I grew up to be a grumpy grandpa instead.
Yeah, that’s the thing, this argument is about a fringe edge-case which almost never happens and when it does it’s in a “write it once in the engine lifetime” code.
People should really get their terminology straight…
Maintainable code != Enterprise code
Optimized code != Maintainable code
Your code should be maintainable. How you do it is your business.
Your code should be optimized. How you do it is your business.
You can optimize your code by efficient architecture.
You can kill your performance by pushing unnecessary architecture.
Your code can be well maintained with good architecture
Your code can be hard to maintain with bad architecture.
//OT:
Funny thing how all devs here has the need to flex and push their ideas to others.
Everyone comes from different background, working on different games with different expectations. Thats fine.
But don’t be toxic jackasses on forums, that is not helpful to anyone.
The reason why people object to your stance because in domain of gamedev the approach you advocate is less maintenable than KISS.
Why do you think people bother arguing with you to this day?
Because maintenable code is important and in domain of gamedev what you propose usually ain’t it. And ideas you promote, especially when given to newbie, drive development and maintenance costs up. In gamedev. They’re often harmful.
Like Ryiah said:
That’s the issue.
I honestly don’t care what you believe in, what practices you use, what is your hardware, and how much cash you saved on tax returns. You have your own WIP thread, you could sing praises to valve index and dependency injection there all day long. That doesn’t concern me.
But the problem is that you drag practices that are ill suited to problem domain, and give them as advice to people.
That’s the reason for the reaction you receive.
I know you believe that but it’s wrong. I believe in KISS too. Our game is modular with a set of reusable components for interacting with VR items and objects. It’s very simple creating a new item because lf this. It also out of the box get networked.
I wonder if the OP “Not_Sure” can say the specific type of scripts they needed to change the order for? I’m wondering if it’s a case where both use Start and they didn’t know you could also use Awake, or if it’s the an actual case where Update A needs to run each frame before Update B (or, which is most common, it’s “Just do it this more normal way and what you’re worried about isn’t even an issue”).
Game-style-wise, I feel like MADdigital is working on a very different type of thing. Ultra-realistic games don’t have much give – they’re always ultra-realistic. It’s a real niche market, and I think so is VR these days. A version of World of Tanks with the correct chances to throw a tread, lose an arm reloading … would have 1% of the WoT player base say “finally” and jump on it. They would stop in the middle of matches to talk about how their granddad was also in a tank that suffered these 3 random accidents but lived when the other tank exploded for no reason. The rest would think it was much less fun. A more typical game is a theme, art style, general types of mechanics, and and gladly iterate until it’s fun. If play-testers really enjoy trigger-pulling to be saying “bang” into the microphone – that’s how it works now. Back to an ultra-reaslitic game, you can’t even change how saying saying “fire” and firing has a random 0.5 to 1 second delay, since that’s how it really worked. You’d only change it it you got better historical research.
Its for sure a niche in a already niche market. But you also have a content hungry audience.
Sure a complex and realstic VR game needs more maintainable domain than a much simpler desktop game. But maintainability always have importance in any domain.
@Owen-Reynolds Oh, I don’t have any issues.
A script of mine changed its order and caused bugs that took me about 5 minutes to figure out.
When I went to change it I found myself instinctively changing it in the inspector, although I new it wouldn’t work, then thought to myself “why shouldn’t this work?” And posted this thread.
Right. But what caused the bug? Was it actually a problem with the execution order? If so, was it merely start-up and using Awake() in one script fixed it? Or was it what we’d say is the real purpose of execution order: you actually needed the 2 script’s Update’s to run in a certain order?
I have a movement script for a FPS controller and I have independent scripts for various movement abilities like double jump.
The double jump has to go before the movement or else it will trigger after the initial jump.
I also want my movement script to be completely independent of the other scripts so that it’s easy to keep adding stuff to the controller for various games.
In this scenario you’re going against YAGNI principle (You ain’t gonna need it) and are trying to plan ahead for something that might not happen in the future. Meaning you think you might need to extend the script (which is not necessarily true) and you think you might want to reuse it in the future (also not necessarily true). You’re also trying to isolate it completely, which is not necessary.
The simple way to get it working is to make a monolithic class that handles player movement and control double jump from there. This will not be “easily extensible” with modules and subclasses, but you’ll be able to hack it to suit your needs later and it will be all in one place and likely easy to understand.
If you want to make it “extensible” and keep every mode independentn from each other, you’d need to utilize Decorator pattern ( https://en.wikipedia.org/wiki/Decorator_pattern ) and basically controll all movement from an equivalent of state machine written in C#. Meaning the player woudl be unable to move, and would forward update() calls to the currently active decorator. But this will take longer to write, will produce more code, and the movement logic will be split across multiple classes or multiple files.
I would recommend the simple way to do it…
P.S. Reminds me of Monolithic vs Microkernel debate…
I would make that with a single monoB, than add the abilities as strategies onto that monoB.