Archive for the ‘AI’ Category

More Prototype Progress

February 26, 2012

I’ve been working pretty much nonstop since that last post, with various successes and failures. Let’s start off with a screen, shall we?

A Healer heals a Warrior, while a Wanderer waits for an upgrade.

Noteable changes and additions:

  • Basic Item system
  • Basic Gambit system
  • New npc class: Healer
  • New item: Heal spell
  • New item: Pickaxe (used to remove blocks)


When NPCs enter the world, they start as wanderers. They follow you to the town. Once near enough to the town crystal, you can assign them a useful class – Warrior or Healer. The Warrior gets a melee weapon and extra HP, while the Healer gets a heal spell. The gambits on the NPCs define how they act.

You can use the upgrade items on any NPC, and have any number of either class.


Each NPC class has a default gambit setup that makes the class useful. The Warrior will “attack” “foe: nearest”, and if there are no foes in its range of sight, it “wander”s. The Healer will “heal” “ally: lowest hp” first, and if the target or action fail for some reason, it will “heal” “ally: hp < 100%”. If there’s nothing to heal, it wanders.

I tried to make each gambit target and action “smart”: There are certain conditions where it doesn’t make sense for a gambit to fire. For example, if some gambit’s action is “heal”, and its target is found to have all of its HP already, then the gambit fails and the game moves to the next gambit. It’s pointless to heal something that’s already full, right?

Both monsters and NPCs have gambit sets. This makes it easier to build new creatures, and check to see what might be failing in AI code. When I have a decent number of gambits to use, I’ll set it up so you can change the gambits around on NPCs in-game.


So far only the player has an inventory, but it’s pretty straightforward for me to add inventories to the NPCs and monsters. I’ll be doing this in the very near future. I’ll also be adding an inventory trading mechanism so it’ll be easy to give NPCs items and let you choose what they have equipped. I’ll probably set it up so they automatically equip any stronger items you give them.

While I’ve made all the above progress, I was kind of stupid yesterday. I spent most of the day trying to figure out how to set up scripting. There isn’t enough here to bother with that! I don’t know what I was thinking, I had it on my mind and then I tried my hand at it. I was even ready to try building a roguelike that would do everything out of scripts! Then I came to my senses. I may still go to a scripting language eventually, but I want to develop my game as quickly as I can.

I have so many things I want to do, I don’t even know what to do next. I’m doing my best to stay focused on Keeping It Simple and driving my efforts to get One Of Everything in. The next goal right now should be to assign NPCs to/from the player’s party. After a bit of a break, I’ll try to start on that.

One of the guys that’s building Dwarf Fortress said that it’s not easy to balance the time put in to design and implementation. I’m starting to understand what he meant.


Inter-Entity Interaction

February 19, 2012

For this post, I’m going to go over the first interactions between entities.

Monster and NPC contact

The first monster, the Slime, will do damage when its hitbox touches an NPC’s hitbox. When the NPC takes damage, it will enter a knockback state and won’t be able to be damaged again by that one monster for a period of time. Other monsters will be free to do damage, however, so monsters ganging up on one NPC will do damage much faster than one monster alone.

During knockback, the NPC will slide away from the last monster to cause damage. The NPC will also take damage on each hit, and will lose hitpoints until there are none left. At this point, the NPC will be killed.

Monster and Monster contact

All monsters, when in contact, will push themselves away from each other, so that there won’t be monsters inside of other monsters. I’ll have to be careful not to have them push each other into blocks, since I don’t want them to get stuck. I assume I’ll have to apply acceleration in opposite directions or something. I’m not really sure how I’m going to deal with physical collision response. I’ll figure something out.

I think that I’ll wind up having all entities push each other away from one another. I have only ever done this kind of thing in my ludumdare 10 entry. There were no boundaries to have to worry about, so I was free to push each colliding sprite completely outside of each other. I have a world to collide against so I’ll have to deal with that somehow. Maybe I’ll just do the push with the incremental movement function I already have.

When NPC takes damage

It would make the most sense for an NPC to run away when she gets hit, but that might get annoying. I’ll add a Flee state that will be active for a certain amount of time, or maybe a distance from the attacking target.

When Player takes damage

The player weill be knocked back just like the NPCs will be. The difference is that after the knockback, there will be a temporary invincibility period. The player will blink to show this visually, and the entity clipping will be turned off during this period. It will be possible for alot of monsters to hit you at once, or one monster to combo you with several quick hits, but I want to make sure you won’t be in stun lock forever. Allowing for that kind of thing is unfair and not fun.

Damage counters

Like in the last version of ActionRPG, I want to have damage counters pop out of whatever takes damage, so you can see visually that there was damage done and how much it was. I may not put this in right away, since it’s only a visual indicator. I want to focus on only the core code.

