Moving pictures - Bernie in Lumsden & Auchterlony

The new year has started with some great progress for the Much Haste to Igford! development team - though we have lots to do before we can sit back and relax.

It's been a while since we brought something visual to the table, so here's some of the latest in-game footage...

The Maxton Muycrosse Eighty-Eight has lost its roof since we last saw it, exposing its owner, Bernie Maxton, as she clatters around the chilly streets of Lumsden and Auchterlony in the Upper Igford Valley. How did this happen? Only Bernie knows, and she's not telling - just as well there's no such thing as a no-claims bonus on her car insurance in 1890.

Keep checking here and at the Igford Facebook Page for general Igford updates!

'Much Haste to Igford!' © Evil Corporation Games

From the ancient Igford archives...

Following an enjoyable talk with the 2nd Year BA Games Design students at Swansea Metropolitan University in their Level Design seminar last Friday, it was felt that some older Igford-related material should be shared with regards to the setting and environment of the game.

A representation of Igford (incorrectly titled here as a city - Igford is actually only a town) and the village of Much Haste on the Glencorwyn Peninsula in northern Caledonia.

The Igford Annual Steam Car Derby takes place on a number of point-to-point races throughout Glencorwyn, starting at the crossroads at Much Haste and ending in Igford town, which is where the game's title comes from. The race is - quite literally - from Much Haste to Igford.

The town of Igford, the Upper Igford Valley and Glencorwyn are much more sprawled and larger than suggested in the illustration above, which was produced as an initial visualisation way back in October 2009.

This image also features Castle Igford, the ruins of which stand on an isolated scrap of land just off the shore, connected by a very old stone bridge. Castle Igford was originally going to be a feature in the 2010 Igford demo but was removed after the project was scaled down. However, with recent developments it may be possible to finally take a steamcar trip to it... or through it - watch this space!

'Much Haste to Igford!' © Evil Corporation Games

Igford character Update: The Major

The final Much Haste to Igford! playable character has been announced today: The Major!

The Major: Outrageous Windbag

The Major (as he insists on being referred to) is loud, abrupt, and eager to share his stories of battle and exploration with anyone who stands still within earshot for long enough. He lives in an old inherited manor house on Highbrooke hill with his trusty (but utterly ineffective) guard dog, Sargeant. However, the Major can more often be found in the Ruhmkorff Inn in Lumsden, scrounging beverages from locals who aren’t clever enough to avoid him.

He talks proudly and frequently of his expeditions and exploits in Aikanaland, though many people who have heard his lengthy tales of improbable exploits wonder if he has ever been – and question if Aikanaland even exists.

Keep checking here and at the Igford Facebook Page for general Igford updates!

'Much Haste to Igford!' © Evil Corporation Games

A minor news update

Due to some entirely necessary time-travel experimentation and some of the Igford development team having to make an unavoidable last-minute expedition to the colonies, this week's scheduled Character Update will be delayed by approximately another seven days.

Do not despair, citizens of Caledonia! Keep your wireless or telegraphic devices switched on to receive future Igford updates!

'Much Haste to Igford!' © Evil Corporation Games

Igford Character Update: Albert

Another Much Haste to Igford! character has been announced today: Albert!

Albert - Long-Suffering Husband

Albert is Hyacinth Hepburn-Allsopp's mild-mannered husband, a timid man who has aged beyond his years due to the strain of being married to his overbearing and demanding wife.

A reasonably successful man in his youth, Albert inherited the Hepburn & Sons Engine building company from his father in Callaburgh and enjoyed a comfortable life, eventually meeting his wife-to-be and promising her a life of leisure.

With his carefree and comfortable life now a distant memory, Albert has become little more than a chauffeur and source of income for Hyacinth - and is expected to do his duty by his dominant spouse to drive her custom-built steamcar to glory in the Igford Annual Steam Carriage Derby - by whatever means are necessary.

Keep checking here and at the Igford Facebook Page for further character and general Igford updates!

'Much Haste to Igford!' © Evil Corporation Games

Igford Character Update: Bernadette 'Bernie' Maxton

Another Much Haste to Igford! character has been announced today: Bernadette 'Bernie' Maxton!

Bernie Maxton - Innovative Engineer

Bernadette Maxton, better known as ‘Bernie’, is a focused and determined amateur engineer with a fascination with steam technology and engines. She is very much an independent and unconventional person who does not adhere to Caledonian social expectations for a lady of her age and is supported, somewhat surprisingly, by her partner Oscar Samuel Muycrosse to maintain this individuality.

With the help of Oscar she has spent the last two years building the Maxton Muycrosse Eighty-Eight, her very own steam car to compete in the Igford Annual Steam Car Derby. The Maxton 88 (as it is more commonly known) has become a familiar sight on the winding cobblestone roads of Lumsden and Aucherlony. She is often preoccupied and distant, lost in her own world of constant improvement and refinement of machinery - particularly her own steam carriage.

By winning the Igford Annual Steam Carriage Derby with her own hand-built vehicle, Bernie hopes to justify herself as a competent engineer in Caledonia’s male-dominated engineering industries, enabling her to make her mark in the Empire’s age of invention!

'Much Haste to Igford!' © Evil Corporation Games

Igford Character Update: Theodore Robert Mulrainy Jr.

Another Much Haste to Igford! character has been announced today: Theodore Robert Mulrainy Jr!

Theodore Robert Mulrainy Jr. - A foreigner from Overseas

Theo hails from Carcharbro, one of Caledonia’s most distant colonies in the southern hemisphere and fancies himself as a bit of a rogue and hustler. Essentially a well-intentioned conman, Theo’s line of ‘work’ causes a slight internal conflict which shines through on occasion, allowing him to occasionally do the right thing in a crisis. However, he does succumb to temptation all too easily and is known to spend a lot of time indulging in his many vices in the more notorious areas of Igford such as Doxel and Maggleworth.

