Feature Wishlist
This page is intended as a space to list and brainstorm possible new features for chiventure.
For most features, we have included a list of "reasons to pick this feature" and caveats, to help guide whether that particular feature can be a good fit for your interests.
- Adding graphics/images to interface
- Sound support
- Enhanced CLI
- Framework for creating test games
- RPG features
- Multiplayer support
- Domain-Specific Language for Game Authors
- Game authoring tools
- Support for custom scripts
NOTE: Two teams (in 2020 and 2021) have already made progress towards this feature; you can find a wishlist for this feature here: Feature Wishlist (Spring 2021)
chiventure currently has a purely-text based interface, but it could have a more graphical interface while still being a text adventure game engine at its core. For example, consider the following screenshot from King's Quest:
Notice how there is still a text-based command prompt, but a graphical interface to display images as well as text (Note: in King's Quest, you're also able to walk around graphically; that's not something we would support)
NOTE: Work on this feature began in 2021, but can be continued in 2022
Add support for playing background music (which could be room-dependent, etc.), as well as sound effects when certain actions are carried out.
Reasons to pick this feature:
- You will probably end up learning quite a bit about sound formats, etc.
The Command-Line Interface in chiventure is currently pretty rigid, and relies on very low-level tokenizing (with standard C functions) to parse each command. It would be nice to have a more flexible command parser, using something like yacc or ANTLR.
Reasons to pick this feature:
- You get to learn some basic parsing
Caveats:
- You need to learn some basic parsing
Right now, some features are effectively non-testable until they are supported in the WDL/WDL++. For example, suppose we added support for NPCs and dialog trees. While we could write unit tests for individual functions, it would be hard to test a game with NPCs until it became possible to specify NPCs (and their dialog trees) in a WDL/WDL++ file.
We need a framework to easily create in-memory games that can be used in automated tests, as well as in basic user testing. While it is already possible to use game state functions to create an in-memory game from scratch, there should be higher-level functions to easily create such games.
Those games could then be created solely within automated tests, or invoked from the CLI to do user testing.
Reasons to pick this feature:
- It will be a bit heavier on design (which can be a good thing if you're interested in that aspect of software development). If the design is well though out, the implementation should be (relatively) straightforward.
- Will get you thinking much harder about how software testing works (what we're proposing is basically a mechanism for easily creating test fixtures, a very common aspect of software testing).
NOTE: A variety of RPG-related features have been worked on since 2020 (see Battles, NPC, Open World, Player Class, Quests, Skill Trees, and Stats in the sidebar). There is also an [[Open World wishlist|Open-World--Feature-Wishlist]] and a [[Battles wishlist|Battles--Wishlist]]
If we wanted to allow game authors to write RPG-style games, there are a large number of features we could add to chiventure:
- Player classes (monk, knight, healer, ninja, etc.) with different skills/stats
- Each class would have a unique set of available traits and items, meaning that there would be a mechanism to block certain item types to be picked up/used by certain classes (e.g. healers can't have swords, knights can't have staffs, etc.)
- Player races (human, orc, elf, etc.) with different factions in the world
- Possibly different "starting locations" for each race and/or faction, with a world that is auto-generated to be similar in gameplay but different in content (i.e. still same game, but the races of the NPCs, names of regions in world would be different)
- Player stats, such as health, experience, speed, attack, mana, stamina, charisma, etc.
- Skill trees (unlock spells like teleportation, lock-picking, or magic light sources for some random underwater room that would put a normal torch out)
- This could be expanded to combat spells/abilities as well if some sort of battle system is implemented
- "Open world"
- An increase in map size from what we have now to a more "open" world for exploration: it could be fun to look into ways to autogenerate structures and world types randomly, and then to possibly fill in the blanks with NPCs, quests, dungeons, bosses, etc.
- Battle system with NPCs
- Perhaps Pokemon-style battles: turn-based, can choose from one of 4 moves, try to escape, roll for seduction, use an item, etc.
- "PvE" battles: implementing a system to have NPCs that are more difficult to battle with; bosses, etc.
- Player statuses: these would be effects that modify a player's stats for a given amount of time or until a condition is fulfilled
- In particular, adding support for custom statuses would likely be most beneficial
- For example, poisoned decreasing health, fatigue decreasing movement speed, or durable increasing resistance/hit points
- Quests: the world map would have NPCs giving out quests for the player to complete.
- These could be as simple as "bring this item to this other NPC" to "go to this location in the world and kill this boss"
- Reward mechanism for the quests would also be cool: when completed, the quest would give you items, gold, experience, etc.
- Add a way to optionally give items a flavor text
To be clear, it would be infeasible for a single team to implement all of the above.
chiventure currently assumes that there is a single player. We could extend this to allow the user to control multiple players in the game, where the user could switch to a different player at any time, or only at some set points in the story. The players could also be in entirely separate worlds.
We could also add support for multiple users playing within the same chiventure world, but that is something we probably don't want to tackle until much farther on (specially since it would require non-trivial amounts of network coding).
NOTE: Work on this feature began in 2021, but can be continued in 2022
Right now, we envision WDL++ as being a pretty low-level file format that is easy to process programmatically, but not easy to write by a non-technical user. Ultimately, there have to ways for game authors to easily write games, without having to understand formats like YAML or JSON. A first step in that direction is defining an author-friendly DSL (Domain-Specific Language) that can be "compiled" down to WDL++.
Reasons to pick this feature:
- Because you're effectively writing a translator from a DSL to a file format, your code would be separate from the chiventure code (but would still depend on it, because you have to translate to WDL++)
- This also means that the DSL could be implemented in other languages, not necessarily in C.
Caveats:
- Unless you are already familiar with parsing, DSLs, etc. this is likely to be a challenging feature involving a lot of self-guided research.
Related to the previous feature, we may want to eventually have tools that make it even easier to write games, like map editors, dialogue tree editors, etc.
NOTE: Work on this feature began in 2020, but can be continued in 2022
chiventure currently has an Action Management component that allows actions to have certain effects, where the set of possible effects is fairly constrained, and has to be baked into the chiventure code. It is effectively impossible for a game author to express actions like "if the player pushes the wall, remove the wall only if the user has three amulets in their inventory, and more than 500 coins in their money bag", unless we added support in Action Management (and in the WDL!) for expressing conditions, checking the inventory, comparing integer amounts, etc.
Ideally, game authors should have a mechanism to express these more complex conditions. One way of doing this would be with a scripting language like Lua, which is specifically designed to be embedded in other systems.
- Lua has a C API that can be used to interact with a Lua machine inside of a C program- documentation
- Potential uses for custom scripts
- Complex custom actions (using some sort of powerful action builder API)
- Better world generation (simple example- use a doubly-nested for loop to generate 2D grid of rooms instead of by hand, with random item placement at runtime)
- More complex control over NPC interactions (have the NPC call functions in the Lua scripts and the scripts return complex dialog/response options in real-time instead of predefined ones)
- If Lua has a way to interface with the internet, could be a janky way to set up cross-server interaction or even multiplayer through reflecting actions through an NPC on each side (Lua script interacts with another chiventure server running another Lua script)
Reasons to pick this feature:
- You get to learn Lua
- More generally, you get a lot of exposure to using APIs, which is a valuable skill to have.
Caveats:
- This would be a pretty challenging feature, requiring a lot of self-guided research.