mzgoddard
commented
8 years ago Thought about this a lot this last weekend. Index is the most immediately implementable thing I thought of since its disconnected from these two later harder issues. While Index provides in essence a memoified FindWhere, I thought of two other things I'd call State and Struct.
State is an basically a datastore combing the three parts of data for games immutable, immutable future, and mutable memory. State manages the current immutable state, controls a set of changes or a mutable future that will become immutable at a marked time (before a render), and keeps a separate structure for mutable or volatile data. The volatile could also support memory by extending arrays of volatile fields (instead of {x: 0} it'd be {x: [0]}) and setting and returning the array member that is at the current frame member (or at the same time immutable future becomes truly immutable store the current volatiles in such an array instead of constantly accessing it, in which case the volatile data could be considered the volatile future).
Struct is a view into State. It helps access and determine future values. If getting a member and a future is set, it'll return the future. When setting immutable it talks to State to queue a change. If getting or setting a volatile it similarly works with State to get the appropriate value. Structs couldn't have their own members beside the info they need to access the right part of State.
There are some common data handling needs for games, that may or may not overlap with more general applications.
One such need is an Index. Say in a grid based game you have tiles that move around. You want to know tile is at a given position. Index would fill this roll. I've written demos that manually manage this Index as the keys to the grid tiles but its extremely error prone. Instead I'd like to recommend having an array of tiles or a map of tile key to tile value and an Index in such a game mapping a tile's x, y values to the tile's index in the array or tile key in the map.
Outside of an Index other needs should be considered to determine implementations that are additive to the React community's data tools.
A common need in demos so far is interoperating with an existing state and the future immutable state. In essence there is either a mutable future state being built or an object describing the changes to make to the current state. In either case checking both manually is error prone and hard to think about. Objects that can mutate the future state and return that parts of that future when they are defined instead of the current state will help greatly.
One last part of the data flow to consider is always mutable state. A lot of games tend to rapidly change parts of their state that voids many benefits of immutable state. An answer here may be like the last idea mentioned, where there is something to consider the present and the future state, likewise that same or a different thing could consider the mutable and immutable. Part of this would be what is acceptable as mutable. Data that controls what is should be immutable, data that controls where that what is could be mutable. State like there are 10 enemy medium ships and 5 enemy heavy ships is immutable along with their max health and armament types. State like their position on screen and current hp is mutable. A way to think about this is what changes constantly and is animated. A game character shooting is animated, a game character having weapon to fire isn't. Immutable data provides an easy way to do something a lot of games have difficulty with, rewinding time. With a system to help mix immutable and mutable data and rewind changes (selectively as well to support different time mechanics) opens an avenue for some neat time based games or just to quickly mark states to return to if say the player enters an un-winnable situation.