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.

25 Feb 2010 - Seeing Red - or not...

The successful implementation of the water tower means I am one step closer to having a basic working game. The Trigger volumes used to boost the health are a really simple way to both increase and decrease the health of the player vehicle.

One snag with the default settings in the UDK is that any damage inflicted on the player results in an on-screen alert that appears quite drastic - the screen edges flash red, the player's view shakes and a red 'target' appears in the centre of the screen shoing the direction from where the impact came from.


This would be fine for a game where a player is under attack but I want to use these 'health decrease' volumes regularly along the race track to decrease the health of the player (which is the water level of the vehicle in-game) and a constant red flashing on-screen would suggest to a player that they are doing something wrong. This is not something I want to be happening during the game as it is misleading and frustrating from a player's perspective, even if the game is simply a demonstration. There is no excuse for confusing a player in a game.


The red damage effect is part of the game's Heads-up-Display (HUD) and with the help of some more of the UDK forum members, I was able to find the script that deals with this red damage indication - which is in the UTHUD.uc script file. Seems pretty obvious now, but it still took me a lot of time to figure it out!

By 'commenting out' the body of the DisplayHit function using *// in front of the lines of code (UTScript differs slightly from standard languages such as C++) it becomes a useless piece of script that has no impact on the game. The reason for making a blank function and not getting rid of the entire code is that other seperate Unreal scripts in the UDK refer to the DisplayHit function and deleting it entirely causes compiling errors and game crashes later on.

Here is the result of removing the code when passing through the 'health decrease' water tower:


Once again, quite a bit of effort to see nothing at all. Still, it's what I want, so it's all good!

23 Feb 2010 - First run in the Maxton

It's in the game!

Well, only as an initial test so far. But, after a lot of mistakes and (very) frustrating dead-ends, it is now possible to drive the Maxton Eighty-Eight around in the UDK.


The basic car test done in January laid down most of the foundations for this vehicle and the success of that is down to people like GeoDav and xXxDancexXx on the UDK forums so thanks must once again go to them. The UDK forums are here if any budding Unreal modder is reading this and doesn't know of it. Setting up vehicles in-game is a long winded and frustrating process and i've done it about half a dozen times now. I'm hoping it'll get easier for me, as I have at least one more attempt to get a vehicle in the UDK left to do.

The Maxton Eighty-Eight in UDK with basic texture, next to the UDK's Scorpion (left) and my very basic test vehicle (right)

The suspension/axle bones don't quite work in the way i'd like them to - it seems the axles rotate with the wheels - which is pretty cool in itself - but what i've defined as the 'axle' includes the Maxton's leaf-spring suspension too which means the suspension also rotates while driving. I can see two solutions to this - either adjust the weights on the rig in Maya to 'remove' the suspension from the axle, or see if settings in the vehicle's AnimTree can be adjusted.

I thought something had gone horribly wrong with the model when I tested initially to find that none of the wheels were moving. I checked and double checked the vehicle AnimTree, the naming conventions, the unreal scripts... and found that adjusting the wheelRadius in the 'Wheel' script (vehicles in UDK have a seperate script for wheels) solved the problem. The wheel radius was too big, it seems - and must have been cutting into the floor when the game started. An odd effect and a simple solution, but i'm making a note of it here because I just know i'll forget the remedy if I run into this problem again. Especially when deadlines are looming.


In other Maxton-functionality news, the rig setup rigidly follows my previous attempts to get a car in the UDK, including the naming conventions. I think that unless this causes major problems with core gameplay I will continue to follow this method. I'm not a scripter and trying to overcomplicate things will just cause more problems and a lot of wasted time.


There are some issues with the model too - some of the faces seem inverted on the wheels and undercarriage when the car is in the UDK, looking as if you can see right into them. This might be an issue with Normals on the original model in Maya (which looks fine, incidentally).I will have a look at it and see if I can solve it quickly. It's more of an annoyance than a real stumbling block... I hope.

21 Feb 2010 - More on the Maxton

Well, that didn't take as long as I expected (but don't worry, the UV mapping will more than make up for it) - the Maxton is complete!


Technicaly it's not as the UV maps aren't started yet, plus some minor modifications may be made to get rid of the seam running down the middle of the vehicle in an attempt to shave of a few excess polygons from the model. The lower the poly count the better - I think at the last count the Maxton stood at approximately 9000 polygons (tris) in total, which is a realistic number for a player character in the UDK.

Here are some more pictures of the Maxton Eighty-eight:


The wheels were a bit of a challenge, trying to make something ideal while keeping the poly count down. Various methods were tried based on polygon cylinders in Maya but in the end I practically crafted the wheel from planes and extruded/tweaked it. Not entirely sure if that was the most efficient method but it did give me complete control over how it looked.

Additionally, the shape of the model has been adapted slightly to make it slightly longer. This makes the vehicle look a little more realistic in my opinion.

20 Feb 2010 - A Maxton Eighty-Eight in the workshop

With designs for the player steam car complete, the models had to be built. This is straightforward with the right resource material, and so I produced some orthographic projections of Maxton's steam car to use as references in Maya when modelling in 3D.


I have spent the last two evenings modelling the finished design for the Maxton Muycrosse Eighty-Eight. The '88 is shaping up nicely and is well on the way to completion. Here are some screenshots of the work in progress:


My plan is to build half of the steam car, then duplicate it to create the other side. The design of the Maxton is asymmetrical in places, but these are only small elements that can be adjusted in the final stages of making the model. Hopefully the model will be finished this weekend - and then I will have the wonderful task of UV-mapping such a complex model for textures!

19 Feb 2010 - Maxton enters the steamcar market

As promised, I have finalised the design of the steam car that will be used in my game concept. This is as important as functionality elements of the game as this is what the player will be seeing the most of while playing. It is essentially a player character and will be present on screen at all times during the races.

As this is a key visual element in the game, I wanted to make sure the car was a design I was happy with. Additionally, I decided to incorporate some of the feedback I have had from the tutorial group which led to thinking about how the steam car might work. With this in mind, I produced the following sketch.


This is a very simplistic overview of the engine that I decided to build the rest of the vehicle around. Using the most popular vehicle design (as judged by my peers in University as well as friends and family) I came up with a design that I felt was appropriate for the Steampunk theme as well as being plausable as a form of transport. Some Steampunk fiction is almost as far-fetched as high fantasy but I wanted Igford to have a grounding in reality - I am a big fan of Jule Verne and H.G Wells and the ideas penned by both of these authors often seem perfectly realistic.



The design needed a name and out of nowhere while sitting in traffic, I thought of one: Maxton Muycrosse. Of course, it's not that catchy, but not many automobile manufacturers has short, snappy names in the last decade of the 19th century. The car itself is the Eighty-Eight, named after the year in which the design was conceived. So, finally, the finished steam car... soon I hope to see a Maxton Muycrosse Eighty-Eight driving noisily around the streets of Igford!

14 Feb 2010 - Rich's Rapid Repairs

Another piece of game functionality falls into place - this time it's an important one. Any damage sustained by the car can now be 'fixed' by passing through a 'trigger volume' in UDK. This invisible volume will be placed in-game at a pit stop/water tower (for the steam engine, you see) to enable the player to repair the vehicle.

Here's a visual summary:


These 'water towers' (VERY basic ones for testing purposes only) affect the 'health' of the vehicle. The green tower increases the health of the vehicle by a specified amount as the player drives under it. The red tower damages the vehicle and reduces its health, but will not feature in the finished game - it is just a demonstration of how the vehicle can be affected by in-game trigger volumes.

The red tower's functionality was a result of a 'happy accident' in Kismet enabled me to take away player health and served as the foundation for my actual goal, which was the green tower's health-giving abilities. It will be handy if I want some other object or action to damage the player vehicle though, so it's worth keeping a record of how it's all done.

Once again this was solved with Kismet, inside the UDK. A slight modification on my previous unsuccessful attempt (though that was a good opportunity to learn a few things) gave me the result I wanted, and this is how it looks in Kismet:


I'm not entirely sure of how or why the setup needs to be like this but all I know is that it works, which for now is good enough. Understanding why things are set up this way is invaluable though, especially when trying to work out other functions in Kismet, but the clock is ticking and I need to look at other areas in the project for now.

There's still an incredible amount of work to do on the project including a lot of functionality issues and problem solving but every time something like this is completed, I feel that getting something close to my original idea is possible.

The next big hurdle is implementation of a 'dummy' HUD (that won't work but will serve as a demonstration of what the player will see on screen). More on that when i've made some progress.

13 Feb 2010 - Traffic increasing in central Igford

Here are some more rough designs for the finished Steamcar for the game, drawing influence from real Veteran cars from the 1890s and 1900s.A small steamcar built for speed. This sporty looking model is more streamlined than the others and would be quicker and lighter, but probably not as robust.

This Steamcar is much heavier and would probably be more powerful, but also sluggish and slower. These designs are in aid of me coming up with a single vehicle design even though different classes of vehicles are also being considered, but due to time constraints only one vehicle will be created for the game.

In feedback from the seminar group in University this week it was generally felt that these designs were quite grounded in reality and felt very functional. People's opinions suggested that Steampunk should be a little more bizarre and chaotic with its approach to technology. With this in mind, I aim to develop the ideas and by next week a finished design will be complete.

12 Feb 2010 - The end of the Equine transportation era

In a week, the designs for at least one Steamcar have to be finalised. This is an odd kind of pressure as I like a lot of the early designs but picking one will be difficult. I want to make sure that the design that is chosen is one I really like, but also one that looks semi-plausable and functional at the same time.

Here's an example of a rough proposal I sketched and coloured last night:
This vehicle, as yet unnamed, is not the first design for the Igford steamcars - I came up with a few in the initial stages of the project. Since then I have read a lot more Steampunk fiction and visited the Steampunk exhibition in Oxford and I feel that now I have a bit more of an insight into what kind of visual elements make up a 'typical' steampunk setting (though having said that, Steampunk is incredibly varied in both theme and visuals and depends wholly on the author/producer rather than a specified set of rules).

I'm going to produce more design proposals over the weekend and hopefully by this time next week, Igford's first steamcar will be ready for production!

10 Feb 2010 - Get to the Vehicle!

Kismet doesn't seem too bad. A method of implementation can't be user-unfriendly when you accidentally accomplish what you set out to do.

Well okay, it was more me experimenting with certain nodes (if that's what they're actually called) and using a little logic and common sense, but I didn't expect a result. Still, i'm certainly not complaining as it means one more thing can be ticked off the 'to do' list. Which makes me very happy.

Today I managed to get the player to appear in a vehicle when the level starts up (as opposed to spawining nearby and having to get in manually). As this is supposed to be a racing game, being IN the car to begin with is kinda important - not just for presentation purposes, but also because you'll always get at least one player running off and deliberately not doing what you want them to do.

So, this is how starting a UDK level inside a vehicle looks in Kismet (Click on the image for a larger view):


New nodes are created by right-clicking in the empty workspace and selecting from a list of options. 'Level Loaded' is an event (New event>Level Loaded). 'Enter Vehicle' is an action (New Action>Pawn>Enter Vehicle) and the Player Variable and Object Variables are the inputs to the action (variables) - the things that are affected by the event/action.

The Player is the target, and the Object Variable is the vehicle the player will appear inside. (this is placed by selecting the Vehicle Factory in the Editor, right clicking, and then selecting 'New Object Var Using [name of whatever is selected here]'. I'm not providing a tutorial here, but thought i'd give a brief explaination. I'll only forget how to do it myself if I don't leave a note like this on the blog.

Kismet itself is not difficult to use - it's understanding the different nodes within it, what they do and how to set them up to work in game. I'm still new to this (I've been using it for under 24 hours at the time of writing) but i'm hoping the guys in the UDK community will be as helpful as they usually are. Kismet will also be used for other aspects of this game and they're a little more complex than this one. It's ironic really, I thought it would be the other way around.

* * * * * *

In other news on the project, I attempted to create a title screen for my Mod/game, but it crashes UDK on startup. Interestingly, it only does this when a custom vehicle is included in the level (but trying the same level with the UDK 'Scorpion' vehicle causes no problems).

This means the Mod files are set up correctly, but there is an issue with the custom vehicle script. Something I hoped would have been sorted by now, but that's the way it is sometimes, I suppose.

9 Feb 2010 - A breakthrough at breakfast!

I seem to spend most of my time in the Programming and Unrealscript section of the UDK forums these days - though for good reason. Another breakthrough in the game development while I was getting ready for University, and yet another of those tiny details that are so important.

The vehicle has been renamed when the player enters it! See for yourself:


Admittedly, this is only relevant if the player has to get into the vehicle in the first place (as opposed to starting in the vehicle when they enter the level - another thing I want to look at) but it's good to know these things, right? A similar method would be employed to rename in-game weapons, and i'm sure i'll want to do that in future.

So, how is this done? It's really simple, you just need to know where to look - and I didn't - but those kind souls on the UDK forums helped out... again.

To rename a vehicle I had to alter the string for the following code in UTGameContent.int found in UTGame/Localization/INT:

[UTVWeap_ScorpionTurret]
ItemName="Custom Name For Vehicle Goes Here"


Also credit should go out to GeoDav again because thought he hasn't dealt with my issue directly, a similar post he made some time ago indicated that I have to change the vehicle's WEAPON, not the Vehicle name itself.

That's put me in a much better mood today.

8 Feb 2010 - Looking at Pawn

A week ago I experienced some problems with the camera view in-game. This simple issue was easy to resolve - as I suspected it would be - but required a little help from the always helpful UDK community. Some editing of the UTPawn.uc file was required that took about 15 seconds to do.

Basically, the Mod was set up using Toltec Studios' The Ball' tutorial, which can be found here: http://www.toltecstudios.com/theball/tutorialudk.htm

The UTPawn.uc Mod file included script for a camera that I didn't notice - not being a scripter, I wasn't familiar with the code and I wasn't looking for it. A little bit of feedback on the UDK forums gave me a different perspective on the problem. I 'commented out' parts of the code to make it inactive, which are shown below in green (click on image for larger version):


The highlighted text specifies a third-person camera. Disabling this code in UTPawn.uc returns the player's view to the more traditional first person view in Unreal Tournament 3. With the weapons disabled and the central crosshair also removed, the screen is beginning to look a lot less cluttered.


The result of my efforts. I never thought i'd be so happy to see nothing! Next big topic is editing the Heads-Up Display itself!

7 Feb 2010 - Show me your Assets!

Time this week has been mostly spent on a seperate project, though I still feel a little tired out after the Final Year Dissertation in University. Having said that, I have spent some time modelling and texturing.

Here are the assets I managed to model and texture on Friday and Saturday of this week - a victorial lamp-post, a generic barrel and some haybales.

The lamp is mostly for in-game aesthetics to add a more 19th century feel to the world in which the game is set (with the use of alpha maps to make the glass panes look transparent - these are not visible in the Maya viewport in which this screenshot was captured) .

The barrels and haybales serve a more practical purpose - these will be arranged as 'barriers' on certain streets and pathways to prevent a player venturing into areas where they are not supposed to be. Though these are all relatively low-poly models, the haybale is perhaps a little over complicated - at 200 'tris' it seems a little excessive but this was an attempt to make it look a little less blocky and generic.

I'm getting much more efficient at 3D modelling and UV mapping. Models like these are good practice for me as I will have to make a steam car model very soon and as the player will be using this vehicle throughout in-game, it must be produced to a professional standard.

1 Feb 2010 - Drop Your Weapons!

Today I set out to remove the default weapons in my game, and look briefly at HUD (Heads-Up Display) editing in the Unreal Development Kit.

A way to start the game without player weapons can be specified in the UDK editor, which is a refreshing change from all the script i've been trawling through over the last few weeks. To disable weapons, you must go to View > World Properties > World Info and check the box marked 'no default inventory for Player' (highlighted in green below).


This removes the weapon on startup when playing the level but in third-person view the Impact Hammer appears 'under' the player through the floor when game testing for some reason. This led me on to an unexpected problem - third person view is the default setting in my mod and I need the game to be first person only, otherwise a custom character will be required for aesthetics and that would require a substantial amount of time to create - time I do not have with the deadline for the game demo being in May of this year.

The camera view is affected by the custom MyPlayerController.uc file that is created when setting up a Mod in UDK. There is no information in the script in this file to define the camera position and so my conclusion is there must be a 'default' setting in which the UDK is referring to.

The remedy to the issue must be that I need to explicitly specify the camera view in the custom game script (MyPlayerController.uc).



However, the crosshair can be removed with a small section of Unreal Script added to this file (highlighted in green above) so I have made some progress - just not as much as i'd hoped for today.

On the topic of HUD editing, I found no hard-and-fast tutorials so far but I will continue my search for this subject. The problems encountered with the camera view dominated today's work and slowed me down somewhat, as well as tiring me out mentally. I am not a scripter and looking at code I don't understand for hours with no progress does knock my enthusiasm somewhat.

I will have to resort to harassing the UDK community again and hope some kind souls will point me in the right direction.