Hi, this is a guide to help developers get started with ArchaicQuest and what they need to do to contribute to this MUD codebase.
If you go to the main Repo https://github.com/ArchaicQuest You will see 3 projects:
The first MUD project ArchaicQuest-II is the main codebase, this project handles the game, logic and the API required for the web admin. The rest of this guide will be about that project and what’s required to run it and the overview of the project structure.
To run the project you just need
- Visual Studio 2019/2017
- You need to have .net core 2.2 installed
In visual studio you will see 5 projects in the solution explorer
The API project is pretty basic and hopefully self explanatory, the main classes you’ll be using or replicating similar functionality of are these shown below in the controllers folder.
Entities, helpers and services is to do with authentication which is implemented as a proof of concept but net yet applied to the project so these can be ignored.
This API is just simple CRUD endpoints for the web admin tool, In the first version of ArchaicQuest the game content was hard coded and was slow and cumbersome to make updates especially if you’re the only coder 🙂
So with this API and an admin tool anyone can add content to the game without coding knowledge.
The database project is small, just 2 files that uses generic methods, if you want to add a new DB table you just need to update the Collections enum with the new table name. This is shown in the image below.
The Database class has a few key methods that you will use.
- /// Use this to Save or Update
bool Save<T>(T data, DataBase.Collections collectionName);
- /// Use this to get a List of the collection data
List<T> GetList<T>(DataBase.Collections collectionName);
- /// Use this to get the LiteDB Collection, allows you to use linq
LiteCollection<T> GetCollection<T>(DataBase.Collections collectionName);
- /// Use this to get item by Id
T GetById<T>(Guid id, DataBase.Collections collectionName);
T GetById<T>(int id, DataBase.Collections collectionName);
Game Logic Project
This project is where the magic happens ✨
The first folder Account are simple POCO classes for the player account, and player stats.
The Character folder is as obvious too, everything to do with the character or player lives in this folder. The only file that needs explaining is Attribute.cs shown here:
The reason I have added attributes like this in a dictionary is to avoid if/else soup in my generic skill and spell code.
I want it to be simple to add any spell or skill in the admin tool. so they’re generic I only need to check what type of spell it is, for example if the spell is one that affects a player I don’t care what that affect is and the code to affect a player negatively or positively is only a few lines
And as you can see we have the flexibility to create spells or skills that affect anything in the attributes list without having to explicitly code condition checks. I expect this file to get bigger and most of the player information may end up in here that could be affected by a skill or spell.
Next folder is commands
The commands are a simple switch statement.
the key parameter is the command keyword, the options parameter is used for multiple things a few examples would be if you want to extend the look command to look at objects in a room. You would pass the options param into the look method and options would contain a value like sword. or if you add a kill command the target would be the value in options. Player is the player that triggered the command and the room parameter is the room that the player is in.
You will also notice I have a movement folder in the commands folder, plan is to have the majority of command logic in this structure with an interface so the command can be tested
Commands are executed every 125ms in the UpdatePlayers() method in the gameLoop.cs in the core folder which is the next folder to go over. Also when you run the client and see Update posted every second that’s because of the UpdateTime method in the same gameLoop class.
Two important files here, Cache and WriteToClient. If you need anything from a player or room you should get it from the cache and not call the DB this is to keep the MUD performant and fast. Room cache is set on start up with every single room added. Player cache is set when a player logins.
WriteToClient contains the method used to to send messages to a player or players so you will see this used everywhere
Option and OptionDescriptive can be ignored these are only for the API and should eventually be moved.
Next notable folder is Hubs this is the Signlar web socket Hub that the Front end client talks to, there shouldn’t be any reason to make changes here yet. The frontend calls SendToServer and any command they sent is sent to the buffer.
Looking at the Item folder now this is mainly copy paste from the original project as there is no interface or tests yet around items. the main files are item.cs and baseItem.cs.
Skill and spell folder is work in progress and I won’t document them as they may change but before I had a break from the project I was getting set up to add the ability to create skills and spells in ArchaicQuest. The code here should be generic as possible to allow maximum flexibility in the Admin tool.
The world folder is for the areas and rooms in the game. You must have an area before you can add a room as rooms are linked to Areas. Rooms are all coordinate base so it’s simple to create a decent looking map in the client. Look at the Room.cs to see the properties of a room
I haven’t mentioned the test projects but any new methods that are created should have a corresponding test associated to them to cover all scenarios this again is to reduce bugs and give confidence that nothing is broken after a code change.
To run the project just hit the run button in VS
The is no indication the application is running, no windows appear. but if you are running the web admin or game client it will work as expected.
I hope this helps, I’ll add a guide for the admin tool and game client soon