Recent Articles

Week 13

June 7th, 2013

This article is the 17th out of 17 in the series INB379 Journal.

Final presentation.

Miles gave the final presentation to the panelists including industry members. The presentation I believe went well and some feedback about the progression of the story & the marketability of the game was given.

We were also given feedback and how we need to approach this project for the next unit in the next semester. The team will be busy throughout the following seeks to respond to this feedback to start to make our game unique and longer.

Comments Off

Week 12

June 6th, 2013

This article is the 16th out of 17 in the series INB379 Journal.

Changed some code so that the HEV suit doesn’t have to be equipped to enable sprinting. The player can now use the flashlight and the sprint mechanic without equipping the HEV suit, with this we are starting to move more away from the half life code base to create our own unique game.

I’m hoping that during the interim ( semester break ) I will have the time to re-implement some core features of half life with our own code so that it will be easier for other people on the team to edit the code without having to spend an inordinate amount of time dealing with the obscurity of the Source SDK.

Comments Off

Week 11

June 6th, 2013

This article is the 15th out of 17 in the series INB379 Journal.

  • Tweaked torch behavour
  • Created batteries that can be placed around the level that will fill the player’s torch bar as they are picked up.
  • Created an inventory for the player.
  • Created an item the player can pick up that will add items to their inventory.
  • Created a trigger object that peeks at the players inventory and activates if they have the correct number of an item. It also consumes this number of the item from the inventory on use.
  • Changed the sprint behavior so that the player can’t sprint for as long.
Comments Off

Week 10

June 6th, 2013

This article is the 14th out of 17 in the series INB379 Journal.

AI is finally working, and this week I also edited some of the base players attributes in the source SDK to introduce some of the game play elements we desired. The source SDK does have a large amount of it’s values hard coded into the source code, so tweaks and other changes to mechanics have to be done by a programmer.

With the modification of the torch behavior; the game is beginning to instill fear in the player, and is, I believe, coming together quite nicely.

Comments Off

Week 9

June 6th, 2013

This article is the 13th out of 17 in the series INB379 Journal.

A very primitive version of the AI is up and running now, we received feed back from our Friday presentation that we are behind on schedule and that we need to focus on taking all of the elements that are in the game, combine them together and produce a playable prototype.

Comments Off

Week 8

June 6th, 2013

This article is the 12th out of 17 in the series INB379 Journal.

I’ve been busy with work for a few weeks and it has been interferring with the time I have available for work on the games project, but during the last 2 weeks I got set up & running with the Source SDK.

My main task with the Source SDK will be trying to get the AI running to provide an effective challenge against the player.

Comments Off

Week 6

June 6th, 2013

This article is the 11th out of 17 in the series INB379 Journal.

Last week we acquired a new member, Andrew, and this week we selected Assembla as our task tracking system, source repository and have decided to test the viability of the Source SDK as the platform for developing our game.

Comments Off

Game Design – Circa Week 5

June 4th, 2013

This article is the 10st out of 17 in the series INB379 Journal.

What follows is my documentation of the game design circa week 5

Game Design

Item 1: Level Layout & Progression

Starting with some level layout concepts to further refine and develop the aspects of the game design that were not yet fleshed out, we tried paper prototypes of a number of different game play modes that could be used. We also examined how different layouts would impact the game feel.

We decided to abandon the randomly generated levels concept as although it offered re-playability, it increased the design risk of the project and reduced the options we had for selecting our mechanics.
The level layout with the latest design follows a concept where a level has a progressive state towards termination of the game. The termination of the game in the event the player fails. At which point they must restart from checkpoint.

The player starts and interacts with the level in a safe environment, this acclimatises the player to the mechanics & layout of the game. The player has an objective to reach a security room where they can remotely unlock a locked door that is preventing progressing, but when they unlock the door, the lights go out and the player must traverse back through the level without the safety that was offered at the beginning.

This offers the player clear objectives for each level that they must complete, and gives them both and environment to experiment with the game and an environment to have their skills challenged.

The levels do not follow a linear path, they have multiple paths so the player has to use lateral thinking to attempt to avoid obstacles.

Item 2: Monster

