in a world of actualities, not cloudy abstractions, work by example -- make an example of the monster, then inherit -- a 'proto' -- and now the abstraction is a tangible object that is manipulable as data in an editor
another attempt at reducing creative friction between the artist and the artwork
conceptual docs (see 'terms' below)
- event capture
- alignment (vertical/horizontal tabular)
- textedit (based on text?)
- button (rect + text)
- input (rect + textedit)
clone object, move slot, inspect multiple objects, force inherit slot, etc.
in-game output console
set slots in order of appearance in protos
automatically maintain 'methods.x' as a proto for 'entities.x' (?)
docs for 'entity'
fix 'slot deletion' to remove metadata too
switch to 'get_slot_meta()' and 'set_slot_meta()'
entityin 'lib.entity' and move
entity._slot_meta()etc. into methods again -- will allow setting name in
entity.add()as a regular slot -- will also separate 'game' library (boot) from super basic entity stuff
- rename 'update' to 'updateable' and 'input' to 'inputable' etc.
- coroutines for
- use luasocket for scratch handling and add interop with non-emacs editors
- individual 'pause/play' and 'visible/invisible' icons (toggling 'updating'
and 'drawing') in object inspectors
- when editing 'player' trait you might toggle its visibility to see it, but you'd probably never toggle its update
- individual 'pause/play' and 'visible/invisible' icons (toggling 'updating' and 'drawing') in object inspectors
how to play
Make sure you have love2d.
git clone https://github.com/nikki93/pgame cd pgame
love . will load the boot image
boot/boot.pgame, which is
created from the
bootstrap recipe as described in the code in
recreate this image you can run
love . --bootstrap new_boot.pgame, which dumps
new_boot.pgame as a new boot image. The boot image contains basic entities
A different boot image can be loaded with
love . --boot input_image.pgame. So
you could load the default boot image, modify the world a bit, save a new one,
then load that in the future.
The first of the remaining arguments gives a directory to load methods from, then the rest of them should name images to be loaded in order.
will write docs defining everything soon...
proto, rproto, sub, rsub
name + method registry relationship
how to design entities
for any entity that you think will have rsubs, keep asking the question: what behavior are entities that derive from me endowed with? this gives you the documentation of the entity, and the entity is defined by its documentation--it must be expressed both in implementation by code and explanation to the user through documentation
if adding an entity as an rproto doesn't change observable behavior, then it is accidental complexity
document early--use documentation as a way to formalize the definition of an entity and actually help coding--any error in the documentation is either a bug in the code for not matching the documentation, or an error in the documentation for not matching the idea
think of it this way: the purpose of an idea is to be realized, and this happens by documenting it, because the purpose of code is to make documentation true (it isn't true, but the point is to work with such belief)
documentation must be well organized:
- have per-entity documentation of what the instance represents by itself (if it isn't simply a trait), what rsubs are endowed with and under what conditions, and a todo section for what future work needs to be done
- have per-slot and per-method documentation
documentation must be /written/ close to its code, it can then be collected in other ways for viewing--writing close to code ensures some level of code<->documentation invariant maintenance--don't document behavior of other entities in this entity (use 'see: ') etc.--so, docstrings!
as much as possible documentation should be in docstring form however abstract--if you have outside-code abstract ideas are just ideas and not a realization of them (of course, it's ok for the design process)
the vision is to store documentation in entities so that it can be queried
through the system (i.e., inspect an entity, ask for its main documentation,
documentation or a slot or method, for the filename of the function associated
with the method (see lua's
the documentation could be more than plaintext--link to other entities (opens inspector), potentially include formatting/images, a 'realtime preview' rendered through a camera following the object--all this will be drawn in the documentation viewer
for now entities are mentioned by name like
name and their slots by
(perhaps this documentation network could be exported to markdown/HTML?)