So this is the showcase for the game we've been working on for our 2nd semester project. The team is called Good Lord! What a lot of biscuits! The team name has a long story about it, maybe a story for another post. P.U.N.C.H is a product of 7 programmers, 1 artist, 1 designer and a producer and was developed using the Havok physics engine.
Saturday, 11 May 2013
Limbo: A beautiful and horrible experience
(Artical was originally part of assessment for a narrantology/ludology module for my postgraduate)
I started playing a game called Limbo; it’s a small indie game that’s gotten a good reputation from fans. It’s a beautiful looking game that sets the environment up perfectly, with its minimalist scenery and monotone colours. Everything on screen matches the beautiful but depressing path the boy character follows.
But what surprised me the most was the amount of attachment I had gained in the first 60seconds of gameplay. A boy wakes up in a forest. The smooth running animation glides you across the grass to the next scene. My first reaction was ‘awww how sweet, I’m going to love this game’. I see something on the floor, I go to investigate but get too close. The bear trap snaps shut around the boy’s body which ricochets like a rag doll with the force, decapitating him with a small squirt of blood. It happens so fast it makes me jump. My mouth just dropped, I was in complete shock and within 60seconds of me starting the game, it had managed to make me feel guilty. I shouted ‘IM SO SORRY!’ at the little boy. This theme continues throughout the game but never seems to get old. I felt so attached to this boy; I felt so much responsibility towards his survival. When he fell from a tree and broke his legs, when he got flattened by a rolling boulder, when his convulsing body drowned in a small pond, I had exactly the same reaction each time.
It’s got nothing to do with the graphic deaths. I've played games with much more gore than this. Nor has it anything to do with the death of a child, this concept isn’t one of much horror to me. It is however completely down to the atmosphere the environment makes. The simplicity of each scene draws all your attention to the death, it allows for no visual dilution. The smoothness and fluidity of the boy’s animations are in contrast with the large, sparse surroundings making him seem far more vulnerably and human like. The death events can happen so quick that in less than a second you’re left with nothing, and the boy always dies in one hit. I think this is a fantastic example as to how effective spatial use can be in games, compared to any other medium in which it barely exists at all. This game would not be viable in any other format.
I started playing a game called Limbo; it’s a small indie game that’s gotten a good reputation from fans. It’s a beautiful looking game that sets the environment up perfectly, with its minimalist scenery and monotone colours. Everything on screen matches the beautiful but depressing path the boy character follows.
But what surprised me the most was the amount of attachment I had gained in the first 60seconds of gameplay. A boy wakes up in a forest. The smooth running animation glides you across the grass to the next scene. My first reaction was ‘awww how sweet, I’m going to love this game’. I see something on the floor, I go to investigate but get too close. The bear trap snaps shut around the boy’s body which ricochets like a rag doll with the force, decapitating him with a small squirt of blood. It happens so fast it makes me jump. My mouth just dropped, I was in complete shock and within 60seconds of me starting the game, it had managed to make me feel guilty. I shouted ‘IM SO SORRY!’ at the little boy. This theme continues throughout the game but never seems to get old. I felt so attached to this boy; I felt so much responsibility towards his survival. When he fell from a tree and broke his legs, when he got flattened by a rolling boulder, when his convulsing body drowned in a small pond, I had exactly the same reaction each time.
It’s got nothing to do with the graphic deaths. I've played games with much more gore than this. Nor has it anything to do with the death of a child, this concept isn’t one of much horror to me. It is however completely down to the atmosphere the environment makes. The simplicity of each scene draws all your attention to the death, it allows for no visual dilution. The smoothness and fluidity of the boy’s animations are in contrast with the large, sparse surroundings making him seem far more vulnerably and human like. The death events can happen so quick that in less than a second you’re left with nothing, and the boy always dies in one hit. I think this is a fantastic example as to how effective spatial use can be in games, compared to any other medium in which it barely exists at all. This game would not be viable in any other format.
Labels:
Abertay Uni
Location:
Dundee, Dundee City, UK
Saturday, 20 April 2013
Error: Stack Overflow
The stack is a part of memory used by your program at run time. It has a predefined size allocated to your program (based on different things like language etc). A stack overflow is when a program uses too much memory from the stack by trying to go outside its allocated area.
The most common reason for this error is infinite recursion:
int function()
The most common reason for this error is infinite recursion:
int function()
{
Or a deep recursion function that compiles but overflows on use:
void function (argument)
Which can be fixed by using stack loops:
Stack overflow caused by infinite recursion:
bool ifCollision()
return function();
}
Or a deep recursion function that compiles but overflows on use:
void function (argument)
{
if (condition)
{
function (argument.next);
}
}
stack.push(argument);
while (!stack.empty())
{
argument = stack.pop();
if (condition)
{
stack.push(argument.next);
}
}
Another possible cause could be by using stupidly large variables, the array below takes up 8 megabytes!
double x[1000000];
Previous examples I've accidentally coded:
Stack overflow caused by infinite recursion:
bool ifCollision()
{
if(oasisCollision)
{
}
}
if(oasisCollision)
{
}
}
bool oasisCollision()
{
if(condition)
{
ifCollision();
}
}
{
if(condition)
{
ifCollision();
}
}
Location:
Dundee, Dundee City, UK
Saturday, 30 March 2013
Elephant Algorithm: They Never Forget
At the moment the elephant memories are represented by a 2
dimensional array but I was actually thinking I might put different types of
geographical locations in other that just the oasis, and use a 3 dimensional
array for the elephant memories. The 3rd index being a 'tag' to distinguish
between the type of location. This might end up as polish though as I want all
the basics in by the end of this weekend so I can start on the crowd algorithm.
Elephants can now store information on where the oasis' are
located. This is done by calling a remember function on collision, which stores
the current x and y position. An elephant will continue to store coordinates as
long as there is collision. The result is the storage of not only the
geographical location but also its partial coverage (the area in which the
elephant travelled). Originally only one coordinate was going to be stored but
this way has given the memories more depth and given the algorithm more
functionality, without increasing the complexity. I'm very pleased with how
this has worked out even though it isn't as planned. However it is currently
using arrays 3600 in size, eventually this should be changed to a vector to
increase efficiency.
I would also rather the arrays size was set on the fly at
run time based on the number of various locations, which would be randomly
placed and in randomly set quantities. Probably with a limit to the amount of
locations present based on the screen resolution. The amount of elephants could
be generated at run time too. It's likely that these features won't be in the
build I hand in in May but I have enjoyed working on this project and so I will
carry on working on next semester.
Labels:
Abertay Uni,
Allegro,
C++,
Project
Location:
Dundee, Dundee City, UK
PS2 Project Proposal
I handed in my project proposal for the PS2 module. I plan
on allowing the player to 'cast spells' by shooting a fire ball at enemies and
the enemies will catch fire too. I'll need a model of some kind to represent
the enemies and ill need a chase function so they chase the player, then some
kind of collision detection, box probably, nothing fancy. The fire ball will be
the main feature as I want it to be an animated texture on a sphere model. I've
done this before in my Direct X module last semester so I understand the theory.
I need 3 textures of varying opaqueness and layer them on top of each other
over the sphere. Then I have to cycle each texture across the surface at
different speeds.
Labels:
Abertay Uni,
C++,
Project,
PS2 Development
Location:
Dundee, Dundee City, UK
Sunday, 24 March 2013
Elephant Algorithm Project
It was my intention to finish the 1st algorithm for my
innovation project by the end of the month. This leaves me with this weekend
and next weekend to complete it (at least the code, write up can come later).
Managed to get the collision between elephants and oasis in with no problems. Elephants now know when they are at an oasis or not, they just don't do
anything with the information. Next I have to store the information so the
elephants can use it.
Labels:
Abertay Uni,
Allegro,
C++,
Project
Location:
Dundee, Dundee City, UK
Narrative Presentation
Spent most of my time this week working on a presentation
for my narrative module. The task was to analyse the narrative of a game of
your choice to an academic level. So I posed the question 'does having a small
development team have an impact on narrative quality'. I chose the game
Penumbra for this specifically because the company behind it (Frictional Games)
numbered just 3 at the time of development and the game originally started off
as a tech demo for their in-house engine. All graphics, audio and writing was
outsourced. Even now the company has only 5 employees and the rest is
outsourced. But the 4 games they've produced so far could be mistaken for AAA
games. Anyway, the problem i had is that i gathered loads more information than
i needed too. Then found i had to cut loads of it out to fit it into 8mins. So
the end result became a jumble of information that didn't necessarily relate or
prove anything. The presentation itself wasn't grate either as this my skills
in this area are weak. This aspect of the assessment is only worth 20% so im
not that bothered and the good news is that i am going to use all the
information i gathered to form my essay for this module, worth 60%. So less
work for me.
Labels:
Abertay Uni
Location:
Dundee, Dundee City, UK
Saturday, 23 March 2013
Tutorial: 2D Box Collision
2D Box Collision
Theory
If the corner of one square is inside the other square the
collision has occurred. For easier reading write 4 functions which check for
possible collision on each side (left, right, top, bottom). Then write another
function that compares which sides have a possible collision to figure out if
collision has actually occurred.
Example
Write a function that checks collision with a single side.
Note: sprite is 30 pixels large and getX and getY return the origin point of
the sprite which in this case is the top left corner.
bool Blue::possibleCollisionLeft(Orange* orange)
{
//get necessary coordinates
int blueLeftSide = getX();
int orangeLeftSide = orange->getX();
int orangeRightSide = orange->getX() + 30;
//return true if collision could occur on left side
if((blueLeftSide <=
orangeRightSide) && (blueLeftSide >= orangeLeftSide))
{
return true;
}
else
{
return false;
}
}
Write a function like
this for all 4 sides.
Then bring them all together in another function to compare
which ones return true. And don't forget to check if its even colliding with the object you want. If its not then return true, doing this at the beginning of the function will stop the function comparing all the edge functions for no reason.
bool Blue::orangeCollision(Orange* orange)
{
if(!orange)
{
return false;
}
if(!orange)
{
return false;
}
//compare collision function results, return true if a collision
has occured
if((possibleCollisionRight(orange)
== true && possibleCollisionBottom(orange)
== true)
|| (possibleCollisionLeft(orange) == true && possibleCollisionBottom(orange) == true)
|| (possibleCollisionLeft(orange) == true && possibleCollisionTop(orange) == true)
|| (possibleCollisionRight(orange) == true && possibleCollisionTop(orange) == true))
{
return true;
}
else
{
return false;
}
}
Tuesday, 12 March 2013
Elephant Algorith Project
Started on my innovation project, it's all going to plan so
far. I've got the basics for the elephant based algorithm demo in. Elephants
move around on screen on their own and the geographical locations (oasis) are
in too. The next step is to give the elephants a memory back which will
probably be made out of an array. Once that's done I have to work out how to
transfer data both ways when two elephants have collided. This shouldn't be too
hard anyway as the elephants have their own class and so a change to one will
change them all. It's more a case of, arrays can confuse me a lot and collision
can be a nightmare. Once these two features are in though the rest should be
straight forward. Then that's one algorithm and demo down and one more to go.
The aim is to get this one finished by the end of this month, and the second
one finished by the end of next month, leaving me 17 days until the hand in for
polish, paper work and to work on the 4 other modules that are due in on the
same day.
Labels:
Abertay Uni,
Allegro,
C++,
Project
Location:
Dundee, Dundee City, UK
Monday, 11 March 2013
Tutorial: Terrain Smoothing
Terrain Smoothing
Theory
Take one point. Then take its 9 neighbouring points. Work
out the average height of the 9 points, and set it to the original point. Pass
it through multiple times to be smoothed more.
Example
The framework already has a function for height generation
and a function for random noise generation. It also has a single dimensional
array to represent the 2D terrain so the example is in a triple nested for loop.
In an ideal world a multidimensional array would better suit the representation
of a 2D plane.
- The smoothing was put into its own function and called from within the terrain generation function. Strength will be how many times you want to pass the terrain through to smooth it. The higher the number the more it will be smoothed.
bool TerrainClass::GenerateSmoothing(float strength)
{
- Then make a for loop to carry out the smoothing as many times as required.
for(int times; times < strength; times++)
{
- Start cycling through the terrain array.
for(int j = 0; j < m_terrainHeight; j++)
{
- In this example it has to go through 2 loops because it's a single dimensional array.
for(int i = 0; i < m_terrainWidth; i++)
{
- Make a temporary variable to hold the value of the average height for the 9 adjacent heights.
float totalAdjacentHeight = 0;
- Find each point using the array (see diagram) and add it to the temporary variable.
i+1, j+1
|
i+1, j
|
i+1, j-1
|
i, j + 1
|
i, j
|
i, j-1
|
i-1, j+1
|
i-1, j
|
i-1, j-1
|
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j - 1), i - 1].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j ), i -
1].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j + 1), i - 1].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j - 1), i ].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j ), i ].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j + 1), i ].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j - 1), i + 1].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j ), i +
1].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j + 1), i + 1].y;
7.
Retrieve the original
point(the centre position in the diagram) and set it equal to the temporary
variable (after you've / 9 (9 for 9 neighbours) this is the average)
m_heightMap[(m_terrainHeight * j),
i].y = (float)(totalAdjacentHeight
/ 9.0);
8.
Close off the
function.
}
}
}
return true;
}
Source Code
bool TerrainClass::GenerateSmoothing(float strength)
{
for(int times; times < strength; times++)
{
for(int j = 0; j < m_terrainHeight; j++)
{
for(int i = 0; i < m_terrainWidth; i++)
{
float totalAdjacentHeight = 0;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j - 1), i - 1].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j ), i -
1].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j + 1), i - 1].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j - 1), i ].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j ), i ].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j + 1), i ].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j - 1), i + 1].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j ), i +
1].y;
totalAdjacentHeight += m_heightMap[(m_terrainHeight
* j + 1), i + 1].y;
m_heightMap[(m_terrainHeight * j),
i].y = (float)(totalAdjacentHeight
/ 9.0);
}
}
}
return true;
}
DirectX Terrain Smoothing
If added smoothing into my DirectX. The theory behind it is
quite simple. Work out each points height by averaging the neighbouring
heights. The problem i had was that the framework works out the height terrain
with a single dimensional array instead of a multi dimensional array. So i had
to use a triple nested for loop just to get it to work. One for each pass through the smoothing (the
more passes you make the smoother the result is), one for the height and one
for the width.
Labels:
Abertay Uni,
C++,
DirectX,
Project
Location:
Dundee, Dundee City, UK
Friday, 1 March 2013
Havok Project
This week we started working on the new prototype for the
house wrecking game. I worked on making objects randomly drop a coin when it’s
smashed. This code will then be used to update the score when a coin is
collected. I had to wait to put my code into the project because it relied on a
function that someone else was writing. Rather than waiting I went ahead and
wrote the code as I knew it wouldn't take long. I then translated it into Lua
as I didn't know if the code I was waiting on would be in a component or a
script. Testing ended up being peer
programmed because of version control issues, but largely remained the same. I'm not required too but I'm doing to go beyond my task and try to make a ‘COIN’
object actually appear when an object is smashed rather than it just displaying
‘COIN’ to the screen. I have no idea how to create objects from the code alone
without using the engine but it seems like it would be something were going to
do a lot of and this feature would be needed anyway so it would save time if I
did it now.
Lua, from the little I’ve done, seems to be quite a nice
language. I was expecting to find the syntax difficult and to get confused
between languages as I am working with two. The version control however seems
unnecessarily complicated. I’ve never used any version control before so I am
unfamiliar with it. But setting it up was a real hassle and I still doing
really know how to use it. A lot of us are having problems using the interface.
Labels:
Abertay Uni,
C++,
Havok,
Lua,
Project
Location:
Dundee, Dundee City, UK
Friday, 22 February 2013
PS2 Development
This week I started on PS2 development. I've only been doing
the controls so far but I'm really enjoying it. I've covered all the all the
buttons, analogue sticks pressure and vibration, but what I really want to do is
make a small framework with all the controller features mapped so I can use it
for my project. I have to wait until the room is free though. I don’t like not
having the equipment available for me to do it at my desk or at home, I'm not
use to it. There is one thing now ingrained in my memory though. At the end of
the program the controllers don’t automatically unlock from the mode they've been
set in (analogue/digital). So you have to remember to unlock it at the end of the
code. Whilst implementing the vibration controls I hadn't yet found this out. I
ran the program and the controller started to vibrate. But because the
controller was locked in analogue mode when I closed the program it carried on
vibrating. There was an awkward 15 mins involving 3 people working out how to
stop it vibrating and me constantly holding the controller in the air to stop
it making a noise against the desk.
Labels:
Abertay Uni,
C++,
Project,
PS2 Development
Location:
Dundee, Dundee City, UK
Thursday, 21 February 2013
DirectX Framework
I also got given the new framework the PC and Xbox module.
I’ve gone through half of it to make sure I understand what’s going on and made
my own comments etc. I noticed the controls were, at least to me, very counter
intuitive. So I’ve started converting them over to a more FPS look-move style
control. Putting mouse control in was easier than I expected. The camera now
points at the mouse curser but now I have to get forward to go in the direction
that the camera is facing. There are two tutorials I’ve found but they look
really complicated. It looks like I’d have to modify and add a lot of code to
make it work. I think I might have under estimated the task and it might never
actually get implemented. This means I could end up taking the camera look
controls out too.
Labels:
Abertay Uni,
C++,
DirectX,
Project
Location:
Dundee, Dundee City, UK
Monday, 11 February 2013
DirectX Randomized Terrain Generation
Started implementing procedurally generated terrain when the
space bar is pressed for my directX module. I wrongly assumed that the code to
procedurally generating stuff would be long and complicated. But you can
produce basic mountains with only 2 functions. Randomly generating the terrain
was literally as obvious as using a random number generator on the y axis. Mine are really
spikey/ridged mountains so I want to add some smoothing to make them look more
realistic.
Labels:
Abertay Uni,
C++,
DirectX,
Project
Location:
Dundee, Dundee City, UK
Subscribe to:
Posts (Atom)