MileStone Status 1 | John Andrews

Right than, so this week there were a bunch of issues, mostly with getting vectors movement right, and granted it still isn't perfect (especially for the presentation)

First thing this week I took about 3 hours to try and reword all of the files, functions, etc to a more "Sharky" of the uncooked variety but in the end it decided to not commit he project file and any attempt to recreate it to work broke string tables so we just moved on.

I spent then some time just basically adding the functionality to throw a hook, which was basically copy pasta from the previous jelly bean code. We had decided early on to try and implement a line going from the player to the hook and present that on Friday.

The line is something that we still have no idea how to implement per se. Paulo gave us some code that we can take a look at but after lab on Wednesday we decided that getting movement was more important and should be the highest priority.

The movement of the player was originally just done in the hooks controller so that when the hook collided it would move you forward. This involved a lot of issues of trying to get the right math for the vectors, the speed of movement, and compensating for the player height. Finally everything seemed to be going fine except for that it would move you to the point, delete the hook, but then teleport you right back. We tried having it set position and a bunch of other jazz but no dice.

The day of the presentation we made the choice to change the movement out of the hook's collision and into the characters move. This involved working with the propel force and while it was able to move it wasn't working as intended. This prompted us to use this version for our demo which was probably not the best idea. While it was closer to the correct bit fo the code it wasn't "display worthy" and we probably should have just shown the version that had us teleporting back.

After the presentation we worked on the propel movement and currently it works! We just need to make it so that when it moves you it won't collide with the ceiling/floor. Right now if you fire at the floor it won't move you because your model collides with the floor and you get stuck. While the demo went a little worse than we hoped we feel confident that we can show off a better demo next week. We'll also probably have working art by then too.

Milestone I Status Update: Kevin

Alright, so today's Milestone 1. We've gotten a good amount of work done. Right now I'm going to talk about what I've been doing.

My primary concern this week was the minions. Or taking ghoulies and turning them into minions. One of the bigger differences (and simplest) is that, while ghoulies require a succession of three colored jellybeans to appease them, minions have the characteristic of being damaged only by one type of projectile. The ghoulie appeasement system is going to be recycled into our boss later on.

The other system I worked on was minion movement. Minions, being cowardly little things, stick together whenever they can, and attack in groups. I implemented this by creating a simple flocking system that covers most of the minion movement. I'm still running into the issue that, if minions get as close as they can together, they start to vibrate (I realized what the issue is just as I wrote it); I don't think that will be a huge thing to fix.

The biggest issue I've run into was (as was with the projects) C4 itself. Or, in this case, it's list system. We used lists extensively in Project 2 - ghoulies were stored in lists, which were iterated through every second or so to see which ghoulie was closest to the player. That ghoulie's jellybean sequence was shown to the player on his or her HUD. For this, we would be iterating through the list of all minions for each minion to get a list of all minions within a certain distance of each minion - to see which minions each minion saw as in it's flock. Seems simple enough, right?

Well, it's not. Not in C4. In C4, you can't simply iterate through a list. It has the index operator (the square brackets, []), but using it doesn't just get the object - it gets the object and removes it from the list. Also, an object can only be in one list at a time. And there method for getting the length of the list simply iterates through the list and counts as they go.

For Project 2, I only knew of the first issue, and I found it the hard way - a good half hour or so of debugging. Then, I took the easy (and inefficient) route of simply storing all the objects in a temporary list as I went through them, and then iterated through that again adding them back to the original list.

I wasn't going to do that again. I hated myself for doing it once, and wouldn't let myself hate me even more. I created a Peek function, which did the exact same thing as the index operator but didn't remove the item from the list.

The second problem was that an object could only be in one list. This was a problem because there would be the global list of all minions, and then each minion would have a list of nearby minions. To solve this problem, I created a wrapper class called "NearbyMinion" that simply has a pointer to a minion controller as it's only member. The minions had a list of NearbyMinions.

The third problem was that the list's "Get Count" function had a time of O(n) - it iterated through the list and counted as it went. As I was now calling this function all through the code, I saw fit to make it a little better - like O(1). I did this by creating a private count member, which was updated whenever the list changed, and had the function just return that.

Overall, I think we're on track. Things have been going well, and I hope that they stay that way for the next two weeks to come.