Wednesday 1 September 2010

Igford comes to life!

The deadline came and went, and Igford arrived - and delivered! While not a completed game by any means, the functional demonstration was played by my Tutors during my final presentation, and many more people at the end of year show!

Much Haste to Igford! - Final Project footage from Rich Morgan on Vimeo.


I'm so pleased that it all came together in the end. It was an awful lot of hard work, research, perseverance and frustration but Much Haste to Igford! achieved it's goals - and not only that, but I graduated with a First Class Honours Degree in Creative Computer Game Design for my efforts!

Much Haste to Igford! is currently offline while I attend to pressing issues such as self-promotion and job hunting, but I do intend on releasing it as a playable Beta when I have the means to package it in the UDK (my computer seems to lack the capabilities of doing this at present). Watch this space!

Tuesday 18 May 2010

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!

Tuesday 11 May 2010

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!

Sunday 9 May 2010

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.

Wednesday 5 May 2010

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.

Tuesday 4 May 2010

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.

Monday 3 May 2010

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.

Sunday 2 May 2010

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.

Saturday 1 May 2010

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.

Tuesday 27 April 2010

27 Apr 2010 - One Step Forward, Two Steps Back

Texturing the vehicle is becoming almost as much of a nightmare as the track construction which, incidentally, is still not complete. Yet another stage of the project that's dragged it's heels, the UV unwrapping of the steamcar was simple enough in the earlier stages of the project but to organise its textures into seperate 'UV layers' took the whole of today and i'm VERY annoyed about that.

Turns out I misjudged how to tackle this, which added to the time it took - seperate UV Layers don't seem to work on a single mesh object (unless i'm missing something really fundamental but I haven't been taught about it in Maya). After a lot of anguish and readjusting the UV layers, I ended up combining sections of the model together, exporting those sections as seperate UV texture maps, and importing the steamcar's model into UDK again. Every time I export, I have to re-rig the model and i'm glad I found a relatively quick way to do this otherwise right now i'd be looking at a project without a car.

A quick test in the UDK (I say quick, but it keeps crashing and I seem to spend more time these days fighting against it than using it as a helpful tool, so it's more like an agonisingly frustrating process that I have to repeat several times before any shred of success) shows that, mercifully, the new imported file handles as it used to in the game level and that the textures are mapped to the relevant sections.

The Maxton uses four textures - seen here colour coded in the UDK

Tomorrow, hopefully i'll actually be able to start on the texture of the vehicle. I can only pray that this won't take as long as everything else has over the last four weeks or i'll be in SERIOUS trouble with the project progress.

Monday 19 April 2010

20 April 2010 - Fixed the plumbing

Another productive day!

The Water tower model is now complete and in-game. I played around with specular maps on the drain section to make it look like water had been spilled, to moderate success. It's not that noticable in game but I feel better for putting it there. It's also a good test of specular mapping because I know the car will need it in places.

One of the finished Water towers in-game

I also quickly put together two more posters to break up the bare walls on the course. These don't take a long time to do but I know I won't have time to make things like this later on so i'm getting a few done now in the evenings, when I don't want to be engaging in full-on headwork.

Bill stickers will be prosecuted - but it doesn't stop them. What next? Graffiti?

This week I think i'll finally tackle the Maxton 88's texture maps. That'll be a HUGE job and will probably take a good few days, especially as i'm back in Uni now.

Sunday 18 April 2010

18 Apr 2010 - Why have one when two will do?

Things are finally moving along now after almost a fortnight of agonizing over the in-game terrain. It's still not complete but it's 85% there - no point in doing any more polishing until props and models are in place, so i'm working on that now.

So, a big one today... the water towers in-game, a fundamental part of the game and essential to gameplay. This is something I meant to do almost a month ago and i've finally got around to modelling them today. It didn't take that long to build - with a decent reference image nothing really does.

The water tower is complete! No Texture at time of writing though

Anyway, I thought I should try using multiple UV sets* on this model - partially as a test before texturing the steam car, partially because I need to see how the UDK handles more than one texture on a single model. It worked after a little trial and error, and means that I can use two materials to make a higher resolution texture for the water tower. Doing this with every single model in the game would be a huge memory drain and massively inefficient, but as the towers are almost as much a focal point for the player as the car itself I thought the should take priority.

Applying multiple textures didn't work for me until I re-exported the water tower as two grouped objects - a group for the wooden stand, and one for the tank + pipes. In order to texture the Maxton 88 steamcar using this method, I will have to group parts of the model together that share the same UV set. This will mean nothing to most people reading this but I'm writing it down as a note to myself - I will need to use this again before the project is finished.

The water tower with multiple (basic!) textures in UDK - the Pink and Yellow are two completely seperate texture files

Now i'm going to work on the actual water tower texture, which is uncomplicated Photoshop work. Something light-ish to take me through to the early hours of the morning on another weekend of solid work.

*Note: for anyone reading who hasn't got a clue about what a UV set is - it's a texture map similar to 'nets' that kids sometimes do in Maths lessons in schools. I could blog and explain in detail but time is of the essence and I have a water tower to finish, so it'll have to be done another time!

Saturday 17 April 2010

17 Apr 2010 - Views of the Upper Igford Valley

This was more a post to show members of the family how the level is shaping up - just a quick photo-update with very little in the way of tech-talk. At long last, I know!

Here are some of the most recent shots of the level, and how it's looking as of today:

Billboard on the road to Auchterlony - and the finish line

Streets of Auchterlony - This section still needs a lot more work

The damaged Viaduct - visible from the Lumsden Aeronauts rugby field at Cairncross St.

The Lumber yard in Lumsden, on Drake Hill.

Inside the Crestwell's Cannery section of the course

Additionally, i've also done some more billboard adverts, walls (purple brickwork to match the viaduct), some wrought-iron arches for the factory entrances and a floor for the 'tunnel' warehouse in the level. I've managed to get through a few 'small' modelling jobs like these in the last day or so. This is good for my enthusiasm and motivation, but there's still a LOT to do before this level is even remotely finished.

Back to work - no rest until hand-in!

Thursday 15 April 2010

15 Apr 2010 - Environmentally Unfriendly

As time is really against me at this point, I decided to investigate the UDK's Speedtree tree model generator to make trees for the in-game environment. Whether these will be kept in will depend on the time I have left and the opinion of the Tutors when I go back to university next week.

Anyway, Speedtree is a little complicated but a few handy tutorials online such as this allowed me to get to grips with it without a lot of hassle. I've made a few custom trees to go in-game in an attempt to boost my enthusiasm with the project - creating the terrain has become a laborious task and i'm sick of it at the moment.

Some of my Speedtree trees in the game environment

Some of my trees didn't work initially - the ones without leaves. The Level of Detail (LOD) was drawing them as flat coloured squares from a distance, and this was noticable in game. I thought it might be that Speedtree requires every tree to have leaves, but upon further investigation that was not the case.

I did solve the issue quite quickly (thankfully) - to stop this happening, all I had to do was to uncheck the 'Use Billboards' tickbox in each 'bare' tree's properties. Problem solved!

Problems with the tree LOD / billboards in-game - this is visible when playing

Problem solved!

Now back to the terrain editing...

Saturday 10 April 2010

10 Apr 2010 - That Cursed Viaduct

I'm currently re-working the viaduct for the level - building it at the start of the project was possibly a bit premature. Without something to scale it to, the bridge has been riddled with problems in-game. The latest problem causes the camera to 'shudder' as the player passes through the arches... something that has never happened before now, and is one of many little annoyances that are starting to surface as time is getting short.

So instead of hoping the problem will go away, i've decided to modify the viaduct sections. They're not really wide enough for more than one car anyweay so here's a good opportunity to address something that's been on my mind. Even if it is taking precious time out of my already overworked and hurried schedule.

In other news, the first of the terrain sections for the level is shaping up nicely - and the track is complete. There are lighting issues all over the place with it though, so I hope to find the answer/explaination/solution to that soon. Unfortunately as of late the UDK forums have not been quite so helpful.

Wednesday 7 April 2010

7 Apr 2010 - Delays expected until May 2010

I've been working on the roads in-game for the past three days straight.

It's been a hellish, tedious process if I have to be honest - building and placing bland models with precision and repeatedly testing it is not quick work. Additionally, some glaring issues in the track design have become apparent - ones that should have been identified much earlier in the project (which probably would have happened if so much time wasn't used up by trying to get vehicles working in the UDK engine).

So, the level is going to have to be stripped down and built almost from scratch. I'd have no problem with this but time is a real factor now and i've lost so much of it already to trying to solve functionality issues - something I made quite clear at the initial project proposal in October that I would not focus on. This means no days off for the forseeable future.