Letting the Player fight back

Finally, I want to give the player a weapon and let him do damage to the monsters. I’ll be building this pretty well exactly like I did in ActionRPG, with a horizontally arcing sword attack, but I also want to add a vertical arc and a thrusting attack. Eventually I’d like to set up the battling system to work like they do in the 3d Zelda games, with the z-targetting system.

When I have most of the above into the game, I’ll have satisfied the fighting system core requirement. I’ll start looking at either the Town levelling or more stuff with the NPCs. I want to get into the NPC class stuff soon so they can start doing something useful.

Monster Spawning and AI Code

February 18, 2012

I’ve added the firstĀ  monster to the game, the Slime. They hop around at random, until the player or an NPC gets within their 16-block aggro range, and then they start chasing it. The monsters will tend to head towards the town center block like the NPCs do, if they don’t have a target. Monsters will need to be taken care of as you build your town.

I fixed the spawning system so that things appear anywhere within the active portion of the game world, except for within the town limit and too close to the player. Right now things spawn every half-second, to the set limit of 64 monsters and 8 NPCs, so the town would be swarmed pretty quickly. Obviously I won’t be leaving it that way.

I had a problem with massive slowdowns if anything fell off the edge of the map, so I’m now killing anything that gets under the map by 100 units. If the player hops off the side, I’m just respawning him.

I took the time to fix the sprite lighting a bit, so now they’ll be colored to match the time of day. It isn’t as smooth as I’d like, but I’m moving forward:

The monsters will chase now, but there’s no entity collision testing yet. That will be the next step.

Monster AI Design

February 16, 2012

What’s next

My goal right now is to get Ano Sekai to a point where I can show off all of the core features. Right now I’m working on the Town Building game stage. Now that I have NPCs spawning around a Town Center block, I have several directions I can go in:

  • Monster spawning and interaction
  • Levelling up of town
  • Interacting with NPCs

The most interesting thing to do right now is clearly the Monsters. I didn’t really talk much about the monsters themselves yet, have I?


I was thinking about starting with the Minecraft method and working with that. The rules are easy: Every once in a while, try to spawn a monster at some distance from the player, in some random direction, but not too close. An additional rule will need to be that monsters should not be allowed to spawn within the Town Limit. (I’m letting NPCs spawn near the player, but I’ll be changing that.)

So the game has decided where it wants to spawn a monster, but what will it spawn? In this case the town level will be a big part of the decision. Each town level will have a set of monsters to choose from, where higher levels will have stronger and more difficult monsters to deal with. I won’t have to deal with that until I start working on the town levelling, though.

The actual number of monsters that will be allowed to spawn will have to be decided on during playtesting, as will the spawn distance and rate.

If you’re far from the town, the decision will have to be made differently, but that’s the next stage and I’ll leave that design for later as well.

Monster AI

Part of the task of building and maintaining a town is to defend it and its people from monsters. Some monsters will be more aggressive than others, some will be more dangerous than others, and some will try to literally destroy your town. You’ll want to build your town in such a way as to keep your NPCs and buildings safe from harm.

The first monster that will appear in the game is going to be the Blue Slime. If you’ve seen my actionRPG project, you’ll already know what it looks like. I’m going to be putting a little more work into the AI this time, though. In Ano Sekai, the slimes will act like the slimes in Terraria. I don’t know for sure, but they seem to have been based on Zelda II’s slimes, and that’s what I’ve always been looking at as the AI model for the slimes.

The Blue Slime will move around at random, but will only move in short 1/4 block high hops. It will take 2-4 small hops in one direction, and then stop for some amount of time. It will then pick a new direction at random and hop in that direction. If it runs into higher ground, it will hop up a full block but at half the forward move speed.

That will be its non-aggressive state. When it can see an NPC or the player and is close enough, it will become aggressive and chase whoever it has targeted. It will still do the same thing as before, the difference will be that it will always hop towards its target. When it can’t see its target anymore, or the target goes outside of its aggression range, it will return to its non-aggressive state and once again move in random directions.

Inter-Entity interactions

When two entities touch one another, something may or may not happen. There needs to be functionality to check for collisions between all entities, and functionality to cause a reaction in some of those cases. I bring it up here because I’m going to want to be able to tell when a slime is touching the player or an NPC, so that I can code a reaction to it.

I guess that ideally, if the slime touches any entity that isn’t also a slime, it should deal damage to it. There will be exceptions, such monsters made of stone or metal, or dragons. Taking damage will involve causing a knockback state, and reducing health by some amount.

I want to introduce health bars to the game at this time as well. Health bars will be shown over all entities as you would expect to see in an RTS, as a green bar perhaps with black or red to show how much health has been lost. Right now I’m thinking about FFXII because I’m replaying it off and on at the moment.

