To: Extensibility, ilu

So I'm really happy with myself that when I designed out my object manager and factory I thought about the long term and how to handle objects swapping meshes and textures and how to make specific items contained in a large class like our Projectile class which has 28 different kinds of objects.

For PoC we only needed to have our coconut in, so when you wanted to spawn an object in the game all you would need to do would be just specify that you wanted such as:

(ENTITY_TYPE, Transform Matrix, Velocity)

but now that we are going to have a few more in for feature frag 1, I needed to change the function call to spawn objects around a little. I added in the fact that certain objects needed a specific specifier (projectiles needed types, as did trees), so I added in a second parameter for that. I also decided to put in two sublists into the manager, one for each island. This will help out Ryan who is working on our AI right now, because he requested that I put some sort of system in so that each of the objects in the game know what island they are on so that when he calls to look for an item to collect he doesn't accidently try to go to the player's island. So after all these changes the new spawn function looks like:

(ENTITY_TYPE, int objSubSpecifier, Transform Matrix, Velocity, ISLAND_LIST)

So, I was able to change around two functions in the manager, and one in the factory and I got the desired behavior in under a half hour, all thanks to extensibility.

Hey Bro, Nice Camera!

So Tuesday night I stumbled upon the largest problem in the project to date. Our character artist made his model facing down the wrong Z axis. Initially we thought it was a problem with my camera, but after I ripped apart my camera and found there wasn't actually a problem with it, we realized the problem was with the actual model. I threw about five hours at trying to nullify the backwards model with code by: building the camera with a right handed system, negating the z axis when rendering the model while reversing the wind order, but none of these seemed to fix the problem all the time.

Not to mention this also made for some interesting problems with translating the model and having the camera go in the opposite direction (since the model was not being drawn where it existed in world space.) Realizing that trying to get the model to render properly in game would alter more than just the three systems I mentioned, we decided to get Carlos' opinion on the matter. We evaluated the risks both changing the code or changing the model, and it was easy to see that fixing the actual model would be far less of a problem down the line. This however meant that most of the work our character artist's work (100+ hours) needed to be redone.

The next day we told the artist that the model had been done facing the wrong z, and at first he was angry that we couldn't fix it on our end. Luckily however, he found a way that he could do some kind of voodoo in Maya and get it working in a fraction of the time it took him to start from scratch which was good.

Anyways though, the camera code still needs some attention, so I'm focusing on that now.

Proof of Concept

I think all in all proof on concept went really well for us, almost all of the people who played our PoC had positive input for us. We did get some negative input on the difficulty and the fact that the camera needs to be changed (we kind of hacked the camera positions together at the 11th hour, so I'm really not too worried about it being terribly complex for me to fix). Also we learned that we need to change the shape of our islands and the fact that there shouldn't be any point on the islands where the player can go that makes it hard to see or shoot at.

I know some people had to hack a lot of their code to get it working for PoC, but thankfully I didn't have to. This can be attributed to the fact that I designed out my modules to be working for our game's gold build. I think the majority of the changes that I'll have to implement would be the "Director" interface for lua and the camera for FF1.

Overall I'm very pleased with what we accomplished in the two weeks development time for PoC. The prototype really helped minimize how long the gameplay took for us to implement (we started putting in game play 2 days before the dead line) and enabled us to devote the majority of our PoC time to setting up the engines.

Object Interactions

After I got the factory integrated into the build and working properly and registering with the scene manager to get the render nodes for the objects, I moved on to working on the object interactions, which currently is an abomination of switch statements held together by hopes and dreams. I'm debating if I need to rework the code so it doesn't create a hot spot later, but for now it will work fine.

On a different note, someone broke into my car and stole my CD player while we were watching southpark... driving without my tunes is going to suck.

Templates, Singletons and Factories oh my!

So after I put the finishing touches on basic camera movement today Andy and I were going over how we wanted to have the objects get the appropriate rendernodes from his scene manager. Initially I did not plan on writing my factory for PoC but rather FF1, but it would be alot easier for me to just tackle the Factory now and having that interface with the scene manager which then tells his node factory.

I did a few hours of research and found out that google thinks that I am looking for an industrial park or wanting to recycle factory equipment (I want our factory to behave like the one we did in AI where it would put the memory that was allocated for an object that is no longer in use back into the pool for recycling memory purposes, cutting down on new calls == win.)

I stumbled on one source code example that did perhaps the craziest macro I had seen to date, which can be found HERE. Yeah, its madness, but luckily I was able to use pieces of it for what I had intended.

Currently I'm trying to decide whether or not to use multiple vectors or a map to store the objects to be created now...

Forgot to post last night...

So I'm posting now! Yesterday we got feedback on our schedules and tech doc, which overall went pretty well. I finished up some more objects and the manager, and today is looking like i'm going to be working on the camera some more.

Last night when I got back to my apartment after class I basically crashed and had a coma until 8am today, the coma was glorious. I don't really have much else to update at this time, just going to get back to work I guess.

Captains Log, Star date... who knows?

Today was our PoC Milestone acceptance due date. Our IPs had already talked to the EPs about what we planned on having in prior to todays turn in, yet somehow we got thrown for a loop when they told us that they wanted some features in the PoC that weren't planned for and then ones that we were specifically told that we needed to have in were now cut for the PoC milestone.

I'm not sure if its a communication error between people, or the fact that some people didn't take the time to read what was actually submitted and then have questions about why something isn't going to be in for PoC when it says it will be there in the document.

Over the course of 4 hours we obtained 3 sets of feedback, the first told us that the dynamic wind feature was going to be cut, that they wanted this that and the other thing put in, and all the placeholder art assets that the AD was pushing us so hard to get as much of into our PoC as possible was not really that "big" of a deal for the turn in all of a sudden.

I'm honestly not sure what the EP's vision of the game IS for PoC, but I just hope we don't end up turning something in that they tear to shreds like they did our acceptance turn in today.

I don't know if the breakdown in communication is supposed to emulate industry, or if the meetings between the EPs and our group are just not seeing the same vision for the game.