stevengann / trpg

An OOP C# framework for Text RPG games, inspired by the improved console window in Windows 10.

TRPG

An OOP C# framework for Text RPG games, inspired by the improved console window in Windows 10.

What is this?

TRPG is a very generic implementation of a rogue-like text RPG game, implemented entirely as a console application with an interface reminicent of Zork and the like. Your soul means of contol is typing action commands for each turn. These commands are interprited and actions are taken, and the game provides you with a description of the locations and events.

From the top down we see the major features of the UI

• The inventory tray holds all the items your character is carrying. It collapses to one line to make room for the rest of the UI, but can be expanded to however large is needed to show all the loot. The top of the inventory tray shows [weight / weight limit] and [count / capacity] for the inventory.

• The largest section is the main text window. This area serves as the main window into the game world. It displays descriptions of rooms and items, as well as describing events as the unfold.

• The messages tray is simply a log of the 3 most recent messages from the game. These may be echos of player commands, or summmaries of recent events.

• The final section is the command prompt itself. This simple textbox is where the user types the commands to interact with the game world.

Planned Features

• Loading from XML files. Every detail of the game should be configurable via external XML files, from dungeons to items. The only thing bound to the code itself will be the core game rules, but the OOP nature of the framework makes those simple to modify.

• GUI application to generate the XML files. A simple interface for defining dungeon maps, the contents of each room, and the stats on every piece of loot.

• Online multiplayer. By advancing the game according to a fixed clock, actions can be pushed to a server and game states sent back to clients, creating a simple online MUD.

To Do:

• Text GUI system
• Inventory system
• Ability to describe and navigate dungeons
• Load dungeons from files
• Load game rules from external scripts
• Finish combat mechanics
• Improved random generation of items, monsters, and dungeons
• Non-combat NPCs, like merchants
• Improved generated text descriptions of items, monsters, and rooms
• Magic system and weapon classes (melee, ranged, etc.)
• Player skills
• Enchanting
• Crafting
• Survival
• Zombies

trpg's Issues

Levels, Leveling, and Skills

As of now, the TRPG player starts with a set of stats and those are modified by the buffs on items in the inventory. There needs to be some for of leveling at least, and some way for players to choose how their character advances.

Levels:

• Giving Players a level would be an important first step, but it also makes sense to give Monsters levels also. If NPC merchants are ever added, a level on items would be convenient for determining what items a merchant should be carrying at a given time. Basically, the whole Item class needs a Level field.
• Items, and by extension Monsters, already have an Experience field. The intention was that killing a Monster or picking up an Item would impart that experience to the Player. Unfortunately, there's no means to translate this experience to a level. In theory, once experience gets above a certain value, it resets to 0 and the player increases in level. The experience required per level would probably be "A + B * (level + C)^D", where A, B, C, and D are loaded from an XML file or given reasonable defaults. This way game designers can define a linear progression or exponential.

Skills:

• This would probably need to be similar to Buffs, or possibly an expansion to Buffs. This would involve things like melee weapon use, ranged weapon use, magic use, crafting, enchanting, defense, etc., which would be taken into consideration for actions and combat. Expanding Buffs would probably be the most flexible solution, and would mean moving some fields like Health and Defense out of the Item class and into the Buffs class. I am starting to think Buffs should be renamed Stats. This will require an annoying refactor.

[Bug] Some monsters become invulnerable after another monster is killed.

Sometimes, though not all the time, some monsters will become invulnerable after another monster in the same room has been killed. Specifically, the message "You cannot do that." is shown, meaning that there was a caught exception from this line:

gui.MainText = GameRules.PlayerAttacksMonster(this, (Weapon)playerInventory.Find(newCommand.Tokens[3].Text), playerStats, (Monster)dungeon.CurrentRoom.Contents.Find(newCommand.Tokens[1].Text), (int)DateTime.Now.Ticks & 0x0000FFFF);

The Try/Catch block surrounding this line of code was a lazy approach to making sure that the thing being attacked is a Monster, and the thing being used for attacking is a Weapon. I could replace it with a bunch of If blocks, but that'd be ugly and tedious.