I had devised a way of building the track in the level, using static meshes created in 3D. The track would be constructed in sections, and assembled in the game engine, much like a Scalextric track or toy train set. This proved to be relatively simple, but came with its own set of issues.

Collision of complex mesh objects (in this case, the sections of track) is hit and miss in the UDK engine - every collision mesh that surrounds the visible mesh has very specific (and limiting) criteria that must be followed in order for the collision to be accurate. If not, this happens:

Collision errors in UDK - the vehicle falls through solid objects

This is not an issue with overly simple objects and props, but the track HAS to be perfect. This is the course that people will need to use to play the game and it will become glaringly obvious if any errors are present. So after hours of experimentation and trial and error I think i've cracked it, with a little help from the forums and constant game testing.

'Breaking up' the collision meshes for UDK into multiple simpler meshes

Collision meshes need to be as simple as possible but can consist of more than one mesh. This means that instead of one complex collision mesh surrounding the model, many simpler ones can do the job. this does use more memory but it's a price i'm willing to pay for the game to be playable. Additionally, collision meshes need to be made of convex angles otherwise the collision information can be incorrect, resulting in the problem shown in the first image of this post. Thankfully, after a lot of backtracking and alternative methods (I was considering making the roads again from a really simple flat surface which looks and feels like an old PS1 game) I think i've managed to solve the problem.

What remains to be done is to test the more complex sections of track such as the banked corners and junctions, make note of any collision errors, and break down the collision meshes one by one until the car stays on top of the road instead of sinking through it.

This should hopefully be done by tomorrow because I still have a list of things as long as my arm to complete before the holidays are over.

Saturday 3 April 2010

3 Apr 2010 - You take the high road...

NOTE: Basic thoughts outlined here - more detailed post to follow. Apologies to any regular followers of the journal. I'm incredibly busy and trying to catch up on the project schedule.

Road proposals - small sections: Initially entire sections of the course, but still had collision issues. considered using UDK BSP brushes in the game engine that don't need collision boxes, but are far more simplistic in shape.

Decided to 'break down' each road section into individual pieces - this sorts collision issues but increases time to produce each section of track. No instancing may mean higher demand on memory

Problem: UV textures will take considerable amount of time to produce if each section is individual. also, scaling issues will add even more time to production.

Solution: UV unwrap one piece of track and crossroad, scale them so they match, and modify these to make extra sections. As the texture is already in place this should save time and allow them to tile/scale properly. Some deformation in the texture may occur when making curves/hills but this should not be too noticable - will test this.

*add pictures*

Wednesday 31 March 2010

31 Mar 2010 - Productivity ramped up in Igford

NOTE: Quick 'placeholder' post, as I'm really busy at the moment. Pics of work will be included later.

Progress Report - since the presentation, working mainly on 3D modelling. This week I have made:

Airship
2 Warehouses - one derilict (used as a 'tunnel' for track)
Shed
Broken Viaduct Section
Railway Track
Broken Railway track
Piles of logs (barriers for track)

Also, feedback from tutors: Look more at terrain/geography of land to get away from 'game environment' style level and move to something more realistic

Improve HUD as it is very basic - this can help set the mood of the game

Colour schemes - use of complimentary colours with lighting - perhaps a little too drab at the moment

Next Priority is the racetrack - need to work out how it's going to be implemented or there will be no finished game in May.

Saturday 27 March 2010

27 March 2010 - Game within a game

The last few weeks have been really busy with other projects, a trip to Blitz Game Studios in Leamington (which was awesome) and a presentation / exam in University. As a result progress has been slow but I have managed to do a few more things in the last few days.

As it's been an exhausting time, I decided to work on the aesthetics, slowly ticking things off the monumental to-do list. The Lumsden Aeronauts rugby ground was textured in a day, which was a massive boost to my confidence. I love it when things are done as quickly as that - because they rarely work out like that.

Here are some screencaps of the ground: Please excuse the purple hills, they're untextured and work-in-progress. I'm not colour blind or putting tributes to Eminem and D12 in my game.





At the time of writing, i'm currently working on a damaged section of the Igford viaduct, an Airship based on the ones featured in last year's game project Igford-Under-Siege!, some railway lines and log piles for obstacles. It's going to be a busy weekend...