Week 3 Overview

This week I analysed the Art of Game Characters by Leo Hartas, which provided insight into the creation of NPCs, specifically their visual appearance and how that affects how the player feels about the character. It can be read here.

Using research from this book, I wrote an article exploring the methods developers use to characterise their NPCs visually, with examples from a wild range of games. It can be read here.

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.

Week 3 - NPCs and Visual Information - Part 1

This week, I researched the methods developers use to make NPC characters stand out and memorable. Due to the number of images this article has and the image per post limit, it can be downloaded here.

Week 2 Overview

During Week 2 I wrote a study of the Half Life character the Gman, which gave me a good base to work from in regards to character appearance and how that affects a player's perception of an NPC. The complete Character Study can be read here.

Source Analysis - The Art of Game Characters by Leo Hartas

Our project goal is to investigate and research what makes a compelling NPC, and for this we need a variety of NPC characters that can be tested in our final product. It is therefore important to pin down the most vital parts of making a compelling NPC, making it easy for us to design a character that is easy to implement and at the same time viable for our tests.

The Art of Game Characters by Leo Hartas is a good starting place to research how players react to different NPCs, mostly on the visual medium. It breaks down the many different types of NPCs into broad sections based on their appearance, and goes into detail how these characters were designed, including the reasons and ideas behind the designs, and how they were used in the finished games, along the impact they had on the players., with examples from many different genres of videogame.

Perhaps the most useful sections of the book are the interviews Leo Hartas conducts with various game developers, character designers and concept artists at the end of each chapter. His interview with Ajibayo Akinsiku, Visual Director for Evil Genius (2004, Elixir Studios) has some good points about characters in different media and the importance of thorough design.

“Characters in games and other media differ absolutely no way whatever. There are mechanical issues but these issues cut right across the board. A comic-book character will translate differently in movies or literature because each medium’s capacity allows for unique traits, but the fundamental principles are universal, fundamentals never change! One should not confuse superficial trait for fundamental rule.” – Ajibayo Akinsiku [1]

“The start of a good concept process is always the brief. The better the brief the more chances of a successful design.” – Ajibayo Akinsiku [1]

Another useful part is a short section by Sandy Spangler (Humongous Entertainment) called Game Character Creation.

“While ugly graphics and lousy gameplay cannot be salvaged by interesting characters, the ‘creative layer’ of a game (story, setting, subject and style) can be the factor that determines whether or not a potential player picks up your title off a shelf.” - Sandy Spangler [1]

“What does the player need to know about this character in order to understand the game? Is this a character they should fight? Befriend? Follow? Keep in mind that unexpected outcomes can also make for interesting gameplay; a terrifying monster that saves your life is much more memorable than one you just kill.” - Sand Spangler [1]

Sandy lays out a series of questions that a character design should answer for them to be successful, stating that it is important to take into account all the issues that are common to game characters. Questions like “what purpose does this character fulfil?” “What do the game mechanics require of the character?” and “What does the player need to know about this character?” are vital to the character design process, and if we are to design a successful NPC I feel it would be a good idea to come up with a list of similar questions we must answer with your character design.

Another interview with Masami Kochi (Sony London Studio) goes into detail about using character design to appeal to a particular demographic (like male teenagers, for example) and notes that people from the same age group will react to a character differently depending on their country of upbringing.

“I tried to appeal to teenagers [with the Eyetoy: Play characters] but it’s quite difficult for me as European teenagers are more mature than Japanese ones!” – Masami Kochi [1]

“When designing a character, I think about their look and personality together. Dex [a character from Eyetoy: Play] likes football, so he’ll wear a tracksuit and football trainers, and he is sporty and athletic. I found that teenage guys who also like football made a connection with him just because they saw what he was wearing, without knowing football was Dex’s hobby!” – Masami Kochi [1]

The Art of Game Characters by Leo Hartas is a good source to look into when it comes to designing the NPCs we will use for our testing product. While some sections of the book are presented in an informal and basic way, the interviews with designers and developers provide a first-hand insight into creating believable, effective NPCs.

[1] The Art of Game Characters, Leo Hartas, The Ilex Press, 2005