The monster design was changed slightly. The monster remains limited to patrolling the darkened areas of the game so the player has the safety of the lights to use. But the monster can capture and ‘kill’ the player if the player fails to avoid & outrun the monster.

The monster walks at the same speed the player does, but runs slightly slower. (Possibly 2% slower, not much slower, just slow enough for the player to get away while keeping the monster a threat.) The monster will walk when on patrol until it spots the player at which point it will run the player down.

If the monster looses sight of the player, but not in terms of the player going around a corner, more in terms of the monster coming around a corner it knows the player went in to, and then not seeing the player, then the monster will return to it’s patrolling mode. It may patrol faster & more aggressively after it has spotted the player, example: an AI algorithm that searches the player out given the player’s last known location and the possible directions the player may have gone in will engage. This ‘searching’ behaviour should be more difficult for the player to avoid then the default patrolling behaviour.

Item 3: Mechanics

Using our paper prototype levels we went through different mechanics that could feature in each and what those mechanics would mean for the game play.

The mechanics the player now has at their disposal are built on top of some base mechanics for movement and interaction with context sensitive objects.

The player mostly walks through the levels, but the player has a sprint mechanic they can engage.

The player has a parkour-esque set of jumping mechanics, but these mechanics can only be engage when the player is sprinting.

The player has a stamina allotment, displayed as either a ‘mana bar’ (which would be in violation of current design thesis) or as a screen colouring effect along with animations of the character to indicate to the player that they are running out of stamina. The stamina is used whenever the player is sprinting. This gives a limit to the players sprinting abilities.

The mechanics should fit the theme of the game as well as provide interesting mechanics. The interesting mechanics are where the player is forced to think up a lateral solution to problem very quickly to avoid failure in the game.
The mechanics along with the level progression fit the themes as the player is given a risk free environment to learn that they can indeed fail to avoid obstacles. Which will then inform them of the very real possibility of their failure to avoid obstacles in situations where there is high risk, when they are being chased by the monster, which will inform the players decision to do everything they can to avoid confrontation with the monster to begin with.

Game Prototypes

AI Prototype:

Getting the AI algorithms working before putting them into the game will be easy in 2D. This will allow rapid prototyping and play-testing of the three different states the monster must act out. A correct patrolling state, a correct chasing state and a correct searching state. Prototyping this functionality in 2D with just a console application will allow a correct implementation to be built without dealing with the issues and debugging limitations of what ever technology we select to build the game with.

The AI prototyping allows us to develop a complex AI at low expense that we can then take into any technology we choose to build the game.

Fluid Prototype:

The monster in the game is currently designed a combination of mist and a dense smoky fog where the monster is such as an aberration rising from the mist. To correctly implement this we will need to create a 2D simulation of a fluid dynamics driven particle system. Having this in 2D will allow us to tweak the force equations to achieve just the right effect, and then port those equations into 3D. It is also a low expense method of putting this artistic aspect on trial to see if the monster doesn’t simply need to be made as a 3D monster of a vague beast. The prototype may also inform the artistic direction as to whether or not a 3D model should be used instead as it should provide enough of an insight to make that artistic decision. All though that insight could be gained by creating a fluid simulation in max.

Room Connection Prototype:

Within what ever technology we elect to use, a prototype to build in that technology that isn’t the direct game prototype itself, would be a prototype to test methods to display levels/rooms using the portal occlusion algorithm. ( Not related to the games ‘portal’ or ‘portal 2′ but I highly suspect that both of these games may in fact have used this occlusion algorithm. )

The portal occlusion algorithm is useful for indoor games, but not outdoor ones, as it treats each section of the level like how ‘screens’ used to be treated in old 2D video games. Only the parts of the level that are known to be possibly visible within a certain space set are shown and each space set becomes a zone that is visible when you are standing in it, or when you are looking through a ‘portal’ to it, i.e.: a door to the room.

This algorithm if successfully implemented will reduce the rendering cost of each moment in the game significantly which can then be leveraged to render the fog/monster as well as rendering little greeblies everywhere to add to the quality of the games art design.

Comments Off

TDD Version 1.1 – Circa Week 5

June 4th, 2013

