Addon System for Characters

As alpha approached, we needed a system that allowed the programmers to add various objects to the Avatar models. For example, the team wanted me to add a placeholder helmet for the guard characters. This was simply to show we had the capability to do this before the alpha stage was completed, but I decided to go ahead and create the first iteration of the system beyond just adding a hat.

To start, I had to configure the Character Factory class to include this addon system for the guard characters. This was relatively simple to do, and our robust system for adding components seems to be paying off.

My first goal, after that, was to simply create a class that put a box on top of the guards, so I used our dummy avatar class as a template (which is just a big box anyway). From there, I expanded the code to be much more adaptive. When calling the AddModel ability from within Addon component, one has to supply it with the model's location in content, and a Vector3 which is an offset to where the model will be in relation to the character's center.

At this point, the box would now appear wherever I wanted it to be, but I soon realized that my code needed to accommodate multiple objects being attached to a character within the same addon class. I heavily tweaked the containers that held the model's information to be compatible with multiple objects. The Dictionary class proved most useful in keeping tabs on information that was associated to each model (transforms, positions, etc). From there, I simply needed to tweak the Draw method to iterate through every model and draw them.

The final challenge was translating the Vector3 position to be relative the character's position and orientation. Without that, the attached object would quickly become detached once the character started moving. Thus, created a function that takes in the position, and translates each coordinate properly according to the character's orientation.

In the end, I'm quite satisfied with how this worked out. We can now freely add any models, like weapons/armor/clothing, to the characters through my Addons component. Here's a little picture showing a couple of addons being attached (do note, I did this on the Windows version which means I didn't have use of the Avatar models). I attached the little box to all the guards, and added a little shuriken for kicks.

From my testing, both objects move completely in sync with the character, so I'd say this is good progress!

Ledge Swapping Mechanic

I was briefly assigned to work on a control mechanic for the game. I worked on allowing the Avatar the ability to jump to another ledge. This would apply when the Avatar is already hanging on a ledge, but needs to move around to the other side without climbing up.

Going into this, I had little information on the actual avatar movement mechanics, but I figured it would be a good exercise to learn more about it. Fortunately, there was already a movement controller (a movement controller is a class that governs how an object moves given a certain state) that was similar to what I needed to accomplish. This was in the climbing movement controller which governed the movement when the Avatar needed to climb up from a ledge. This was similar for two reasons. First, it used ray casting to see if the ledge connected to a valid platform. Second, it handled the movement of the Avatar automatically (most other movement controllers take in the player's input).

With this in mind, I set out to program the ledge swapping ability. To start, I had to figure out which way I needed to ray cast. To set the direction, I needed to get which side of the ledge the player was on. If he was the right side, I needed to set the ray's position forward and to the right of the player's position; I then needed to ray cast to the left to see if a ledge existed on the other side. If the player was on the left side, I simply needed to set the ray's position left and forward instead, and then send the ray right. This handled the logic I needed to determine if the player could swap to the other ledge in the first place.

The second task was the actual movement which was a tad trickier than I anticipated. I asked Blake to help me understand his climbing movement code. With a good bit of help from him, we were able to get the player to snap over to the other ledge by using the position given by the previous ray cast (which determined if he could grab the other ledge in the first place). We did run into a little tiff about the player not latching on to the ledge, but that was fixed by re-oriented the player's facing so it faced the wall properly (it's hard to tell if the player is facing the wall when the player is just a box on the windows version).

After all that work, the ledge swap mechanic works very well, and the player can swap to another ledge, given that such a ledge exists, at the press of a button. In addition, I learned a more about ray casting which is quite useful in 3D programming.

Projectile Prediction

For this week, I've improved the design of our projectile system.  Previously, the projectile only fire to the player's position when first fired.  This, of course, wouldn't be very logical as one wouldn't fire where he was, but rather where he was going.

Thus, I added a prediction system for the AI to use that allows the AI to gather the player's forward orientation and predict where the player will be in x amount of seconds (it is currently set to about 1 second). The implementation was a bit complicated, and nailing down the precise formula was difficult (3D space is infinitely harder to work with than 2D space).  However, I was pretty happy with the results at the end. Now, if the player runs in the same direction when the AI fires, the player will be hit (with some error built in for good measure).

In addition to that, I've worked on re-modeling the projectile class as not just a part of the enemy class, but rather an ability that can be extended from and used for both AI and player alike.  I've implemented the basics of how the class will be set up, but I need to do some pair programming with our other ability programmer, Blake.  We need to get together and solidify the ability class, so that it properly extends to both the player and AI in a reasonable manner.  Hopefully, we'll have a robust ability class that will serve well until the end of the project.

Katana Model

I've taken some free time to do something a little extra for this project.  Since the basis of the game is Ninjas vs. Samurai, I took it upon myself to model a little katana for the Samurai to use.  Here are some pics of what I made.

I used a tutorial to help me out with the basics whilst adding a little flavor of my own in the blade and hilt.  I especially like the hilt design.  It's still a bit primitive, but it should work for our alpha build.  Just a little something I thought would be fun to do.

Projectile Mechanics

I implemented a system that would allow the guards to fire projectiles at the player. To start, I simply needed to launch a simple projectile. Thus, I modeled a system that let the enemy take in the player's position, create a projectile at the enemy's position, then propel the projectile towards the player's position every update cycle with a given velocity. A relatively simple function, so I expanded the functionality a bit.

First, I developed a projectile manager that would handle any and all projectiles that a guard may use. This would provide a method to create and delete any projectiles that belong to a particular guard. 

Second, I implemented a hit detection method for the projectiles. Every projectile would check, every update cycle, whether any of the current player's were colliding with it. The function would return true if a player was colliding with it, and false otherwise.

As of now, it works pretty well.  I added a timer so the AI would only fire a projectile every x seconds, and it seems to work well in testing.  I did have some problems manipulating the angle of the projectile at first, but I worked it out to face properly.  I'll be refining this system to include all types of projectiles, and to compute smarter paths over the next week.