Version 0.4
The tech demo is available at eden-test.rpgframework.de 4000 .
All previously existing characters may have been deleted - your old account though should still exist.
The Combat Overhaul
Previous versions of the GraphicMUD already had combat functionality, but more as a proof of concept - it was far from what I intended to implement. For this release I decided to really start working on it.
The cornerstones of the new implementation should be:
- an opponent AI that supports some planning (like walking to a weapon, picking it up and equipping it before going to the target and attacking it)
- a framework that allows games using the engine to define their combat rules and initiative tracking
- a user-configurable speed (e.g. for idle gaming players vs. fast auto-combat players)
- a user interface that visualizes health of actions combatants
So, let us have a closer look at those cornerstones:
Opponent AI & Planning
Our first combat draft had a simple auto-combat. In a given initiative order combatants could make their attack (or could have cast a spell, if supported). That's not really sufficient—first, because we have a 2D map and combat positions (you may have to move toward the enemy first), and second, because actions can vary widely (for example, a defensive maneuver is only worthwhile if you've been attacked in close combat).
To allow more complex planning we introduced Goal Oriented Action Planning (GOAP) , which is an concept that came up in game development nearly 20 years ago and is well established. That also meant we needed to introduce an API for actions is simple enough that real game implementations using the GraphicMUD framework will be able to make use of that.
Since some time now, the GraphicMUD engine uses Behavior Trees (BT). They are intended to a) power fixed behavior of mobiles and b) drive actions like walking to a position. For this release we merged BT and GOAP in a way, so that every action the GOAP planner deals with is also a possible node in the behavior tree. For example when the planning results in "Attack Action" but that one requires to walk into weapon range, the planner dynamically inserts a sequence node with a "Walk to Target" node and an "Attack Target" node.
The game can register its actions. Each action comes with a list of preconditions for world state and information how the world state would change, if the action is successfully executed. The whole concept works, but we have yet to test it with more complex cases to be really sure it is final as it is.
Customization of combat rules
Combat is one of these topics where a generic engine isn't really that involved, since combat rules, balancing, dice rolling and stuff is heavily dependent on the game rules - which are by definition not part of the engine. We solved this so that whenever a new combat object is created, the builder itself is passed up to the game to be modified as it seems fit.
CombatPlugin.setCombatRPGConnector(new CombatRPGConnector() {
@Override
public void onNewCombat(CombatBuilder builder) {
SACombatHandler handler = new SACombatHandler();
builder.initiativeModel(new DynamicTickBasedInitiative(handler));
builder.rpgListener(handler);
builder.combatAI(new SACombatAI());
builder.mode(CombatMode.FULL_AUTO);
}
});
The example above has SACombatHandler - a game class - that implements an interface named RPGCombatListener , which is called whenever an action is performed. The example also show that the game can select how initiative and combat order is handled (initiativeModel), where an implementation of a tick-based system is called (DynamicTickBasedInitiative, which uses a second interface named TickBasedIniListener to determine the initiative of combatants).
Combat Speed
A lot of Diku derivates have auto-battler, that once the combat started do auto-attacks for you and allow you to watch the text cinema scroll by and type an occasional command. Let's call that "Full Auto". Other games give you a few seconds time to type your command or - you either don't act or some default action is performed. And still other games (e.g. idle games) wait indefinitely for your input. We want to support all of them.
Currently we have the following combat modes:
- FULL_AUTO - Does not wait. Either you have an action already prepared in the queue or a default action is performed.
- FAST - Waits 10-15 seconds for user input
- SLOW - Waits 30-60 seconds for user input
- IDLE - Waits indefinitely for user input
The exact intervals for FAST and SLOW needs some testing. The general idea, though not yet implemented, is that the user can configure a preference.
Visualization
The GraphicMUD engine performs screen management on the client wherever possible. This also means that we want to have a special screen layout only used in combat siutations.
The details how this is implemented differ depending on used protocols (VT100, MXP, Webviews), but the general idea is to have the following areas:
- A list of opponents with some kind of health bar/information
- Same for your party members
- A map area showing the battlemap
- The scrolling output
- A line with gauges for your health/resources
- A line of clickable shortcuts for useful actions
- The command input area
- A list of active effects
- A list of upcoming combatant turns. Especially useful for tick-based tracking.
Here is an example of a combat using Mudlet (4.20.1 PTB)
We made a huge step forward regarding combat in this release, but far from finished. I expect future releases making incremental improvements for this topic.
Engine changes
New method for room scripts
This release only had some fine-tuning in the core architecture. The most significant addition was a new option how to call room scripts. Previously such scripts where extra files which reside somewhere in your static data directory. Now you can give a fully qualified Java method reference, which is then called via the Reflection API. This allows better verifying and debugging scripts inside your IDE.
Clean up WebViews
The webview UI code has been cleaned up a bit to follow a constent structure.
Default actions on entities
Plugins can now register default actions for certain entity types. For example, the combat plugin registers a default "Kill" action for mobiles - or the Inventory plugin registers a default "Get" action for items.
In the normal exploration interface those actions are listed below each entity as clickable buttons.
Stat commands
A new command has been added to the engine to expose all stats of entities. We don't have a permission system yet, so currently this command is available for all players, but it is intended to be restricted later.
Plugin Changes
New Plugin: Grouping
You don't need to fight alone anymore. The new grouping plugin allows you to form groups with other players, which then share the same combat and can see each other on the map. The plugin is still in early stages - we are not sure about the exact syntax and eventually missing options - but it is already usable.
MCP Connector
With this plugin the MUD offers a MCP server to type commands and receive MUD output as a result. It was used for an experimental MUD-playing LLM. The lesson learned from that experiment was that
- LLMs have problems to ignore items that are only described in fluff descriptions, even with explicit instructions to ignore them
- It is better to provide a list of all possible actions instead of letting the LLM guess the commands
So, in its current state the plugin is a fun toy, but not really useful. That might change in a future release.
Steam Arcana changes
Adjusted actions to the GOAP action datatype. Implemented new combat logic. Implemented handler for new stat command.