This article is the 9th out of 17 in the series INB379 Journal.

Technical Details 1.1 for Design 1.1

  • Version: 1.1
  • Date: 2013-03-12
  • Author: Kyall Henricksen
  • Audience: Programmers, Designers, Artists and Stakeholders

Outline

The design of the game creates technological risks for the development as the design creates complexity for which elegant solutions must be found prior to development. The purpose of this document is to outline some simple solutions for intended design features as well as to research the best practices or available knowledge that can be leveraged to achieve the game design while reducing the technological risk. Some features that will be highlighted include random lego blocked levels, narrative driven game play and the rendering issues of the ‘mist’. As of yet this document does not deal with existing architectures or technologies such as which engine or tool set to use, it simply highlights available algorithms or knowledge that can be used to achieve the aspects of the design.

Design Condition: Player Choice

The design requires that the game not be completely linear. The intention is not to avoid linearity, but to allow the player to interact with the environment on their own terms, to provide further immersion. This condition creates problems for the control of game logic. Which will be discussed in the section ‘programming solutions: game logic’.

Design Condition: Lego Block Levels

To meet the design goal of creating re-playability in the game it is desired that the game should have some randomly generated elements in terms of it’s layout and narrative so that when a player replays the game a second time they enjoy a modified experience. As the game play that can have re-playable value added to it is limited to the progression of tasks and challenges, the goal here is to create a series of events when the game is begun that differs with each play through.

As there is an intended narrative and theme to the game, the game does not fit under the heading of Emergent game play, such as a game like Mine craft would. The game would fall under the heading of more scripted game play. Hence the randomisation method that is available is not the procedural generation of a world by set rules, but the design of levels into pieces that can be made to fit together in different orders. When the player creates a new game, the pieces will be fitted together to provide a different challenge to the player. For an example of a randomly generated set. Lets say we have 3 rooms. One room contains a key, the other contains a challenge and the third contains a door. We use this rule as the basis for the generation of a level, and then all we need to do is to swap in and out each room to create a different play through from others. But since the location of the key, the location of the door and the location of the challenge are all scripted items, every player will have a shared experience of the game, this allows us to leverage our narrative and theme into an environment that is randomly generated.

This randomisation however creates problems for programming of the game logic. This problem also arose from the design condition that the player would have some element of free choice in how they progress through the game. The solution to this issue will be dealt in the section ‘programming solutions: game logic’.

Design Condition: Narrative Driven Game Play

The design requires that the mechanics of the game reflect the narrative. This technique has been used in commercial games such as “Spec Ops: The Line”. Critics of the game ‘Spec Ops: The Line’ pointed out it’s clunky controls that seemed outdated compared to more streamlined modern shooters. It was suggested by some critics that this was a deliberate decision by the developers to reflect the games theme. A design goal is to use the same technique but more elegantly. Slightly varying attributes of the mechanics throughout the game to use the mechanics to get the games theme across.

This can be achieved in at least 2 ways. By changing the FOV of the projection matrix (camera) that the game uses. And by modifying the sensitivity of the mouse/gamepad and/or increasing the movement speed tied to the controls of the keyboard/gamepad.

Programming Solution: Projection Matrix FOV

The FOV of the projection matrix, aka camera, is in modern times one of the most commonly varied elements to create more immersion in a game. Many flying and racing games will modify the FOV to communicate to the player the issue of velocity. Some will introduce an element of turbulence to the FOV when a players avatar is moving at terminal velocity or maximum speed, to communicate to the player that they have reached maximum velocity and can go no faster.
Our implementation will not be velocity driven as the game is neither racing nor flying, but we will leverage the same mechanics so that throughout the game the players field of view continues to contract to communicate a height of tension to the player, to communicate a message that ties in with the narrative.

Programming Solution: Mouse Sensitivity

For the purposes of allowing designers to tweak/polish the way the mouse sensitivity is varied throughout the game it is up to the programmers to implement an equation that contains fixed input parameters that the designers can set and have at least one parameter that is varying and is derived from the state of the game.

