Nacho Disk

I spent today updating the ‘area reader’ code and it evolved into a replacement for my previous level generator object. I combined the code into a single loop so that once the areas have been dumped into DS grids and the Hamilton path has been generated, the game goes through the maze in order and builds the dungeon. This is far more efficient than my previous versions of this process for a couple reasons. The first reason, as mentioned previously, is that the code no longer needs to reorganize the dungeon layout into a top-down arrangement. The second reason is that I created special area transition objects that make constructing pathways between rooms much easier.

Instead of checking specific indices in an array, I can now simply place objects in the area templates that determine which areas are valid exits.

// If the object is a transition, see if it matches an exit in that room
if (object_get_parent(_object_id) == o_transition) {
  if (exit_exists(path_,_room_count,_object_id)) {
    _object_id = noone;
  } else {
    _object_id = o_solid;
  }
}

The object o_transition has four children: o_transition_north, o_transition_south, o_transition_east, and o_transition_west. If _object_id is a transition, we check to see if this transition’s direction is one of the exits in the area we are currently building. If there’s a match, we skip placing an o_solid object in that transition object’s location. In the future I plan on changing this procedure so that it uses predefined transition regions rather than explicit transition objects. This will allow for greater flexibility in the application of my area templates. For example, I could define a region that would create a tunnel or passageway if such an exit was needed.