dev log #6 - API - feedback

[ruby0x1]

Post your feedback and questions on luxe dev log # 6 - API here

[ThaisRobba]

Small typo at the end: var cam = Entity.create(world, "outsgide_camera"), should be: var cam = Entity.create(world, "outside_camera")

I love the data-first approach, it just seems so much easier to grok and evolve, I'm happy to see Luxe going in this direction.

Have you taken a look at Redux? It seems like a really good data oriented approach.

I've been implementing something similar to it for games and it works really, really well. Instead of executing callbacks I just fire a "tick" event in the gameloop update cycle. On debug mode I keep the list of events, meaning I know exactly which data I started with, how it transformed and can do something similar to console emulators and simply "load" any game state.

Fun times!

[ruby0x1]

Thanks the typo has been fixed.

Redux is data binding isn't it? That's a bit different usage of the word data contextually here, but I do know redux yep! The engine is also data driven which is asset/content related... to many words are overloaded around this stuff haha.

[ThaisRobba]

Yep, it pretty much is data binding. :-)

I'm looking forward to the next posts, curious as to how Luxe will work!

[sponge]

Redux doesn't have to do with data binding pe, that's more on the React side of which it is most commonly used in conjunction with.

Redux is more of a model of working with your data. You have a single data store for the whole application, and the only way you interact (mutate) it is by creating Actions. Actions are just plain old objects that have a type, and parameters. That action is then sent to Reducers, that listen for Actions of a certain type, which calculate the next state given the Action, and then return the new state. (In React, that new state is then fed into the program, and all of the components will re-render themselves)

I've often thought about it in the context of game programming, but I think the Redux approach is too much overhead. Reducers are supposed to be pure functions, so no calling random numbers, or looking at the current time. You also are supposed to return a copy of the new state, and never mutate the state directly.

While in a game, you could probably get away with not returning a new object every time, the overhead of creating Actions that are routed through the web of reducers every time you want to do something would be expensive. It works in Redux because generally you're only calling Actions in response to user input.

What you would get out of Redux style approach is determinism. Everytime you run the string of actions through, you get the same results. Quake/Source engine games accomplish this by having the only item over the network essentially be the keypresses of the client. Those are then played back on both the client and the server in order to reach the same next state. Demos/Replays are implemented based on this model.

The data oriented approach in this article feels like a cousin of the Redux approach, though. The big difference there is instead of passing around objects, you're passing primitive types that act as handles.

[ruby0x1]

Yea, data oriented in this context is specifically more on the low level side of designing the code to handle memory in a way that works well on the hardware it's running on. The handle based approach is just a way to decouple the data from instances that have that constraint, like an entity.

While the redux data binding stuff is certainly interesting, it's a topic best for another thread. Appreciate the insight and thoughts though, thanks!