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