Refactoring for AI

Initially I started this project as a set of technologies such as dungeon generation, field of view, lighting, pathfinding, etc. My code was always from the perspective of the player and I made no provision for monsters and other gameplay elements. That’s why previous releases have always been in the form of tech-demo’s, because that is all the were.

For AI I have to rethink the whole thing. I don’t want to have the concept of a player and then some monsters, but would like the engine/game to deal with both in the same way. This adds some complexity, but also opens up a lot of possibilities.

The main update loop would be something along the lines of, for each actor, act. The AI controlled actors would act immediately and the player actor would do nothing until input (which is translated into an action) was received. All actors after the player would wait until the player completed his action. Rinse and repeat.

So far so good. I implemented a basic wandering monster with chase AI and let it loose in the dungeon. It looked cool with two little critters running around the dungeon and then converging on each other when they entered each other’s Fov. I added some more critters which promptly sent my framerate to 1Fps.

I guess it’s time to optimize.


2 thoughts on “Refactoring for AI

  1. Pingback: My Tiles are Evil « Writing Kode

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s