3

I'm developing a computer game. It is a single person hobby project. I will implement it in . As proof of concept I'm trying to procedurally generate a scene by randomly selecting entries from several tables. The scene should dynamically react to the player.

I intend to use a custom kind of entity component system architecture entities/components and their mutual connections are stored as linked data in RDF. Behavior trees, also stored in the ECS, will allow the game to react to the player.

I was encoding the potential objects for the scene in triples in a custom probabilistic format and creating function in lisp to read this data and to randomly generate the scene.

Now I'm wondering why am I developing a custom data format with limited expressivity if I could encode the data/code in lisp directly (possibly extending lisp in the direction of this particular application along the way)? Has creating a reduced data format any advantages in the context of a project implemented in lisp? Is it something one should only do in non-lisp languages (i.e. the Greenspun's well known quote "any sufficiently complicated C or Fortran program contains an ad-hoc, informally specified, bug ridden, slow implementation of half of common lisp")?

I can think of some reasons, but i can counter them all for this project:

  • the project team has members that cannot write lisp
    • counter: it is a single person hobby project and probably won't be big with non-lisp team members
    • counter: using lisp tools that emit, read, and process lisp code can be created when needed
  • the data format should be used in other non lisp languages
    • counter: for this project interoperability with non-lisp is not required.
  • performance issues
    • counter: at this point I don't know if it will perform terribly; we should use measurements to find if there are issues; and premature optimization is not wise
    • counter: high performance code can be written using lisp
    • counter: if needed we can simplify later
  • the game might be a nice test case for a custom built triples store and for the custom entity component system kind of architecture
    • granted, however, both are also future hobby projects; the ECS architecture can evolve along side the game and the triples store has other uses.
sds
  • 861
  • 7
  • 15
Kasper van den Berg
  • 2,646

2 Answers2

1

There are companies (e.g. Franz Inc.) that successfully sell both Common Lisp (e.g. Allegro Common Lisp) and a graph database (e.g. AllegroGraph). There is cl-neo4j, an interface to the neo4j graph data base (a.k.a. graph platform), and Vivace-3, a lisp native graph data base, both by Kevin Raison. Their marketing lingo doesn't shout "don't get left behind by using a semantic graph database; switch to Common Lisp and join the big boys". And probably some of their customers successfully use both together.
So there must be situations where combining Common Lisp with a graph database and thus creating less a expressive data format to store in the graph data base is good software engineering. Are these situations all exempted by OP's specific situation? Probably not.

The are some advantages of using a reduced data format based on RDF or a property graph:

  • (Semantic) graph databases/property graphs offer the combination of persistency, concurrent mutability, and scalability.
    The concepts in isolation are available or can be implemented separately with relative ease in Common Lisp. Combining them would lead to a (graph) data base written in Lisp (though perhaps an ad-hoc form tailorred to OP's application). And note that supporting storing (partially evaluated) functions while keeping concurrent mutability and scalability might be a different beast altogether (e.g. Elephant stores only objects and slot values and not functions, closures, and class objects).
  • Existing tools support RDF or proprietary graph formats but not a rich custom lisp evaluable code/data format.
    Although OP specified that interoperability with other programs was not important, being able to use existing tools might be a kind of interoperability the OP would be wise to appreciate.
    A limitation of the existing tools would be that they support the basics of RDF or an other graph format; for the semantics of the custom ECS format on top of RDF OP will have to write custom tools anyway.
Kasper van den Berg
  • 2,646
0

Gerald Jay Sussman, Julie Sussman, and Harold Abelson in Structure and Interpretation of Computer Programs give more advantages of using conventional interfaces (§2.2.3 Sequences as Conventional Interfaces):

  • Using conventional interfaces increases the conceptual clarity of the resulting code; i.e. code becomes easier to understand for those familiar with the conventional interface used.
    Altough sequence operations are more common than operations on RDF graphs, querying an RDF is more conventional than arbitrary lisp constructs with lisp's full expressivity.
  • Modelling produres as operations on sequences (or operations/queries on RDF graphs) makes the procedures more modular.
    With a conventional data format (e.g. sequences or RDF graphs) one can devellop or reuse an existing library of operations for that format (e.g. operations such as mapcar, filter, generate, select, and graph-walk) and express the procedures in terms of these operations. The library of operations is stable. The operations can be reused in many procedures. And the procedures are flexible and can be changed easily by composing differently.
Kasper van den Berg
  • 2,646