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.

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...

13 Mar 2010 - A trip through Auchterlony and Lumsden

With much of the basic functionality in-game sorted, I've been able to concentrate more on the stuff I want to look at - building the level. I've been making really rough tests using the buildings and props i've created so far in the build up to my second stage Viva on the 23rd of March. Time is flying now so I need to make sure I prioritise tasks. For now though, the level takes priority.

The Auchterlony Viaduct in the (very) basic level test (NOTE:These pictures are a rough level in progress with many elements missing)

Older, low-quality housing near the Auchterlony Viaduct, Upper Igford

Today I've built a stand for the rugby field (the local team are going by the name of the Lumsden Aeronauts, even though they don't feature in-game) and a stand for spectators to watch. These kinds of details are important to me as they suggest that the place is a community and not a series of lifeless buildings purposefully set out for a race. I want to feel like this is a convincing place and i'm really getting into the world building, both physically and fictionally.

The Lumsden Aeronauts rugby ground at Cairncross Street, Auchterlony

Part of the initial test map - The Maxton 88 races through the streets of Auchterlony and Lumsden in Upper Igford.

In the last few days i've been adding details to see what they look like in-game - a 'crowd' made a lot of difference (See picture) even though they're just cardboard cut-outs. These are placeholders for the purpose of the project to demonstrate the visual feel.

My tutors also suggested windows that are lit up on some buildings (I'd use Emissive textures like the Skydome for this) as well as some consideration given to sound effects. I haven't thought about sound so far but it would be good to have some in-game to really bring it to life.

Additionally, the tutors mentioned that the player camera needs attention and some areas of the track need to be illuminated for players to see where they should be going. Playtesting is also vital and as soon as I iron out the collision glitches in the prototype level, i'll be ready to unleash my creation on friends and family. I bet it takes them under a minute to break the game.

9 Mar 2010 - From Start to Finish

Just a quick update regarding one of the more important aspects of the game - the track itself.

Now that the car handling issues have been addressed I no longer have to compensate when designing the course. This will allow me to have more freedom in how the track is designed vertically - I want it to be interesting and all the most interesting racetracks in games I play have lots of hills in them. Maybe i'm just a hill person, I don't know.

Anyway, heres an initial sketch that was scribbled instead of paying attention in University a few weeks back:

I quite liked the feature of the viaducts in this, so I spent a little while refining the design after looking at Formula 1 courses online such as these. This is what I came up with:



The track is broken down into sections (for visual design later on), and the lighter sections of track are alternative routes that a player may take (the large grey lines that intersect the course are train tracks - only certain sections of which will be accessible). These may or may not be advantageous and will hopefully add a small amount of exploration in the game to increase longevity and variety while not detracting too much from the racing element.

I plan to use the above image as a reference in Maya, construct a rough track, export it to the UDK and test how the vehicle reacts to the slopes and turns of the course and adjust them accordingly before creating the final models.

7 Mar 2010 - Mad Maxton beyond the Skydome

Sorry, it's a terrible play on words (based on a certain Mel Gibson film) but I couldn't help myself.

Anyway, Some visual progress for a change - I've made a 'skydome' for the in-game level. This is basically a half-sphere with a texture that surrounds the whole in-game level, giving the impression that there is a sky in the game world.

Custom Skydome in Maya - the game world would be positioned within this dome

Instead of using the ones supplied in the UDK I thought i'd make my own, and with a little help from the forums, all went well. Some initial issues with the visibility of the skydome were caused by me wrongly setting up Materials (Textures) in the UDK. The texture of a skydome needs to be an emissive texture, not a diffuse texture (which is what is used for most other objects in my level). This won't mean a thing to anyone else but i'm making a note in my blog for myself - I know i'll forget this further down the line.

I've started painting the texture of the skydome - which is the fun bit - and early tests in a test level look encouraging.

The Maxton 88 in a test level with skydome visible in the distance

Tomorrow i'll spend the day on Photoshop - no coding for a change! Wow, I almost feel like i'm on holiday. At long last, I can be creative for a few days!

6 Mar 2010 - Handling the handling issues

After a busy and exhausting week of setbacks, deadlines and frustration, some unexpected progress was made on something critical - the vehicle handling.

As recently as yesterday I was coming up with nothing on the vehicle issues. The Maxton worked fine on a completely flat surface but any slight gradient would cause it to do all sorts of things that removed control from the player. This has been an issue for some time but now I think it's finally been resolved, thanks to a post on the 3Dbuzz forums from four years ago.

Basically, the 3Dbuzz thread found here suggests that the 'root' bone (centre of the vehicle skeleton) actually has an influence on the pivot and weight balance of the vehicle, and this was directly related to the problem of the vehicle 'rearing up' like a frightened horse. Moving the bone will influence how the vehicle behaves in the game engine.

The infuriating 'rearing up' problem in-game that has been an issue for far too long.

Moving the 'root' bone further forward affected the weight balance of the Maxton

I gave it a go - I moved the central root bone much further forward and re-imported the vehicle from Maya into the UDK, set the PhysicsAsset (which I was convinced was the cause of the problem before now) and tested the Maxton in-game on uneven terrain. Success! The car is responding much easier now, shows some signs of suspension in the wheels (though it is not visually accurate for the model) and doesn't come to a halt when it touches something as insignificant as a slight incline or a kerb.

This makes me very happy as designing the track and terrain - a vital part of the whole project - should now be able to proceed without having to compensate for poort vehicle handling. Fingers crossed that things will be a little smoother from this point!

5 Mar 2010 - Can it be? Real visual feedback?

TEMPORARY ROUGH NOTES:

Looked at HUD tutorial by Shad:http://www.shad-fr.com/udk/hudtut/english.html
Tutorial works with vehicle health in game - stripped down the code to only include relevant pieces for the game, needed help from forums and got some helpful feedback - pity the bedroom programmers also feel compelled to have an elitist attitude while dispensing information

Eventually got HUD to work though the gauge is co-ordinate specific, not screen percentage, so window cannot be resized during play unless a solution is found.

ADDITIONAL:

Terrain work started, issues with vehicle collision and handling. Cannot drive on uneven ground and this is a MAJOR problem for the development of the whole project. Tweaking vehicle handling cause more problems to which a solution is yet to be found.

Have posted on UDK forums about this but feel a bit halfhearted after the snobbish response from the coders.

3 Mar 2010 - Trimming the HUD

TEMPORARY ROUGH NOTES:

Managed to disable in-game HUD with blank 'MyHUD'.uc file for an empty screen (screenshot)

UI 'Titles' created and tested, works in game. (screenshot)

Issues with UI to UI transition - crashes game for unknown reason?

Tutorial discovered on how to implement basic working HUD - will see if this can be applied

2 Mar 2010 - A problem with the Natives

Another issue, another solution. Once again the programmers on the UDK forums have pointed me in the right direction and have helped me stop the game crashing on startup, which, as errors go, is a bit of a big one.

Apparently the critical error was cased by my vehicle script (no surprises there) - as it borrows heavily from the default 'Scorpion' vehicle that comes with the game. The error in the game's log file (found in 'UTGame\Logs') was this:

Critical: Can't bind to native class *name of custom vehicle*

This was caused by the 'borrowing' of the Scorpion's code. The Scorpion has a 'native' class definition in it's script, which can only be used by official vehicles that come with the development kit (I assume this also applies to other objects that Epic provide with the UDK).

So, the solution is to remove any references of 'native' from the vehicle script. In my case, it was in the UTVehicleMaxtonSteamCar.uc file. I commented out the code using /** and */ .



This wasn't successful initially, resulting in the exact same crashing on startup. But another look at the UDK's log files showed two more messages:

Error, Cannot use cpptext blocks in non-native classes

Error, Only functions of native classes can be declared native

This required a further study of the script but was solved quickly thanks to the search function. It just required further commenting out of the 'cpptext' function and another 'native' reference further down the script:


Running the game seems successful now, and it loads up without crashing! Of course, commenting out code rather than deleting it allows me to return to the default script if anything should go horribly wrong - but so far, so good.

I cannot describe how important looking at the log files are. Not only do they give you an error to work with when looking for a solution, but they also give you the file in which the problem lies, and the line of code that is causing the issue. This saves such a lot of time!