I haven't fully got all the actions back in, else I would've released a build. What I do have so far works like so. Every creature has a turn delay. Performing an action adds to this delay. A creature can not perform any action until the delay returns to zero. The system happens seamlessly without the player even know its waiting as long as it might have to. Right now there's no delay between turns, which causes fast creatures to seem to move multiple squares at a time. I'll be trying out a delay before releasing, very short delay but something to notice what each action is that's being taken.
My first inclination for speed is to have a speed rating for each creature, not sure what I want to effect it though, or if specific items will effect specific actions. I want to keep it simple so for now, speed affects every action equally. Speed is rated as one equals the fastest and ten or more equals the slowest. Each action will have a base turn delay, which is multiplied by the creatures speed. A creature with speed one can move one space per turn, but a creature with speed five can only move one square per five turns. Right now it works just how I want it too.
Though I have one worry that I don't have enough functionality to test yet. Every action no matter how big the delay, happens immediately. I could see the delay being broken when it comes to really powerful attacks. What draw back does the player encounter if an ability is strong enough to wipe out all threats in one use. What matters if it has a 100 turn delay if it removes any threats that might have killed them during the delay? Like I said though, I wont know till it comes up.
I also redid the basics of the combat system. You can finally miss and so can the AI. Each creature will have a hit chance ranging from 0 to 100, and a defense rating that should range anywhere from 0 to ~200, though anything above 200 should be difficult to achieve if not impossible. The calculation I'm using is
successful Hit = rand(100) < (hit / (hit + def) * 100)For now defense only helps in dodging. I plan to incorporate a sort of damage reduction later like a sort of resistance. I want multiple types of damage, not just physical. Different weapons will have different attack properties. They will all act almost identical to physical damage except they use a different resistance parameter for reducing the damage taken. These will go along with the dungeon theme-ing. Ie a snow filled dungeon will primarily spawn creatures with ice based weapons.
Continuing the dungeon theme idea, I've implemented the finite set of floors. The bottom floor spawns the boss creature. Killing it wins the game and starts it over again for now. The player dieing does the same. The system uses a Boss parameter that identifies a specific creature that should spawn only once on the floor. I haven't done too much thinking about it but I might use it to add unique monsters to the game, one per floor. They'd have to be specific to each floor the way it's implemented but I'm thinking they could give alot more xp or even have unique items they only drop.
One last major change. I'm trying my hardest to stick to my coding rules of this project. Most of the major parts of the game are split into separate systems that contain and manage their respective data. This data should never be directly exposed and forcing the use of using the systems as an interface is a must. It helps keep things clean no more mingling code spread out amongst three system just to preform a ranged attack. Creatures no longer contain items, let alone have an inventory. Atleast not exactly. Creatures no have a handle to an inventory that is managed by the item system. They use id's and names to link the items, and higher level systems apply and remove the effects upon equipping or unequipping. In theory this will make it easier to script starting weapons and such on creatures.
Till next time, happy coding and I promise a build next post :)
