UNDERGOD

Here's our review document mostly composed by Matt (I tacked a crappy paragraph on the end).
Anyway I hope the 2nd presentation went better for the networkers. I know personally how hard some of you guys worked, so hopefully you were able to get that across better this time.

Undergod
A review

Our project, Undergod, had various issues, some we overcame and others left us scratching our heads. Many of the problems we had were due to something being poorly documented or just beyond our skill levels, here are the issues we had and how we solved them:

Animations
Animations were the most time consuming part of Undergod, the process of creating a model, texturing it, rigging it and then applying animations is a long one. Although we completed this process for a few models, getting the finished product to work in Torque was another story.

One of most noticeable issues in the presentation game build was Kali's second pair of arms being unanimated, the task of controlling two sets of arms without them conflicting with each other is a extremely time consuming one. This was never corrected and the model was left with a pair of static arms, with more time we would hope to finish Kali in the future.

Another issue relating to animation was the motion capture process, although this technology makes creating great looking animations easy it doesn't integrate into Torque seamlessly. Thankfully we did find a solution for this, we found that the sequence node must be oriented such that it points forward in the direction that the character model looks at; this is best achieved by drawing the sequence node in from behind the character model.

A lot of the problems with animations were also learning experiences. A bounding box defines the shape's orientation and position in the world, this came into play when our scythe demon model was disappearing when it was still in sight. The reason this was happening was because the bounding box was too small, smaller than the model in fact. The solution for this problem was easy thankfully, by simply increasing the bounding box variable in the scythe demon's datablock corrected the issue.

Melee
A brand new feature we implemented into Torque with the help of an online resource was the melee mod. Currently the Torque game engine is built to only handle projectile based weapons and one of the main concepts of Undergod was the use of melee weapons such as swords. A couple problems arose from this addition however.

A less noticeable problem with melee was hitting your enemy twice in one swing. The cause of this problem is being too close to your enemy and attacking, for example, if you hit the enemy first with the tip of your sword and then if the handle also came into contact with the enemy in the same swing, they both are counted as damage. This isn't ideal because bigger swords would always have the advantage over small swords. Since this issue wasn't really noticed until we were well into development it wasn't fixed.

Another problem with melee which is the complete opposite of the above was the weapons not doing any damage. The problem arose when creating new attacking animations, we found that the melee mod works by defining an amount of time that the weapon can do damage for each animation. Fixing this was simply modifying the time to suit each animation and weapon.

A*
Although A* wasn't really utilised as well as it could have been nor really needed it was still a good learning experience. I say it wasn't really needed because our terrain turned out to be quite open without a large amount of obstacles.

Possibly the most annoying effect of the A* addition was the fact it destroyed a bunch of other useful functions. Most notably being setMoveDestination, it took several weeks for us to come up with a solution for this but in the end it was discovered that the A* movement function could also take in a vertex as a parameter making it exactly the same as setMoveDestination. A* also broke a few other AI player specific functions but thankfully we didn't require those functions.

Another issue we had was the enemies stopping before arriving at their set destination, it was later discovered that a variable in client preferences was the cause of this and lowing it resolved the issue.

An issue that didn't arise until very late into development was enemies getting stuck on tree branches. Trees are correctly detected on a navmesh however things protruding from them are not, there really isn't anything you can do about this other than moving the branches to have a lot more clearance from the ground or removing their collision mesh from the tree.

GUI
The graphical user interface for Undergod was one of the less problem ridden tasks and probably less important compared to others since it doesn't have a major effect on gameplay.

The character select screen had the nice touch of giving you a 3D object view for each playable character. Unfortunately, this along with the terrain as a background caused it to remove the fog effect from the game. A solution for this was never discovered so rather than spend time trying to fix it ourselves which changed the 3D representations to 2D ones.

Another nice touch to Undergod was the use of circle health bars to give the illusion of a bowl of blood, something more exciting than the typical rectangle. Yet more problems arose from this engine change, mysteriously the health bar was using the health variable as a float which would give an inaccurate view of health since you can't draw a fraction of a pixel. The issue was easily resolved by rounding the health value up and making it a whole number.

Finally an issue that came from poor coding on the AFX side was the spell bar displayed across the bottom of the player's screen. While trying to draw the spell bar at the beginning of a game, two spells were always mysteriously skipped and not displayed. Strangely the solution for this was to also include the two navigation arrows for switching multiple spell bars into our version. Even though we only had one spell bar.

AFX Spells
Probably the coolest addition to Undergod was the new effects by the AFX resource. With these cool effects came complexity.

One thing we were quite ambitious about was adding our own spells, it turns out that this actually really difficult and time consuming. We settled using the default spells that came with AFX and they still looked awesome.

Management
The Battlefield of the Gods project started with five people working on various aspects and as such required a firm commitment to maintaining focus and remaining coordinated.
In order to ensure maximum productivity and collaboration remained at an optimum level. Regular check-ins with team members by the Team Leader and weekly meetings to update each other on progress made towards currently assigned goals.
Additionally posts were made to a project blog to allow members who were unable to make it to TAFE to remain up-to-date with other members’ progress. In order to facilitate offsite access to documentation and tasks assigned members a wiki site was created.
When challenges arose due to lose of participation by a team member, we were able to adapt quickly and efficiently by reassigning outstanding tasks to other team members.
To cope with a potential disaster the latest copies of all files were stored in a centralised location and members endeavoured to maintain current copies on their personal storage devices.

Monday, August 2, 2010

Links

Thursday, June 25, 2009

Review by Matt (with a final paragraph by Brett)

Tuesday, June 23, 2009

hey

23/6/09 Tim

Monday, June 22, 2009

Week 9

late blogging

late blogging

Week 8

emma,s blog

w 4

Week 7

week3

week2

week 1

PRESENTATION WEEK

BLOG FOR LAST WEEK

Week 6

Week 5

Week 4

15/06/09

Labels

Links

Blog Archive

Contributors