18 May 2010 - Shop 'til you drop

With time becoming very much the predominant factor in the project and with so much to do, new methods were employed to 'speed up' production of the in-game assets.

I came up with a 'modular' building idea where each of the shops could be built exactly the same scale and in sections, so I could re-use the assets in different combinations - giving the impression that each one was a seperate, individual model.

How some of the 'basic' models look in Maya - many variations from a few assets

Of course, the first assets took as much time as any other building made for the project - but re-using the pieces (which were then ALREADY textured) meant that variations were almost made on a whim. As a result, the empty third section of the course that was worrying me somewhat was populated in a matter of days... which is a fraction of the time it took to place objects in the other areas.

Every building in shot has been built with the same template (with texture variations in places)

Maximum effect - minimum work. The way it has to work with looming deadlines.

If i'd thought of this method from the start I might have been able to produce even more buildings, but that's how it is - live and learn. I shall definately use this method in future if I have to make a large number of buildings in 3D again!

11 May 2010 - Are you sure you want to quit?

Just an overview of the last few days as I have a report to write by next Monday. I've resolved a few issues and had to come to some compromises.

First, the compromises - I don't think i'll have time to make the Church/Chapel in-game. This is a blow to my vision of making the game level appear as a convincing pseudo-Victorian community. The vacant space left for it in Lumsden has been filled with houses for now, with the idea that if I have time, i'll come back to it - but I won't have that luxury so i'm bringing in a contingency.

Also, a big compromise on gameplay - the camera view can't be 'fixed' to the vehicle using the methods i've researched / had reccomended to me. I find it incredibly frustrating that there's a distinct lack of support for Vehicles in UDK and due to this my entire project schedule has suffered. It would be possible to fix a camera using a code/script-heavy method i'm sure, but this was never the intention and i'll have to just playtest without it and see how people get on. At least the 360 Gamepad is configured, which makes playing the game much easier.

Now, the things i've achieved:

I've finally managed to work out how to replace the loading screens in game. This has such an impact on the 'feel' of the game, as before these screens were wholly inappropriate for the project. This forum thread helped provide some info and the necessary tools to change the loading screen.

After some tests with still images I decided to make a simple sepia-style movie (5 seconds of looping effects) which have really enhanced the front end of the game. Alas, I can't change the font style, which is infuriating, and yet another aspect of game modification that seems to require an advanced knowledge of coding, so i'll have to compromise here too. I have located where to change the loading screen hints though, and have replaced the random messages with suitable ones for this project.

Before and after - the in-game 'loading' screen which is visible to the player while the level is loading for the first time. Unfortunately I haven't got the time or expertise to replace the in-game font set

I also used the sepia effect of my clip to make a new Unreal logo screen. I'm not sure if this is against the rules (for a fully developed professional and publically available game at least) but I did enjoy adapting it and it looks great when the game starts up. It's just a shame I can only show still images here.

The custom Unreal Logo screen - Original (left) and edited (right)

In other development news, i'm also placing blocking volumes and trigger volumes in the level. Blocking volumes will keep the player on track, stopping them from leaving the playable area, and the trigger volumes are rigged up to decrease player health on contact - this is to simulate the 'water loss' feature of the game while driving.

Volumes (hollow green and purple cubes) in the Editor - these are invisible in the playable version of the game

And, changing the subject once again, the final installment of work this week - in order to give the player a 'get out option', should the game break during gameplay (and it will, no matter how extensively I test it - someone will always find a way to get stranded) I have mapped a console command to the controller with the help of Craig Higley, co-creator of the first Igford game (Igford-Under-Siege, 2009) .

Craig explained that in-game console commands are mapped to the UTInput.ini file in the same way that I configured the buttons for the 360 gamepad. It's just a case of adding another line of script that tells the engine what action to perform, then pasting this action into the relevant button code. Difficult to explain but simple to do in practice, which is nice.


This was successfully implemented and now I can tell players if they get stuck, all they have to do is press the 'H' key on the keyboard or the 'Y' button on the gamepad and they'll restart the level with a brand new car, ready to break the game again.

So much for a quick update - I'm off to start my 4000 word report now - which I hope to finish as soon as possible in order to get back to level construction!

9 May 2010 - Replay Value

Another big issue has been solved with a straightforward solution - which is more than welcome at this late stage of the project.

There are ways for the player to destroy the vehicle during the game. Should the player end up destroying their car through lack of water or falling off a hazard, they need to be put back to the start so they can try again. I got this this to work when the level started up but if the player destroyed their vehicle in-game, it would place the player at the start of the level as desired... but out of the car. This breaks the gameplay because at no point in-game should the player be able to leave the vehicle.

I think I overcomplicated the issue by assuming it was something code related and fully failed to check something that I have used before that was right under my nose. I suspected Kismet would have the answer, but I overlooked something so basic I can't believe it's taken this long to try out.

Every Action / Event in Kismet has a set of properties. These properties can be adjusted to alter the performance of the event being defined. So, the player is placed in the car, but this only works once. The solution? Look for the Max Trigger Count of the event, and change the value to zero.

If the value is 1, the Event will happen once, if it is set to 2, the event will happen twice, and so forth. But if it is set to zero, it will happen an infinate number of times, allowing the player to reappear in the car after destroying themselves for as long as they keep playing the game. This is EXACTLY how passing under the water towers and getting them to 'fill up' the car works.

Setting the Max Trigger Count of this Event/Action to zero was the solution to the problem

I can see how this could be used and adapted to create a 'lives' system limiting the player to a certain number of attempts to play the game. I have no plans to implement a lives system but it is a thought - especially if I want people to be able to play the game at the end of year show.

Once the player was able to respawn into a vehicle, the only thing left was to tell the game to instantly create a new car at the start of the level for the player to be placed into in the event that they destroy themselves. By default there is a delay for this in the UDK of about 30 seconds. As I don't want the player hanging around and waiting, I had to find where to change this.

Changing vehicle respawn time in UTVehicle.uc - Default value is 30

Changing the above float value in UTVehicle.uc speeds up the respawn time. I tried setting this to a value lower than 1.0 so that the car is replaced instantly, but this seems to break the game with no car respawning at all. So, through trial and error, I looked for the lowest value that doesn't do this. 1.5 seems to work and although it is not instant, it seems to give the desired effect. I have been testing this by destroying the car and pressing a button to 'reset' the game as quick as I can but the car always respawns before I reset the player to the start, which is good.

So, another functionality issue has been resolved. If I can find out how to 'fix' the camers to the vehicle i'll have a game that can realistically be played without having to explaint o people how to 'get around' gameplay issues I haven't addressed - which again, for the end of year show, would be fantastic.

6 May 2010 - Heads Up!

I'm well on the way to finishing the final in-game Heads-Up Display (HUD). This is a simple overlay that covers the 'real' HUD. Feedback from last term suggested that the work in progress HUD looked a little lacklustre, so i've dedicated a whole day to making this one work (that wasn't intentional, that's how long it's taken).

The new HUD - 80% complete, some details on the watch need to be finished

In the 'full' game (which I am not producing for the project) the pocket watch on the right would be used for time-trials

I was considering modelling the HUD in 3D, texturing it, and rendering an image. I'm glad I didn't - as well as it taking much longer (unneccessary UV mapping, etc) and wouldn't be very personal at the end of it - also, considering I want to specialise in 2D art after the course is over, i'd be doing myself an injustice by resorting to modelling to produce a creative piece of work.

5 May 2010 - Can you handle it?

Just a quick update - no doubt i'll extend this blog post later on when i've made more progress.

I've looked briefly at the handling of the car today - and found three values that can affect the performance of the vehicle in the UDK code. Thanks to the UDK forum and the Unreal Wiki I got some much-needed explainations of some of the code and this enabled me to locate the relevant sections that deal with vehicle handling.

The car handles a little too well with it's default game settings - it is possible to steer around the corners at full speed, which eliminates the need of a brake. That's not very good for a racing game, and any game mastery is irrelevant if you can drive through the course perfectly on the first attempt.

MaxBrakeTorque : This affects how sudden braking is when the brakes are applied in-game.

EngineBrakeFactor : This affects how long it takes for the car to come to a stop if all buttons are untouched - it should roll for a while before stopping, and this is the value that controls that effect.

SpeedBasedTurnDamping : This affects the handling while travelling at speed. A higher value here means turning is difficult at higher speeds - perfect for encouraging the player to use the brake. This has a significant effect on gameplay and without testing and tweaking could lead to a lot of player frustration, so I need to get some opinions on this.

Of course, thorough testing should be done with other people anyway to see what the general opinion is on the gameplay. I'll try to do that in the next week or so in Uni (and hopefully after I can get the camera to stay fixed behind the vehicle - if it's possible).

Right now i'll get on with the HUD design - and leave the volumes until tomorrow evening.

4 May 2010 - Industry booming, emissions soaring

I've added the rest of the particle effects in-game for the smoke effects on the factory chimneys. I also added some smoke to some of the chimneys of the houses but I may remove them - as it's barely noticable and will be a drain on resources.

Here's some screenshots of how Igford looks, as of tonight:

Crestwell's Canned Consumables - as viewed from the Lumsden Road

Lumsden Road, looking north past Crestwell's and part of the old Threshersen Automata works

Inside Crestwell's Cannery, Lumsden

An Ebrill airship over Crestwell's Cannery and the Auchterlony Viaduct, Upper Igford Valley

I also looked at emissive textures on the lamp-posts but this must be a massive drain on processing power as the PC ran out of memory while compiling. I've had to remove these effects again, which is frustrating but it looks like i'll have to compromise on this matter.

Tomorrow I plan to put all the trigger volumes in place so that the water level aspect of the game is fully operational. After that I will look at a final HUD design, which I hope to finish by Friday in time for my project seminar meeting.

3 May 2010 - Let there be (proper) Light

Today I decided to get on with a glaring problem that I knew would become soul-destroying and just eat up time while being resolved - I hate it when i'm right. Today I had to re-import EVERY section of track after deleting unneccesary faces and creatintg a lightmap for each section.

Why?

Here's why - the screenshots show what the problem was - huge seams/lines across the track which were impossible to ignore. Fortunately, advice from the UDK forums (as usual) offered solutions, though admittedly I did work it out on my own when waiting for a response. Here's a 'before' and 'after' example of the track lighting issues:

Lighting issues created lines across the track sections and hurt the game's visuals badly - they're finally gone after a whole day of mind-numbing clicking and exporting

This involved creating a second UV set on each section of road, using the automatic mapping to ensure that the UVs didn't overlap, and re-importing into the UDK. I had much more defined shadows initially but increasing the lightmap resolution caused UDK to crash and made the size of the level package enormous. I've had to scale them back down as a compromise which is a shame, but better to have a working level with general shadows than a broken level that won't start up or save.

I also intended to get the particle systems in-game tonight - so far i've got a water effect for the water towers in-game (which is the most important one).

Who left that tap running?

I could do with a generic smoke particle for chimneys - this will probably be a modification of the steam car's smoke, but larger and slower.

I also finished the Maxton steamcar last night (after a last-minute catastrophe that almost looked like the car model was broken) - here's how it looks!

The 1890 Maxton-Muycrosse Eighty Eight - finished at last!

Tomorrow I have duties to attend to in University but I hope to get both the water 'power up' volumes and invisible health decrease volumes in the level by Tuesday night.

2 May 2010 - Your Maxton's on Fire

I was convinced it couldn't be done - but positive procrastination (sick and tired of texturing every day) combined with the functionality breakthrough with the gamepad yesterday pushed me into looking at a very important visual aspect - emissions from the steam vehicle. It's hardly a Steampunk game with no steam, is it?

A carbon footprint belonging to a size 12 Doc Marten boot - The Maxton is no longer shy when it comes to spewing fumes into the skies above

Anyway, the advice given to me on the forums (essentially, "look at the code that comes with the game") proved fruitless in March when I attempted this before - though after a bit of thought I decided I was looking in the wrong place. I looked at the weapon files (as weapons have a 'muzzle flash' that is location-specific - as in, it has to come from a particular place on the model) and they might as well have been written in Egyptian Hieroglyphs for all the good that did me. Then I looked at the Unreal Tournament 3 files - because the Hellbender truck that comes with that version of the game engine has an exhaust stack which is essentially what I want. I managed to find a piece of code that linked to a particle effect in the varios game packages, and using my tried and tested copy and paste skills, I moved the relevant code into the Maxton's content file and adjusted the paths and filenames to link to my own smoke particle emittter (which I created from scratch, specifically for this purpose, following this tutorial).

The three lines of code that have been added to the Maxton's file with the relevant paths - this was mainly logical thinking and linking to directories than actual coding

The material set-up in the tutorial is much more complex than my usual materials

