Recent development

Recently I took up the work on this project again and I finished the automatic testing part quite quickly, once I started to work with the interactive part I realized that all the code I put in the interactive test class I realized it worked more or less the way I wanted to, but the code was messy and it took a long time to extract it to what I call event classes; I now have action events and item events. This was the first step to going away from playing in a console window and building a guided user interface instead, I managed to sort the test class out and make an interface for I/O and set up a GUI to display and get choices from instead, also for testing purposes I created a third implementation of that interface which always gave fixed returns and displayed the same as the original test class. Finally the differences between the tests were so insignificant I could use the same code for all and from that I created a driver class, which is the main thread of the game.

Parallel with this I worked on stages, jobs, monsters, skills and items where I managed to implement all of these using simple configuration files and the properties class, this way I have created all but the agility job among the base jobs and one or two jobs for higher grades. Stages full with monsters and item rewards at the end ranges from stage 0 to stage 7 now, with stage 6 as a boss, I’m only satisfied with the story behind stage 0 and 1 though, the introduction and tutorial stages. For each stage there will be a lot of work needed with the balance but as long as I haven’t finished the jobs and their skills there is not much point in working on balance questions, the new timing attribute I will add today will also affect balance greatly.

Timing

Even if it is a turn based game still I will introduce a timing feature; basically all actions will take a specified amount of time and cannot do anything new until this time has passed. I have already in skills set two variables, cast time and cool down, and all weapons also has the cool down variable. To start with I will let all actions be instant and only work with cool down. It feels somehow more realistic and easier to imagine to work in seconds therefore I will set a normal cool down, or a normal action, to about 2 to 3 seconds, the representation for this, however, will be in hundreds of a second, each countdown will be .1 seconds at a time, which will basically be a turn, and decrease countdown value by 10, this can be increased though and that is why the representation is larger; with increased speed a higher value, such as 11 or 12 will be deducted each .1 second, giving a 10% or 20% speed increase respectively. The time variable will lie in the unit and counted down on each iteration, a unit will not be selected to do an action if the value is higher than zero.

Tanking

My original thought on how the battle strategy and monster AI should work is quite similar to WOW were you have a threat value and threat range; basically each monster will have a priority list with each player in it and simply attack the one who has built highest threat, action would cause threat to rise depending on distance and action. For example a damage spell like firebolt does X damage and raises the threat by X times f(distance), where f is function that reasonably decreases with distance. However since damage dealers would reasonably do much more damage than tanks they would easily steal the position as target, to counter this the tank uses skills which does additional threat even though damage is low, and other skills that only exist for threat building and/or forcing the user to be the target of the target for some time, so called taunts, another way to counter the higher threat from damage dealers is to let them have skills with reduced threat or have skills that reduces the threat value of enemies, single or all. Finally to make it a bit more difficult each action should affect all enemies within a distance, forcing the tank to divide his attention to several targets or have several tanks, this will require the tank to have skills that build threat very quickly and/or skills that can build threat on several enemies at the same time. Outside the threat distance enemies will not raise their threat value, and as long as their threat level is below zero they will not attack anyone.

The new idea that Kei introduced to me yesterday is more dependent on the positioning of characters; basically the monster will chose a target based on some value, perhaps can use something similar to a threat value, but as the enemy moves and attacks it will do so with the first target it can find along the way, e.g. if you place your tank between the enemy and the target the enemy will automatically attack the tank. There will have to be a form of calculation where the targeting system decides on a path from the unit to preferred target, and then basically simulating a walk over that path and picking out the first target available as the real target, this could also include positions neighboring the path.

I guess I could use a combination of the two, basically making it more difficult for the tank to hold a high threat level but allowing positioning to matter, so that even if a tank loses the main target position he will still take the damage as long as he is standing between the enemy and the preferred target, giving the tank a chance to build up threat again.