post mortem of 'the nightmare

GAME SEMESTER 2014

1Made by Sai Narayan Natarajan.

Post Mortem:

As concept owner, I had to take on many roles and perform differ-ent functions during the course of the GAME project. These various jobs will be broken down and explained in this document. Things I worked on include:

1) Concepting and story creation 2) Dialogue Writing and System 3) Level Design (lighting) I had to implement many other things, but the above topics are my major contributions.All of the content described hereafter was used towards the making of “The Nightmare”. It is a First Person Platformer with elements of psychological horror and RPGs. I lead a team of 20 people(including myself) to make this game in just 9 weeks. It was an exciting experience that taught me a lot, and something I shall look back on fondly.

The final conclusion at the end of this document describes the lessons I learnt and what I took away from this project.

GAME SEMESTER 2014 GAME SEMESTER 2014

2 3Made by Sai Narayan Natarajan. Made by Sai Narayan Natarajan.

1) Concepting and Story Creation:

The idea for this video game was conceived to be submitted as an assignment. We were asked to create a ‘High Concept Document’ where in we outline all the fundamental aspects of the concept for a video game of any genre.

At this stage I had a rough idea of how the game would look and feel. Things I had planned at this point included:

1) Platforming system (running, jumping, sliding, crouching) 2) Gameplay elements (sanity system, enemy behaviour) 3) Structure of the game world (overworld and dungeons) 4) Theme and mood of the game (how it feels and plays) 5) Role of the player (objectives and perspective of the hero) 6) Influences (comparisions to existing games) The idea as it existed at this point was very different from the final concept we decided to base the game on, however. To point some major differences out, it was to be set in modern times, there was no fiance that the hero was seeking vengeance for, and I wanted there to be a freerunning/parkour system implemented.

The story was not an important point at the early stages. We were encouraged to keep story and gameplay as abstract as possible so as to not be designing to suit the story, and rather have a core set of mechanics that the game was based on, and then build the story around these mechanics instead.

(Moodboard as it was designed for the HCD)



(Storyboard for the original concept)

After the HCD came the Level Design Document, in which the more concrete aspects of gameplay were laid out, like:

1) How the progression system of the game would function 2) Description of how the game worlds’ different parts would look 3) Construction of levels (geometry and spaces) 4) Enemy Designs 5) Obstacles and challenges 6) Health and death mechanics 7) Sounds for ambience and atmosphere 8) Assets required and the art style of the game as a whole 9) Story of the game in a more definite form

After my concept was chosen to be made into a game at the project kickoff, we had one week of concept meetings, during which, me and the heads of the various teams (i.e. - Character, Level, Art, Pro-gramming and Sound) went over the various elements of the game and discussed as to which were feasable and which weren’t in the short time we had.I was considerably stressed at this point, trying to defend my idea from being mauled and torn to pieces, because understandably, everyone had different opinions on my concept and they were not shy about expressing them. Some things that I had to compromise on include

1) The collectible life mechanic 2) A semi - open world hub 3) Wraith mode (offshoot of the death mechanic) 4) Dialogue system with NPC characteristics 5) A journal system (a player driven way to maintain record of events 6) An idea I had to tutorialize all the skills required in the game 7) A proposed layout for the interface was rejected in favour of a minimalist approach.And various other small features and aspects. Needless to say, I was also quite vocal about keeping my concept as close to the original as possible, but in the end I had to agree to give a little to get a little. CONCLUSION:

I learnt how to create a concept and go through the stages of its de-velopment and how to brainstorm and conduct team meetings.

“A really good compromise is the one that leaves both sides equallydissatisfied.”

- Henry Clay



2) Dialogue Writing and System:

During my time in ‘The Nighmare project’, it proved surprisingly easy to both create characters with believable personalities, and to write dialogue for them that didn’t sound altogether too cliche.

The main difficulty came in writing dialogue for these characters in the form of a dialogue tree, with different responses leading to dif-ferent answers from the NPC in question. This led to a few cases of “cheating” where we simply led multiple choices to the same answer, and only made one out of 4 options yield a different answer.

