An engine for describing games built around Xerces, exprtk, and SFML.
Status: idea; extends 08 and 07
The second batch reopened the basic question in the redesign of Pong: what does an object need in order to be one? The answer that kept coming back is little more than a name and a place, with everything else opt-in:
A score readout or a background logo has a position and an appearance and nothing else. Giving it a zero velocity is noise: zero is the absence of motion, not a property. So velocity and collision belong with the physics part, and an object with none of it costs nothing.
Position and motion can read in the same voice or not. Options seen:
position with velocity (plain, physics vocabulary, chosen so far).at with moving (reads as English; an object is at a place, moving so fast).heading with speed (what the object is doing, rather than exposing a vector).Leaning: keep position and velocity because they belong to a physics part, but note that a heading plus speed pair may suit games with rotating ships.
Two ways to write the reaction to a touch:
The first reads like a description of the game; the second is easier to validate and to extend. The current form (13, 21) is the first, kept because readability was preferred over schema regularity.
Shapes are their own topic. A vector game stores each outline as a short list of points and reuses it: a handful of asteroid outlines, each drawn at several scales and rotated every frame, instead of a bitmap per size and angle. That suggests, for the language:
The current sprite options (rectangle, circle, text) would gain a polygon or outline kind (02).
The idea already noted in 20 (a component that owns a growth stage) fits this shape: a component is a named part with its own state that an object opts into.