Once an NPC’s health has been reduced to zero, I want to kill it. At that point there won’t be any way to fight back other than to build. Once NPCs can be killed, it will be time for me to code in a way to fight back! The player will be given an arcing sword that will deal damage to the slimes and knock them back.

As I build things, I’ll be sure to post about them. Look forward to it!

SG’s Game Development Video Diary ep 8

February 16, 2012

I made a vid about the stuff I’ve updated since I started up the blog. As always, sorry about the sharp “S”es. I don’t have any way to soften those yet. Here it is:

NPC AI code

February 15, 2012

I spent the night coding the NPC wanderer AI and I’ve managed to get satisfactory results. I want to make a video tomorrow, because it’s better to actually see something like this in action rather than looking at pictures of it. That said, here’s a pic:

Some random points:

  • limit of 1 town center block; no spawning without it
  • time between spawns: 5 seconds
  • spawn distance from town center: 32 blocks, or 2 chunks
  • town limit from town center: 16 blocks, or 1 chunk
  • time between NPC nextThink calls: 1 second

Of course all of these values are for testing purposes, I’ll be changing them to suit the game as things are built.

I did a couple of retarded things while I was coding, which I’ll go over in the video. I’ll end this post with another picture:

NPC AI Design

February 14, 2012

The next two logical steps are to give the NPCs their wanderer AI, and to add monsters that will hunt them. I’ll get a basic wanderer AI in, and then I’ll tackle adding the first monsters.


Let’s go over the wanderer AI again. You place a Town Center block, and after some time passes an NPC will spawn some distance from it. The NPC will wander around randomly from that spot, with a tendency to go towards the Town Center. Once they reach a minimum distance from the Town Center, near enough to it to be considered “within the town”, they’ll wander completely randomly. The wanderer AI will keep them within that minimum radius: when they go outside the “town limits” they’ll once again tend to move towards the Town Center.


The NPC will spawn at a pretty far distance away from the Town Center, though I’ll have to play with the exact number during playtesting to find a good one. I think it will be fine to let the distance be a constant, since it will be a random direction from the Town Center and that should make for a decent spawn distribution.

In what cases should the spawning fail, and how should that be handled? I don’t think they should be able to spawn too close to the player – having anything suddenly popping into existence near me would startle me. The spawning should also fail if the NPC would wind up over water. I don’t think anyone’s going to be wandering in the sea. Another obvious case is if they spawn within a solid block.

If it’s determined that the spawning failed, then the game will wait until the next frame before it tries again. I don’t want to halt the system if you put the Town Center block in the middle of the ocean. I could try to come up with a way for the Town Center to build a list of valid spots and then spawn in one of those, but I wont bother for now. I’m more concerned with seeing results than making the game run perfectly.

When the Town Block is placed, after a period of time it will try to spawn an NPC. I would think that 1min or something would be reasonable but this is another value I’ll have to play with during playtesting. After that length of time has passed, the Town Block will try to spawn a new NPC. Once the NPC has successfully spawned the block will check the number of NPCs against the NPC count maximum. If there’s room for more, it will start the timer up again to spawn a new one. If there isn’t room it will enter an idling state, waiting until there’s room for a new NPC – whether an NPC dies or the town levels up.


The ‘wandering’ process will have two states: moving and idling. The NPC will idle for a time period and then will decide on a direction to move and how long/far to move. While the NPC is moving, they will need to deal with stepping up blocks, and I’ll have to allow them to jump. At the end of the moving period the NPC will choose the length of time to idle, and re-enter the idle state.

When the NPC is deciding on a direction. they’ll start by picking one completely at random. The speed and length of time to move will be consistent, only the direction will be chosen. If the NPC is outside of the town limit, a vector towards the Town Center block will be added to the chosen direction, and the resulting vector will be normalized and used.

I’ll need the NPC to figure out when they’ll need to jump. I was thinking that if they were trying to move forward but hadn’t moved from the spot they were in last frame, that they aught to try to jump. This will solve the simplest cases, but has problems if they’re walking into an L corner that was 2 blocks high, like this:

I’ll look at more complicated pathfinding at another time.

About the Town Center

The distance from the Town Center block to the “town limits” is going to be another value I’ll have to play around with. Within this distance, NPC wanderer AI will stop bothering to try to go towards the Town Center when they choose their wandering direction.

The game will need to keep track of where the Town Center block is at if it’s moved. The way I’ll deal with it for now is that whenever you place a Town Center block, it will change the location of it. I will be limiting the number of Town Center blocks to one in the entire world, and I’ll be dealing with the case when the Town Center block has been removed.