The sad part is that the dialogue system really can support a large number of answers and choices, potentially giving us the ability tocreate a huge and varied dialogue tree.

Lack of time however forced us to remove the dialogue system from the final version of the game.

The basic system by which the dialogue is implemented does not belong to me. I found it online(3), and it was a collection of Unrealscript classes that allow anyone to use the dialogue functionality entirely through Kismet, without having to fiddle around withScaleform and Actionscript, which requires a fair degree of expertise to attempt.

The dialogue system essentially reduces the effort of incorporating dialogue into the level by bundling all the code and classes requiredinto Kismet nodes. It simplifies the work involved in creating a HUD specifically for dialogue by drawing the HUD without even using any coding directly! It really doesn’t get simpler than this.

As someone who had no knowledge of Scaleform or Unrealscripteven, at the beginning of the project, this was an absolute godsend.I had found a way to implement dialogue with little to no effort and best of all, it was free to use in all projects, commerical or otherwise.

(Sample of how it looks ingame)



However it did not prove as easy as it seemed. These classes were made in roughly 2012, and were implemented with the help of the UDK UIScene parent class, and since then Unreal has removed these classes from the functionality of UDK, rendering this more or less useless, because the dialogue and choices would display, but the mouse was completely disabled during the dialogue scene, even though the cursor showed up on - screen.

I had to make a few changes to the source code in order to get it working with the 2014 build of UDK. These fixes include:

1) Adding a new class to replace the old mouse position tracking function which was reliant on the UIScenes functionality.

(The old code)

2) The new code directly returns the mouse coordinates to the PlayerController instead of passing it through the UIController, a now defunct class. As someone who, at the time, was completely unfamiliar with Unrealscript, it took a huge amount of Googling and forum crawling before I found the neccessary functions to use as a substitute. I’m pretty proud of this as a result.

3) However, even though mouse coordinates were being updated with the new code, the cursor would not move onscreen. I had quite a time picking over every inch of the code trying to figure out where I went wrong. It turned out that even though the mouse position was being updated, the function for moving the cursor was being overriden by an empty function. So I commented it out. Lo and behold, the dialogue system was working!



The dialogue system essentially consists of 4 main Kismet nodes that can use different options specified in-Kismet by the designeraccording to the type of dialogue experience one is trying to achieve and present to the player.These 4 types of Kismet Nodes are:

1) Begin Dialogue 2) Message 3) Choice 4) End Dialogue

1) Begin Dialogue: This node activates the “Dialogue” state for the player. The only variable it needs is the target player variable.

The designer has the option of supplying a custom texture to use as a dialogue box background, choice box background etc. The settings for the margins of the dialogue box (i.e. - distance from box to edge of screen), can also be changed here.

2) Message: This Kismet node accepts 4 variables: 1) Player: The player variable the dialogue is targeted at. 2) Camera: The camera actor whose field of view will be used for the duration of the dialogue scene. 3) Text: The string variable which contains the text to be displayed. 4) Name: The string variable which contains the name of the speaker of the dialogue.

3) Choice: This is an interesting one. It accepts the same 4 variables as Message node, but it has 4 outputs called ‘Choice’ instead of traditional ‘Next’ output. It also differs from the Message node in that instead of just offering the usual dialogue box, it also displays 4 choice boxes the player can choose from. These 4 choices correspond to the outputs, and each of them can lead to either another Choice node (another choice of 4 options) or to a Message node (just a dialogue box) or the end of the dialogue state. (and the dialogue scene)



The tickboxes activate the corresponding Choice output and allow them to be clicked on by the player. The field Choice text is themessage to be displayed in the choice box as the players’ response.The Dialogue box top tickbox at the end, allows the dialogue box to be set at the top of the display.

4) End Dialogue: This Kismet node ends the dialogue state and scene. There are no options to modify.

CONCLUSION:

I learnt quite a bit about the Unrealscript fundamentals and how to search for bugs and errors from this. It also gave me a good under-standing of how Kismet works, by analyzing how the dialogue op-tions should lead from one to another and create a dialogue tree in the process.

3) Lighting:Lighting is one of the most important elements of a game. It does not matter how well designed a model is, or how skillfully it has been textured, if the player is unable to make out the details due to lighting that does not allow him to do so because of badly chosen color contrasts, or lighting that is too dark or too bright. To give you an example of how essential lighting is to a game, take the picture below. Shown side by side is the same scene, the left pic-ture without lighting information, the right picture with lighting information.

It is easy to see that the scene without lighting lacks any sort of aes-thetic appeal. Hence the need for lighting.

Without lighting all the textures look flat and lifeless. By adding lighting, we add shadow and depth to these objects, and at the same time also covering up portions of the corridor that are otherwise empty, with darkness, thus preventing the player from noticing the lack of objects.

I will be laying out the basic fundamentals of lighting that I learnt during my research into it, and my findings and results from those learnings.



1) Color and Contrast:

To give you an example of how important color and contrast is to a game, observe the picture below. A scene, with good and bad color contrasts. The first picture has a washed out white light emanating from the streetlights which isn’t unappealing exactly, but does noth-ing for the scene itself, and the spotlight on the pavement and street is very obvious.

2) Sources of Light:

One of the most basic rules is that whenever a light is placed in a level it must be done so as to appear to originate from a light source. This is because when there is illumination present without any source to emanate from, it looks extremely unrealistic and breaks the players’ immersion. Simply placing a Spot Light or a Point Light in a level without a light source to accompany it causes situations like this:



This may not necessarily look bad, and sometimes you are left with no other resort, but it’s a detail that has a surprisingly large effect on player immersion.Whenever possible I tried to design the levels with this idea in mind.Here are some examples from the game of sourced lighting.

1) House2) Sewer3) Sewer tunnel4) Floating Islands



3) Flickering Light Functions and Materials:

The thing I’m probably most proud of in terms of lighting is the way I created a method to simulate dynamic lighting that flickered realisticly along with it’s source. This can be done in two parts:

1) Modifying the light sources’ emissive material:

If the emissive of the light source mesh is modified to flicker using a set of math nodes, then the light source will appear flicker as well, at the same rate.

2) Creating a light function for the dynamic light: Adding a light function with the same set of math nodes (to produce a similar flickering), to a PointLightMovable (or) PointLightToggleable that is placed next to the light source mesh.

After watching this tutorial:

https://www.youtube.com/watch?v=Vu5xkff50k4. (2)

Which teaches you how to create a flickering light material (also called as a light function), I thought to apply the same technique to the material of a light source mesh, in order to give the appearance of the light source flickering too.

Might be hard to make out, but the flickering light function consists of TWO Sine nodes, and ONE Cosine node. These are found by(Right click -> Math). The node connected to all three of them on the right is a Time node, which is found in the Utility submenu.The two Sine nodes are given different values and combined used an Add node (also found in Math), the Cosine node is passed through an Absolute node (found in Math), and then the sum of the two Sine nodes and the absolute value of the Cosine node, are combined using an Add node again. The output of this Add node is then connected to the emissive chan-nel of the material.

In the options that are available for the material as a whole, expand the ‘Mutually Exclusive Usage’ tab, and make sure the ‘Use as a Light Function’ checkbox is enabled. This tells UDK to disable all the channels for the material except the emissive. Which allows it to be used to change a lights behaviour. Make sure to save!



You now have a flickering light material.

Place any PointLightMovable/Toggleable in your level, open up it’s properties menu, navigate to Light -> Light Component -> Light Component -> Function -> Click on the blue arrow to create a new object, and in the newly create Source Material field, select the newly made Flickering Light Material in the content browser and press the green arrow to assign it.

Press Play in Editor, and if all the steps were performed correctly, you should see your light flickering!

The next step is modifying the emissive material of any light sourcestatic mesh. Find a suitable mesh, open the Static mesh Editor, and under LODInfo -> [index] -> Elements -> [index], press the magnifying glass button in order to find that meshs’ material in the content browser, and edit it in the Material Editor.

This next step is very easy. All that needs to be done, is that the same nodes from the Flickering Light Material made in the first step need to be copied into this Material Editor instance and then combined with the existing materials emissive channel.

This can be done by simply finding the current node that links to the emissive channel, combining it with the chain of Flickering nodes, by using an Add node, and then making the binding from that Add nodes output to the emissive channel.

Do NOT however, select ‘Use as a Light Function’ from the options below. Save and recompile the material, and place it in level, along with your dynamic light. If all went well, you should now have your awesome flickering light source and light!



CONCLUSION:

I learnt an incredible amount about Unreals’ lighting system and Lightmass. I discovered many small tips and tricks, as well techniques that are applicable on a broad scale. I also appreciated for the first time exactly how important Light-ing is in a video game, and how most gamers would take it for granted that good lighting just exists within a game, but when it isn’t present, how much a player notices and critiques the lack of good lighting even subconsciously.

FINAL CONCLUSION AND TAKEAWAY:

This project was an incredible experience. It was my first team project that involved the creation of a video game, and even though it was a decidedly small scale project, the sheer complexity involved in the process of video game development quickly dawned on me.I think I performed quite well in my role as a manager, motivator and coordinater. There were times when the stress definitely got to me, and other times where I could not believe the situations that a manager has to deal with.

Conflict Resolution:To cite an example, one of my team members burst into tears during a meeting where I had to inform him that his attitude and approach to work was not being appreciated by the other team members (including myself). There were other situations that had led up to this moment, and dealing with them taught me a lot about how to resolve conflict. This was made worse by the fact that the team member in question was the Project Manager. After this, he gave up the role voluntarily and I took over his role and responsibilities (which in truth I had been performing for some time anyway).

Crunch:An issue that snowballed into many sleepless nights was the severe lack of level designers that we had. There were 3 of us, out of which only 2 (one of whom was myself) had contributed in any significant manner to the project by the end of it. This led to the necessity of me spending a lot of time picking up the slack, and by the end of it I had designed and implemented 2 out of the 3 levels of the game and polished and completed the 1st level. Suffice to say, this cost me a lot of sleep towards the end of the project. I bore it with good grace though and tried my absolute hardest to do as much as I could. The silver lining to this was I ended up learning a huge amount about the capabilities of Unreal 3.

Motivation:An even bigger issue was the difficulty of keeping up the teams’ motivation as the project entered the later stages and the initial excitement had faded away. For instance, the asset creators were done making the required assets about 2 weeks before the project ended, and were left to twiddle their thumbs, which meant they sometimes wouldn’t show up to work at the very end of the project. This was disastrous for morale and the team spirit. It was definitely my fault for not assigning them to other tasks or occupying their time with testing out the game and reporting bugs.

Testing:Maybe the biggest lesson that I learnt from this project was the importance of testing the cooked build of a project every step along the way of the development process. The lack of comprehensive testing led to a disastrous event right before the final presentation where the level transitions (though they worked fine in the editor) completely failed to function in the cooked build.

I was left with no choice but to present the game using the in-editor version, which was decidedly less than satisfying as an experience.

GAME SEMESTER 2014

24Made by Sai Narayan Natarajan.

Scoping:Another thing I learnt a lot about was the critical importance of scoping a project within reasonable limits. At the start of the project we had overscoped by an incredible amount, and I’d be surprised if even 50% of the initially projected features made it into the final version of the game.

SOURCES:1) Hourences. (2006, December 6). Lighting in game environments. Retrieved from http://www.moddb.com/tutorials/lighting- in-game-environments-the-hows-and-whys

2) GAME TIME. (2011, July 1). Flickering Light Material. Retrieved from https://www.youtube.com/watch?v=Vu5x kff50k4.

3) Shad. (2010, July 13). Dialogue System. Retrieved from https://forums.epicgames.com/threads/737078-Beta-0-1-Dialogue-Sys-tem?p=31057896#post31057896

4) Unreal. (2011, January 1). Using Light Functions. Retrieved from http://udn.epicgames.com/Three/DevelopmentKitGemsUsingLight-Functions.html

5) Unreal. (n.d.). Lightmass. Retrieved from http://udn.epicgames.com/Three/Lightmass.html

post mortem of 'the nightmare

Documents