“real-time 3D content”—a category that includes games and material with game-like interactivity—will account for almost half of all visual digital content by the end of the decade, compared with what he estimates at only about 3% today. [1]
Over time I agree with him and think the better part of 3D UI/UX game design elements will make their way in to traditional enterprise software and web stacks. They will be both more functional and beautiful to work with as a result.
[1] https://www.theinformation.com/articles/unity-ceo-predicts-a...
Lol, what better part? Game UI serves the game. UI of serious applications serves the user. Traditional enterprise software and web stacks will be inspired by serious well done consumer software that serves the consumer and is so pleasant to use that they want this at work too (see e.g. https://www.se-radio.net/2021/01/episode-442-arin-bhowmick-o...). Nobody wants to fumble seriously in inventory screens and go through click fests that are meant to keep you in-game.
10k games were released on Steam in 2020. In 2021 Q1 there are 316k games available on iOS. When creating a game is what you like, it might be rewarding, but the coding work is usually not very rewarding when it comes to the details. Especially because game ideas are usually not as original as most people think...
When you are not a code monkey, coding is always highly creative be it games, missile control systems, high frequency trading, insurance policy management etc. It might be easier to imagine fun in the idea of coding for a leisure activity, but in reality it can also feel very shallow.
With the problem about status effects, how is this typically implemented? Do the rules for interactions exist within the game objects themselves, as if-then-else statements? If so, I can see why that would be error prone. Even if those rules exist in abstractions like "Burnable" and "Metallic", it's still hard to see the side effects of changing or adding a single rule.
Does anyone ever implement it in a single place, where you can query for the interactions between the different status effects? That way, all the rules are in one place, and being able to query for it, the results would tell you how it came to that conclusion. If not, how come?
A significant amount of my time is not even spent coding, but doing admin and spreadsheets.
But I hear you. 30 mins probably isn't enough frustration to warrant something like that. What spreadsheets? Like systemic design in spreadsheets? Or you're doing accounting?
I've seen quite a few use an OO modeling approach. That's fallen out of favor for good reason.
Another approach is Entity Component Systems. I suggest googling for one of the better blog posts on that.
Another approach is to build the equivalent of a datalog engine.
An approach I favor is to have a stack per entity, and as you parse input events things get stacked up. Then a processing pass iterates across popping things off the stack. If you know how MTG rules work it's roughly the same idea.
None of these are a panacea, because you can have logical contradictions in your ruleset that are subtle and only emerge in very niche situations.
It's definitely very difficult problem. What you suggest is similar to what I termed the datalog style. If you've ever tried to debug a prolog or datalog program, you'll know that it all being in one file is a trivial concern compared to the emergent complexity and potential for you to have misstated your logic or included contradictions.
If you have a stack per entity, like MTG, how would you find a contradicting rule?
So the stack approach essentially doesn't, because it forces a linearization. You'd have to rewind back through and see why what the system did didn't match your expectation. But at least the order is comprehensible vs some of the other approaches.
But actually in this specific case like 99% of my elemental interaction code is in the same place just as you recommend!
In this specific case the problem was entirely that I added a new rule to make ice decay into wet when it was removed, but didn't add a check to see if ice had been applied in the first place before removing it. And of course, that was all in the elemental interactions file. 28 of the 30 minutes were spent in just puzzlement why the fire wasn't applying and checking a bunch of irrelevant dead ends before I thought to check "oh obviously it's probably the elemental interaction code, go check the elemental interaction file." 2 minutes were spent fixing the actual code.
For something like status effects, I was thinking about using a datalog engine, like jasonwatkinspdx mentioned in a sibling comment. That way, you can query it for applications of status effects, instead of hunting it down in code.
That said, I never heard any game dev talking about Datalog, and was wondering if there was a reason for that--whether it's obscurity, or if it's impractical for some reason.
So a bunch of design work happens in spreadsheets, yeah, that and long form google docs. Then a lot of business and admin stuff too (if you're an independent dev which means you're making games AND running a business). Whether that's accounting or projections or any number of other sundry things.
I have mixed feelings about this. When you do something creative for a job it takes on an entirely different character than doing it for yourself. Another thing is that gamedev is still software coding (among other things), and only a fraction of what you're doing amounts to the "fun bits" related to making interesting game design decisions. The majority of it is endless slog in trying to get collision detection to stop snagging on corners or figuring out why your fire status effect is cancelling as soon as it's applied (turns out it's because fire is cancelling ice without checking for the presence of ice in the first place, and ice turns enemies wet when it expires, and wet status cancels with fire status, so setting things on fire made them wet, which means they're no longer on fire). And 50 million more thing like this.
I enjoy it, but then there's also the fact that the industry itself has a lot of pathologies that "boring" software development doesn't, lower pay and worse working conditions as an employee, and extremely turbulent ever-changing conditions as an independent developer or freelancer.
Whenever some kid tells me they want to go into games for their career, I like to trot out the probably-apocryphal story of the Jewish rabbi who refuses to let a proselyte convert until he's come to the rabbi three times and been flat refused twice. I use the same method -- "no kid, you don't want to go into the game industry for all these reasons." If they keep coming back despite all that, they at least know what they're getting into.