1) Game concept: How and why did your game concept change from initial concept to what you implemented?
    -As a whole, we felt that the original game concept was preserved completely throughout the design process. A few changes were made here and there, but nothing that changed the core concept.
    -Trent would like to announce: "Although we added the concept of being able to roll over the edges of the cube faces, rather then using tunnels, to travel to new faces, the game itself remained the same simple concept the entire way through".
    -Daniel, also expressing the same sentiment, cries: "For the most part, the game concept remained the same in that the balls fought each other on top of a cube where each face can act as a battlefield".
    -AG, drunk with power, would like to relay the following: "Once the group had settled on an initial concept, the game never strayed from that vision".
    -Arizona, hot and sunny, says: "Probably the biggest change was the controller. Originally we'd decided on trackballs, since it fit with the theme of the game really well and it sounded like a good idea, but after getting them and playing the game with them we found out that they were somewhat unwieldy, and that the Xbox 360 controllers played wonderfully".
    -Eddie pontificates: I'd say that the game idea didn't change largely due to the many hours and meetings poured into fleshing out the initial design document".

2) Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
    -We stayed on target for the most part the entire way through. A few graphics changes here, an input change there, a mod or two someplace and a number of small GUI redesigns made the final game what it was.
    -Eddie birthed this comment: "The design remained the same as well, except for the user input. When UI was finally integrated with the main code, we found that using the mouse was not quite as thrilling and fun as we had initially hoped. Furthermore, and much to our surprise, the trackball provided an even more clumsy form of control! It was Vinh's blind desire to test our game out on a 360 controller that happily birthed our incredibly fun and intuitive control scheme. Plus, I am a huge fan of force feedback, and it would have only been possible with the 360 controller.".
    -Daniel etches this words onto your soul: "The basics remained intact where levels and most player models were heavy in procedural modeling.  I wanted to try for more hand made models but either their uses became invalid or we simply ran out of time.  However, I’m more than happy with the signature “wedge” weapon of the game".
    -Trent whispers into the day: "Our original design had called for only three elemental based modifications: Fire, Ice, Rock. As we began implementing new features like the level flattening and Daniel designing some awesome sphere weapons, we just couldn't stop ourselves from making use of those".
    -Arizona declares, with excitement in his voice: "The project design also remained fairly stable. Alex G came up with the initial idea for the code structure and implemented it within the first week or two".
    -AG stated stately: "The graphics engine changed slightly from the original design. It was determined that dynamic environment mapping wouldn’t be very visible from the player’s viewpoint, and irradiance mapping with a dynamic global illumination scheme was added instead"

3) Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any?
    -We had a few instances of backtracking and redesign that slowed us down, but as a whole we remained on schedule and had a working game by the time we had planned. We never really froze the design process however and were making changes about thirty minutes before the presentation.
    -AG echoes in the caverns of my mind: "The schedule for the graphics module was largely on target.  Steady progress was made throughout the quarter, and weekly goals were almost always met.".
    -Trent, speaking the mad ramblings of Elder Gods, cackles: "The physics engine met every goal it set for itself and remained mainly on target. It was usable by week three thanks to testing with Daniel's demo and throughout the project only required small changes and tweaking here and there to improve game play and adjust for framerates".
    -Eddie, with a wink to Daniel, adds: "Looking back at our initial schedule, I can't help but laugh (I am only speaking for networking, here). It took me so damn long to finally understand what I was doing with the networking code, that I actually held back the group (with respect to game play testing) by at least a week. It turned out ok, though, because everyone found something else to pick up on or improvements to the current code. I spent too much time trying out different models for the networking code, instead of reading up on some winsock literature and asking around for help. When I finally chose a design, stuck with it, and implemented it, it was already week 7 and I was pretty sick of the project".
    -Daniel, shaking like a bear full of jelly, chortles: "I was personally hoping for a basic game to be ready sometime during 5^th or 6^th week. However networking proved to be the slowest part of the process".
    -Arizona reminisces: "We were supposed to hit alpha 1 (playable game) by week 4. We hit that, maybe... week 6? or 7? Our projected schedule always seemed a week or two ahead of where we were, though in the end we managed to finish up most of what we had planned for".

