if I want to make a "reactive world/systems" for my game (like in immersive sims/systematic games) - how do I approach this in not very complex way? I don't want to do/use some sort of ECS (did it once and it worked, but it was so convoluted, so I don't want to do anymore, lol) or DOTS (too much overhead and little gain for my scope).
my only idea is to use some sort of heavy interface based structure + heavy events/triggers usage, but it will require some sort of getcomponents all the time (kinda avoidable via controllers/managers, but I don't like it). also, the state management is kinda pain in the ass if I want to preserve reactivity.
any tips on this code-wise?
#Coding tips for reactive/systematic game?
true fox
paper oyster
Not entirely clear what the question is. You kinda mix up several concepts here.
DOTS and ECS are not meant to improve code architecture(although some people consider ECS superior to OOP), they're mainly meant to improve performance at scale or of processing heavy and parallelizable algorithms. And you seem to be talking about code architecture(interfaces, events, state and such). So maybe think a bit more on what you're trying to ask and rephrase the question.
true fox
Not entirely clear what the question is. You kinda mix up several concepts here....
yes, I ask only about architecture tips for this type of games, nothing else. sorry for my funky speech style, I'm not a native speaker (as you can see).
I just don't know how to approach the code structure, nothing else.
like, general tips for implementing immersive sims/reactive games.
paper oyster
I don't think there are any general tips. It would depend heavily on your project needs and requirements and your personal preferences.
The only thing I can suggest is to get acquainted with OOP and SOLID principles and start working on the project while keeping them in mind.
Then if you have an actual real issue or some code that bothers you, you can come back here and ask about it, while providing relevant details/context.
leaden viper
if I want to make a "reactive world/systems" for my game (like in immersive sims...
The key thing to do here is to make a simple contract by which all systems can cooperate and then trusting in that contract and never ‚orchestrating‘ specific player experiences.
meaning you have simple, shared abstractions that compose into gameplay features by player-usage and let new gameplay happen without you specifying it.
this means for code: you make everything data driven, code operates on abstract keys and values. code does not know what the data it transform means for gameplay.
true fox
so, I do something like a blackboard per object + one for the world itself and systems just iterate over them to alter the state?
and avoid events, etc.
(events affecting the state change I mean)
leaden viper
yes, think of each entitiy in your game as having an inventory of "items" of a certain "count" ( a Dictionary<Identity, int>) and every gameplay system, only transforms these inventories.
the keys can mean anything, an actual item, an unlock, a status, a resource, and identifier, a quest completion, a fact about the world that was discovered etc.
keys can for example be instances of empty scriptable objects, an enum, plain integers, or strings. The key is that you have a global vocabulary of them.
but your code does not care what they mean
this forces you to design systems separate from gameplay
true fox
hm, interesting. I did something like this before in my previous attempts. like, my blackboard was just generic dictionary wrapper and contains just typed keys (as readonly structs to identify the meaning) and some value of that key.
I did not "pre-bake" them tho, instead create them as I go, but I scrapped it, lol. I suppose time to redo a bit of it.
or count the keys/value. they were just key values pairs of data
but I did not use them inside iterative systems, but just in monos on gameobject, so I suppose that was the main problem, hehe.
leaden viper
in most cases a blackboard is an overabstraction
rarely useful as a generic interface
95% of what you do in state-transforming gameplay code can be abstracted as transformations on a (int key, int value)[]
this doesn't produce nice code for non-system games, but for a systems game with the goal of producing emergent gameplay, this is a very useful thing to keep in mind.
it also helps (a lot) with prototyping and iteration
true fox
tuples are cool. I like them, even though I rarely see their usage in random code I see, lol.
but what I did before with my convoluted overengineered blackboard is something that you described before, right? just want to be sure that I understood all correctly. sorry for useless re-questioning (if it's even a word, lol)
leaden viper
it sounds like it was the beginning of the right idea but possibly under the wrong light
i think something like this takes a shrewd eyes to get just right, you need to look at the whole game dev experience of such a game as a whole and poke at it precisely with a sharp, pointed object
you could think of it this way: make one, very expressive and extreme abstraction, then use that abstraction to make all the rest of your code as simple and non-abstract as possible.
(personally, i think abstractions are the devil)