Arcade mode

I made a framework for the logic flow of the arcade mode, this is essentially managment of spawning ships as well as keeping track of several timers and ships alive. as of now if the capships AI were completed it should be done.

1 more week to beta

Over the last week or two I've finished out implementing the logic of all three of the tactical pods.

Big Bomb Pod: farily self explanetory, will track your targeted ship and when it explodes does AOE damage too all ships nearby.

Gravity Pod: Also a tracking pod, when it hits a ship it pull on all ships around it and if any ships get too close to the center  they are destroyed in the awesome gravitatious energy.

Slow Pod: Tracked to target, slows down all enemies based on their distance to the pod.

To accommodate all these pod types I had to implement a system to manage your active tactical pod and cycle through them.  

Spring Semester Catch-Up

So an update for this semester to this point, because I think this is possibly the first time I've gotten around
to blogging:

1) Pod System was originally completed in the 3.1 version of the game. Pods could be looted fired, consumed and such and stability was maintained.

2) The moved to 4.0 killed a lot of the previous code and much work as gone into just recreating the pods in 4.0, basic pods are now completely re-implemented in 4.0, including looting.

3) For the past two sprints I've been assigned to the collision system with felix that was completely redone and optimized. The world is now divided into smaller subsections we call grid objects, these gird object build a list of objects that reside within themselves and the collision is only ran on these objects. It is a fairly simple theory, but was exceptionally complex to implement.

4) while number 3 was only the collision detection, we had to implement the collision handling. We decided to as a standard have lower ranked entities handle collision against all higher ranked entities. So lasers must know how to collide with everything, but nothing has to have code to collide with a laser, because that is already handled by the laser. It's a hard to enforce rule, but with felix and I writing 95% of collision code it should work out.

Bloggin On

This week we did the playtest with our own classmates and tonight is the playtest with the
master eae students. The game came together a lot in the last 4 or 5 days. I spend the
majority of my time adding the the functionality and modifying the behavior of the pods.

Shield pods got an overhaul: They now can be used to gain temporary invincibility as well
as right before death a pod will be auto consumed (like a life) to keep the player alive.

Engine Pods: Now have the improved graphic and have a more pronounced effect.

Weapon Pods: the lock on now working allowed me to make the weapon pods heat
seeking missiles.

The other major feature I implemented recently was that enemy ships now occasionally
drop a new pod that will be auto looted to the player ship. The mechanic that had to be
written to make this possible was the functionality for ships to gather and use the pods
found in the environment.

So I Don't Like Bloggin... Apparently

The last few weeks have revolved around pinning down the exact way pods will work. After a final decision was made last week I was able to Implement 3 of the 4 pod types.

Engine: Passive bonus to thrust, use:temp boost
Shield: Passive bonus to shields, use:Overshield
Weapon: Passive bonus to lasers, use:temp strong lasers(maybe something cooler later)

Special: not yet done, because we have yet to decide exactly what this will be i did not implement it, but the backend logic to quickly incorporate it is there.

originally there were going to be many pods of everytime, but in order to streamline the interface we have decided that the only pods that will have any variation are the special pods. all engine, shield, and weapon pods will be indistinguishable from other engin, shield, and weapon pods. this may prove to make balancing farther levels later on, but that may be solved by allowing the ship to "unlock" additional ports to carry extra pods even if the pods are not more powerful they will have more of them.

The pods apply the passive bonus and then when use will have the bonus affected for a set number of frames and then drop off the ship and then begin smoking with the particle engine.

Stardate 64339.5

This week most if not all my work revolved around implementing the core of our game, pods. The realization that we could store meaningful information in the form of locator points in maya was a major plus to our idea. After a naming system was established i wrote code that would look at all the locators for various pod types and then created the data structures to support those points. All said and done every ship can now read a significant amount of data in from it's own model and will manage it's own pods and types appropriately. Also the pods now fire satisfactorily from the ship. 

Progress or something resembling it.

This week we moved away from the twice a week mandatory meetings to a single saturday morning meeting.
I think this is a smart move for two reasons: 1, we won't get burned out as easily meeting only once a week, and 2, meeting Saturday morning gives us a lot of time to work with compared to after school during the week. Also i personally find it easier to code not after a long day at school and work. It is somewhat hard to give up sleeping in Saturday morning but ultimately i think the gains will outweigh the negatives.

This Saturday I implemented a large portion of the functionality of the pods. There is now a base pod class that all ships can interact with by picking up, droping, and shooting. To begin with I added on test pod that makes the ships "laser_strength" variable grow and shrink accordingly. the firing animation if you can call it that is not exactly polished though and the pod sometimes jumps to a new location as it is fired from the ship.

The deeper we dive in to the 3d of xna the more we find that there is much we can use built into the framwork.
 when researching how to generating bounding boxes for the collidable models we found that xna will make bounding sphere's for each seperate mesh of the model as well as for the model as a whole. So by having our artists break up their models into several meshes the bouding spheres will be generated for us. However it was hard for our artist to know how the bounding sphere's where going to look so i made a small windows forms program that incorporates xna and will draw the model loaded with the auto generated bounding spheres.