Being in the early stages of planning TBRPG has me thinking about a lot of interesting things regarding building a game engine. While this isn’t a graphical endeavor and therefore a lot more simple in nature, there are a lot of elements used in RPGs that I didn’t really think about until I had to think about them. I figured I would share some thoughts on what I am currently working on and the direction I am going with the project.
One of the first things I did was thought about the limitations I had with previous projects. As a result, I have been rewriting a lot of the aliases that I generally use during development to make them easier to use and easier to understand. I am essentially building a framework first to start developing the game on and then starting to delve into specifics of the game such as how encounters work, how questing works, inventory management, and other functions.
Since I am using mIRC as the base engine for this project, there are both some benefits and limitations to this approach. While it is possible to run mIRC within Wine, it is not something I am interested in exploring at this point since I don’t know what kinds of issues I could encounter given that I am generally using the latest version of the IRC client. mIRC has its own scripting language and therefore could run into some issues with the scripts that I write if I try to run them in a Linux environment.
This essentially means that hosting the bot is going to be a bit more complicated since I cannot just get a cheap Linux VPS for the project.
How mIRC Works
In case someone reading this doesn’t have a background in coding in mIRC, I figure I would give a quick rundown of how scripting works. You can break it down into the following types of scripts:
Aliases – These are commands you can create which you can use by typing them with a forward slash in the chat window or reference it within code.
Remotes – These scripts generally have some sort of trigger for them to activate, such as a user joining a channel or a specific text being posted in the channel or in a private message.
Popups – This is the drop-down interfaces found in the mIRC client.
In essence, I will use Aliases as the core of the framework and use remotes to allow for users to interact with the bot. The popups will be used for administrative purposes such as enabling and disabling the bot or making changes to a character or NPC.
Since mIRC doesn’t have a built-in means of communicating with a database, data is handled in configuration files and individual data files. There is a plug-in for mIRC to give you access to MySQL databases, but it is out-of-date and may not work well with newer revisions of either MySQL or MariaDB, therefore I want to avoid a database implementation.
Data management will be as simple as storing all of the information in either local variables (temporary variables only accessible to those specific scripts), global variables, and files stored on the hard drive. There will be data files which contain information about every element of the game including items, spells, skills, quests, and NPCs as well as individual files for player characters. The storage is a simple format.
This format allows for me to easily access and ready information in a variety of different ways. I have built aliases that will be commonly used to fetch this information. For example, the ‘readvalue’ alias is being used as a way to retrieve a particular value for a character (both player-controlled and NPCs). Different aliases will be made to make it easy to retrieve specific types of information including a specific value for an item or returning the enabled/disabled state of a specific feature.
Previous projects I have worked on have focused on having different playable characters. In this case, I am planning on having different classes to choose from which will influence a number of different aspects including the skills/spells the character has access to and how their stats are affected as they level up.
Each class will have it’s own focuses and optimal strategies, though I want to provide a level of control for players to be able to approach their character in different ways. For example, one of the classes will be your standard magic user, but will be able to choose which elements they employ and which spells are most important to them.
Each playable character will have its own unique stats and will be able to level up as they play the game. I am using a standard experience system, although the experience curve is defined on a per-level basis right now in order to prevent the experience requirements from going out of whack. I may try using a formula to determine the experience on a per-level basis, but right now I am quite happy with how I determined the totals for now.