Keep it super simple. Or that game will never come out.
So a day on their game wasted over efficiently removing an item from an array of 20 items every 5-10 minutes.
> If I optimize this, how much time is it going to save the whole world? What will be the sum of time saved by everyone who will ever run this code? Is that less than the time required of me to do the optimization? Then, don’t do it!
That question was relevant quite often.
The big optimizations though really mattered. And, required planning before initial implementation to set the system up to be optimizable.
Reminds me of when another subreddit was mocking some legacy code (I think Motorola? Some mobile device stuff) for using bubble sort. Meanwhile, the sort probably wasnt on more than a fee hundred items and the mobile embedded is constrained for space. Bubble sort is easy to read, write and has O(1) space. Performance isn't a concern at the scale being worked at. We're talking maybe microseconds of difference.
It's not necessarily a bad thing that acedemia focuses on theory. But we keep using school to put a square peg into a round hole and wonder why students are so unprepared for actual production.
It's ultimately the company's fault. If you want certain skills, you need to train for it. Your processes aren't public, so you can't just expect candidates to magically know what matters to their role.
----
now acedemically: the answer is to swap an item to the end and reduce the buffer size. I don't think that's taught in acedemia either, but that's a trick you learn on the job. When and if you do need it.
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
Sometimes the best way to tackle that 3% is upfront when you're deciding on your system architecture.
No - spending a lot of time making tools you don’t need is the problem. You can write your own engine and leverage existing tools.
The key to making no engine work is to make only what you actually need.
I have limited experience scripting Blender, but there is a BPY API to add custom panels, so adding metadata to “entities” and simplifying the export workflow is probably feasible to the point it will be very close to an editor.
And of course since Blender is used for movies, it does scenes well already.
Really depends on the team size, composition, and game. If you have designers on the team who aren't dedicated programmers, I don't think blender will cut it for them.
The demands of a movie differ from a game which is why I'm a bit doubtful. But nothing is impossible to achieve with peope planning, so I'm not dismissing it.
At least when I last tried Blender the UI was a lot harder to use than something like Unreal or Unity editor.
I'd probably look at the Godot editor first.
But I do like the idea of trying to find an existing editor in the same domain and modifying that rather than building from scratch.
When working on your own engine you also feel as if 90% of the time is spend on user interface creation if you actually want to have an visual editor.
People don't realize that they will spend 95% of the time on the engine and 5% on the game.
Which is ok if you don't want to make a commercial living out of it.
But unless you are making a game with extremely specific needs (eg Factorio) using your own engine will probably kill you commercially.