To get the particle emitter to produce smoke or steam from the relevant sections on the vehicle, additional bones had to be made on the vehicle rig in Maya and the Maxton had to be re-imported into UDK - which i'm doing a lot recently anyway with the texture testing.

Additional bones in the Maxton rig for the steam/smoke emitters

These bones formed the foundation for adding 'sockets' in UDK - in much the same way as custom weapons use them - and the sockets are what the code needs to tell the game engine where to produce the smoke from my emitters. So, in that respect, I was on the right track with looking at weapons but I had to make a massive detour to finally arrive at my destination. On the other hand, I worked this out myself, which is really something. It's a much bigger sense of achievement than being told what I have to do (not that I mind being told what to do, because 9 times out of 10 it's quicker).

Creating and positioning sockets in the UDK finally allowed me to make the Maxton a lot less environmentally friendly

I'm really happy that i've made this breakthrough, another that just seemed to happen after I gave up on it weeks ago. I'm sure i'll have to do more tweaking to get it looking a little better (time allowing) but at least now that chimney doesn't just look like an uneccessary decoration.

Player view with the smoke in action - testing will indicate if the smoke affects gameplay and visibility

A steam engine it may be, but it needs no rails.

1 May 2010 - More Maxton

Just some additional progress renders of the Maxton. This should be completed by tomorrow with any luck.

1 May 2010 - Back in control

Something just fell into place today - with a financial contribution and some help from the UDK forums. The control system is now customised, in a crude fashion, to allow a player to use an XBox 360 Gamepad with the game, and to play it in a similar fashion to a 'real' racing game.

This is a big deal for me. It's a REALLY big deal.

Interaction is everything. If the player can't interact with the game properly, it might as well be a rendered screenshot or an animated sequence. Okay, so a steering wheel would be far more immersive but a game pad almost makes it into a game for me. A game lacking in gameplay elements maybe, but to be able to drive around my project work using a similar control system to a game like Forza Motorsport 3 is such an amazing feeling.

A 360 Pad for Windows (not a standard 360 console pad) was required because it needs to be installed on the PC - and fortunately, the UDK is already set up to fully support the gamepad. The controls needed to be changed for it to behave like a typical current-gen racing game which looked to be a complex coding job. Asking on the UDK forums seemed to confirm that notion, but it was far simpler than I thought. In fact, it was a copy and paste job - and when tested, it worked wonderfully. It's all in one file - UTInput.ini:

Three commands were changed to give the control system I wanted

The Left and Right trigger buttons on a 360 gamepad are 'mapped' to firing weapons by default in the UDK. I looked for the lines of script that were responsible for player movement (which are the W and S keys on the PC keyboard) , copied and pasted those commands over the Trigger Button commands. A quick test in-game proved that this was all that was necessary to sort the control system out - taking up just 5 minutes of my time! The commands highlighted in green (above) are the ones that were changed in order to get this to work.

An additional bonus to this is that up to now, the car still had a 'default' weapon from the UDK that a player could fire in-game, which wasn't something I wanted. By replacing the fire button with an accelerator function, i've solved both the movement and the weapon issue in one go. While I was at it, I also disabled the ability to get in and out of the car, as I don't want players to be able to move around on foot. By changing the command to a nonsensical one (highlighted in red, above) the button is disabled and made useless. No longer do I have to worry about a player accidentally jumping out of the car in-game!

So, all in all, a very satisfying day so far. I'm backing everything up before something bad happens!

In other work-related news, the Maxton itself is nearing completion - which is what i've spent most of my time on this week. Admittedly I wish i'd done this a LONG time ago, because quite frankly I could have, but it's getting done at least. Using multiple materials has definately enabled the car to look a lot better texture-wise. I decided to start with the read textures of the engine and chassis - because they are what the player will see most of, and I didn't want to have to rush them in case time was short (well, it ALWAYS is, but you know what I mean).

I can possibly have some semi-transparent glass for the windows too - which won't be seen much in-game but it'll look much better on the still images of the steamcar. All that's left to do is the cab, brasswork and windows and the Maxton will finally be complete!

If this is what you see while operating the Maxton-Muycrosse Steamcar, you're doing it wrong

There's still a monumental amount of work to do but as far as the basic criteria are concerned, almost everything has been touched upon. I won't be able to produce a finished, polished game for the final hand-in but that was never the intention. As long as I can provide a decent overview or demonstration of the basic game elements i'll be more than happy.