With the end of this iteration of chiventure, there is a lot of room for future developers to improve upon the current modules included in the dev branch, and for them to create brand new modules. Here are immediate things that can/should be improved upon with the future of the graphics team in chiventure:

GDL

One of the most important things is to implement modules integrating the features of the read_gdl module, and gdl files in general. Each module currently works rather independently, and while some do use important structs within gdl to make their own structs, they still lack in a way to dynamically implement information when a gdl file is read. In the future, it'll be useful to:

1. Load information from parsed gdl file into structs
2. Link all these structs and information together to make to make graphics more cohesive

Statistics

Statistics is one of the most skeletal modules currently in graphics. The structs needed for statistics are implemented, but other functions in the module are just defined without any implementation. When dealing with this module, it'll firstly be more important to implement the rest of these functions before considering any other expansions with the module.

Inventory

Important structs and the draw function for inventory are implemented. In the future, it's desired that the player will be able to have a graphical display of the descriptions of items in the inventory, rather than just relying on any output that may come to the terminal. Exploring how the inventory can update and change in real time (such as when the inventory is currently open) would also be worthwhile to explore in the future.

Maps

Important structs and the draw function for maps are implemented. In the future, it's desired that there will be expansions on how to better update the draw function with the coordinates with the player's location. When graphics is better implemented with chiventure as a whole in the future, it is also desired that there will be inclusion form open_world, especially when attempting to display a map system that allows the player to see the possible rooms near their current room when playing a chiventure game.

Quests

Important structs and the draw function for quests are implemented. When implemented with the rest of chiventure, it will be important to watch the improvements with the quest team. There are possibilities for images that relate to the quest to be added to the quest, along with giving more freedom with the author to display quests that isn't visually the same as a tree-like structure. Especially with the large variety of the way quests can be displayed in other games, it's most important to give flexibility to the author.

NPCs

While important structs and the draw function for NPCs is currently implemented into chiventure, the module is not merged into the dev branch. Adding this module to the dev branch is an important first step before expanding upon it. Nonetheless, to expand upon NPCs, it may benefit on implementing how NPCs can be friendly/hostile, and have the ability to have such a graphical display change in case a conversation with an NPC causes this friendliness to change. Along with this, it may be worthwhile to allow there to be visual cues if the player choses the right/wrong choice for a conversation with an NPC. This is stuff that will likely be able to be added to what is already in NPCs rather than creating entirely new functions, but still something worthwhile to consider.

Input Box

Important structs and the draw function for input box are currently in chiventure. It'll be worthwhile to expand upon the use of the buffer that holds information when the input box is used, and how cleaning it up can be most seamless for the author.

Scenes

Important structs and the draw function for scenes are currently in chiventure. Scenes currently take png files as textures, but it may be worthwhile to expand how scenes may change immediately or within a certain frame when players move around a specific room.

The biggest goals for graphics is for everything to be flexible for the authors of chiventure games. Knowing when to be broad and specific is integral in making this aspect of the engine compatible for not only authors but for its integration into the rest of chiventure.