Tilting at Windmills

I’ve had combat code written for several months, back when I was going to split it off into its own engine for development. So it was quick to port it into the travel engine. I created a stationary “monster” mob that I could tag, and ran it to see how my code worked.

Not surprisingly, I got a screen full of garbage. Going back to the source, I found a multitude of problems:

• A copy routine I was using to generate a “grass only” battlemap for simplicity wasn’t copying words but bytes, finishing too early.
• The unit array structure had two different expected structures, one 4 bytes and the other 6 bytes in two different places.
• Display constants were wrong for several of the right rail elements
• Monster data files didn’t exist, and the creation source I had for them had flaws that created bad files.

Anyway, you get the idea. The code was totally untested, so I figured I’d have plenty to work out. With most programming, having something work the first time is not celebrated, it’s in fact rather creepy and unsettling…

After a hour or so of work, though I got all the issues sorted or clipped (for now) and it finished building the combat display. Voila!

Combat Screen

There’s a number of small details, like monster colors, battlemap loading, ambush determination, unit placement, that’s being faked with constants. I’m not concerned with that stuff right now because the main focus first is to get the controls for player actions done.

The main reason is player interaction code is by far the most expensive in space and time to write. I have to find out if I’ll have room for special effects and everything left in the other portion of the game, namely, dialogue, shopping, questing, etc.

So, the next step is the basic controls, so the player can move his units about on screen, designate targets, and so forth.