- 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 Table class to do. I expect that I’ll have to change this in the future as we go through more game features. For now, the table has some rows and some query methods.
It would’ve been simpler not to have query methods. I can loop over table rows instead. However, I want to change how the loops work in the near future. That means I should put those loops inside the Table class.
I decided queries will be represented as 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 type of query is different from many ECS libraries that let you query for entities that have any location, but not a specific 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: