• entries
  • comments
  • views

Casting spells

Sign in to follow this  


I've spent the last little while working on spell targeting, casting, selection, etc... getting magic and stuff back into the game. I've also been tinkering with alternative combat styles, which has taken up the bulk of my time. Haven't done anything at all about the interface in weeks, despite it being still at the top of my gigantic TODO list. I'm actually in the middle of implementing integrate UI elements exist as pickable entities in the game world, rather than the overlays currently in use. This would allow for interface elements to be directly in the world. For example, for the crafting tables I could just build a graphic that looks like the table and insert it as an entity in the world that the player could interact directly with, placing materials in slots on the table, rather than a pop-up screen as in the action-RPG version of GC. That stuff is still very much in development, though.

Anyway, here is a shot of the targeting system and a test fireball spell in action:


When a spell is requested (currently only TestFireball is supported, via a hotkey, and enemies can't yet cast it. It also doesn't do anything except spawn an area of flames) the interface enters a targeting mode where a region of a certain size is targeted and tested for LoS against enemies and blocking cells. The interface shows a grid of blue hex overlays for valid locations, and the red X for locations out of LoS. Casting a spell will still work out of LoS, the spell will merely travel until it hits whatever is blocking LoS and explode there. I am hacking on various details of the actual system, but so far it works pretty well.

I also implemented the (relatively minor) fixes I needed to make to allow the player to adjust the game speed. Until now, the clock has been hard-wired at 3 updates per second. That doesn't seem like much, but one logic update represents the time it takes to walk from the center of 1 hex to the center of a neighboring hex; to move 1 unit, in other words. (Assuming no haste/slow effects.) So at 3 updates per sec, this amounts to a fairly decent pace. 2 is slightly slow, 1 is unbearable and very hesitant-feeling. However, it is possible and even comfortable to bump the clock up again, and I can definitely see a use for bumping the clock up during testing phases.

The thing is, in the current working version of the combat state, everything takes turns. The player's units get their turns first (no initiative rolls at the moment) then the enemy gets their turn. Each unit gets a number of movement points to use. The player will not end his turn until he asks to; I do it this way because eventually, when more combat is fleshed out, the direction a unit is facing will be important, and I want to give the player the chance to correct his facing after his turn is done, hence the need for an explicit End Turn command. Anyway, with a whole bunch of units, a single combat turn can take awhile to complete. Expert players or impatient ass-hats can bump the game speed up to soothe their demons of impatience. I could see setting the minimum clock at 4 updates per sec, and I think 6 or 8 is a reasonable maximum.

I have also been experimenting, as I said, with alternative combat modes. Specifically, a combat mode that is more like a rogue-like system. In this combat mode, the player is allowed to go first, and he can move any number of steps up to some maximum, or cast any spell/action. Once he has moved or cast, then execution is taken away from him and each enemy in turn is given a number of combat points equal to the number of combat points spent by the player to move/act. For example, if the player walks 6 hexes, then each enemy will be given 6 movement points in their subsequent turn. In this combat mode too, the camera remains locked on the player.

I am experimenting with how I want to handle the enemy turns. I can either a) make the enemies take turns, spending their full allotment of movement points at once, or b) interleave the enemy turns so that each moves 1 space at a time and these movements are simultaneous. This second alternative feels snappier, but the logistics of it are kind of difficult to figure out.

At any rate, once I get a fully functional version of this combat state, I want to upload a small demo that allows the player to select one state or the other and play it, to see if I can get some player feedback on which combat scheme works the best.
Sign in to follow this  

1 Comment

Recommended Comments

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now