This week we decided to further explore Magnetx. The two main things I added to the prototype is having the magnet powers lock onto magnetized objects and adding basic blocks to push and pull.
This is a very simple mechanic of being able to pull and push blocks within the environment. This would later be used to solve puzzles.
The way this locking on mechanic works by using what we had before and adding a lock on target effect. Once you hit a magnetized object the magnetized rays point towards the point that they hit regardless of where the player goes. This gives sort of a grappling feel.
This grappling feel was definitely very fun and could work in our platform puzzle environment but the problem is that it starts go away from the realism of magnetization. Mechanics such as this could be fun in a platform puzzle but don't represent how magnets really work. So we have to ask ourselves if we were interested in the mechanics or the realism of magnets.
This week my team decided to explore a co-op stealth game. The setting of this game takes place in a 1950's house. The main characters are two kids that are trying to sneak cookies without their parents knowing. This week I made a basic game play prototype to show off the kind of mechanics we would have in our game.
An interesting part of what I did this week was my detection implementation. The initial goal was to create an accurate cone of vision for the parent. I decided that an easy way to do detection that would not see through walls would be to use Unity's line-cast or ray-cast systems. So I created an object that would take a start point, an angle, and a distance for line casting. It also had a line render attached to it so that the detection could be displayed. From here I wrote a generator script that took in an angle range and a transform and then created these line renders around the given transform. In the picture above I have a parent with a range from 0-70 degrees creating a cone like shape of vision.
In this second picture the kid is in range of the parent but is not detected because the line-cast does not go past other objects.
The first game we're looking into doing for senior team is a game called Magnetix. In this game you play as an electromagnet in a puzzle platform environment. We have ideas of exploring magnets and different things that magnets can do too add to the fun of this puzzle game.
For this first week though I created a prototype that shows off the base mechanic. This prototype has attracting and repulsing abilities for the player. In order to do this I first had arms that rotate around a single axis. From here the player could left/right click and shoot out attraction/repulsion lines in the direction the arms are facing. This was done by simply adding force relative to the direction the arms are facing.
As you can see in the image above the attraction lines can be used to move the player towards objects. This can be useful to get to higher platforms.
The other option is to use repulsion. In the image above it is used on an object directly below the player to shoot him strait up. This could be used to get over areas that maybe have traps in a pit but there is a magnetized area to push off of.
Overall this prototype was successful in showing that these sort of physics can be fun. As soon as you jump in and play around it is kinda fun, even though there isn't much of a game yet. Based on that reaction alone it seams this game could have some good potential.
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.
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.
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.
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.
