• Register

A Competitive light based arcade game. Navigate the randomly generated maze to find weapons and powerups to defeat your friends!

Post news Report RSS More in-depth about our AI!

We talk about our AI and briefly mention the current state of our Menus.

Posted by on

AI Structure

In order for the AI to make decisions it needs to have information about the world around it. There are several different ways for this information to be conveyed, but because we chose a method that makes it easy to have one programmer dedicated to the AI while the other works on the world.

We created an abstract PlayerAI class that can be subclassed, filling in the gaps for each kind of AI. This base class does all of the common dirty work of gathering up the information so the subclass just needs to react to it.

For example, whenever a player is added, the PlayerAI calls an empty function passing that player as a parameter. Any subclass can then implement this function in any way it sees fit, or not at all. For example, one AI type wants to abandon its current target if a new player is a better target so it implements the playerCreated function to make that comparison. Another AI type may be fixated on a target and not need to do anything if new players are added so it leaves this function blank.

The PlayerAI base class gets its information by hooking into various events from the PlayerManager, GameManager, and Map. Early on, we compiled a list of all of the events we thought would be useful and wired them into the architecture. Even now, events are sometimes modified, added, or removed as the codebase evolves, but have a starting list of events allows the AI programmer to handle most situations.

Path Finding

There are a handful of pathfinding algorithms out there, especially for 2D games. Sine the number of possible paths from A to B grows exponentially with map size, most of these are optimized to return the first direct route. One of the things we needed, however, was the ability for AI units to evaluate all possible paths from one location to another rather than just one.

In order to facilitate this, our pathfinding looks at our map as a collection of rooms rather than tiles. Rooms serve as nodes rather than the individual tiles, so the pathfinder only needs to evaluate about 25 nodes or so, compared to 480 possible tiles in a 30x16 map.

One issue we ran into in the first iteration of the pathfinding was that despite this, if two rooms were far enough apart, the number of possible paths was still in the thousands, which is far too many to reasonably parse. What we noticed was that there were often more than 2 doors connecting two rooms, and for each additional door the number of paths doubled. So instead of giving the pathfinding a path through each doorway, a single path is created and the room itself stores the various routes to the other rooms it's connected to.

For example, when asking for a path from Room A to Room F, the pathfinder may return this path { A, C, D, F } and this path { A, B, D, F }. The AI can then evaluate each path based on what's happening in the rooms along each path and pick one. Once one is picked, it can then evaluate how to get from A to B, and only once it reaches B does it need to figure out the best way to get from B to D. And at this point, it may decide to abandon its current task and pick a new route altogether.

pathfinding

Here is an example of 4 paths of 28 generated. The green line indicates its path (while going to the center of each room). The red squares indicate the rooms needed to be entered to complete the objective while the yellow squares are rooms that are ignored.

Our old AI test video if you missed it shows the AI moving, now it fires when another player (or AI) enters the room. We also have some classes set up and should be shown in our next update/video.

Main Menu

We've also spent the last few weeks working on our menu. Like most UIs, it feels like making another game entirely with the amount of time and work needed for it to function properly.

Our goals are to reduce the amount button presses to get into the game while providing the player with many customization options which makes this a great balancing act. We're also coming up with a variety of systems to build the menu modularly to change or add additional menu options. Currently the menu isn't how we want it graphically but its functionality is there so we've not included it into our game loop.

mainmenu02

The menu is independent of the background so it can be placed on top of any level. We may have a background specifically for the main menu or have it use the previous level's background. With the look of it still under huge development, anything is possible!

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: