From The Mana World
Line 18: Line 18:


== Improving visualisation in the client ==
== Improving visualisation in the client ==
== Conclusions and Future Work ==

Revision as of 01:59, 15 May 2008

(Apologies for the style, but I was in a bit of a hurry. This is how I'm normally expected to write these things, which is why it looks a bit weird and says `we' all over the place.)

Abstract: eAthena is not part of the medium-term development perspective for tmw. Consequently, changes to eAthena are subject to a short lifespan and little hope of re-use. As a result, there is no discernible feature development for eAthena to extend the player experience on this server. This document proposes a simple magic system as an addition to the eAthena system. The magic system satisfies the following requirements: (a) it is easy to implement and integrate into eAthena, (b) it can be easily configured and fine-tuned, (c) it requires no client-side extensions to function properly. We present the system together with fifteen spells as well as their intended behaviour and describe how we expect the system to function in regular gameplay. To test the proposed system, we have implemented a prototype that we describe as part of this document.


Introduction

eAthena conceptually supports a magic system; however, this magic system requires client support. Furthermore, if there are bugs in the system, the generally low quality of code in eAthena would make debugging those a less than pleasant experience. Since plans on the tmw side further expect eAthena to be retired soon, it seems wasteful to spend much time on a feature-rich magic system. Instead, we propose the adoption of a simple magic system that provides the `bare-bones magic experience' as quickly as possible before eAthena support is retired: players can cast spells, but will not be required to wait for a new client to become available. To facilitate such a system, we opted to use the regular chat interface as a means for communicating the intent of casting a spell to the server. Player location and heading further affect the spell's effect more or less subtly. While these interface choices are limiting, they (a) do not require players to familiarise themselves with a new interface, (b) do not require the implementation of `throw-away' interface and protocol code, and (c) are already sufficient for a number of interesting spells.

In the following, we first summarise the basics of the magic system, specifically the notions of `spell power' and `spell requirements'. We then discuss a number of spells that can be expressed with the proposed interface; all of the listed spells are also implemented as part of our prototype. We then give a high-level overview over the implementation of our prototype, followed by a description of how `spell requirements' can be configured. We conclude with a list of possible approaches towards improving the visualisation of these spells by means of altering the client.

Basics

Spell list

Prototype implementation

Spell configuration file

Improving visualisation in the client

Conclusions and Future Work