As some of you may have noticed, this is my first blog post in a while. There are many reasons for this, mainly because I've been working hard trying to meet deadlines and haven't found the right time to write anything, partly because I've not stepped foot in a lecture hall for 3 weeks and to some extend i felt i had nothing useful to say. Not much has changed on the last point but nevertheless I will hopefully be updated my blog on a regular basis from now.
The first thing i want to write about is the work i have been doing in Unreal this semester. I ended semester one saying that i wasn't going to touch the UDK this semester and that I wanted to get back to basics in terms of level design, back to pen and paper and learning to write things down, plan and then iterate my ideas into a level design document. I also wanted to pull out the key factors of what level design documents consist of use my own interpretation of these to reformat the LDD. The reason for doing this is because sometimes when i read a LDD I do not fully understand what it is trying to achieve. Sometimes this can be because the designer has no communicated it well enough, but i think the main reason for this is the lack of understanding junior designers have when it comes to presenting the work as it needs to contain all the information that, not only the designers need, but also Animators and Artists. This is a hard thing to teach and its only really from experience that you can gain an understanding of what is needed in a document to hit all the criteria that a team needs to make your level. I will go in to more depth in a later post LDD's but for now back to semester 2.
So i started the year with a brief to create an Unreal level that had to be Alien looking, with lots of triggers and fun things to do. Without it mustn't be too complicated, but easy to navigate and also to have a constant loop so that the player could be playing for X amount of time without the game ending. The way that my mind works is to start a level with no real direction. I know the brief and what the level must contain but i don't know where I'm going to place each mechanic or what the level is going to look like. This is no doubt a bad design mentality to have, and i wouldn't argue with anyone that called me lazy for doing so. It is also questionable whether my levels would turn out better if i did plan them. But for me creating a level is all about how it feels to me at the time and i like to add things when I can visualise the mechanics and feel that they fit into a specific scenario. I don't think this can be achieved on paper but that's an argument for another day.
The level itself was one of the most challenging I have done in the Unreal engine for many reasons. The main reason was because the requirements were so specific in terms of game play the kismet (the best way to describe kismet is the scripting of the level, doors opening, lifts moving etc) i had to create i had no idea about and it was only through trial and error that i could meet the brief. The main mechanic was creating 6 triggers that when all 6 were triggered would randomly trigger off until the player decided to quit the game, i.e having no ending. This was a new concept to me because when designing levels i normally have a start point and an end point and whatever happened in between was entirely up to me. This in itself was quite a simple concept to get around however implementing it was another issue. It would have been easy to cheat the player and let the player trigger the 6 and then manually turn off different triggers after different amounts of time, however adding 'random' to the equation was a completely different issue. To add on top of all this, the player had to know which trigger had been turned off and in what location so that they could go and turn it back on. The player also had to visually see the triggers triggering on and off. To tackle this i added a Matinee sequence which consisted of a camera actor so that when the trigger changed state it would play a small matinee camera animation which showed the trigger so that the player knew which location the switch was on. I also added a simple coloured light, that turned off by default, and when the trigger was active the light would come on. This seemed to work well and wasn't too difficult. However another issue arose from this was when the trigger played the matinee, you saw the character stood there, in normal circumstances this wouldn't be an issue, but because of the concept of the level (a drone navigating a spaceship) seeing a high poly Unreal 3 character with a huge gun stood there ruined the atmosphere. I got around this by toggling a cinematic mode which hid the player and also disabled movement. Problem solved. After testing it became apparent that the player must be invisible whilst navigating the level because when you pressed the trigger there was no one stood next to it. To address this issue i used a static mesh from an existing Unreal asset which was a gun turret off of an Unreal vehicle. This worked well and i added these at every trigger and had them hidden in the game, but when the trigger was active it would become unhidden whilst the camera played and then became hidden again.
I wont go into every little detail about how i got to the end result of the unreal level but i think its a good example of how one problem in a game can turn into multiple issues. I think, as a designer, you have to ask yourself how much certain issues will affect the overall game play and how much time they would take to fix. Time is a crucial factor because when working to a short deadline like i was, you need to distinguish between issues that need fixing as they will have a large impact on the game play and factors you would like fixing but wouldn't affect the game play too much.