Project Title: Room Generation
Development: ActionScript 3.0
My Role: Programmer
While not overly elaborate, this iteration on the console project reflects a foundation designed to allow for future level creation values to quickly be applied to the generator process. Along with implementing a base algorithm for room creation, I also several features designed to visually convey the changes applied to the level, allowing for players to readily explore the rooms via connections, and for a mini-map to communicate their location within the level.
At the current time, the generation process only reflects two core values. The first is essentially the number of rooms it will be required to generate. The second value is labeled as divergence, and allows for editor to specify how compact the level creation process should be. Lower divergence values will prevent rooms from being built too far from the central location, while higher divergence values will allow for random generation to create corridors over clusters.
After any room is created, the algorithm simply randomly cycles through the list of available rooms until it manages to locate an available connection point. In this scenario, it begins by examining a room, and then checks to see if the divergence value of the room is within the divergence bounds. Each room contains a divergence value, specifying how far it is from the main cluster. If creating a new connection from the room will go beyond the current divergence value, it then continues cycling through the list.
If the divergence value is tolerated, then the room's connections are checked. If any are available, a random one is chosen and a new room is built from that connection point. The current grid position of the room and the connection allow for the initialization of the values within the new room. Afterwards, it is added to the list, and all rooms check their connections based on the new room. If all rooms are cycled and no room has been created, this means that all possible rooms within the current divergence value have been created, and therefore the divergence value is increased by one to support the next set of rooms.
The interior components of any room are built based on pre-designed layouts randomly selected from a data file. A unique level is available for the starting room. These layouts do not begin within any locations for exits, as these are dynamically built based on a room's available connections. After all rooms are placed and have their connections finalized, the tile-maps for all rooms are built. This is simply done by creating a bitmap based on tile values from a 2D array layout array. Depending on the North, South, East, and West connections, this tilemap may be amended to open pathways representing the exits from the room.
Exits are always bounds to the perimeter of the room, and therefore any openings within these areas can be matched with their corresponding connection. This means that a list of grid points for each possible exit can be saved, and if the player grid position aligns, the room can evaluate the room connection to enact. This is important, primarily because it allows for exits and entrances to rooms to be potentially be randomly created and aligned with adjacent rooms, since each room can examine exit blocks based on its perimeter.
A side challenge for this exploration involved designing the systems based on the presence of more than one player. In most situations, if an individual player reaches an exit, the room will note the direction, and the current room will be changed to the room associated with the connection point. This changes the camera, player, and current room tile-map.
However, if more than one player is present, in order to exit a room, all players must be positioned on the same type of exit blocks. This means that if players want to travel west, all players must be at one of the West exits, or the transition will never occurs. Each player holds onto an exit value, representing the current exit connection that they are standing on. Normally this is -1, representing the lack of an exit, so these value are utilized to test transition agreements.
Along with their available HUDs, each player also can toggle a mini-map to examine their party's current location. Dark spots represent unexplored areas, white spots convey visited locations, and the unique marked symbol is simply their current room. Since players travel in a group, these will always reflect similar map representations, but it is useful to acknowledging where the players would need to travel to, as well as the results of the level generation process. Ideally, future development would further the feedback by including boss or treasure locations during actual gameplay.
This short project primarily allowed for a simple examination of room generation, along with continuing development within the console environment. Going forward, I'd want to return to the console side and possibly implement a few additional features required for efficiency. While the level generation process is well refined, the creation of the bitmaps can cause some problems on the console, which could easily be resolved by limiting the display and creation of bitmaps depending on the proximity of rooms. Furthermore, many of the features utilized in level generation would require gameplay to properly convey, such as difficulty, enemy spawns, bosses, and treasure. Therefore, a further iteration many involve adding some gameplay features, and then returning to continue polishing how the level generation system is done within actual game session context.
