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

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 talk 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!

NPC Character Study: Half Life 2’s The Gman

When the player starts a new game in Half Life 2, the first thing they see is this:

This is the Gman, an enigmatic figure that follows the player through the series. He is not overly malicious or obviously supportive, but does on several occasions trap the player in serious danger as many times as he is seen simply observing from an unreachable area.

"While the codename 'Gman' slipped into common use, it remains merely a codename." [1]

The character of the Gman alludes to the Men in Black that feature in various UFO conspiracy theories. Their attire, strange behaviour and unflappable calmness in the face of danger is very similar to those of the Gman, and his ‘name’ is merely a codename, taken from the slang “G-Man” which is short for Government Man.

Unlike the carefully designed and animated rebels in Half Life 2 (HL2), the Gman was designed to deliberately invoke the Uncanny Valley effect.

The most obvious aspect of this is his voice. It is rasping and slow, but commanding. As he speaks, he places unusual emphasis on certain syllables, stutters in the manner of a broken record, elongates S sounds, pauses in odd places and has a constant, low-key grinding sound just out of hearing.

“He behaves as though he's had to learn 'human' behaviour out of books and films.” [2]

His posture and movements are rigid, precise and robotic, a huge contrast to the smooth movements of the other humanoid characters. He never runs, even if danger is imminent, and walks with all the grace of a wind-up toy. His gestures, such as straightening his tie or brushing off his lapels, are unconvincingly stiff and oddly routine, as if he had been practising the movement beforehand rather than doing it without thinking.

Doug Wood, the animator of the Gman, states that "I wanted the player to never quite know what side the G-Man was on. I would have him express an apologetic look toward Freeman as he 'regretted' to put Dr. Freeman in this situation, but then give a slight smirk or smile at the end to keep you guessing about his sincerity."[1]

His face is uncommonly gaunt and pallid when compared to other HL2 characters. His facial expressions do not match his tone of voice or what he is saying, and some of his facial muscles will twitch and pull in odd directions, and sometimes his lips won’t synch up with his voice.

Heightening the Gman’s strange speech and mannerisms is that he has only directly communicated to the player during abstract sequences, his face being contrasted with the black void, images of important places or characters, and hints of events to come.



The Gman appears to have powers of teleportation; on many occasions he has appeared in unreachable locations, or seen walking into what is evidently a dead end, disappearing without a trace. The Gman uses this ability to keep track of Freeman, to make sure that things are following his plans, with the side effect of heightening paranoia in the player whenever they see him watching. At other times he has moved Gordon Freeman from the real world to a featureless black void. The reason for this is not entirely clear, but it appears that the Gman is “storing” Freeman for the purposes of having a skilled pawn to unleash when he needs things doing.

Gman also occasionally hints at his “employers,” suggesting that he is working for a higher power than himself, though the reason is unexplained. These employers, among other things, have been theorised as the source of the Gman’s powers, some benevolent organisation working against the Combine (the main enemies in the Half Life series), or a group of Gmen.

At one point, Dr Wallace Breen hints that there is more than one of these employers, in competition for the Gman’s services, and by extent the player’s:

"Did you realize your contract was open to the highest bidder?" – Dr. Wallace Breen, during the Our Benefactors chapter [3]

Dr. Breen also seems to know about the time Dr. Freeman spent in the black void:

"I have good reason to believe that in the intervening years, he was in a state that precluded further development of covert skills." – Dr. Wallace Breen, during the Nova Prospekt chapter [3]

The Gman is always viewed at a distance, as he is seemingly keen to stay out of the thick of things, relying on pawns like Freeman to do his dirty work, taking a direct hand only when Freeman’s mission is complete and he needs to return the doctor to the black void again. However, in the HL2 sequential Episodes the Gman is forced to take a more active role, as the alien Vortigaunts rescue Freeman from the black void in Episode 1.

“We’ll see...about that.” The Gman to the player, Half Life 2: Episode 1 opening cutscene. [4]

During the opening cutscene of Episode 1, the Vortigaunts can be seen holding back the Gman with their own psychic powers as a pair of them rescue Gordon Freeman. This is the first time the Gman has shown emotions; at first amusement at the Vortigaunts efforts and then annoyance when he realises they’re succeeding against him. This is the only time the Gman is seen during Episode one, representing that Freeman has escaped his surveillance.

The Gman doesn’t catch up with the player until partway through Episode 2, waiting until the Vortigaunts are distracted so he can communicate with Freeman in another abstract sequence. He also places a hypnotic suggestion in Freeman’s companion Alyx Vance. During this exchange he comes across as apologetic in the most sarcastic manner possible, still viewing Freeman and other humans as tools in his master plan, and mocks Freeman for his method of dealing with problems. He also drops a few hints about his plans for Freeman and Alyx.

“Doctor Freeemaaan. I realize this moment may not be the most convenient for a 'heart-to-heart', but I had to wait until your... 'friends' were otherwise occupied. Hm. There was a time they cared nothing for Miss Vance... When their only experience of humanity was a crowbar coming at them down a steel corridor. When I plucked her from Black Mesa, I acted in the face of objections that she was a mere child and of no practical use to anyone. I have learned to ignore such naysayers when... quelling them... was out of the question. Still, I am not one to squander my investments... and I remain confident she was worth far more than the initial... appraisal. That's why I must now extract from you some small repayment owed for your own survival. See her safely to White Forest, Doctor Freeman. I wish I could do more than keep an eye on you, but I have agreed to abide by certain... restrictions. Mmm.” The Gman, during the This Vortal Coil chapter of HL2: Episode 2 [5]



