Review by Matt (with a final paragraph by Brett)

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.

I forgot how to sleep

So the game may or may not be playable in time for the presentation. Animations are likely to be glitchy, there will most likely be no changes to AFX, our presentation may be dodgy as all hell and documentation may or may not be in existance. So if you hear swearing or screams of frustration coming from 104 this week you'll know what's up.

Overall things are going pretty well considering our ambitions.

Spellcasting without clicking on GUI buttons

I read through the code for how a spell is cast when you click a button on the spellbank GUI. Most of the code can safely be ignored, the castspell source function can be called directly if we have the following:
-a spellbook with the desired spell in it
-the slot of the spell in the spellbook
-the gameconnection for the client / caster who has the spellbook
-the id of the target object

I haven't looked at giving the AiPlayer a spellbook yet and I can't remember if we are using AiClient for AiPlayers; both of which will be required for bots to cast spells.

I think by using components of the Smokin' & Arcane in the Membrane spells we should be able to give the Scythe Demon a nice constant effect below him that sheds some light on the model so it doesn't look so dark.

Smokin' Arcane in the Membrane

AFX fun

As you can see in Matt's post below I've got the demo AFX spells working. This was actually quite a trial as the management system for spells is quite complex.
I additionally had a problem where the first two spells on the spellbar weren't showing up, but were being created as data objects. I eventually found out (thanks to Matt) that it is assumed that the first two items in the spellbar will be arrows to scroll through sets of spells. Considering I spent at least 4 hours trying to figure this out, asking for help from everyone who could possibly help, for it to turn out like this is quite aggravating.
Anyway, I'll probably spend today & tomorrow trying to modify the demo AFX spells so that the can be used for our characters, and next week we'll start planning our presentation & finalising our documentation.

***Update***
Oh, and I guess we have to

• add in the models + animations for the skeleton, Ares, & Kali.
• add Nicks stat system.
• finalise the monster spawning system.
• create some AI for the Scythe Demon.
• test multiplayer, again.
• create seperate spell books for each character.
• and whatever else I've forgotten.

Anyway the core basic gameplay should be complete by next week.

***UPDATE 2***
I got selectrons working so here's some pictures.

Progress Report

So things seem to be going okay we have some code to move bots around and next week hopefully we'll be able to add in the experience system, spawn code for enemies, enemy models, player models (maybe?), and play gui.
Keybinding is being awkward and though I've created a GUI I don't know if I'll bother putting any code into it, there's other more important things to do.

Stronghold Gui Fix

I put the modified Join Server Gui in the copies of Stronghold on the computers in the facilitation room. If you need it again it's on earth in ProjectTemp; it's a file called joinServerGui.gui and it needs to go in the Stronghold\game\scriptsAndAssets\client\ui folder.

Scythe Resolution

Bounding box issue is fixed. Apparently the player (and by extension aiplayer) objects get the size of the dimensions of their bounding box from script [specifically the boundingBox variable in the datablock definition for the player object].
Fortunately I found a post on GarageGames that had to do with a similar problem, though the post was nearly two years old & by someone using Torque Game Engine.

Anyway the bounding box for the scythe demon is now the correct size so collisions work for the entirety of the demon's body.

The picture shows 2 scythe demons, the left one has a correctly sized bounding box boundingBox = "6.2 6.2 7.3"; and the right one has a bounding box with the default value boundingBox = "1.2 1.2 2.3";

4 weeks left: Scythe Image Mounting Problems

The Scythe Demon is being painful and won't mount the scythe at the correct point, although it will mount the melee test weapon. I'll to offset the mount of the scythe and some other things to get it to work. If worse comes to worse I'll just make the scythe part of the Scythe Demon DTS and create some sort of invisible weapon that it can swing about to cause damage with (this might actual work better as getting the Scythe Demon's swing of the scythe to collide with a player could be difficult).
Additionally an old issue has reappeared with the engine moving the position of the arm when you rotate the camera in the vertical axis, useful for a first person game but not so much for a third person game. I guess I'll try to chop it out and hope it doesn't break the game.

Anyway the presentation is in the second last week (June 22nd), so there is only
4 weeks left.

Multiplayer

Woo, my multiplayer gui works. I've tried to make the gui as easy to use as possible by automatically checking for servers when the gui opens.
















The above pictures show the gui and the game running the level in multiplayer mode. The gui does need a bit of checking to make sure all it's elements actually work when a server is found (can't do this myself at the moment as I need to run the game on two seperate machines and that requires going through the firewall, which needs admin rights) but I'll do something about that tomorrow.

Presentation Report

Today we had our little mock presentation. Both teams of the networkers made interesting presentations that were quite different from each other.

Team A was more unified in their presentation, though only three members spoke (not good guys; this suggests that the rest of the team did nothing to an audience that doesn't know otherwise). Including a network diagram was an excellent move, and the explainations given on how it all worked was very good. Only working with 2 nodes at the moment might be an issue if problems occur when you try move onto 4 nodes late in; of course I don't know if that's a realistic concern or not.
The website had a very nice layout and the plan for how it would function was excellent. About the only possible addition is the inclusion of pages for individual players, though that sort of thing isn't strictly necessary and would take too much time to do well.

Team B was essentially had two seperate presentations by two different people.
The networking presentation went through the actual process used to create the cluster and was particluarly interesting to me as I've heard a lot about clustering over the past two semesters but never really had any idea of how it was all setup.
Presentation of the website was good also and whilst the site wasn't as pretty as Team A's it was just as impressive since it had been built from scratch. I was particularly impressed with the scripting.
Unfortunately it appears that there is a distinct lack of unity in Team B and several members have expressed annoyance that they have not been assigned meaningful work. From my outside perspective it seems that two key factors are affecting Team B:

• Firstly there appears to be a lack of coordination by the team leader.
• Secondly there it seems that team members are not trying to work as part of a team enough.

Anyway this is just how thngs appear to an outsider like me. Hopefully Team B can resolve whatever issues it has before the final presentation and all members will be able to present what they have contributed to the project.


Finally as for the programming team's presentation.... Yeah we just babbled some crap for way to long. Only me and Nick were here in time for our presentation, though Will did show up later.
We didn't really take this presentation seriously. We will however be devoting the two weeks before the final presentation to just work on the our presentation.

Level and pathed camera

Finshed making a usable level, though I want the rest of the programming team have a chance to review it. I've implemented the pathed camera for the menu, the screenshot shows the camera at various points on its path, I'd post a video but it's too much trouble trying to capture in-game footage. I've had to modify the game scripts a bit so there is a new version of the game on the share called "UNDERGOD_150509" (only the scripts are included as I haven't changed the source recently).
Earlier this week I attempted to port AFX to the new Torque3D Beta1, unfortunately the changes to the lighting and shadow system as well as the Terrain rendering procedure means far too much time would be required to get a working build going even if various features are striped out (e.g. zodiacs, afx lights).
Next week I'm going to propose some changes to the character select GUI that should fix the problem with the fog shader. I need to get the textured version of the Scythe Demon into the game sometime and hopefully I'll be able to get a working Play GUI going soon. Then I'll start work on the AFX for special attacks.
We have also decided to drop the Minotaur as the Boss and promote the Scythe Demon. We had to do this as we haven't done the motion capture for the Minotaur, the rigging isn't quite finished and he isn't textured either. Hopefully we can still use Nick's awesome model as a statue or something.

Environment Design

Here's a rare short post from me as I'm feeling quite tired right now.
I've been working on the level, here's some pictures.














Thanks to Bianca from FTI we have some great motion capture data for Kali.
I've made an attempt to get the image based health gui working in game, with some success.

Jerry: Missing, Presumed Dead

Jerry has failed to return from holidays. As the last anyone heard from him he was getting over a serious case of alcohol poisoning. Jerry being Jerry we are assuming he has done something stupid and drunk even more alcohol whilst he was supposed to be recovering.

Thus we say Rest in Peace Jerry
(you better be dead or you will be)

Progress

I've been messing about trying to get the dividing wall set up.
Initially I wanted to set up a scene in Max using trees & foliage we would be using in game and then render it out as image that would be the texture of the actual divider plane object. I even found a model of some realistic grass that I wanted to use as ground coverage, unfortunately the grass model had quite a lot of polys and I needed 144 copies of the model to cover the desired area. This ended up creating a scene with ~750,000 polys, that max couldn't render (I got a too many faces error).
I decided to abandon the idea of putting the grass in the scene, in favour of rendering an image of the grass and placing the image on planes in the scene. Unfortunately I couldn't get the grass to render an image that would be tileable.
Abandoning the grass altogether I decided to just use some tileable textures I had. After numerous attempts to get a decent render I fincally gave up and ended up just making a flat tileable image.

Besides the divider I've done a little work on some technical documentation on exporting character models for TGEA from Max.


Additionally I've tested the animations for Ares & the Scythe Demon in-game, which was suprisingly frustrating due to a typo that stopped most of the animations from working the first time I tried them.

As for whatever else I was supposed to be working on..... I haven't done anything and I should probably check the Project Tracker on the wiki to find out what I should be doing (which itself badly needs updating).


On another nore you may have noticed already but Tim has finished the logo for the game (see the top of the page). I've added it to the UI and documentation, though I may add it to some additional UI screens in order to make better use of it.

Animation Progress

I've gone through the motion capture data and most of it's pretty good. A few retakes will be necessary though and all of it needs tweaking. The sheer amount of time required to get the animations working in game is quite daunting and as such I think we should drop a few characters. Specifically I think we should drop Kali & Ra from the player characters, and the ghoul & lich from the monsters. This would mean we only have to capture data for Loki & the boss monster, do retakes for Ares & the scythe monster, and use Ares data for the skeleton monster. Obviously if we have time we would do the rest of the characters and if not we can place the static models in the gui as placeholders.
Of course ultimately we are programmers and it would be best if we could spend the majority of next term working the actual gameplay.

Sunrise

Well after much hardship we finally have a sun for Ra. The animation is a bit jerky, the glow/emissive effect looks a bit off on the flames and the billboard doesn't actually work quite as well as we had hoped but it's good enough for testing.
Making this object has taught me a number of important things. Firstly I've learnt a good deal about graphics manipulation in Photoshop and Gimp. I've also remembered a lot about using Flash. I also learnt how to have animated textures in Torque.

Finally I learnt that Billboards and I shall forever be mortal enemies. I had to steal Alan's Billboard after my best effort ended up looking like this:

Where the hell are my diploma multimedia students

I spent most of last week trying to figure out a problem with exporting characters to Torque from Max. This week I've spent most of my time trying to create the sun that will float above Ra's head, the actual object for Torque is easy enough: just a sphere with a billboard through the centre.

The thing that has been taking up my time is the creation of animated flame image I want to apply the billboard. At first I thought I could just get some images or movies of the real sun and some how turn them into a sequence of images I could use for the billboard. Unfortunately the created images need to have a transparent background and I couldn't figure out a way to strip out the current background.
I then decided I would get some flame brushes for photoshop and make a halo of flames that I could then animate. The fatal flaw with that scheme is that once the halo was created I had no way of animating the individual flames since I stupidly collapsed the layers, additionally I have absolutely no idea how to create an animation in photoshop.
Fortunately I did save the individual flames I created as seperate images so I am now using flash to build an animation. See below for what I have so far for the image for the billboard and the sphere for the sun:



Obviously I have quite a ways to go but hopefully it will turn out alright. Once I'm done animating in flash I still need to export as a series of images and stich them together so the animation acan be used in Torque.

All of this brings me back to the title of my post; I'm sure if we had any diploma multimedia students they could get better results in a less time.

A Vile Pestilence

For weeks now Will has been working hard to build and rig a base male player character model. Last week he finished it. He tried using the DTS exporter but for some reason the models failed to export correctly. Not wanting Will to get bogged down with exporter problems I told him to move onto other tasks and I would sort out the export problems.
Unfortunately my attempts at exporting the model encountered the same problems. Upon hearing of my troubles Alan decided to test the exporter in 2009. He found that the same problem occurred. Since he couldn't remember having such problems when using 3D Studio Max 9 (rather than 3D Studio Max 2009) he reinstalled Max 9 and tried it out. Using the exporter in Max 9 worked so Alan arranged for Max 9 to be reinstalled on another machine in A104 so I could use it.
Unfortunately another problem reared it's head when I found that Max 9 cannot open files made in Max 2009, further complicated by the fact that Max 2009 does not allow a file to be saved in a legacy format. Even worse none of the export formats exported the links between the skin and the bones.
Despairingly I turned to the Internet in hopes of finding a plugin or script that would let me export from Max 2009 and import Max 9. I searched diligently but there were remarkably few import/export plugins/scripts that work with Max 2009 and none worked as wanted.
I have several other ideas to try before I resort to getting Will to re-rig the model in Max 9.

****** UPDATE ******
Thanks to Tim being awesome and putting me in contact with a super cool person from Interzone, I was able to get the mesh and the skin data into Max 9. Best of all in Max 9 I have been able to export the model correctly so that it works in Show Tool Pro, proving that the irrefutably proving that the export problem in Max 2009 was due to a fault in the exporter.

Unfortunately I couldn't find a way to get the biped into Max 9, so I had to create a new biped. This is not an ideal solution as the new biped is not exactly the same as the old one meaning the weightings for vertexes in the skin data is not perfectly accurate. I'm going to have another attempt at making the new biped, this time I intend to try to copy the values for each bone exactly (a time consuming task).

Ninjas ate my monkey

Well since my last post I've been working on the user interface(UI), getting animations to orient correctly in TGEA, maintaining the programming wiki, and learning how the Arcane FX system works.
Problems arose whilst working on the UI when I decided I was not happy with simply using an image and decided to add some new fonts to the game. Firstly to install fonts into windows administrator access is required and secondly it is necessary to restart (log off?) the computer after fonts have been installed.
Fixing the problem we had with our .dsq animations also caused issues. We went to the trouble of recording motion capture with four different orientations (i.e. facing different directions), however once imported into torque all the animations had the same problem; that being when played they would reorient the player character to face the left (whilst leaving the camera position alone). Some frustrated experimentation revealed that unlike what every piece of documentation available says the orientation of the character doesn't matter but the orientation of the sequence node does. It turns out 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.
Arcane FX is a commercial engine mod for Torque Game Engine Advanced that allows advanced special effects to be created through TorqueScript. Effects are created using modular components; at the top of the hierarchy is the choreographer, which sits above phrases, below that are wrappers for each effect and below that are the building-blocks effects themselves.

I have also contributed to the programming teams efforts in planning animations for characters, level design, and character planning.

This week I hope to continue work on the UI, get our test animations working in the game, continue working on the wiki & documentation, import our test character into the game, begin work on Ares special effects, and a bunch of other crap I can't think of at the moment.

Divine Fonts

Fonts for our four pantheons (Egyptian, Norse, Greek, Hindu).