Skip to main content

Coding general AI.

As promised I've spent most of my time this week
on coding basic gameplay.

[text above each agent displays debug info]
I started out having separate state machines for AI decision making and actions/animation.

Sometimes AI control calls for very rapid switches of states which would also disrupt the animations. Causing them to stutter or jump.

But by setting up Animations to only switch after a short delay I eliminated the problem you get with having AI and actions in the same state.

If a call to switch animation occurs, but rapidly switches back (like stopping for an instant when walking) the switch is ignored.

So I refactored them in to a single finite state system with inheritance helping to structure things like animation and path finding.

[Blocked in!]
AI is pretty basic. They just try to get towards you avoiding squares they've already visited. But it works surprisingly well.

It's easy to get blocked in by the enemy, but you can use the nature of the grid to avoid fighting too many enemies at once.

I don't know how well this system will work once I introduce the other party members. That's going to take some serious testing to see if it's fun or not.

[Big and small agents interact seamlessly]
 I added the ability to rotate the camera 90 degrees, this keeps the WASD movement system working well, but allows you to see behind things or get a better view.

Controls are going to be all keyboard based, with a radial menu handling things like item use, switching control of party members, resting, using special abilities etc...

There will probably be a shortcut bar too, so you can map some short cuts to the number keys.

[Water shader]

I did spend some time this week mucking about with shaders again, but there seems to be some kind of bug when rotating the camera. Sigh.

You know, it's funny that shader isn't in the spellchecker dictionary...

You can check out the video that goes with this entry HERE.


Popular posts from this blog

Back to Vinland.

I'm going back to my real time tactics project, Vinland 1936.
While working on the other project I overcame the problems which were stopping me from saving/loading the game and also cleaned up the base code a lot.

After a few weeks I'm getting near the the state I was in before.

Infantry are back to their previous state, and vehicles are running OK.
This time I'm going to push ahead with mocking up the combat system though before I work any more on the vehicle builder or graphical aspects of the game.

Map screen designs

I've been working some more on the map window. Right now you can only see the base, it doesn't show items, enemies or even doors on the map yet. These would be decals.

In the top window you can see the modified result of last night's tile based map. It looks good but there are some visual artifacts related to the problems I encountered yesterday, and as well it takes much more code and time to calculate.

The second window uses a cheap trick to fake an beveled look from a smoothed version of the 32x32 map. It uses black to mask unexplored areas.

Finally the third version is meant to look like a had drawn map. I'm using a cross hatching texture to distort it and unexplored areas are shown as blank map paper.

There's going to be a mechanic in game where you need to use some paper every level in order to activate the map for that level. From there it will fill it in automatically. Paper will be pretty rare so it might be worth keeping it safe for the more complex level…

Infantry combat and entering buildings.

I've been working a lot on the game recently and I've nearly rebuilt it to the level it was before. Past that maybe, since now I have the beginning of a working combat system and the ability to save and load the game.

Infantry can now occupy a building. It's quite an abstract representation, since they stay at the door and turn invisible. But they can then fire from one of the windows and take damage from shots at the windows too. I think I've set it up well so that when building damage and destruction is working then the system should continue to work.

For combat I tried some new ideas, but they didn't work out that well. It seems that it's important that viewing range should be further than shooting range. Now shooting range is pegged at 18 units of distance, while viewing range can extend out past that.

In the above image one unit has an officer, so has further viewing range. The other can only see as far as they can shoot, a dangerous situation since the en…