- Project page
- Tutorial[1]
- Repo[2]
The tutorial shows how to make a dungeon generation algorithm. I decided not to do that. I used ROT.js’s library to create a dungeon. I instead spent my time making a Table class.
It’s early in the project and I don’t know exactly what I’ll want the class to do. I expect that I’ll have to change this in the future as we go through more game features. For now, each table row gets an id (currently unused), and I wrote some query methods.
The simplest thing to do would be to let the game code loop over table rows. However, I want to change how the loops work in the near future. That means I should have those loops inside the Table class.
Queries are objects. If you’re looking for an entity with location {x: 5, y: 3} then you pass the object {location: {x: 5, y: 3}} to the query method. It will return a list of rows. Note that this is more expressive than most ECS libraries that can return rows where there is any location.
I often expect 1 resulting match. I wrote convenience wrappers to check that there is 1 match, or 0-or-1 match.
There are several potential extensions here. Databases have a wide variety of WHERE clauses. For now I only have equality at the top level field. But it might be useful to have equality or partial equality on a field, or on a subfield. It might be useful to have NOT clauses. I decided that I can implement these later if I need them. I don’t have to implement everything right away.
Here’s the game at the end of Part 3: