Pew

This is a game I developed for my production 2 course with Matt Struble, Matt Therrien, Matt Cerasoli, Ryan Atkinson, John Cotto and Dan Thomas. Pew is a networked multiplier game. There are three teams, an ogre team and two archer teams. The objective of the game is to be the last team standing. 

Matt Struble and I were the programmers on this project. In general we liked to work together in the labs, so we often had our hands in the same parts of the projects. There were a few things that got more separated towards the end such as I did more of the level/weapon select, loading, arrow homing, and UI/HUD elements while he worked more on the ogre weapon attacks, animations, and power ups. 

One of the more challenging aspects of this game was to get the arrows to look good over the network. Initially we implemented prediction and smoothing techniques for the arrows. This made the arrows look like they hit when they hit more but caused the arrows to curve in unexpected ways. At the same time we were having a design issue where an archer on archer fight would go on for too long without any hits. In order to solve both of these problems we decided to add arrow homing to give a reason for arrows to curve and make hitting enemies easier. 

In this project we tackled a challenge of creating a networked game, with three teams and asynchronous multiplier. Given how little experience the programmers had with unity at the start of the project, it did seam that this might be a bit of a stretch. In the end the game came out pretty good. There are still some bugs though that it would have been nice to have more time to polish out. We ended up still adding important things even in the last week that gave us little time to make sure that everything new ran smoothly. Even still this game was a great accomplishment.

Click the Pew link to play the game.

Flashlight Game

This was my final project for Game AI. I was on a team of three programmers consisting of Evan Schipellite, Paul Kubik, and myself. We decided to try and create a flashlight game with networking, sharers and AI for players and ghost for this 5 week project. We decided to use C# with XNA because we had already learned how to do networking in XNA for our game networking course.  For this project I primarily worked on the level editor, the flash light effect, and the AI for the player.

For the flashlight I created a triangular light in front of the player that gets darker based on the distance from the player. I looked at this source to create the triangle effect and this guide to create the differed lighting effect. I also wrote a simple blender that uses the brightest light between all the players flash lights. This way there is not a darker spot in the middle of your flashlight from another player. I wanted to go further than this by making the flashlight stop at walls. I had several ideas on how to approach it but due to time constraints I decided that it was better to start focusing on the AI.

In this video I have the player (Jake) controlled by the AI to show off the player AI. The player AI has 4 states searching a room, opening an object, avoiding a ghost, and moving to a room.

In the searching a room state the player moves randomly around a the room. There is a set amount of time that a player searches a room. When this time runs out he will go to the move to room state. This works generally well but for smaller rooms it does not look right. It would be better if we scaled it based on the room size. While he is searching the room if he finds an object he will go to the open object state, and if he sees a ghost he will go to the avoid ghost state.

In the open object state the player moves to the object that he saw, rotates towards the center of the object, and opens it. If during this time he sees a ghost he will go to the avoid ghost state. Otherwise, he will return to the searching room state after he finds the object.

In the move to room state the player moves to a random adjacent room that the player hasn't been in yet. This way the player doesn't constantly search the same room. The player changes to the search room state when he gets to his desired room. If he spots a ghost on the way, however, he changes to the avoid ghost state.

In the avoid ghost state the player will choose a random adjacent room to move to. This is not the best thing because it can cause the player to run into the ghost instead of run away but given the time constraints this is what we decided to do. The player changes to the searching state after arriving in the randomly chosen room.

If we had more time some of the things we would have liked to improve is some of the AI for both the player and the ghost as well as making the flashlight not go past walls. In the avoid ghost state it would be better if the player choose a path that would avoid the ghost as well as leave the room. Currently the ghost can see players through walls. It would be worth limiting the ghost to only seeing what is within the room that they are in. Given that this was a 5 week project the overall scope for a networked game with AI was a bit ambitious. Considering the time period we are happy with what we were able to get done and enjoyed exploring how AI, networking and sharers work in a game together.

Flashlight Game Download

Flashlight Game Level Editor

In Game AI we were assigned a final project to create a game with state machine based AI. My group decided to make a networked collection game in a haunted mansion. In order to setup levels easily I created this level editor. I decided to iterate on the level editor that I created for our Hierarchical Pathfinding Tech Demo.

The first tab is used to add walls and paint the rooms. All you have to do is import a tile strip and it will separate the tiles for you. Then just click on a tile to select it and left click on the editor screen to paint that tile.

 

The next tab is used to add and manipulate objects. To import new objects the user simply opens the import object window, selects a .png and give it a name. Similar to the add walls you can select and object on the right and place it in the editor. However, when adding objects if the user holds down the mouse the user can move the objects around. The user can remove objects by right clicking on them. The user can change the rotation of an object or its search weight by clicking the middle mouse button on and object, which opens the edit object window. In order to easily add collisions to the objects and prevent more than one object being place on the same tile, I save where objects are in a 2D int array. When placing an object I check to see if there is one an object on any of tiles the object would be on. This prevents any overlapping issues. When saving the game I add the object array to the collision array, so in game the player can't collide with objects.

In our Flashlight game the AI for both the player and ghost utilize rooms to define a search area. This tab is used to setup the rooms. When you select a room all of the room tiles and connection lines are highlighted while the tiles and connections for the other rooms are alpha-ed out. The ability to use alpha so easily is given to us because the editor window is using XNA. The user controls are pretty similar to other tabs, click the room on the right to select it, left click to paint rooms and right click to delete. The user can also change the name of the rooms in the text box in the top of the right side. The connections are created automatically by checking if any adjacent tiles are in another room.

Ghost are the enemy in our Flashlight Game. This section allows the user to place new ghost spawn points, ghost free zones and set up information about the ghost AI. If you middle click on a ghost spawn point it brings up an edit ghost info window that allows you to manipulate how the AI works for that particular ghost. Similar to how it works in add walls the user can draw ghost free zones that ghost can't travel into. This is so the ghost won't be too close to where the players start and reset. There are also options to setup the transitions for each of the ghost states.

The player section is used to setup the player start positions and add transitions for each player state. To place a player start position the user simply selects a player on the right and left clicks. To change transitions the user can click the transition buttons on the right to open up a window for that state.

Though this level editor isn't completely bug free I am happy that I was able to make a working version in a about two weeks. I had to make it robust enough so that my other team member Evan Schipellite could use it to design the level. It worked well for us and allowed us to create an interesting level for our game.

Formation Movement

A formation is a structure for units to move within. This can be used in games to make the AI look more realistic.

 In the above example the first part is the movement of units that all act on their own to get to an end point. These units could have simple behaviors to avoid colliding with each other but don't have any knowledge of the group as a whole. The line formation on the other hand has to have an outside system with knowledge of where everything in the group can be. This system can be ran with one unit leading a group or an external formation manager, managing all of the positions and movement of the desired positions. This post will focus more on an external system managing units rather than a leader but many of the concepts can be applied to both.

Dave Pottinger in an article called "Implementing Coordinated Movement" discusses many strategies of how to create and move formations. Researching these ideas I gained a good understanding of how the basics of formation movements work. Formations have slots that units fill and follow. A formation should have multiple states such as currently forming, formed, and moving along a path. A formation that is currently forming has units in it that have not yet filled a slot. It is often important to plan out the order in which units join the formation and can be worth it to have the units join one at a time. This is especially notable when creating a box formation.

This problem can easily be avoided with some planning. One way of approaching this is having each slot get filled one at a time. The order for filling the slots would be based on their distance from a reference point. When a slot gets chosen it will then choose the best available unit based on a heuristic value. This heuristic value can be created by taking into account factors such as distance, and ease of travel based on obstacles in the way of the path. For this situation it would make sense to have the reference point be the center position because that is the most likely point to get blocked off. If however the formation was created in a corner the center may not be the best choice. In this case using the center point will often result in the part closest to the corner being blocked off as the last unit attempts to go into place. These sort of things depend on the environment of your particular game.

Now that we have formed our formation, according to the way our states work, we can move. In all formations the units will be simply following their assigned slots in the formation. The formation itself and the slots will move using its own logic. Depending on the shape of the formation depends how it should move and rotate. In some cases the rotation doesn't matter much because the formation will look good regardless of the direction it is moving.

However, as seen in this example, with a line formation it must rotate in order to look correct. This can be done rather simply by stopping the formation and reforming it based on the new desired rotation.

I made a tech demo in order to understand some of these ideas in action. In this demo you can see square formation with the center as a reference point when it is not made at the corner of the screen. It also shows movement with both box and line formations as previously described.

This is just a simple example of formation movement but in a full game there would be many more obstacles to deal with. If a unit within the group gets far away from a point it needs to act accordingly. The article "Realistic Behavioral Model for Hierarchical Coordinated Movement and Formation Conservation for Real-Time Strategy and War Games" discusses a movement strategy to help solve this issue. Each unit has three movement states, slow, normal, and fast. Based on various factors such as the units distance for its slot it may switch between states. But regardless it will stay within the constraints of the fastest and slowest states. I implemented this in my tech demo based on the distance but it is not very noticeable due to lack of obstacles and collisions.

In the book,  "Artificial Intelligence For Games" by Millington, Ian, and Jon Funge, there is a section on scale-able formations. This is a formation such as a defensive circle that can get larger based on the number of units. This can be done fairly simply by increasing the radius of the circle allowing for more slots to be added.

Formations are often used in RTS games. In this case there are many units that group and move together across a complex map. In this situation path finding algorithms would be necessary to figure out a path that the entire formation could go but we won't go into that here. Another game that formations can be used in is a battle ships like game. In this situation a player could be the captain of a fleet of ships and have a formation follow him in an intelligent manner. These are just a few examples of where formations can be used.

As discussed earlier in order for formations to work well a lot of planning is needed. Making these plans and acting on them takes a decent amount of CPU time. Because of this it is important to consider how complex you want to make your formations based on your platforms restraints. On PC it is entirely possible to utilize the CPU power of modern day machines to have really well working complicated algorithms that create intelligent formation movement. This is not to say it can't be done on platforms such as mobile because it most certainly has; it is just important to tone down the complexity of the AI for a platform such as mobile to allow it to run smoothly. This technique can be used on most platforms if the complexity and efficiency are considered with the platform in mind.

References:

Mamdouh, Abdulla M., Ahmed Kaboudan, and Ibrahim F. Imam. "Realistic Behavioral Model for

Hierarchical Coordinated Movement and Formation Conservation for Real-Time Strategy and

Games."IAENG International Journal of Computer Science (2012): n. pag. Web.

Millington, Ian, and John David Funge. Artificial Intelligence for Games. Boca Raton: CRC, 2009. Print. 

Pottinger, Dave. "Gamasutra - Coordinated Unit Movement." Gamasutra Article. N.p., 22 Jan. 1999. Web.

04 Dec. 2013. 

Pottinger, Dave. "Gamasutra - Implementing Coordinated Movement." Gamasutra Article. N.p., 29 Jan.

1999. Web. 04 Dec. 2013. 

Hierarchical Pathfinding Tech Demo

This is a tech demo I did with Evan Schipellite for my game AI course. We implemented hierarchical pathfinding and path smoothing. The purpose of hierarchical pathfinding is to make the movement path calculated much smaller and relative to the characters current area. For example if your in your room and you need to get to work, the only path that is immediately important is the one to get out of your room and into the next one. In order to know which room is the next one (going into the hallway instead of your bathroom) there needs to be a higher level plan. To create this plan the hierarchical pathfinder needs to group up sections and layers. The first layer being the node information that would be used for something like A*; In our tech demo we use a tile grid with connections to all adjacent tiles without collision. The next layer could be grouped as rooms like the bed room, upstairs hallway, bathroom, ect. The layer after that could be the buildings such as your house, your work building, ect. From here you can keep making as many layers as necessary to increase efficiency. I created a level editor using C# XNA with winforms to provide the data for our tech demo. Using this editor we were able to easily specify sections in as many layers as we wanted as shown in the pictures above.

The most challenging part of this project was understanding and implementing hierarchical pathfinding. We used Artificial Intelligence For Games by Ian Millington and John Funge for the explanation of how hierarchical pathfinding works and algorithm for implementing the pathfinding. It took us a few hours to completely understand how hierarchical pathfinding should work and how we should approach doing it. I was able to create an infrastructure that would read in the data from my level editor and create multiple layers that we could use in our pathfinding algorithm. We were then able to take that infrastructure and apply it to the algorithm in the book to get a working hierarchical pathfinder.

To show off the smaller subsections of hierarchical pathfinding working we added the ability to turn on and off continuous pathfinding. When continuous pathfinding is off the characters only move to the next room on the higher path. This demonstrates how small of a path is created at one time.

