Friday, 26 February 2010

26 Feb 2010 - More of that damned functionality

Yesterday evening was strangely productive. Strange in that I didn't set out to do any work but somehow I solved some issues and gained a little more understanding of the UDK editor, leaving me with the thought that perhaps I should make it my aim not to do work more often.

First up: Camera settings. The vehicle in-game is still a bit too close to the screen in my opinion, so I looked for settings that might be able to help with the issue, and I found this in one of the custom vehicle's .uc script files:

Changing the field of view

This is not really a fix but it does make a difference. FOV must stand for 'Field of View' as if the value is cranked up the player's view is skewed and highly distorted. However, subtle tweaking does allow the player to see more of the surroundings without this distortion, and I am using this as a workaround unless I find more specific settings that I can adjust.

Additionally, CameraLag affects the player's camera tracking of the vehicle. Setting this value much higher let me see the car drive away and around a corner long before the camera even started to follow it! A little useless but interesting, and any understanding of the code could be helpful in future. I came across an issue when trying to reset the camera even after I had reset the values and was unable to understand how a computer can retain knowledge of changes when given explicit values in code to follow. The files have to be compiled before the editor will run, and it is these compiled files that retain the information, even if you reset values. The solution is a strange and unnatural one: You must DELETE core files in the game - not quite as drastic as it sounds as the editor recompiles these files every time you start it anyway, but still. The files that needed to be deleted are shown below:

Deleting relevant compiled files

This may be the solution to many persistent errors encountered while working with unreal script, so I think this discovery may be an important one.

With that issue sorted, I looked at using trigger volumes once again - this time using invisible triggers. Here is a top-down view of the map in the UDK editor, using some of the houses as mock-up streets that the player has to drive through:

Top view of a test map - the red circles in boxes are trigger volumes that decrease the water level when the player comes into contact with them.

The 'damage' triggers are exactly the same as the red water tower used as a test in previous posts, only this time they are invisible. This is only one of a few solutions to the decreasing health aspect of the gameplay but if all else fails, this system can be used. The triggers are set up just as the water tower was, and I also made a discovery by being lazy by testing to see if a single action could affect multiple triggers, and it does. This potentially saves a lot of time in Kismet in the long run:

Multiple triggers can link to a single action - making the management of Kismet actions easier

Next week's goal is to have a look at a BIG issue: User interfaces and the dreaded Heads-Up-Display (HUD). These topics are enormous and essential to any game. My tutors assure me that a working HUD is not required, I still think the whole subject will be a difficult and time consuming one. On the other hand, implementing any form of UI or HUD will give me a massive boost in confidence as well as making the game look like a much more a professional piece of work.