PvP combat is something that is very dear to my heart and nothing quite beats the rush from testing myself against a human opponent. You just don’t get those extremes of emotion from the elation of victory to the utter despair of defeat when fighting against mobs. One problem you are going to face when designing a PvP combat system is how to control the impact of client side scripting or automation.
I am starting with the assumption that too much automation is a “Bad Thing”, but you may consider scripting to be just another measure of player skill and see no problem in a combat system that can be heavily automated. That’s fine and dandy of course, just as long as you don’t find yourself in that position by accident.
Let’s start with the basics; what is it that we want to achieve from a PvP combat system? In my case I want a system which places equal, or perhaps even greater, importance on the skills of the player as opposed to their character. So far so good, but what kinds of player skills do we mean? This is a topic for another blog post I suppose, but we can say there are two very broad categories; game knowledge and speed of thought.
Game knowledge
This includes things like knowing how different skills work, how to use equipment, what counters there are to various attacks, etc. Essentially we want our combat system to favour players who have spent time learning how the game systems work. Game knowledge is usually also a significant factor in combat systems which are biased more towards character skill than player skill, for example in choices the player makes when developing their character or in preparing for combat.
Speed of thought
This second component is principally what differentiates a player skill system from a character skill one. We want the system to reward players who are able to apply their game knowledge to make choices quickly and accurately “in the heat of battle”. This kind of “twitch” game play is common in FPS games which are usually purely about player skill. Unfortunately client side automation has the potential to make this a non factor in MUDs.
Preventing client side scripting
The short answer is you can’t. The best way would be to require a custom client, although it’s still possible to use third party software to simulate input so even this is not completely effective. Instead of looking at enforcement it’s much better to design a combat system from the start that doesn’t reward scripting.
Types of automation
While it’s possible to script all sorts of strange things with MUD clients, the two most common tasks are aliases and triggers. Aliases are good because they save us having to take the complexity and frequency of commands into account when balancing our system, particularly as we aren’t concerned with typing speed as a factor of player skill. Triggers however have the potential to remove any speed of thought from our combat system by replacing the human decision making process with a scripted one.
Limiting the effectiveness of triggers
When all possible outcomes are known then the best choice in any given situation can be automated. Take the example of affliction A that is healed by cure X. We can easily script to use cure X every time our character gets affliction A. What about now if affliction B prevents us using cure X, so we need to use cure Y first. Except we can’t use cure Y because we have affliction C. And so on and so forth.
This kind of system may appear quite complex on the surface, but it’s still relatively simple to script. At any point in time if we know what afflictions we have and how they are cured we can script an optimum choice. The key point is that pretty much all the factors that we need to decide which cure to use when are known to us. If they’re known to us then they’re known to our scripting system and we can let that make the decision for us. Adding another 20 afflictions with another 20 cures won’t solve the problem, and if anything will make it worse. In this system you have a lot of information that needs to be evaluated to reach a decision. This is much easier for a computer than a human being.
Unknown factors
The key to making choices which are hard to script is to make them depend on unknown factors, or more accurately factors that it’s difficult to program a script to take into account.
Taking our affliction example above, say that now we only have cure X, but it can be used to heal our choice of afflictions A, B, C, D or E with a 60 second cool down. Assuming afflictions A to E differ in severity, at any given time we can script the best affliction to heal based on what we are currently afflicted with, but cannot possibly know if we are likely to be afflicted with a more severe condition within the next 60 seconds. The player then has to make the choice to heal an existing affliction or save cure X for a possible future more serious affliction. This choice is much harder to script because our future affliction state is unknown, instead we have to make an educated guess based on experience. This is much easier for a human being than a computer.
It’s not impossible to script this choice of course, because while we don’t know if we will need to use cure A again within the next 60 seconds, we know that we either will or we won’t. If our opponent has a finite number of choices they can make and all those are known to us then in theory we could calculate an outcome for all situations and from this the best choice to make at any given time, similar to the way a chess computer may calculate many moves ahead. There is also the possibility to use some kind of artificial intelligence or learning system to guess which choice to make, however both of these solutions are probably beyond the realms of MUD client scripting. It is certainly easier for players to use their judgement and experience than attempt to automate the decision process and this has to be the goal.
Maiden Desmodus Powers system
The powers system in Maiden Desmodus is my attempt at introducing a mechanic which is hard to script in an effort to better reward game knowledge and speed of thought over client side scripting. Most powers greatly enhance existing abilities for a very short time with effects that can dramatically alter the course of combat. When a power is used the character’s power bar is depleted and they cannot use another one until it is filled again which can take several minutes. There are both offensive and defensive powers and some are very situational, so the player must choose whether to use a power at a given time with the knowledge that if they do so they won’t be able to use another for some time.
Some players will choose to risk all at the start of combat by using a power in an attempt to gain an early advantage or overwhelm their opponent whilst more defensive minded players may prefer to wait in case they need to use a healing or curing power to save themselves later in the fight. It is my hope that the decision of which power to use and when is not something that can be easily scripted so players can instead use their judgement and experience.
The powers system is something I hope to expand with additional abilities in response to player feedback once we go live for some proper testing.
bcdev.design.blog 