New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dev log #6 - API - feedback #24

Open
underscorediscovery opened this Issue Nov 13, 2017 · 5 comments

Comments

Projects
None yet
3 participants
@underscorediscovery
Copy link
Member

underscorediscovery commented Nov 13, 2017

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

@ThaisRobba

This comment has been minimized.

Copy link

ThaisRobba commented Nov 13, 2017

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!

@underscorediscovery

This comment has been minimized.

Copy link
Member

underscorediscovery commented Nov 13, 2017

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

This comment has been minimized.

Copy link

ThaisRobba commented Nov 13, 2017

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

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

@sponge

This comment has been minimized.

Copy link

sponge commented Nov 13, 2017

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.

@underscorediscovery

This comment has been minimized.

Copy link
Member

underscorediscovery commented Nov 13, 2017

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment