Archive:Combat system

This article collects information regarding the conceptualisation of the gameplay of The Mana World

This article contains information for Programmers working or interested in working for The Mana World

Does it work?

I'm convinced that the greater majority of the developers of TMW are looking for a free-form style of combat that set SoM apart from other RPGs of its class. This system requires skill and alertness on the part of the player, as well as preparedness and training on the part of the character in order for fights to succeed. It also engages the player in combat, by giving him total control over his character's actions.

The real issue with a realtime combat system is feasibility and server traffic. Our theoretical server has about 1mbps upstream, so we have to make packets as small and infrequent as possible.

When a player gives a command to the game, such as cast spell, move left, use potion, etc. A packet of data is sent to the server. The client can requlate actions so that no more than 1 can be performed every 500ms, so as to prevent high downstream server traffic. A player command packet contains 1 variable, a short integer which is the ID of the given command. A packet of this size takes approximately 2 bytes of space.

The server takes this command and interprets it into character movement. When the servers clock cycle reaches a certain interval (250ms for example), it builds an update packet for each player. This update packet contains information on each Being within the player's viewpoint only- it's position(x,y) as well as the action that being is currently performing. The client recieves this data, then interprets it into a visual model. The size of a packet like this (containing 3 short intergers) is approximately 6 bytes per onscreen character.

Math Time: In a heavy load area (50 characters), the update packet contains 300 bytes of data.

We are able to send 1,048,576 bytes per second, or 262,144 per quarter second on our projected server limit. This equates to serving up to 873 high traffic area players per quarter-second without a flaw. If the number of players increases beyond the server's capacity, the server's response interval can be cut in half to accomidate twice as many high-traffic players. Needless to say, this packet rate and size is small enough to run easily on even the slowest modems.

In a more common scenario, however, the player will only need about 10 active characters onscreen, which means 60 bytes per packet, or 4369 players supported by the server under this method, and all within the projected server limit (which means no lag, at least not serverside).

If this page gets rewritten, it should take into account a lot more things into its calculations. In particular, if you consider the IP+UDP+enet overhead and the seven monsters walking around a player on average, you have to add at the very least 100 bytes at each tick and for each player. So for the high traffic area example, you are down to 650 players. And for the more common scenario, you are down to 1600 players. And with the 100ms tick of the current tmwserv, you are down to 250 players and 650 players respectively. silene 11:30, 12 July 2007 (CEST)

As you can see, this method is more than able to cope with realtime combat, and a player feels only a quarter of a second delay maximum before his command executes on his own screen and on everyone elses. That's an acceptable delay to trade for realtime combat.

This delay has to take into account the communications. Assuming 75ms communications and four ticks per second, you get 275ms on average and 400ms on maximum. With the current tmwserv, it is 200ms on average and 250ms on maximum. silene 11:30, 12 July 2007 (CEST)

---

This is it

Ok, so here's the breakdown of the real time, active, directly controlled combat.

Movement - players move when they send a command to move. There are two types of move command-initial movement and end movement. An initial movement packet tells the server to start moving the player until the end movement packet is recieved. This is sent when the key (or mouse click) is first pressed. The second is the end movement packet. The end movement packet tells the server to stop moving the character at a regular rate. This way, movement can be smooth and continuous, rather than pixel by pixel, like some have suggested it will end up.

First off, players have a bar in the screen that measures time, since the last attack. When the player presses the attack key, and the bar is full, he makes an attack (there are no intermediate attacks, to reduce downstream server traffic).

Charge attacks exist too. To execte a charge attack, the player can hold a button. when the button is pressed, the server gets a start message. When it is released, he sends another attack message. The server calculates the amount of time between the two packets, then executes the corresponding charge attack. There are 10 attacks for each weapon type, and they are learned at weapon skill levels that are multiples of 10. Also, to perform a charge attack, the player must be wielding a weapon of the correct type, and that weapon must be built with synthesis up to level X. (see the EquipmentSystem for more information on weapon synthesis). While charging, the player moves a bit slower than normal.

When the player wishes to use a spell, he opens the context ring menu, (spacebar or right click with the mouse), selects the proper spell, then chooses the appropriate target within range (be it an area or a being). The player then goes through a short spellcasting animation, during which time he can be interrupted by a critical attack (10% or more of his HP in damage). After that, the spell is cast and executed. Spell casting is also regulated by the time bar, however, some spells may cause a freeze longer than normal after being cast. This depends on the specific spell, as well as the caster's magic level (higher mastery = lower freeze)

While I personally believe the mouse is one of the great evils of computer gaming, some members of the team feel that it is a necessary evil to include in the system. For this purpose, I've created a list of mouse controls and corresponding keyboard controls.

Move   - Hold the left mouse button in the general area of the screen you want to
         move. The character will follow the mouse to that point.
Attack - a fast click near the player causes him to attack.
Charge - holding the mouse directly over the character for a moment causes him to
         start charging. To move while charging, drag the mouse away from the
         player without letting go of the left button.

I'm not totally sure about how the mouse controlled model will work, but we can edit it as needed to ensure that it engages players in the same way as keyboard control.

On a final note, some have expressed concern with lag issues as associated with our current system. The main argument is that if a long lag hits, players will be at the whim of monsters without a chance to respond. However, since the client and server will be sending packets constantly back and forth (for movement, attack, or even when idle) it is easy to fix the system such that monsters cannot attack a player who has not sent an update packet in the last 2 seconds or so (remembering that monsters, like players, can only attack twice a second at best, and usually only once). This will avoid players having to worry about death simply because of lag.