Trailer & Final level for Viva

I've been up to my eyeballs with work and yesterday I did my final Viva. The year is over. Woopee!
The updates are rather bad this month. I think it is really due to the fact there's nothing impressive to show anymore. However here is a trailer for the game along with screenshots of the level.

Outdoor area (newly constructed)

Bedroom

Hallway, with new particles going on!

Gate with more locks!

One of two grey keys to open the lock above

The final key to open the above

A key idea that never got made :(

 

Special Post!

Here's some cool gifs I made for my Viva, neat aren't they?

 

 

 

Dissonance Progress Video (Viva 02)

Here's the progress video of my project. It shows my current achievments with some mechanics, though it had to be cut down quite a bit since I'll be using this for my second Viva.

Path Node Finding

The path node finding is scripted almost entirely, now I can place as many path nodes in my game level and the monster will randomly choose the destination and head towards it. Therefore I don't need to rely on the MoveToActor kismet.

I cannot take much credit for the code I used to get pathfinding using nodes and scripts. After the pylons were placed into the map, mougli's code worked. So the only problem I really had with it in the first place was a lack of a navmesh. The pylons made everything work!

The code used before to calculated the velocity/speed/distance of the monster when travelling towards the player is now uneccessary. Because of that, I was able to use Mougli's AI Script mentioned in previous posts. Christian Skogen helped me out again especially with two parts of the code that would allow the monster to randomly choose any pathnode on the level and travel to it, of course it has to be within the range of the pylon placed there.

I will explain the additional parts of code here:

I used Mougli's code for AI with slight alterations like changing state names.

Then when it worked and the monster could navigate around corners, I tried looking up a way to call pathnodes into script (my monstersaicontroller). I came across this thread which told me about the arrays. This adds the pathnodes into an Array- a list of data. So then you can begin to use them in script.

simulated event PostBeginPlay()
{
    local Pathnode Current;

    foreach Worldinfo.AllActors(class'Pathnode', Current)
    {
        pathNodes.AddItem(Current);
    }
   
    super.PostBeginPlay();
}

Then looked up Random function, and vector maths (with much of christian's help). Applied that until I had a AIcontroller class that would make the monster choose random path nodes, navigate and travel to them. The chasing state (chasing the character) is still intact and just contains Mougli's code. Instead of an Idle, I changed it to Patrol, since it would no longer be idle and just copy/pasted mougli's code again.

He explained how vector maths worked so I could grasp the last bit of code. The last part of the code is an if statement- basically IF the distance between the monster and the player is less than the chaseDistance=1000 (which was alterable in the Default properties), the monster would give up and go back to finding patrol nodes.

 This was placed at the end of the Chase state just before 'goto Begin;'

    if (VSize(target.Location - self.pawn.Location) > chaseDistance)
    {
        WorldInfo.Game.Broadcast(self, "Lost player");
        GotoState('FindPatrolNode');
    }   

About Pylons

I was quite wrong about my 'discovery' yesterday. It seems that Pylons are picky about the ceiling height of your sub/add brush- they don't dislike subtractive brushes at all, as I tested again and it turns out the real issue was the height of the sub and add brushes. If you have a floor and also a ceiling there seems to be minimum height requirement. Which sucks really that I couldn't figure this out sooner. I was left scratching my head until now.

Navmesh Alternative or is it?

I tried and tried to impliment the code from the previous post in so many ways, I gave up. I looked far and high for a solution, and finally after four painful hours of self-inflicted mental torture there was a god... I mean,  videos:

Still now I'm not sure why the code from before did not work, but I found that I can at least cheat the patrolling of my monster by using path nodes. Very generously Ben Townley shared me a kismet sequence he discovered last year that could attach a volume to a spawned bot and kill the player. Since I haven't enough time to get a full melee system working, this is a very important alternative for me. Thank you again Ben, you've saved me.

I had also used a 'MoveActorTo' sequence, and it should have worked perfectly but it didn't. At first I thought it was the nature of my AIController code, so I tried replacing everything with premade code (copy/paste). But nothing worked, besides the code I already had, and I had lost it. My housemate tried to calm me down and tried to help me look for anything to do with Pylons (because i had started muttering it and remembered Ed had mentioned it vaguely for navigational meshes). I felt like I looked it up almost everywhere, there wasn't any tutorials out there that would guide me except for the videos above (which were found not by me but my amazing housemate).

I watched it with the biggest feeling of doubt ever, since nothing was working I didn't think this would either. The current UDK version uses pylons with a area distinguished by a cube rather than a shere/cylinder/circle as shown in the video. I tried what the man in the tutorial had done but it gave me an error:

'error:Could not find ground position for pylon - this pylon will not build paths' 

These lines appeared after building paths with the pylon.

... I then tried it on one of the simple premade levels, it worked, the paths built just fine. The floor there was a static mesh, and I took a very big note of that. Next then I had tried it in an empty level with and Add brush and subtractive brush inside, it didn't work...

So I was questioning if it was because it didn't work on brushes period... this made my heart sink very low. But that was stupid, either it was because the brushes had some form of navigational mesh there already and this pylon business was unessessary or I was doing something wrong- or both.

In the tutorial I finally noticed he was using and additive brush, and everything else was actually a static mesh. My level consists heavily of subtractive brushes. Turns out the pylons do not bod well with subtractive brushes... *BEEP*ing hell.

So i tested this again.

It works!! The monster travels to the second pathnode. This may mean I have to do some heavy reconstruction to my level. Sorry if this seemed obvious to you, but I am an incredible script/code noob. :)

!!!*EDIT*!!!!!
Turns out I was wrong again. Check the next post.

Nav Mesh and Step sound trouble

I've progressed a lot, but it seems these two things are something that should be easy but are not for the reason that, I've got a crap load of code already and I don't know how to get it working with new code.

Mougli's Navigational Mesh tutorial
This guy Mougli is no doubt brilliant, but his code is something I would have to try and literally integrate with my own.

The customAIPawn is fine, but the customAIController is hard to impliment, here is Mougli's:


My dilemma is I don't know how to integrate his code into my own. I've tried many things, but alas I don't have enough scripting/code knowledge to do this.
Here is my code, you can see I've started to put in some code, I already have and Idle and Chase state though, and all the inner workings of the speed/velocity of the monster to player. However instead of using this odd 'Go to begin' method, I applied it per 'Tick' which is like a refresh, and probably considered a more stable method (as told by a programmer).


Footsteps trouble shoot thread
The guy who started the thread has solved his problems but I don't know what he means when he explains:

 "Got it working, it seems like the footstep animnotify calls PlayFootStepSound(); already, so all I had to do was setup the playsound functions, and the footstep notify in the Animset."

Physics and Death Animation

Physics Asset tweaking. I originally wanted a death animation, but somehow I'm finding the Physics Asset editor to be quite amusing.

Tutorial by a Really Chilled Out Dude

Applying Ragdoll on Death

After quite a bit of googling, I managed to stumbled upon a string of links that helped me simulate a function in my customPawn class to allow for a ragdoll effect on death. I'm extending from UDKPawn, according to the poster of the thread, much of the code comes from UTpawn.
Code that allows for ragdoll on death 
For me the code works completely, but the character fell through the floor, and equally as quickly I found that you must add 'Mesh.SetBlockRigidBody(true);' in the ragdoll properties.

Now this is what it looks like when Cecilia gets killed by a cabinet:

So Much Help with my Monster Animations

After sulking (not getting anywhere) for a good two hours, I recieved a crazy amount of help from a BSC Games Developement student. Unfortunately he tried to explain the workings of enemy AI classes, but my code-illiterate skull could barely comprehend it. So I'll try to write it down here, to look back at.



CustomAIController Class

I have an 'Idle' and 'Chase' state made (line 12 & 29), and within these is where the monster is told to use the animations and when. 'auto state Idle' means it will go straight into the Idle state as soon as it is spawned, this is the default state the monster will be in. Below that is an 'if statement' that will tell the monster to chase the player if she is within range and sight. This is where the AnimationTree is used. 'self.pawn.SetPhysics(PHYS_WALKING)' for example is set when the distance of the player to the monster is less than the max chasing distance. The monster starts the running animation because I assigned it to the 'PHYS_WALKING' node from the monster's AnimTree in the editor.

'state Chase'
'event Tick(float delatTime)' <-- in the brackets we're telling deltaTime will be used, so letting it know where to find it.
In the event of a 'Tick' (a refresh) it checks for distance and direction between player and monster- this is also where the calculations of speed and movement are made too since it is a custom made state.

'deltaTime'
This is a calculation that adapts the speed of any particular computer running the game engine to a constant. For example, a slow computer will have less 'Ticks' per second than a more powerful computer. Without the 'deltaTime' the monster would end up moving much quicker on the more powerful computer, because it moves per 'tick' (it moves x amount of units per refresh). In this case, the deltaTime multiplies by a much smaller number to give the same speed, as it would on the slower computer.

'Normal(selfToPlayer)'
Normalising 'selfToPlayer' is concerning diagonal directions. It is simple to state the speed and distance straight on the X or Y or Z axis, but if it were applied to an (e.g.) X,Y co-ordinate (a diagonal direction) the monster could end up travelling too far or/and too fast as it would try to apply the same speed-per-distance. 'selfToPlayer' is the vector between the player and monster, the direction. Normalising it creates a shorter line, this line is always the same length no matter what direction/distance is normalised and is used like the etchings on a ruler. This line, along with the ground speed and the deltaTime, forms the velocity of the monster. Basically with normalisation and deltaTime, the monster will now travel the same speed, independent of direction and computer speed.

Camera Improvement, Scaleforming & Post Processing

3RD PERSON ACTION CAMERA
In the end- with great results- I decided to opt for the second thread I had found about setting up orbital cameras in UDK. It is very good and provides exactly what I needed without taking away any code I may have the opportunity to use in future (aka extending from classes UTpawn and UTPlayerControllers). At the same time the jagged rotations of the character are solved by a user who replied on the same thread:

• UDK action game- 3rd person camera (which extends from the UT classes)
• Reply to thread above: Smooth directional rotations when navigating character

 FIRST STEPS IN SCALEFORM

Other Scaleform links:

• Autodesk/UDK Scaleform Documentation

• 'Getting Started with Scaleform & UDK' thread<<<< THIS HAS EVERYTHING.

Scaleform & UDK: A Simple Menu by VoxHouseStudios 

From the link provided I learned how to make a very basic menu with a play button. So far when I play the UDK executable, it will only load my game when I type in the console 'open HorrorMaze01', it has also been set to load 'dm-deck' (which is the default DeathMatch map) in kismet. I'm trying to figure out how it can be set to load my map by default, but this will be for another evening. For later reference, I also found from VoxHouseStudio that there is a pretty useful video about post-proecessing anti-aliasing for the udk game.

UDK Anti-alias (Post Process chain How-to Guide)

Motion Capture 01

Edoardo, Christer and I went for a few days this week to do some motion-capture! 

It was a lot of fun, but admittedly on Monday we stood around scratching our heads for 4 hours (Christer was in a mo-cap suite for the whole time!) and hoping Adam would come back and save us.

 Tuesday (today) I finally got to record my own animations, and we each decided to export one animation each to work at home. Here is one I got working in MotionBuilder 2012 with one of the default skeletons.

I followed a tutorial on how to apply the dots animation to one of the default 'Actor's in MotionBuilder.
Not sure how to use my own model and skeleton yet, but tomorrow we might find out.

3rd Person Action Camera

Last time I tried to rid the third person camera, I had used this code when extending from UTPlayerController for my CustomPlayerController:

simulated event PostBeginPlay()
{
    super.PostBeginPlay();

    SetBehindView(true);
    bNoCrosshair = true;
}

The problem with this method (or perhaps I didn't follow a tutorial correctly), was that every time my character died, feigned death or hit a cut-scene it would revert back to first-person. I wasn't sure why, but quickly found another tutorial that worked easily and well from here.
It is an 3rd person action camera that allows the player to run in all kinds of directions, and it works well but...



As shown in the video, the animations are dreadful, and I'm not sure if I can fix it easily. The class I had to extend was UDKPlayerController instead of UTPlayerController, and I think the lack of guns and item pick up is due to the fact I'm no longer extending from UTPlayerController and UTPawn. I cannot feign death or do what the original UTgame allowed....

So which is better? Should I revert back to the previous method and try to redo the tutorials again? Horrible animations aside, this was the perfect camera setup for my game, but it has taken quite a few features away that I could have taken advantage of (though not sure if I would) like picking up items.

*EDIT*
May have found an alternative solution with this other third-person action camera, which is built to extend from UTPawn & UTPlayerControl. I will try to see if I can do this tomorrow, since it's a tutorial dating back 2010.

Changes: Spawning Mechanics

First VIVA

I received some critical feedback after presenting my first Viva. It was basically a pitch for my game (though a lot more informative for educational purposes). One large flaw in my original spawning mechanic was addressed: Every time the spawn point was different, how could the player possibly work their way through a maze without knowing where to go? Each time they find their way there is always the possibility that they will get killed, thus having to start again- being totally lost, again. 

Answer to the Problem
Instead of throwing the player into more confusion from their first or several deaths, it would be better to give them some kind of chance by aiding them with finding the exit. As the player spawns, so will a set of clues to help lead the player in the right direction. The below diagram is an overly simplified version of how the clues would be laid out.

Of course this should only aid the player, not help solve the puzzles, so even if the way is better lead, the player will still have to venture around to find the key(s) and answers to the puzzles.

What are the Clues?
The Clues will be bits of journal notes left in certain areas that will give small riddles as to which way to go.
What will be a secondary and more consistent clue, will be trails of blood that also come in contact with the notes. The source is unknown to the player but will become obvious over time that it leads to the destinations. Blood smeared doors, locks, puzzle areas are a theme in the first maze.

Locked Door & Follow AI WIP!

<_> Not much to show, but this took a very long time for a script illiterate like myself. I am in the middle of looking at how to replace the bot with a different mesh... also perhaps when the bot touches the player, the player should die instantly.

I have made the bot slow on purpose for demonstration, usually it is almost as quick as the player.

 

More Sound Effects

Today I grabbed myself a portable sound recorder. I needed to record a door squeaking, but failed to find anything that could replicate an actual door squeak. So I decided I'd bring the recorder to my home- the land of squeaky old doors.

  DoorSqueak03 by Jin Suen

  AirVentLoop02 by Jin Suen

  FloorboardSqueak01 by Jin Suen

  HeavyDoorUnlockOpen00 by Jin Suen

  TriggerSound02 by Jin Suen

Besides just Squeaky doors, I have air vent noises that can act as atmospheric sound. Locked doors, trying door hands, and anything that makes a place seem old.

Sound Effects Recording No.1

Today I went to my first recording in the Sound Room at the university. These are some of my unedited sound samples. I recorded a lot of potentially useful sounds, including moving objects, picking up books, page sfx, footsteps, scrap noise. I decided to first record these less important sounds to get a grip on the recording equipment today.
Next week I will be recording the Cecilia's voice, the monster's noises and hopefully get a squeaky door hinge in.

  Footsteps_Sneak01 by Jin Suen

  Footsteps_FastWalk by Jin Suen 

  Doorknock by Jin Suen

  OpenBook01 by Jin Suen

Project Folder Setup

As most classmates will know I've had a real hard time trying to get a proper working Project folder- with set up that would allow me to edit and change script files. The solution I found was from a former student who created a Tutorial just to meet my level of beginner.
Henrik Claudelin's Tutorials

I have only just begun, so my Source folder is still quite empty:

Unfortunately after setting up folders, I found an error, that would prevent my 'CustomGame' gameplay to show up in the 'World Properties' of UDK editor. So my previous block out will have to be scrapped.

Camera so far...
I am still in the middle of trying to set up the camera, so that the default will be third person. Instead of working from scratch, I will just 'extend' my scripts from the existing UTGame script files, since most properties needed in the 'Pawn' and 'PlayerController' are already there.

Enemy function & Traps

How the Enemy Detects the Main Character

In the below diagrams, shows the monster's rings of detection. At different points of the ring (indicated by the colour and white line marks) the monster has different levels of sense. The further away, the less it can detect. The blue area on the circle, is the monster's angle of sight. 

This of course does not include walls or obstacles that would be otherwise effecting the monster's line of sight in the Maze.

Traps

In the maze, there will be traps placed in seemingly random areas. By this I mean they will be at the same spots each time the game restarts. 

Wherever the main character is in the maze, if she happens to trigger a trap, the trap will make such a loud bang that the monster will know roughly what area she is at. At this point (below scenario) the player would have to run quickly around either corner to prevent herself from being seen.

Introduction and Ideas

This blog was created to record the process of producing a part of an interactive game and to help keep track of my Dissertation.

Project Plan

Here is a basic project plan listing that I have created for the sake of keeping my progress consistent. Every week there will be a major goal to complete, I have made it so I can change my plans on a weekly basis. It is an easy and simple to-do tick list. (right)

My properly structured project plan will be put into a Gantt chart that will lead to two simultaneous routes, so here is the basic flow of my project:

Design game mechanic > Demo Mechanics in chosen game engine > Finalise game mechanics >

Create Mood boards > Concept visual themes and characters > Finalise character designs > finalise level design



Major Project Introduction


I aim to create a single player Horror themed Maze game- most of the game play involves collecting items, solving puzzles/unlocking doors, and avoiding trouble whilst a monster lurks in the maze. The idea was inspired by Amnesia's eerie dungeon atmosphere and PacMan's maze chasing.

There is one main character, who wakes up in an unfamiliar place (the maze), and she must find her way out. She will come across maze after maze in the hopes of finding an exit. While she is trapped in a maze she encounters obstacles in her path (e.g. fallen debris, hole in the path, or even a monster obstructing the way) that will force the player to choose a different root or find a way across. Sometimes there will be locked doors that need items, and sometimes to get those items you must solve open plane puzzles. The puzzles involve pushing blocks, combining items that fit together to form a key (for the door) or imputing the correct sequence to a special lock.

The whole story will be set in a supernatural-horror scene, where not much makes sense- environments will look half organic (bloody/rusty) and half industrial/medical. The whole concept is undecided for now as more research and mood boards are required.

Basic Game Mechanics

The first maze is made of rooms and corridors. In this example there are 3 different starting points for the main character, and 5 spawn/outpost areas for the monster. In the below example both character and monster have spawned at one of their designated locations.

When the character wakes up/spawns in the maze, she is set at a random starting point. As soon as the game starts, the monster also spawns at a random spot of the maze. Their spots are set up so that no matter where either monster/character spawn they will always be at least two rooms away from each other. This will give the player a chance in the beginning.

Monster: Roams to a random outpost until it spots the main character, in which it will start to chase her until it looses sight or eats her.