1) What software methodology and group mechanics decisions worked out well, and which ones did not? Why?
    -Many of the coding standards that the group held to made progress very easy, and the build was only 'broken' once or twice throughout the whole quarter (and quickly repaired by the guilty party). Some aspects became a little sloppy towards crunch time, however...
    -Trent belts out, abridged: "We attempted to employ three main group mechanics strategies throughout the projects development. The most successful was our Extreme Programming sessions where two members would share the same console. This was especially useful when separate modules needed to interact since we didn't have extensive knowledge of the other module's implementations. The group process was highly democratic, with large decisions discussed among the team until a consensus was reached. We attempted to use Hungarian notation throughout the project so that everyone would feel comfortable with anyone's code. I believe this failed as we got closer to the end as people began to feel rushed to finish some section of code and would revert back to old coding styles with plans to return make it uniform afterwards ".
    -Daniel, says: "I thought the group mechanics we chose worked out just great. We all had our separate parts and integrated it with other people’s code. Since we all meet regularly, conflicts were usually resolved right away so no one was stuck for too long.".
    -AG, pontificates: "Almost all of the methodologies we tried worked out great. Splitting the project into separate namespaces with a fairly strict 'include' hiearchy and well-defined entry points made tracing code flows a snap. I proposed Hungarian Notation and used it throughout my code, but that's just preference. One thing that could have been better defined is the communication pathways between modules. Towards the end, the Game module ended up knowing intricate details about the physics and networking modules."
    -Eddie screams: "We wanted to work on the bigger parts in pairs, and in the end, it really worked out on the networking side. The initial start up code had to be done alone, otherwise it would have just gotten waay too confusing, but once the infrastructure was there, it was a godsend to have a partner (it was almost as if the code was being worked on 24/7). As far as software methodology is concerned, I am glad we used singletons with all member functions and variables static, and separated each key component into separate modules. This allowed us to have one main function call for each module called on each onFrameMove(), and granted us the ability to easily use each module anywhere it was necessary in our main code (though, the goal still remained to keep each module separate). What ended up not working out was our PlayerEntity's onFrameMove(). Instead of keeping everything separate, we took the immediate-results-solution and jammed all of the networking calls in there, which had a snowball effect on the sound calls, and then particle effects, bloating the file to well over 1000 lines of code.".
    -Arizona, refreshingly concise, states: "We had a coding standard and it wasn't strict but it worked out well."

2) What aspects of the implementation were more difficult than you expected, and which were easier? Why?
    -The group relished in smooth sailing for some aspects of the development, but everyone found they were a little too optimistic about the implementation in one way or another.
    -Eddie languishes: "Integrating my code with the main project was a little more difficult than expected, mainly because I didn't understand how to trim the fat; how to seek only knowledge over what I needed to know, and not everything that could be known. I also didn't understand the benefits of keeping everything static and separated, which led to further confusion. On the other hand, sound went up really fast. I didn't handle the integration of sound, but the code seemed pretty cut-and-paste, and using it was really easy. In general, though, putting everything together, especially transmitting and parsing all of the necessary (flattened) data over the network, proved to be a lot larger of a task than I had originally envisioned .".
    -Daniel sympathizes: "Networking would have to be the most difficult just by the fact that no one had real experience with winsock until now. However, with teamwork, it was conquered. I was very surprised how fast particles were integrated into the game (good work Eddie and AG!) during the last few days".
    -Trent takes a big breath and says: "Personally, the most difficult aspect of the implementation for me was coding in such a way that game performance would be uniform across systems of different frame rates and across the network. It was a challenge for me to constantly keep in mind that one machine would be going through the same code faster or slower than the other machines over the network. Surprisingly, the easiest aspect for me was the physics engine itself as so much documentation is available for physical simulations between planes and spheres and realistic collisions that the algorithms were basically already there and just needed to be fined tuned for our game. Occasionally I would think there was some error in the physics engine, but more often than not it merely turned out to be an issue of the aforementioned problem. ".
    -AG exudes: "The graphics engine as a whole progressed very smoothly throughout the quarter, with only minor issues thrown in to spice things up. The hardware limitations of the lab machines ended up being a bigger bottleneck than expected, and developing different shader profiles for different hardware ended up being somewhat cumbersome (though a useful learning experience). The most unexpectedly difficult aspect was the animation of the cube geometry. Since the geometry had been created with no redundant or hidden triangles, some vertices needed to be moved and others needed to only have their texture coordinates adjusted depending on the time step."
    -Arizona brags: "All in all, the code I ended up writing was fairly simple. I only had to work with one external library (FMOD for sound) and that was painfree as well -- link it in and follow the documentation."

3) In implementing your project, you relied upon a number of tools, from the DirectX libraries to modeling software. Do you see the opportunity and need for new libraries and/or tools that would make project development easier?
    -Besides the possibility of a full-fledged network library, team ASS was happy with it's workbench.
    -AG wastes no time: "Nope."
    -Trent offers more insight: "Well, besides the possibility of merely purchasing a pre-designed and tested game engine like Unreal, I can’t really think of a tool I would need or would use to make my aspect of the project any easier.".
    -Eddie offers up a pat on the back: "Ogre is the only tool that comes to mind, but my group really lucked out with AG. He had the experience and know-how necessary to put together a damn fine engine, so I cannot complain!".
    -Daniel contributes: "I didn’t have to implement any additional libraries into my code contributions. I mostly worked off what AZ had from FMOD, the DirectX vector/matrix manipulations, or what Ed had from winsock.".
    -Arizona exclaims with grandiosity: "I think the network team could have used some help from a library, but the code that I wrote was relatively high-level. A sound library was the only library I needed and it worked like a charm."

4) Looking back, would you have rather started with a game engine like Ogre or would you still prefer to work from scratch?
    -The team felt that they gained a great deal of experience developing the engine from scratch, but a couple members lean a little more towards a full-fledged engine:
    -AG screams: "No! I can't express how valuable it was to experience the full game development process - from engine to polish. It would have been exceedingly difficult to wade through reams of existing code to try and figure out where to get my shader hooks in, and the end result would have looked nowhere near as nice and been much less efficient on the graphics side. We would have been coding within an invisible fence and I think the final product - and our gained experience - would have been significantly crippled as a result. Furthermore, from a slightly different perspective, it would have been a much less impressive achievement had we started from an existing code base. There was a fair share of recruiters from game companies (5 or 6 that I know of alone), and the final game result is only a small fraction of what piques their interest about a team or member."
    -Trent stoicly states: "As this was the first time I had ever worked on a project of this nature, I greatly appreciate the experienced gained by starting from scratch. If I were to do it again, however, I would look into investing some money in the purchase of a more industry tested engine like Quake or Unreal."
    -Eddie differs in opinion: "I didn't work on the lower-level DirectX in too much detail, so I can't say my opinion matters all that much on this topic, but I still would rather have used Ogre. Even though our game turned out pretty as hell, it would have been even more pretty with Ogre. Plus I think using the engine (which is now quite full-featured and well-supported), would have freed up a tremendous amount of man hours to implement other fancy features and gameplay elements. On the other hand, I am happy about the little that I have learned about DirectX and its message based system. It is a lot less intimidating now to look at some code smothered in DirectX. But in the end, it's more likely that I will end up in the industry using someone else's engine, rather than building one from scratch, and it is that experience that I am a little sore I missed. It's funny, now that I look back on it, for how much I fought for our right to use Ogre, I can't say I miss it as much as I thought I would. Again, this is all thanks to Alex. His dedication to the engine is really what made the visuals shine. I can't say Ogre is the best choice for everyone, but for the groups out there lacking some intimate knowledge of DirectX, I'd say Ogre is the best choice."
    -Daniel speaks up: "Game engines are still temping, however that might have also created more problems that we couldn’t address. Any problems we had we simply asked different team members for any assistance. Either implementation would have still been a lot of work.".
    -Arizona defers: "Still prefer to have worked from scratch. I'm not sure how much an engine like Ogre would have worked for a game like ours, but AG would have a better answer for this."

5) For those who used RakNet, would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use RakNet, judging fro mthe experiences of the groups that did, would you have used it in retrospect?
    -We didn't use RakNet, but despite their many issues encountered with Winsock, the network masters felt they learned a great deal more from Winsock than they would have with RakNet.
    -Ed edifies: "Throughout the quarter, I maintained that winsock was utter garbage, but I was too chicken to go back and start all over with Raknet. In the end, I am not sure how much easier Raknet would have made my job, but I think I learned a lot more about sockets using winsock, and I guess knowledge is the best prize you can receive. It did seem that the other groups who used Raknet had a much easier time starting up and getting things going, and troubleshooting didn't seem like that big of a deal (compared to the nightmare I felt I was drowning in), but my problems stemmed from a lack of common sense, and some general knowledge of the library. If Raknet really was as easy to use as group 4 made it out to be, then maybe it is the best choice to make. But, despite all of my suffering (ha ha), I can't UNrecommend winsock. The argument seems to be much like the debate going on between Ogre and DirectX. Raknet = Ogre, winsock = DirectX. You decide which is best for you."
    -Daniel exclaims: "After using winsock, I have a better understanding of what is required through a network. Although I’m still not sure on all things regarding the network portion of the code, I think I’d be more comfortable using winsock again just because of the hands on experience I had with it this quarter with Eddie. We didn’t really touch RakNet so I’m not quite sure how much different it is from winsock."


6) Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?
    -Each member had a few things they would have changed, so learn from their mistakes!
    -AG says: "It's hard to say. Honestly, I can't think of anything I regret doing or something that had to be thrown away entirely. There were a few things I experimented with (a Cook-Torrence lighting model, for instance) that didn't end up producing the desired effect, but that's all part of the learning process, right? One thing I wish I had attempted was the use of user clip-planes for the geometry animation. I think this ultimately would have simplified things.
    -Trent also says: "In the last couple of weeks of coding, we began to break away from our original modular design and the code became extremely muddled and, in some ways, completely incomprehensible to anyone outside the person that had written it. If we were to do this again, I would like the make sure that we never went down that path and implemented the separate modules in a far better fashion."
    -Eddie offers: "I would have spent a lot less time trying out different networking models, stuck with the simplest one, and plow through it. I would have also invested a little more time in reading up on socket literature, and taken more moments to step back, write down what I was doing, and really think about the why. In addition, I would have given up on trying to make music for the video game (though it provided a soothing distraction). Making original content like that should be pursued outside the video game class, should the game go on to retail. Your time is better spent perfecting what you have right now, and implementing new features."
    -Daniel states succintly: "I think after finishing up the openGL version, I would have struck Networking harder since that slowed things down the most."
    -Arizona laments: "I would have dropped all of my other classes. I am not joking. Also, I should've spread my all-nighters out over the whole quarter and stocked up on food a lot sooner. Uh, in terms of the actual programming, I should've gotten involved with other modules outside my own few more frequently."

7) Which courses at UCSD do you think best prepared you for CSE 125?
    -AG blathers on: "If you're seriously interested in graphics, I HIGHLY recommend completing both graphics course (167 and 168) before attempting 125. Those course will give you an introduction into many of the fundamentals, and also give you some much needed experience in C++. I also found CSE111 to be very useful in introducing important methodologies and team project-based coding. One of the most important classes that gave me a foundation for 125 was a 199 research project using DirectX and shaders. I had never had experience with either before that, and I found this class to be a much greater experience with some knowledge of those topics going in.
    -Trent [verb]s: "CSE 120 got me the most comfortable in working with a large system of files. Besides that, I drew mainly from my skills learned in PHYS 1A for everything else."
    -Eddie says: "None, honestly. Well, maybe CSE 167 and 169, but I didn't delve that deep into matrices or animation. My best preparation came from my internship, where my boss pushed me to do a lot of things well beyond my programming capabilities (and probably well beyond the scope of the internship itself...I'm no engineer, you know! Not yet at least!)."
    -Daniel jots down: "I believe that the graphics classes helped me become prepared for this class the best. In particular, Rotenberg’s CSE 169 helped out plenty since it prepared me for some of the matrix and vector math that was required in the physics and gameplay portions of our game. The final project of CSE 169 (a cloth made of individual particles) helped structure the basic physics of the game. It helped give me an understanding of how an object can have different forces applied to it, allowing us to manipulate these forces for different gravitational forces to be applied on different faces. With this in place, Trent blasted away with the more advanced elements of the physics code."
    -Arizona transmits his knowledge: "Compilers and Graphics II (131B and 168) because together they taught me what it feels like to physically grow attached to the lab chairs. And good code design of course."

8) What was the most important thing that you learned in the class?
    -AG progresses further towards Carpal Tunnel: "It's very hard to narrow it down to one thing, so I'll have to say 'everything'. I think the entire experience was beyond useful. I truly feel like I could jump right into the industry at this point without feeling like a lost soul. From high level engine design, to the collaborative experience, to hunting down issues in a real-world project, this is by far the single most rewarding experience I've ever been through - both in terms of gained skills and in pure pride in producing something truly useful.
    -Trent says: "The most important thing I learned over the course of this project was what it was like to be involved in a large software implementation with a full team of equals. Over all the other little tidbits of knowledge I picked up on how games are made or designed in the real world, I think the actually team development mechanics are what I’ll be taking away from this course."
    -Eddie also says: "Oh geez. I learned a lot. How to use SVN is probably the most important, though haha. Having multiple backups and versions of your data is so crucial, and I feel like an idiot for not doing this before."
    -Daniel also also says: " I believe my coding skills have improved after getting a taste of what other people know and their styles of implementation. I’ve still got a lot to learn, however multiple people working together always results in better ways of writing code and handling code logic as opposed to working it out on your own."
    -Arizona breaks the mold and states: "That is really IS possible to put something snazzy and fun together over the course of ten weeks. I'm amazed that it's playable but also that it's _fun_, and looks great to boot."

1) What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed?
    -All the group members took advantage of the books with great pride; knowledge that they held for the entire 125 ride...
    -Trent would like to announce: "I found the Physics for Game Designers to be somewhat useful for refreshers in a few realistic physics modeling, but mainly I used Google and Web Documents".
    -Daniel, also supporting the Physics book, cries: "The examples were very clear and I would like to get the book for myself so that I can practice the physics samples shown".
    -AG, filled with jolly, would like to recommend the following:
        a.Real-Time Rendering 2nd Ed. (Moller, Haines): This is a MUST HAVE book for any graphics programmer interested in realtime graphics. It covers a wide range of fundamentals and basic/advanced techniques in high detail.
        b.Programming Vertex and Pixel Shaders (Engel): A little hard to use as a starting resource, but he provides a practical mix of theory and implementation that's easy to follow.
        c.ShaderX (Engel) and GPU Gems series: More advanced techniques that may not be entirely applicable to CSE125, but are always good references for current methods.
    -Eddie sputters: "I read the small chapter on particle effects in the black DirectX 9 book, and it had some nice sample code that I ripped to shreds".
    -Arizona states: "Unfortunately I didn't use any of the books in the lab this quarter. I looked at a few of them but not in much detail."
2) What advice would you give to students who will take the course next year?
    -Thankful for surviving 125 we display a sigh of relief. Here is some knowledge for future students to relieve their grief:
    -Eddie engraves his words into your mind: "There are going to be many long nights. Don't be stupid and take compilers or something along with this course. If you're like me and you need to work to survive, don't even bother taking 125 with any another CSE class. Take a painting class or something light. The more you put into this course, the more you'll get out of it, and damn it showed for my group this quarter. I was pulling all nighters starting 5th week with Danny, and we got our stuff done. Around 6th or 7th week, I stopped going to class, not because I was sleeping, but because I had so much fun working on what I was doing that I couldn't be interrupted to go listen to someone talk about god knows what for an hour and a half".
    -Daniel screams at the top of his lungs: "Maybe make an early due date (like 4th week) for the networking portion of the game to be functional. There were just too many instances where something would work in single player but needed to be integrated over a networked game".
    -Trent whispers into the night: "The best suggestion I can give is to keep things simple and to keep in perspective that this is a game that you need to demo by the end of 10 weeks. It isn't supposed to be the next best thing in gaming or forge new paths in game design ".
    -Vinh triumphantly declares: "working at home is no substitute for working in the labs. though you might have the tools and the will, you might be missing the most invaluable element, morale support".
    -AG proudly states:
        a.If you're interested in using shaders at some point in your project (which I'd recommend), start using them from the beginning and design around them.
        b.Use DXUT! If you think it's going to be too restrictive in any regards, then you're either not familiar enough with it or you?re trying to do something the wrong way.
        c.Start with one of the DirectX example programs as a project base. Begin by slowly stripping their code and replacing it with your own, with the goal of having all extraneous code removed within 2-3 weeks.
    -Arizona boasts condescendingly: "Integrate early!! Get that SVN repo up and running as soon as possible and work in baby steps. (On that note, commit frequently and after small changes, or your partners will show you up in number of commits. =p) FOCUS ON NETWORKING!! We had a lot of trouble with that and we all thought it would be really simple. Lastly, savor those ten weeks, because they won't last forever..."
3) How can the course be improved for next year?
    -Pacing and pondering what the perfect answer will be, we believe the following can only satisfy group 3:
    -AG jumps in to say: "I don't think any real changes are necessary to the class structure. I've heard some suggestions from recruiters in the game industry that they'd like to hear some form of 'postmortem' after each game presentation so they can learn a little about how each team & member handled the various hurdles encountered throughout the course".
    -Trent rises from below to bellow: "A coffee/lunch cart inside the computer lab and more cow bell".
    -Eddie simply suggests: "More pizza. More candy. More beer".
    -Daniel, filled with anger sharks, shrieks: "Discounts from ALL pizza resturants and I guess for another improvement for next year would be to have a mini fridge: yea, I said it".
    -Vinh adds with a sullen voice: "This might be asking for much, but really put more pressure on ACS to get things done".

    -Arizona humbly murmurs: "This quarter it took a long time to get all of the perks on the lab computers and the software from Microsoft, but those were just inconveniences. I think the class works out really well as it is."

    -With the final words said and done, there is only one more statment that must be sung: "Why aren't we getting paid for this sh!t?"

Eddie

1) Accomplishments:
     -eye candy.
5) Morale:

    

AG

1) Accomplishments:

     5) Morale:

    

Daniel

1) Accomplishments:

     5) Morale:

    

Vinh

1) Accomplishments:
5) Morale:

    

Trent

1) Accomplishments:
5) Morale:

    

Arizona

1) Accomplishments:

     5) Morale:

    

TEAM REPORT

Eddie

1) Goals:
    -Finish the important networking stuff, hand the torch over to Danny, start on particle fx.
2) Accomplishments
    -Stole some code to render a basic DirectX window
    -Stole some more code to render point sprites
    -Began work on a particle fx emitter class
3) Missed Goals:
    -I didn't get as much done networking side as I wanted to. There are still bugs left to be ironed out, the ball moves really choppy, and full screen in network mode just plain wouldn't work!
4) Next week's goals:
    -Iron out the networking bugs, go full steam ahead on particle fx; finish the pfx engine, get it all integrated with our main code, and shoot off an explosion when balls collide. Oh, and figure out what the heck is wrong with that full screen bug....and get my hands dirty with game stats and game modes. I've got some good ideas.
5) Morale:
    -I can't belive that, as of this writing, there is only 8 days left! I'm super pooped from the all nighter last night, but I love seeing progress. I know that we'll have a working game by the deadline, but there are so many features I want to implement, I feel it's going to be disappointing any way you slice it. Other than that, a big F yeah! to team A.S.S. for pulling together this week and making it look and feel like a game! I can't wait to play the updated build with everyone in the lab tomorrow! Prepare to get your butts handed to you ;)

Oh, and I'm going kinda nuts over how much of my life I have put to the side, school, and the personal stuff.

meh..

Arizona

1) Goals:

     -Work on levels for the game

     -Add camera autozoom/tracking
2) Accomplishments:

     I made a level for the game (the sphere map, pic posted) though in the end it may not be the best choice... it turns out it's easy to fly off when every direction you move in is 'down.' =)

     Mostly though I did a lot of miscellaneous stuff. I took a good hard look at networking, helped Danny with a little of his model movement, and ironed out random little bugs here and there.
3) Missed goals:

     That darn camera. Again. Autozoom I actually forgot about until now (whoops...) but tracking is really difficult because of the way the camera is set up. Normally you'd just do a lookat matrix, but the current camera system is based around the fact that the position of the camera at any point in time is the result of a series of rotations about X, Y, or Z of the original camera lookat matrix.
4) Next week's goals:

     -FIX BUGS. Maybe a couple of little features but at this point they're supposed to be too small to mention. Must resist.... temptation to add features... right before demo....!!
5) Morale:

     Holy spam, I cannot believe the quarter is almost over. No! Give me back my undergrad! I'm TOTALLY psyched about our game and I want it to be amazing. Yes yes yes we can do it go go go!!!

Daniel

1) Goals:
    -Help out in any way I can; I'm a tool.
    -More networking.
    -Challenge Voelker to a hurtball match! ;).
2) Accomplishments
    -Network has improved. Thanks to Eddie for sticking with me and always going crazy.
    -Sounds implemented for network and GUI menus. Some problems where fixed, new ones came up: always fighting.
    -Model rotations implemented with major help from the state of Arizona. Trying to get the "ballerina" effect to go away. However, models that Vinh and I worked on for so long are ready to be thrown in.
    -Plenty of other little things, I'm starting to lose track.
    -I ate enough Mexican food with AG that would have fed a family ...that's an accomplishment right?
3) Missed Goals:
    -Making the network better. Making the game tweaks better.
4) Next week's goals:
    -OMG, just make everything better!
    -Hopefully the models can be used.
    -Get the game feeling like it should in full screen with a network running
    -More sounds.
5) Morale:
    -Kinda like that feeling when your alarm wakes you up after sleeping for only 2 hours. You're excited but have an overwhelming feeling of dread and tiredness that you just want it to end but you know you still have to get up. Yea...that's it, just more on a positive side...maybe...
6) Quote of the Week:     -"Get ready to dance!" (said with a german accent)

Alex G.

1) Goals:
    -A whole bunch o things that I was apparently too lazy to quantify last week.
2) Accomplishments:
Hoo boy. Here we go...
    -Irradiance mapping: The basic ambient term in our lighting equation has been replaced with an irradiance map sample. Basically, a cube map for a very diffused version of the active skybox is indexed with the surface normal.
    -Dynamic global illumination: It's a hack - but it looks pretty damn good and runs fast. Every frame, 6 weights are calculated using neighboring tiles for each player that control a linear interpolation between the irradiance map sample and an average color for the face. The weights are blended with the normal to produce a directional dynamic global illumination effect. Basically, that there side of the ball done gets redder when it's near a wall. Hey that rhymes. Redneck poetry - loving it.
    -Particle love/hate relationship: Implemented particle system using simple shader. Lab hardware lied and reported it could handle it. It couldn't. Several hours of frustration led to a fixed-function solution that works. I'll step aside for Eddie to work his particle magic.
    -Level transitions: Spent a lot of time fixing a number of issues with the level transitions. Things are now working just how we want them with no real issues.
    -Hunt for new media: Skybox assembly from individual images, irradiance map creation from skyboxes, a few new textures, etc.
3) Missed goals:
Nada
4) Next week's goals:
    -Shader optimization: Provide a better 'wimpy graphics' mode for the lab machines. They only support pixel shader model 2_0. 2_0! Not even 2_a! That means we're limited to 64 instruction slots. I'll have to sell my soul and/or get into voodoo to get everything I want on those machines. Oh well, the main demo PC will handle it all...
    -Finish ball lighting model: I'm thinking a Cook-Torrence lighting model for a brushed metal look.
    -...Etc? We have a ton of stuff we still need to tweak and play around with. We'll have our hands all over the code.
5) Morale:     -Wow... This thing is really coming together fast. We've sacrificed classes, family, and basic human needs, but it'll all be worth it to see this thing on the big screen. Go Go Team ASS!

Vinh

1) Goals:
    - GUI mostly and whatever else
2) Accomplishments:
    -Sexified new menu layout and animations are in place, fade-in/out transitions between menus, jiggly buttons, working text entry boxes with blinking carrots, updatable screen text.
    -Played around some more with the models, working on fixing and texturing
    -Dabbled in network optimization, replaced booleans with bitwised representations on both server and client packets
3) Missed goals:
    -player identification - the idea was to have each player be representable by a specific characteristic. Sounded simple enough, but im stuck trying to figure out how the player would be able to set this up.
4) Next week's goals:
    -Focus on gameplay and feel, this seems to be the area most in need of working on at the momment.
    -Churn out game content.
5) Morale:
    -Ready as long as I have caffeine

TEAM REPORT

Vinh

1) Goals:
    -Inputs, GUI
2) Accomplishments:
    -Input is done the hell up. mouse wierdness is fixed and for the first time rumble support on the gamepads.
    -Gui entry boxes, buttons, updating texts; menu states are there; layouts have been added
    -Started on some normal maps
3) Missed goals:
    -Texturing of models, it seems like the lowest priority right now since they might not even make it into the game.
4) Next week's goals:
    -Making this game perfect, helping out any other areas as much as i can.
5) Morale:
    -Sleepy, but looking forward to the next couple of sleepless nights.

Eddie

1) Goals:
    -GET THE FORKING NETWORKING DONE GWAAARRR
2) Accomplishments:
    -It's ALMOST done! Just need a few tweaks hither and thither
3) Missed goals:
    -I'd say none.
4) Next week's goals:
    -Finishing touches on Networking (fix slow down issue, possible memory leak)
    -Begin work on particle fx, music, level design, etc.
5) Morale:
    -Exhausted from the all-nighter, but excited for what this week will bring! The game's playin awesome!

Trent

1) Goals:

    -Addition of specific effects of game power ups and states such as burning, freezing or moving through tunnels

    -Balancing of game play parameters in order to get a more comfortable feel for the controls

    -Working with network team members in order to help them know exactly what needs to be communicated between server and client

2) Accomplishments:

    -Game power ups were successfully integrated with our base cases of Ice/Fire/Rock

    -Game controls feel smoother and more comfortable with the X-Box 360 controller

    -Mods/Damage/Player State now is successfully communicated between server and client as well as excess data being removed when not needed

3) Missed goals:

    -Tunneling and addition of weapons to be picked up not yet implemented

4) Next week's goals:

    -Addition of game modes and parameters such as death, victory conditions, lives and score

    -Further flushing out of simple elemental power ups with new additions as well as particle/model effects

    -Working with Sound/Particle effect teams to trigger proper events

5) Morale:

    -Very high as the huge milestone of networking was conquered this week and everything is now setup for pure bells and whistle additions

Daniel

1) Goals:

    -Networking.

2) Accomplishments:

    -Majority of the networking is done.

    -Major upgrade in how we handle our project files: before, client and server were in seperate project files. This was good for awhile, but was close to impossible to update. This has been fixed and now client AND server are in one project file: this allows for updating.

    -Powerups, mods, and GUI are pretty much integrated into a networked game.

3) Missed goals:

    -All of the networking complete.

4) Next week's goals:

    -Improve the speed of the network

    -Work on making models work! (they're ready, it's just if we can use them).

    -Help out with map making if I can.

5) Morale:

    -Good but I'm a little down since there might be a chance the models are going to be left behind. No matter how shiny you make them, they're still just balls... However, I'm now determined to make it happen!

Arizona

1) Goals:
2) Accomplishments:
3) Missed goals:
4) Next week's goals:
5) Morale: