Why are modern day game engines so difficult to program in?

How would you program an MMORPG without OOP? What data structures would you use?

procedural, same as any other game

functional programming is worse

nobody mentioned functional programming

>Quite literally the worst paradigm possible for game design.

that could be inheritance-oriented programming (OOP)

functional programming is worse

Literally all functional. You can still do all the data structures you'd use in OOP you just wouldn't bundle them with the functions for literally everything else in an object.

Player.inventory.add_item(pink dildo) breaks or needs a workaround or labor if it were called twice in a row because the data structures are being cunted around for each function call.

additem(player, inventory, pink dildo) on the other hand will do the work, and then just spit up return that modifies the relevant data structure. All immediately simple, performant, and thread safe.

Procedural programming doesn't work for large scale applications.

OOP leads to large applications

OOP is procedural

You're retarded, functional programming isn't performant because it has to copy everything

you are an idiot

>Player.inventory.add_item(pink dildo) breaks or needs a workaround or labor if it were called twice in a row because the data structures are being cunted around for each function call.

Object can be locked to prevent issues like this.

>additem(player, inventory, pink dildo) on the other hand will do the work, and then just spit up return that modifies the relevant data structure. All immediately simple, performant, and thread safe.

It would be overly complex to program without encapsulation.

sevangelatos.com/john-carmack-on/
Useful supporting article before the loud brainlets shit up the thread even more

Relevant excerpt:
>A significant mitigating factor is that performance today means parallel programming, which usually requires more copying and combining than in a single threaded environment even in the optimal performance case, so the penalty is smaller, while the complexity reduction and correctness benefits are correspondingly larger. When you start thinking about running, say, all the characters in a game world in parallel, it starts sinking in that the object oriented approach of updating objects has some deep difficulties in parallel environments. Maybe if all of the object just referenced a read only version of the world state, and we copied over the updated version at the end of the frame… Hey, wait a minute…

I'm not the guy who called functional programming performant

No it isnt.

functional programming is the worst paradigm you could imagine for dealing with video games which have a lot of state and have high performance requirements

>functional programming is the worst paradigm you could imagine for dealing with video games which have a lot of state
And why is that
>and have high performance requirements
Lmao no they dont. Minecraft was written in Java and it is the most popular game ever.

It's all theory. John Carmack had never worked on large scale multiplayer games before. His opinion doesn't prove anything. It's only what's put into practice that counts.

not written in lisp

>And why is that
Because of the nature of the problem
Minecraft both looks like shit and runs like shit, it was also rewritten in C++

No fuck functional programming, its the shittiest paradigm

I think you have a misunderstanding about what game design is. It is the modelling of transitions of state (frames) in a large collection of objects.
Functional programming has no mutability, so any state used must be transcribed in the return type of a function.
This is going to create brittle code in a game.
When your primary concern is mutating things, locking that up a type level makes code very hard to change later.
Performance isn't really the case that most people claim it is, in the worst case the engine can just be written in C++.
To put it simply the issue is of intention, and the one thing OOP excels at is this sort of modelling.

A simple example is a method that comes built in to godot widgets to have two UI components share a value (change one and both do).
It is very useful for creating widgets like a slider + text box to enter a value; the functional equivalent would be miles more complicated.

The poster from mentions Carmack, and I remember reading an article of his that explains the quite well. Don't have the exact wording but:
>You can't really program games functionally, but it still a good idea to avoid unnecessary mutability (eg by adding const to function definitions).
>The little parts of your program that accrue state when you aren't looking at them are breeding grounds for bugs.
It is a nuanced take, so I expect it to be misinterpreted here, but it is worth paying attention to.
Using state is a trade off, sometimes it reduces complexity, sometimes it increases it.
If you are smart enough to only use it in the former case, functional programming can only be a detriment.

>It's all theory. John Carmack had never worked on large scale multiplayer games before. His opinion doesn't prove anything. It's only what's put into practice that counts.

>Quake
Literally the quintessential, textbook example, of what good multiplayer netcode looks and feels like but Ok
>The Fucking Metaverse
I'd say that's large scale multiplayer.