The Gman has had a widespread and lasting effect on the Half Life community due to his mysterious nature. Several websites exist, dedicated to cataloguing his appearances and quotes, and figuring out exactly who or what he and his goals are.

The Gman is a highly sinister form of the Trickster character archetype. He uses his powers to upset the status quo and disrupt the lives of others, for his own goals and purposes rather than just amusement. He also fills the role of the Mentor archetype, but barely, through vague hints rather than direct help.

The character is also used to create a sense of paranoia in players, using his abilities in unnerving ways to make the player question just what his schemes are. This in turn creates a feeling of always being watched, and many players have said that the brief glimpses of him gives them chills, only for him to turn a corner and disappear before they catch up and have their questions answered.

Ultimately, the Gman represents an unreachable figure because of where he appears in the game worlds and his unexplained character, leading him to be tirelessly researched and sought after. Valve, the creators of Half Life, know and exploit this curiosity, leaving breadcrumbs to the Gman’s true identity in hidden spots of their games, found only by careful searching (the so called "Headcrab Barbeque" is the most well known).

However, the Gman is used sparingly. He is the only character who behaves in this way, and he only appears once or twice in each of Half Life’s chapters (most of which are an hour or more long). To have more than one character act like, or to have him appear every ten minutes, would lessen his impact. Careful level-planning, character design and timing has kept the mystery of the Gman alive, the natural curiosity of video gamers fuelling his continued success as a character.

Examples of the Gman’s speech patterns, facial expressions and general oddness can be seen here and here.

[1] Valve (2004) Half Life 2: Raising the Bar. Prima Games Publishing
[2] http://tvtropes.org/pmwiki/pmwiki.php/Main/UncannyValley
[3] Half Life 2, Valve, 2004
[4] Half Life 2: Episode 1, Valve, 2006
[5] Half Life 2: Episode 2, Valve, 2007
All pictures screen-captured from Half Life 2 and HL2: Episode 2.

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!

Week 1 Overview

During Week 1 I researched popular video game antagonist NPCs, and how their characterisation aids player immersion and makes the game experience memorable. I paid careful note to which antagonists stuck out on player's minds. This research will allow me to pinpoint the traits which make antagonists, and by extent other NPCs, believeable characters. A write-up of my thoughts is available on my personal blog.

Week 1 - The Antagonist

The most common and important NPC in most videogames is the antagonist; the character who directly opposes the player’s progress through the game. It is said that “a hero is only as good as his enemies” and this is no less true for videogames. The impact the antagonists have on players in an emotional sense, how well they are implemented gameplay wise and their characterisation all help to make a game memorable, immersing and challenging.

As a narrative device, a game’s enemies can be the most varied in design and execution, ranging from tools to teach the player the combat mechanics of the game, obstacles the player must overcome to succeed, or the main reason the storyline, and by extent the game itself, is happening in the first place.

"Almost all single-player games need an adversary for the player to strive against; otherwise there is no solid goal for the player to work for. Enemies tie the plot and missions together; without the threat of Saren in Mass Effect, the player would just be randomly exploring planets. They give the player something to work against; Resident Evil and numerous other survival horror games would be rendered much less effective without the looming menace of monsters hiding behind every corner. Most of all, the enemies give the player a reason behind the things they’re doing. How would The Legend of Zelda work if it didn’t have Ganondorf, or Metal Gear Solid without Liquid Snake? Even a passive, non-action game like Harvest Moon has a rival farmer the player competes with."[1]

The characterisation of the antagonist in videogames has grown more important over the years. Take, for example, Bowser of the Super Mario series. Originally he was created to give a reason to all the jumping around the player would be doing; the player has to save the princess from him, but at the bottom level Bowser is just another obstacle between the player and success. Later games in the series may have fleshed out Bowser’s character and motivations, but he still remains as an excuse for the gameplay, he is The Final Boss at the End of the Game, and nothing more.

On the other hand is Glados, from Valve’s 2007 game Portal, a first-person puzzle/action game. Glados is a sentient, malevolent AI program, and as such her interation with the player is very limited on a visual basis. Throughout the entire game, Glados communicates to the player via an intercom system, with tutorials, hints and commands woven into a mad babble, though not so much as to be incomprehensible to the player. The AI’s entire personality is rendered in the auditory medium, making full use of writing, tone of voice and added special effects to create a memorable character. Unlike Bowser, Glados was created as part of the game’s experience, she is always there, what she says to the player is tied to the design of the levels, adding weight to her plans and the player’s predicament. Glados isn’t just the Final Boss; she is the Nemesis, the direct cause for all the player’s problems, hounding the player until the very end. It is little wonder that Glados and by extent Portal is so popular and well known.

A compelling antagonist can make or break the success of a game, note the popularity of Glados, and other main enemies such as Shodan from System Shock or Andrew Ryan of Bioshock, so it is important to research how different games use their antagonist NPCs and other secondary characters.

[1] Adam Parker, Villains and Monsters, 2009

To view the Team Fable project blog, click here.

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.