Crafting and Enchanting

An item crafting and enchanting system has been planned since the start of TRPG. The Item and Buff classes already have overloads for the Item+Item, Buff+Buff, and Item+Buff operators for this purpose, though an actual interface for these things has not yet been considered.

Crafting:

• Could be done from normal commands intuitively. Perhaps "combine (with|,) [, ...]", where the player lists two or more items to try combining. If an appropriate recipe exists, those items are removed from inventory and the resulting item is added.
• A Recipe class would need to be added. It would need a list of ingredients, an Item defining the result, and some boolean flags denoting if the buffs of ingredients should summed into the result.

Enchanting:

• Less intuitive. Enchantments are basically Buffs, but how are enchantments made available to the player? A list of enchantments the player has learned? Transferring enchantments off other items and on to the target item? Applied from physical object like scrolls or tomes? I suppose supporting the latter two would be simplest.

Dungeon generation bugs

There's a couple serious issues with the current random dungeon generation. The current generation treats it like a quad-tree, but trees were never really my forte.

Paradox rooms: As the dungeon branches, the tips of some branches have door indicating that they continue on, but going through those doors will put you back in the same room. Even though it says you can go West, no matter how many times you go West you're still in the same room.

Infinite Loop: When the dungeon is generated on started, there's a small chance of an infinite loop. Stepping through the code, it's easy to see why, but I haven't found a good way to fix it yet.

Spell system

Whether it is magic, magicka, mana, or the Force, most RPGs include some form of magic. TRPG needs this. The simplest way would be a command that applies Buffs to yourself or a specified monster. We'd need to expend the Buff class a bit. To prevent making the Buff class too big and general, there should be a Spell class added. Perhaps with the following fields:

• Mana cost. With a Mana field added to the Player class, spells could be cast only if the caster has enough "mana".
• Buffs effected. A Buff object addings buffs or debuffs as needed.
• Health, health regeneration, mana regeneration, etc. so that spells could effect these values also.
• Lifetime. Many spells would probably hold their effects for a short time. With a lifetime that decreases with every step, spells could be cast to wear off after certain turns. Temporarily increasing health regen, or strength, or other stats would make simple, common spells, especially at the expense of other stats.

That leaves the mechanic of how spells are made available to the player, and how they are cast. Many RPGs handle this by having a secondary sort of inventory containing spells. A spellbook of some kind. Alternatively, spells could be physical objects such as scrolls or tomes in the regular inventory. I'd love to see some extension to the parser that allows players to devise their own unique spells by typing in long and convoluted strings or phrases, but that's somewhat out of the scope of TRPG for now.

MUD support

One of the goals of TRPG is that it should be modular enough to be plugged into any interface suitable for a Nethack rogue-like RPG game. One of the intended examples of this was for simple support of MUDs. Adding network support won't be simple, and the following will have to be considered:

• Create Client/Server versions of TRPG_core
• Replace turn-based model with clock tick model. Every n milliseconds the server sends all connected clients updated copies of their current game state (Room, Inventory, Buffs, Health, etc.), after executing the last command they sent in. Each client gets one command per tick, but a special chat command gets processed immediately and echoed to all clients in the same room. Room descriptions would need to account for other players.
• Player class. This is a good idea regardless of multiplayer support. Current the player's health, stats, and inventory are all contained within TRPG_core, but this is quickly becoming messy. An Item:Player container class would make this much neater, and allow for simple management of multiple players in the same room. Perhaps if Player inherits from Monster PvP combat will be simplified?
• Network interface. This is a week spot with my programming experience. The simplest interface would be a direct TCP/IP connection. Of course, using HTTP would allow simple web interfaces, which would be beneficial for getting more players in the game faster. A SQL interface would add even greater flexibility, allowing any number of client or even servers to share, view, and edit the game. With the entirety of the MUD's world contained in a database, a website could provide a view of the world, a table of ranked player stats, or even bridges between servers.
• Compatibility with existing MUD clients. Frankly, I'm not an expert on MUDs. I do know that they are a very old concept, and there are several popular MUD clients available, most of which use Telnet. A compatibility module for standard MUD clients would be a major feature.