RPG-openworld World Generation Algorithm Implementation Plan

Team: Nicole Avila, Carolina Calderon, Chanik Bryan Lee, Eddy Rose

---

Brief Overview:

The world generation algorithm is an algorithm designed to auto-generate rooms with items and NPC's based on specifications to the algorithm and by the game author. It will be able to create a room like a hostile dungeon room that lies as a filler between two custom-designed rooms or it can auto-generate many rooms to give a player a chance to level up or gather items.

Implementation Plan:

Stage 1: Our algorithm in its earliest stage, which is this sprint, will only be able to autogenerate one simple type of room. The room specifications will be hard-coded in and the autogeneration algorithm will simply just create however many of that room.

The algorithm will look something along these lines:

room generation(ENUM type);

• "room_t" is the type of output for the algorithm at this stage. It can only return a room.
• "ENUM type" is the type of room the algorithm is generating based on ENUM's since we only have 3 diff rooms to return.

Stage 2: The algorithm can generate paths for in between rooms. Also, it will begin taking account of the player's level as well, giving the algorithm a bit more functionality to handle the player's level and generate accordingly. This stage is focusing on being able to generate multiple rooms based on

room_t generation(ENUM roomtype, room_t prevroom);

• "room_t" is the same as the previous stage's output. We are still outputting a room but it will now have an NPC in it.
• "ENUM roomtype" is the type of the room that we are generating the NPC in. It is the same as "ENUM type"
• "room_t prevroom" is the previous room that we need to connect to the new room we are making.

One thing you can notice about the new features this stage brings in is that the algorithm can only generate one room at a time. This means a few things:

1. Paths will be handled by giving a previously made room to the generation algorithm. The algorithm will make the new room then connect a path to the both of them.
2. This means that both of these rooms are going to need description identifiers that point out this path. These rooms can't be made and have no way of telling the player they are connected. For this stage, it is fine that we just make the paths but is something we will have to answer later.
3. Since we can only make 1 room at a time, this will mean the algorithm is going to need to be fairly simple to run in the case that a lot of rooms need to be made.
4. Also, later when we dont have simple room_t structs to work with, how will we connect the rooms through a WDL file? We will most likely need helper functions to find the room.

Stage 3: This stage is contingent based on the fact that the NPC team has finalized either the plan or code for how they will implement NPCs into chiventure. Once that has been established, we can just add the NPC feature. During this stage, we can start thinking about how we want to code the NPCs and rooms into a file that the algorithm then grab from to autogenerate.

room_t generation(ENUM roomtype, ENUM npctype, room_t prevroom);

• "ENUM npctype" is the type of the NPC we are generating.

Stage 4: With all the meat potatoes being able to be generated, NPC's, items, rooms, the algorithm will now implement some random functionality to diversify the outputted rooms. Furthermore, it's important that we now start figuring out how to return the generated rooms, items, etc in a wdlfile that can be accessible. However, this cannot be finalized until we have gotten a standard to put it in from the WDL++ team. If the team is not ready, which is not a problem, we can still return a "wdl-like" file that will act as a stub for the time being. Once the team is ready, we can implement the final solution.

FILE* generation(ENUM roomtype, ENUM npctype, char roomid, FILE wdl-rooms);

• "char *roomid" is the room in the wdl-rooms file that has that id.
• "FILE* wdl-rooms" This is the file that the autogeneration algorithm will have to search through to find the prev room.

Now, what will this helper function look like:

room_t findroom(char *roomid, FILE *wdl-rooms);

This function will find the room in the wdl-rooms file based on the given roomid. It will then return that in a room_t struct.

Stage 5: The files from which the algorithm pulls from are fully fleshed out and the algorithm can generate any types of rooms and implement them directly into a set of already coded rooms. It can also be used to generate rooms in the midst of a game. Furthermore, this stage is focusing on how the generation algorithm should be fully implemented into chiventure, such as:

1. How will it interact with the game author?
2. How can the game author interact with it? (not in reference to the CLI but more so its usability)
3. When should the generation algorithm really be used? Can it be used mid-game? That's why it is important that by this stage we have a working algorithm so that we can focus on integrating the generation algorithm well into chiventure instead of working on the main functionality of it.