In order for hierarchical pathfinding to really be worth it the map would need to be much larger than it is in this tech demo. In this situation it would not be impossible to A* across the whole map but if the map was much larger it would take far too much time to A* to any position. In that case this technique would be very useful to allow for pathfinding over a smaller area.

Spacewars Game Jam

In my networking class last Friday our professor John Pile surprised us with a Spacewar themed game jam. The goal was to group with one other person and make a networked game similar to the 1985 version of Spacewar. I choose to group with my friend Evan Schipellite. We decided to use his game for the last assignment as a starting point. From here we both just looked at the requirements and started to code. I started to work on game-play features such as the player class while he converted the architecture to work better with our new game. After I finished creating a few classes I needed to merge them with his architecture in order to test if they worked. Evan at this point had already setup some classes to make it relatively easy to merge our work. With just a little help I was able to get everything linked up and ready to go. The player class started to work with little need for fixes. The speed and some other values weren't the best but it worked and that was good. At this point there was still much to be done and with only very little time left. I was able to squeeze in bullets and the display of health within the last few minutes but there was not time for perfection. I had initially set it up so each player would be authoritative over when they took damage from a bullet but when I looked at the clock and saw less than five minutes left I realized that sending health data over the network was not going to happen in time. So I decided to comment out the line making it authoritative and just had everyone decided the score for everyone else. At the end we had working ships that could move around in a way fairly similar to space wars, bullets that hurt enemies, a awesome star field background made by Evan and a win state. To be able to create all of these things in a somewhat working fashion in such a short period of time was a success that I could feel good about. In retrospect though it would have been good to have a little bit more planning as to what we each were going to get done and what we wanted to accomplish during the time period. While we were doing the game jam both of us had very little idea what we were going to do let alone what the other person was doing. We just looked at the list and started programming things that needed to be done.

After the game jam we decided to improve upon the game and take our own spin on Spacewar rather then trying to make an exact copy. I came up with the idea that instead of in space we could be in quick sand because this would still work for the idea of gravity in the game. We evolved the idea from there and decided to make it a group of tourist that got stuck in quicksand and the tour guide only being able to save the last one. From here I went into polishing the old game features and adding on new ones. One of the requirements for the game was to have the bullets limited to 10 per player but last forever (with screen wrap). This caused a lot more difficulties than originally intended. Having this happen wasn't to difficult but as we watched the game go on the bullets would lag behind on different player screens. If a bullet was only alive for a second than the difference was so minor that it couldn't be noticed but if it were on the screen for 10 seconds a bullet on one screen would be maybe 3 seconds behind another. This was a pretty major problem so we tried our best to fix it. First we attempted to have all the computers sync up without sending bullet information over the network. We used methods such as having a physics timer so the bullets would only update every 50 milliseconds, multiplying the elapsed time by the speed and reducing the frame rate. All of this went to no avail so in the end we made the host authoritative over bullets sending their positions with a byte ID over the network. In the end I am happy with how both versions of the game worked out.

Bounce

Developers: Jacob Ellenberg, Devon Case, Robert Bethune, Noah Drayton, Eric Teall and Stephen Baptiste.

This is a project I did for my production class. We were grouped into teams of 5 or 6 and given 6 weeks to create a mobile game. My group consisted of 2 programmers, 2 artist, and 2 designers. We decided to make our game for the Nexus 7 because it was the most commonly owned device among are group so it would be the easiest for testing.

Bounce is a physics based game so to make our lives easier we decided to use a physics engine. The other programmers, Robert Bethune, and I decided to use Box 2D as our physics engine. This worked out really well except for the fact that comers of objects sometimes did unpredictable things.

Most of the programming in this game went smoothly. Rob and I worked really well together. For the most part we met up in the labs and programmed there. We would divide up what we needed to do at the start and help each other out if one of us got stuck on anything. This worked out well for the most part but towards the end of the project when we added some extra levels the game wouldn't work on mobile. This is likely due to the amount of memory we were requiring it to hold when loading all of the levels at the beginning of the game. We did not notice that this was happening until it was too late to fix because we were testing primarily on the PC when doing finishing touches. I learned from this that it is very important to test on mobile even after making what may seam like minor changes.