evincarofautumn
commented
4 years ago An approach to game prototyping software that I liked very much was ProjectFUN, developed at DigiPen. It offered a visual state machine editor, which let you attach code to each state (running continuously) and upon exiting or entering via a transition (executed each time the transition was taken). You had to write the code itself in C++, which I feel was a uniquely poor choice for a programming tool targeted at beginners, but the general design—concurrent state machines with code attached, hooked up to a game API—was excellent in concept. I’d like to consider borrowing that structure, although not necessarily the visual editor part.
That might look like adding language constructs for states and transitions to entities, which desugar to as long as loops for ongoing state code and when events for transition code (which also change the active state, explicitly or implicitly).
// Parameterised entities
entity switch (
turned on,
turned off,
remaining on,
remaining off
) {
// Instance variables, as above
has is on : flag;
// States, equivalent to e.g.:
// as long as (this: state = on) { … }
state on {
remaining on ();
// Phrase transitions as ‘when’?
when (not (this: is on)) {
turned off ();
// this: state <- off;
go to (off);
}
// Or, desugaring to the above:
go to (off) when (not (this: is on)) {
turned off ();
}
}
state off {
remaining off ();
when (this: is on) {
turned on ();
go to (on);
}
}
// Read/write commands (as in “command/query separation”)
comand toggle () {
this: is on <- not (this: is on);
}
command turn on () {
this: is on <- true;
}
command turn off () {
this: is on <- false;
}
// Read-only queries
query is on () {
return (this: is on);
}
query is off () {
return (not (this: is on));
}
}I think machines and entities can be merged, but it may be useful to differentiate them. Is it desirable to let an entity contain multiple machines? The equivalent here would be an entity that has or needs other entities, each with their own state. That may be cumbersome, but also encourages separation of concerns and detangling of states, in a language that needs as much of that as possible. How about no machines? Not all entities need to be stateful, and many shouldn’t be. Do we differentiate entities that constitute models (data), views (read-only rendering), and controllers (updating)?
I think program organisation will not scale well to larger sizes without some form of type checking. I think some subset of the following features make sense:
A fixed set of intrinsic, principal, inferable types:
An extensible set of extrinsic types (“properties”) that are not necessarily principal, inferable, or statically checkable, which refine intrinsic types:
While every value should have an intrinsic type, it should be possible to give variables a dynamic type. For dynamically typed values, it should be possible to check or assert that they have the correct type, providing static type information to the type checker.
Typechecking the program should produce warnings about type errors without preventing the program from running. A type mismatch at runtime should produce an error and pause the program for debugging. In strict mode, these warnings can be turned into errors.
It should be possible to define objects (“entities”), as a form of property that provides some combination of fields, commands, and queries. I would like entities to declare the fields they expect or provide, with optional defaults; define methods for commands and queries and events for how they update, render, or respond to input; and be automatically linked together. Sketch: