Week 4 Overview

This week, I completed Part 2 of NPCs and Visual Information, which can be downloaded here, and also researched the characterisation of the playable races in the tabletop wargame Warhammer 40,000, which can be downloaded here.

The Characters of Warhammer 40,000

This piece of research involves the background and characters of the popular tabletop wargame Warhammer 40,000. The research document can be downloaded here.

6 Mar 2010 - Handling the handling issues

After a busy and exhausting week of setbacks, deadlines and frustration, some unexpected progress was made on something critical - the vehicle handling.

As recently as yesterday I was coming up with nothing on the vehicle issues. The Maxton worked fine on a completely flat surface but any slight gradient would cause it to do all sorts of things that removed control from the player. This has been an issue for some time but now I think it's finally been resolved, thanks to a post on the 3Dbuzz forums from four years ago.

Basically, the 3Dbuzz thread found here suggests that the 'root' bone (centre of the vehicle skeleton) actually has an influence on the pivot and weight balance of the vehicle, and this was directly related to the problem of the vehicle 'rearing up' like a frightened horse. Moving the bone will influence how the vehicle behaves in the game engine.

The infuriating 'rearing up' problem in-game that has been an issue for far too long.

Moving the 'root' bone further forward affected the weight balance of the Maxton

I gave it a go - I moved the central root bone much further forward and re-imported the vehicle from Maya into the UDK, set the PhysicsAsset (which I was convinced was the cause of the problem before now) and tested the Maxton in-game on uneven terrain. Success! The car is responding much easier now, shows some signs of suspension in the wheels (though it is not visually accurate for the model) and doesn't come to a halt when it touches something as insignificant as a slight incline or a kerb.

This makes me very happy as designing the track and terrain - a vital part of the whole project - should now be able to proceed without having to compensate for poort vehicle handling. Fingers crossed that things will be a little smoother from this point!

5 Mar 2010 - Can it be? Real visual feedback?

TEMPORARY ROUGH NOTES:

Looked at HUD tutorial by Shad:http://www.shad-fr.com/udk/hudtut/english.html
Tutorial works with vehicle health in game - stripped down the code to only include relevant pieces for the game, needed help from forums and got some helpful feedback - pity the bedroom programmers also feel compelled to have an elitist attitude while dispensing information

Eventually got HUD to work though the gauge is co-ordinate specific, not screen percentage, so window cannot be resized during play unless a solution is found.

ADDITIONAL:

Terrain work started, issues with vehicle collision and handling. Cannot drive on uneven ground and this is a MAJOR problem for the development of the whole project. Tweaking vehicle handling cause more problems to which a solution is yet to be found.

Have posted on UDK forums about this but feel a bit halfhearted after the snobbish response from the coders.

Week 4 - NPCs and Visual Information - Part 2

In the second part of NPCs and Visual Information, I use the methods described in Part 1 to create four NPC characters for a post-apocalypse setting. Due to the number of images this article has and the image per post limit, it can be downloaded here.

3 Mar 2010 - Trimming the HUD

TEMPORARY ROUGH NOTES:

Managed to disable in-game HUD with blank 'MyHUD'.uc file for an empty screen (screenshot)

UI 'Titles' created and tested, works in game. (screenshot)

Issues with UI to UI transition - crashes game for unknown reason?

Tutorial discovered on how to implement basic working HUD - will see if this can be applied

2 Mar 2010 - A problem with the Natives

Another issue, another solution. Once again the programmers on the UDK forums have pointed me in the right direction and have helped me stop the game crashing on startup, which, as errors go, is a bit of a big one.

Apparently the critical error was cased by my vehicle script (no surprises there) - as it borrows heavily from the default 'Scorpion' vehicle that comes with the game. The error in the game's log file (found in 'UTGame\Logs') was this:

Critical: Can't bind to native class *name of custom vehicle*

This was caused by the 'borrowing' of the Scorpion's code. The Scorpion has a 'native' class definition in it's script, which can only be used by official vehicles that come with the development kit (I assume this also applies to other objects that Epic provide with the UDK).

So, the solution is to remove any references of 'native' from the vehicle script. In my case, it was in the UTVehicleMaxtonSteamCar.uc file. I commented out the code using /** and */ .



This wasn't successful initially, resulting in the exact same crashing on startup. But another look at the UDK's log files showed two more messages:

Error, Cannot use cpptext blocks in non-native classes

Error, Only functions of native classes can be declared native

This required a further study of the script but was solved quickly thanks to the search function. It just required further commenting out of the 'cpptext' function and another 'native' reference further down the script:


Running the game seems successful now, and it loads up without crashing! Of course, commenting out code rather than deleting it allows me to return to the default script if anything should go horribly wrong - but so far, so good.

I cannot describe how important looking at the log files are. Not only do they give you an error to work with when looking for a solution, but they also give you the file in which the problem lies, and the line of code that is causing the issue. This saves such a lot of time!