3 ms·
Now let's say you want collision with one special item change the way inputs are interpretted (you iterate on the game rules and someone had an idea to add alco
by ajuc 11y ago
Now let's say you want collision with one special item change the way inputs are interpretted (you iterate on the game rules and someone had an idea to add alcohol that reverses the controls).
This very detailed specification of dependencies in applications make it hard to change them quickly, and gamedev is mostly about how quickly you can iterate to make the game fun.
I would love a hybrid system, where you get a "root" object passed to each function, that keeps the whole state, and you can just do side effects on that, but you are required by convention to always reference the members of that root object by full path.
And then when you're finished you run a macro, and it generates nice elegant minimaly coupled functional code that passes only the required stuff around.
Don't know if that's possible but it would be great.
- zdkl 11y agoThis with lisp syntax, compiling to Rust code & datastructures would be fun!
- ajuc 11y agoI was thinking of a system generating code in the same language, and still keeping the root object, so that you can experiment, add some new dependencies, and regenerate dependenceis, many times. But you can at any moment pass null from the main loop instead of the proper root object to see if the code is generated properly and works only with the functional part. It's more complicated than a system that just regenerates everything from scratch every time. And removing dependencies would be tricky. So maybe your idea is better.
- zdkl 11y agoWell you could precompile part of the guaranteed immutable stuff and distribute it seperately from the mutable execution part... Wait we've reinvented the JVM at this point!
- zdkl 11y agoCome to think of it you should take a look at clojure/script, the pattern you describe could easily be implemented with maps in atoms. Cf the 'reagent' libs way of handling state
- eyko 11y ago> Now let's say you want collision with one special item change the way inputs are interpretted Then the rules become part of state and the flow doesn't need to change.
- ajuc 11y agoIt's hard to give small example with so general code, but in the end you either have very general flow (collision between any 2 objects can change state of the whole world, including the way the inputs are interpreted), that doesn't provide much protection against bugs, or you have very specific minimal flow (collision between 2 objects changes the state of these 2 objects, their parents, particle system, music system, and input interpretation, and nothing else) that protects against more bugs, but is a lot of work to maintain. I was trying to imagine a system which could give you the best of 2 worlds.