His inability to turn down a wager has resulted in the young Carcharbran creating some substantial debts among Caledonia’s less reputable inhabitants, forcing him to live a life on the run from a growing number of impatient debt collectors.

Despite this, in a move borne either out of reckless habit or sheer desperation, Theo has entered the Igford Annual Steam Carriage Derby, placing a bet that he can effortlessly beat all the other entrants. If Theo wins the derby or not, one thing is for sure - he won’t have to worry about his gambling debts for long...

Keep checking here and at the Igford Facebook Page for further character and general Igford updates!

'Much Haste to Igford!' © Evil Corporation Games

The Social Network

Just a reminder to all followers of the Much Haste to Igford! Development blog - we are moving with the times (like any good crackpot inventor or alternative 19th-century reality citizen would) and you can find us on Facebook!

The Igford Facebook page - www.facebook.com/igford

For those of you who dabble daily in status updates and social networking - call in to the Igford Facebook page sometime... we'd really appreciate it!

Rich

Igford Character Update: Dr Zebulon Yada Orlo III

Another Much Haste to Igford! character has been announced today: Dr. Zebulon Yada Orlo III!

Dr. Zebulon Yada Orlo III - Eccentric Academic

Doctor Zebulon Yada Orlo is an eccentric inventor from the town of Irgendwo in Jossain Muualla, a small country famed for its scientific development to the east of the D’autres Royaume Empire.

To this unusually friendly and approachable (but somewhat chaotic and scatter-brained) doctor, the Igford Annual Steam Carriage Derby is the perfect opportunity to test the newest iteration of his Patented Personal Transportation Dual-Monocle Module (PPTDMM) experiment and sees the other race entrants not as opponents, but collaborators who are supplying him with valuable data.

The research he obtains from this live exercise will be instrumental in finally perfecting his invention. With this, Doctor Zebulon can finally validate his work within the scientific institutions of Jossain Muualla.

Keep checking here and at the Igford Facebook Page for further character and general Igford updates!

Rich

'Much Haste to Igford!' © Evil Corporation Games

Igford Character Update: Hyacinth Hepburn-Allsopp

Today, the first Much Haste to Igford! character has been officially announced: Hyacinth Hepburn-Allsopp!

Hyacinth Hepburn-Allsopp - Notorious Aristocrat

Hyacinth is a wealthy and infamous aristocrat from Callaburgh who has taken an interest in competing in the Igford Annual Steam Carriage Derby. Her long suffering husband exists only to cater for her every need and does so with nervous compliance.

She feels the rewards and status gained from successfully winning the derby outweigh the discomfort she endures while “rubbing shoulders with the riff-raff” of Much Haste and Igford.

More characters will be revealed over the coming weeks... keep checking here and at the Igford Facebook Page for further updates!

Rich

'Much Haste to Igford!' © Evil Corporation Games

Coming soon - Much Haste to Igford characters!

As of September 2011 the playable character concepts for Igford have been finalised and will be revealed gradually on here and the Much Haste to Igford! Facebook page over the next month.

Which inhabitants of the Caledonian Empire are firing up their vehicles in preparation for the 1890 Steam Car Derby?

Watch this space for developments!

Rich

It Lives!

After what seems like an eternity, the town of Igford is slowly grinding back into life in all it's soot covered, eighteen-nineties glory - I felt it was time to start blowing the dust off this dormant blog as there has been a bit of development on Much Haste to Igford! since I dropped off the radar just over a year ago.

Roads? Where we're going we don't need roads...

The project is currently being developed by Evil Corporation Games, with the help of GamesLab Wales and students/graduates from both Swansea Metropolitan University and the University of Glamorgan. The image above is the first in a series of mock-ups (using the existing game assets from the playable 2010 demo) to demonstrate what we're initially aiming for in terms of gameplay and atmosphere.

It's early days yet but watch this space for further developments of how the Caledonian Empire's best known Steam Carriage Derby will evolve... and it is already evolving!

Also, feel free to check out the Igford Facebook page for regular updates, background info and images!

Rich

Much Haste to Igford! - An online Journal of how a Steampunk Racer came to be...

Much Haste to Igford! is a single player Steampunk-themed racing game demonstration designed by Rich Morgan and built using Epic's Unreal Development Kit (UDK).

The majority of this online blog documents the progress made while working on my Final Major Project at Swansea Metropolitan University between October 2009 and May 2010 and includes design decisions, prototypes, sections of code and workarounds to problems experienced during development (see below).

More recently, Much Haste to Igford! is being developed by Evil Corporation Games in association with GamesLab Wales. The blog will continue to document more recent developments in the game's production from September 2011 with more of a focus on visuals, screenshots, concepts and general progress rather than the specific functionality and problem-solving that I wrote about at length during the production of the 2010 demo.

Additionally, for those of you with an inclination for social networking - feel free to visit the Much Haste to Igford! Facebook page where you can find more information on the development progress as well as a little more information on the fictional world of Igford and Caledonia!

Related links:

Much Haste to Igford! Facebook Page

GamesLab Wales website

The 2010 Much Haste to Igford! UDK demo

The 2010 game demonstration contains a playable custom vehicle, modified loading screens, new title and splash screens as well as a new control system (allowing the player to use a Microsoft XBox 360 controller instead of a keyboard and mouse). All in-game assets in the demo were designed, modelled, textures and implemented in the UDK engine by me.

Feel free to peruse the journal and hopefully it won't get too technical - I promise there are plenty of pictures...

Rich

All work © Rich Morgan

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!

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.