The purpose of this post is really just for me to organize my thoughts about how to go about this. It’s hard to hold all this information in active contemplationg simultaneously as I try to figure out how best to place items.

This is an excerpt from the game’s README file:

Game initializes the screens on window load, and presents the player with Game.Screen.startScreen. Pressing [Enter] initializes Game.Screen.playScreen, which initializes Game.Map, along with the player entity. Game.Map is where most of the magic happens; Game.Map is what initializes Game.City, entities, and items. Game.Map is also where the ROT.js engine and scheduler live, and the Game.Time and Game.Justice modules are initialized. Game.City is where “lots” are generated, which is how I procedurally lay out the city. Each lot in turn (depending on type) contains code for generating their own tiles, which in turn contains the code for procedurally generated buildings.

The key part of that being that Game.Map is the place that houses information for all items. This is tricky, because by the time tiles are generated for the city, it’s really hard to tell which buildings are which; the game just knows “this is a grass tile, this is a floor tile, this is a wall tile” etc. This is not a problem for entities (yet) since I’m just spawning them randomly, but it will be a problem when I want to start spawning them in their living areas. As an overview, this is how tiles are generated by Game.City.getTiles():

Game.City.init() creates a grid of ‘lot’ representations. I use an algorithm to place office buildings and skyscrapers closer to the center of the city, and house and empty lot ‘lots’ further away from the center, after I lay down a criss-cross of road ‘lots.’ Game.City.getTiles() loops through this grid and calls the Game.Lot.prototype.getTiles() method for each lot (as defined in js/lots.js). This method is different for each lot, and is a combination of prodedurally generating one or many buildings, placing them somewhere on the lot, and then filling in all the non-building tiles with grass or air tiles depending on the z-level. Building tiles themselves are fetched from their own various constructors.

The tricky bit is that it is only at the individual building level that it is most practical to place items, since it is only at this level that it is currently possible to tell what kind of building a set of tiles represents, and what subset of those tiles might represent something like a bedroom or a kitchen or something else. What makes this tricky is that building[x][y] does not correspond directly to lot[x][y], and neither does lot[x][y] correspond with city[x][y], as buildings are patched onto lots much like lots are patched onto the city.

Thus, it seems that items should be placed and tracked at the building level, if not actually as a tile then in a map accessible via a getter, the locations of which can then be translated up as tiles are rendered at each level.

As lots generate buildings and construct their own tiles from the buildings, it should be a relatively simple matter to add each building’s items to a lot item map via a Game.Lot.prototype.addItem() method that translates the items position from it’s location in the building to its corresponding location on the lot. Then, it should be another simple matter to do an almost identical operation at the city level as lots are generated. Then, once the tiles have been placed, items can be added to the Game.Map or Game.City, and then perhaps ultimately rendered at the Game.Screen level, much like entities.

Seems like a good plan. We’ll see how it goes.