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.