In order to make it easier for the designers to tweak this mechanic to achieve the effect they want, the mouse sensitivity equation needs to contain a term that eliminates increases in sensitivity caused by the contraction or expansion of the FOV. The contraction and expansion of the FOV will give the player the impression that their input is changing the view point more slowly or more quickly, so this effect needs to be neutralised.

For the neutralising equation: I can’t come up with the equation of the top of my head, but I’m pretty sure it will be derived from visible rads with a given FOV, and rads of rotation with a given input.

Rads rotation = ( base rads rotation ) / ( current FOV / base FOV )

Or something like that.

Design Condition: The ‘Mist’

The mist is an enemy in the game that leaves a trail of darkness behind it and is the constant threat to the player. When the player enters the mist the mechanics of the game change slightly and there are denser areas of the mist that are harder to move through. The changing mechanics as you move through the trail or the mist itself are not main technological challenges. However the rendering of the trail and the mist itself do represent technological challenges.

Programming Solution: The ‘Mist’ Trail

An old technology used by games is the ‘lighting map’ technology. This technology was limited in how dynamic it was, as well as how well it could represent directional lights. It also lacked the ability to cast shadows. This technology is one where an effect of lights was embedded into the vertices of non dynamic elements so that when rendering the lighting would be calculated based off the precomputed lighting values rather than the locations and intensities of the lights themselves.

Taking this technique but with modernisation and with a bit of trickery should allow us to render the mist trail effective. And the resulting method of achieving it is based on how the mist itself behaves. If when we generate the random levels we also generate the path of the mist itself, aka a fixed path mist, then we can embed data into the vertices that tells the rendering pipeline what to do based off a global value ‘mistalpha’ where mistalpha starts at zero and progresses to value 1. We send this ‘mistalpha’ value to the shader, and the shader then uses an equation to determine if an area is in the mist trail or not. This however means that the mist cannot disappear from an area it has consumed, and can not react to player movements.

The other method is if the trail must disappear from an area or if the mist must react to player actions and that is one in which the effect of the mist on different vertices of the environment mesh must be recomputed and the mesh updated according, with each frame. If there are two conditions to being under the influence of the mist, entering mist or leaving mist, then we will only have to update the geometry that is affected by where the mist is moving into and where it is moving out of. We will not need to modify the geometry of the entire level.
The difference between these two techniques is simply pre-processed or computed in real time, and the choice must be selected depending upon the design condition for how the mist is to work.

Programming Solution: The ‘Mist’ Itself

http://www.youtube.com/watch?v=RuZQpWo9Qhs

The mist needs to be a visually impressive and foreboding presence. To achieve the kind of quality that will reflect well on the game it will be necessary to render the core of the mist using particle/fluid simulation, particle or volumetric rendering or some combination of these. This represents a great technological risk to the project, as it will most likely require very direct access to the hardware to achieve. Requiring direct access to hardware to achieve a rendering/simulation effect that is specific to our game, may result in the ruling out of many available tools and middle-ware for building the game.

Most fluids used in games are simply 2D surfaces that have a manipulator along a third access to give the impression of a 3D fluid. As we will require a true 3D fluid, the existing rendering techniques in most engines do not apply. When it comes to selecting an engine or set of technology to build the game, we must select one that allows us direct access, using C or C++, to the hardware as well as being able to directly modify shaders and the parameters sent to the shaders.

Thankfully because our visual effect is a mist, we don’t need a particle simulation with millions of particles like you can see here:

http://www.youtube.com/watch?NR=1&v=g-GFoYolLSU&feature=fvwp

A few hundred points on a vector flow graph, driving a volumetric rendering, should be sufficient for the effect we desire.

Programming Solution: Game Logic

It is possible to build the game directly using scripted sequences and standard methods of building game logic but I would not advise it. Given the randomness of the levels it would be impossible to test in all possible scenarios that the game is indeed working without non-progress bugs. It would also be infeasible in managing the logic of the games narrative given the free choices the player has. The options for how the game logic can be programmed are as follows:

  • A hierarchy of conditions from the microscopic level up to the macroscopic level that tests the player actions against a game state where each condition handles the progress of the game and this map is generated to match the game map when the world is created.
  • An artificial intelligence based approach where a knowledge based agent, otherwise known as a logical agent, is used to handle the games logic.

Conditions System

With the hierarchy set, a class would be created to describe every game condition, and those classes would detect player actions to see if given conditions have been met. When a condition is met, an action will be performed, such as opening a door, so that the player can proceed. The next level up in the hierarchy would determine if the player has completed a set of tasks for a section of the game, and the next level up in the hierarchy would determine if the player has achieved a success state where the final level of the game could commence.

A condition class, other than having unique code for each condition, will also have a set of children, if applicable, as well a sibling, if applicable and a parent, if applicable. When the player has reached a condition success state for one condition, the sibling condition would then be activated. When no sibling condition is met, the parent condition would be activated. And when a condition is entered, the game actually navigates down to the lowest level child condition of that condition, if that condition has not already been met.

The flaw in this design is that this creates a linear pathway through the game in its ( the systems ) most basic state. The game can be made to have multiple pathways through some hard coding, but as the multiple pathways are not compatible with the design in earnest, this limits the number of free paths the player has to progress through the game.

The benefit is that this system matches well against randomly generated levels by blocks, where many levels of multiple pathways are not a requirement.

This system can be seen as a normal, industry standard, based on the thinking behind it, solution to this problem.

AI System

The alternative is to use an artificial intelligence to control the game logic.

http://aima.cs.berkeley.edu/newchap07.pdf

If we were to create an artificial intelligence to play through the game itself, that artificial intelligence would need to know the goals, such as proceed through a door, the microscopic goals, such as collect a key so that the door can be opened, and would solve the problem of succeeding at the game, in the same way the player would. This means that we can create an artificial intelligence that can be used to control the game logic. The artificial intelligence would know that a door needs a key, it would know that it needs to complete certain sections before it can proceed to the main goal. It would serve as a nice replacement to any other game logic system.

Artificial intelligences are designed to succeed in conditions even when there is an element of randomness or the unknown, building an AI to control the games logic will allow the games logic system to react to the randomness, the players free path through the game, with a great amount of code simplicity.

The benefit is that the AI doesn’t need to be strictly constructed or built. It supports the ability to create randomised levels that do not need to follow a linear chain. The impact this solution has is code simplicity as well as freedom for the designers to create a non-linear game that engages the player more.

Both of these solutions are sufficient for creating the game. I am however in favour of the AI.

Comments Off

Week 5

June 4th, 2013

This article is the 8th out of 17 in the series INB379 Journal.

Second group presentation and second feedback.

Topics discussed:

  • Miles reiterated on the design from the previous week displaying new character elements as well as new features.
  • Discussion of methods for prototyping different features of the game to reduce technological risks.
  • Discussion of how the technological solutions that can be used can make the game design’s aspects possible.

Feedback Received

  • Game play was not sufficiently fleshed out.
  • The concept of the monster and what that means for play is not clear, not is it apparently workable.
  • Player can simply keep out running the monster which doesn’t provide game play or challenge.

Group Meeting in Response To Feedback

Levels

To help us respond to feedback, brainstorm mechanics and figure out the overarching progression of the game we drew up a bunch of different types of levels and went over how the world could work and how the mechanics could work extensively. This was the tool we used to refine the games design.

Mechanics

It was commented that the player mechanics of the game were not well fleshed out, and the game design didn’t clearly show aspects that would challenge the player or allow them to engage in the game play in a fashion that you would want in a quality game. In the team meeting we went over extensive lists of options we could use, crossing out the ones that didn’t fit or wouldn’t work, until we had a set of mechanics orientated around avoiding obstacles in the game with a limited ability to do so. The player has the ability to sprint, jump & perform other fast & fluid actions to escape the monster, but at the cost of a ‘stamina bar’ (unlikely to actually be shown as a bar, except during development ). The monster becomes a quantity the player must attempt avoid as there is a definite risk of failure should they attract the monsters attention.

Meeting Resolution

I believe the feedback was a good guide for us to help us better form the games concept as well as mechanics and at the end of the meeting we had a design that we can build in the confidence that the end result will be an engaging game that challenges the player through a set of mechanics that govern the player, the world & the monster.

Comments Off

Older Posts