Test Report
The most testing that we did in our game was performed during the Monday of Level Up. This was useful because it was the first time people outside our group had really touched our game. There were many problems with our game at this point, a lot of which we knew of. We received many helpful criticisms that we hadn’t thought of up to that point.
The most major problem people had with our game was the fact that no one could understand what caused them to die; we had enemies, but their bullets were never visible. We knew we had this problem and it was something we needed to fix, but having all the comments on it really reinforced the fact that we needed this. We managed to fix the fact that enemy bullets were invisible and also changed the colour so that it differed from the player’s bullets. One thing we weren’t able to add was the damage shader we had first semester as it was constantly crashing our game and we couldn’t figure out why.
Another problem that has existed in our game for the entire semester and was pointed out by professors in both first and second semester was the “dynamic” camera. What people at Level Up and our professors agreed on was that the camera was fairly disorienting with its jumpiness. This also affected how players could control and shoot because with the view constantly changing everything became very confusing quite quickly. We managed to change the camera so it was still dynamic and acted as a battle camera. Now the camera is much smoother with all jumpiness completely removed. Testing this new camera showed that our game was much more playable. It now looks less like a glitch and more like an intended mechanic.
Some more feedback we received, although not as much as the other major points, was about the level designs. When we were receiving feedback on our game the levels present within were not yet updated to our newer models, however the feedback we received was still helpful. The feedback that changed our levels the most was people saying they didn’t know the controls, what buttons did what, some mechanics were even completely unknown of because there was no mention of them anywhere. To accommodate this, in the first level we added billboards that slowly showed the player the controls and also lowered the enemy count to give the player more room for failure. Another comment on the level design was about texture stretching, a problem that we have since eliminated with our new levels and we have received many more positive comments on the level design since.
The feedback we got on all these problems was very helpful in letting us realize the errors of our ways. Many times when we were testing things within our group and when someone thought something was bad everyone would just shout “no, no that’s fine”. This testing helped us realize that these were actual problems that needed to be fixed even though some of us couldn’t see it ourselves. Overall this feedback helped to make our game much better and a product we are much prouder of than we were just a week prior.
RayCasting: The following is a code snip of RayCasting for our game. In this function we take in a start, end point, an id of which object is shooting and an id for if it’s a player or an enemy. These variables allow for the ray to shoot into the scene and return the proper data for what it hit. For example we take in the ids, to avoid friendly fire and to give a separate color for the player and enemy. The start point – end point also give a length for the ray. To give a longer ray I take the direction from the start to end and multiply that to the end point so if the ray misses it will hit the wall behind the target. As well there are typedef structs are used to save data on each Rigid Body in our scene. The data consist of id number, a type number, health and max health.
void GameState::Raycast(Vector3f startPoint, Vector3f endPoint, int id, int pid){
//Sounds
mSoundPew->stop();
mSoundPewSlow->stop();
if(SM->m_SpeedUpdate >=.5)
mSoundPew->play();
else
mSoundPewSlow->play();
kill = WM4_NEW bool;
*kill = false;
if(mKill==false)
objectHit2 = m_Beam[id]->fire(endPoint ,startPoint, kill,(id-1),pid);
mKill = *kill;
delete kill;
if(mKill == true){
if(objectHit2->getUserData()!=NULL ){
myData *dkill = (myData*) objectHit2->getUserData();
if (dkill->type==3)//Player
{
SM->m_hW->getHavokWorld()->markForWrite();
myData *j = new myData();
j->id= 0;
j->type=3;
j->healthMax=30;
j->health=j->healthMax;
j->dmg=0;
mEarth_RB->getRigidBody()->setUserData((hkUlong)j);
SM->m_hW->getHavokWorld()->unmarkForWrite();
GC->addf(“player”);
GC->addf(“\n”);
dead=0;
revive=0;
kUpFlag=false;
kDownFlag=false;
kLeftFlag=false;
kRightFlag=false;
mFadeFlag=true;
//SM->ChangeState(GAME);
}
if ((dkill->type==2))//Player
{
SM->m_hW->getHavokWorld()->markForWrite();
SM->m_hW->getHavokWorld()->removeEntity(EnemyArray[dkill->id]->getRigidBody());
SM->m_hW->getHavokWorld()->unmarkForWrite();
m_scene->DetachChild(EnemyArray[dkill->id]);
EnemyArray[dkill->id]=0;
}
mKill = false;
mSoundExplosion->play();
}
}
}
Camera: CameraUpdate Camera function is what makes the camera smoothly change between targets. It takes the nearest enemies postion and the postion of the player to find a middle point to focuse on. It then sets that as its target an interpolates to that position. If there are no close by enemeis the target resets to the player and the camera interpolates to that postion.
Not included in the following example is the code that finds the nearest enemy. It also grabs the distance between the player and enemy and uses that to create an optimul distance so that the player and his target are always in view.
The main point of this code is interpolation and always soomthly switching to a new location by getting a dir and applying it to a camera focus vector. This fixes a lot of issues that we used to have with the camera snapping to points.
void GameState::UpdateCamera(){
Vector3f dist = Vector3f(0,0,0);
Vector3f Dir, Dir2,Dir3, moveDir, moveDir2;
float mag, mag2, mag3;
Vector3f target = Vector3f(0,0,0);
Dir3 = nearTarget-targetNear;
mag3 = Dir3.Length();
//if(mag3>5){
Dir3.Normalize();
targetNear+=Dir3 *(mag3*.05);
//}
//if both player and enemy are near zoom in else zoom out
if(mNear == true){
if(camTime < 1)
camTime+= SM->m_timeDeltaT; //Inc by delta time
else
camTime = 1;
Dir2= kCamFo-mEarth_RB->Local.GetTranslate();
}
else{
if(camTime >0){
camTime-= SM->m_timeDeltaT;
}
else{
camTime = 0;
}
Dir2= kCamFo-((mEarth_RB->Local.GetTranslate() *(.5)) +( targetNear *(.5)));
mZoom=0;
}
kCamFo = ((mEarth_RB->Local.GetTranslate() *(1-camTime)) +(
((mEarth_RB->Local.GetTranslate() *(.5)) +( targetNear *(.5)))
*(camTime)));
target= kCamFo+ Vector3f(0,10,20);
mag2 = Dir2.Length();
Dir2.Normalize();
if (mag2 >5)
{
kCamFoUpdate +=(Dir2);
}
m_camera->setFocus(kCamFo);
Dir= target-m_camera->Local.GetTranslate();
mag = Dir.Length();
Dir.Normalize();
moveDir=(m_camera->Local.GetTranslate()+(Dir*(mag/30)));
m_camera->Local.SetTranslate(moveDir+Vector3f(0,0,mZoom));
mNear=false;
}
Level Loading: Gameplay takes place entirely inside of the Game State and every time a new level is loaded an entry is made into a save file. Upon reloading the Game State the save file is accessed in create scene and it uses the information in the corresponding scenes data file to know what level to load, how many enemies to load, how many doors there are and also what keys have and have not been collected yet. This has to be done this way because of a limitation of information provided in the HKX file as its near impossible to search through a scene that has been exported from Maya via the Havoc exporter. The benefit from how we have our level system in the game is that new levels can be made fast and effectively as long as the level’s designer follows a few simple rules.
GameState.cpp (Level Loading Snippet)
ifstream myfile (“Source/Resources/SaveData/savefile.txt”);
string loading;
getline(myfile,loading);
mLevelID = atoi(loading.c_str());
getline(myfile,loading);
SM->mFileNameImage = loading.c_str();
getline(myfile,loading);
SM->mFileName = loading.c_str();
getline(myfile,loading);
SM->mFileLlevelData = loading.c_str();
myfile.close();
Rules
- Name the player appropriately.
- Apply Rigid bodies to the level, player and enemies.
- Name the level appropriately.
- Name Enemies appropriately.
- Place the player’s model in the scene where he will start.
If all of these rules are followed the person creating a level only has to enter the number of doors and how many enemies into the corresponding data file for that level.
Sample Save File
1 //how many doors
Door91_rb //the doors name
9 //means HUB level is the destination
1 //current level
Source/Resources/HUB/ //path to destinations level assets (images)
Source/Resources/HUB/HUB.HKX //path to destinations level file
Source/Resources/SaveData/HUB.txt //path to destinations save data
1 //how many enemies are in this level
Enemy1_rb //enemies name
E1P1 //point used for enemies 1 pathing
E1P2 //point used for enemies 1 pathing
2 //how many keys are in this level
Key1_rb //first keys name
Key2_rb //second keys name
State Manager: Our StateManager system was designed and coded as a singleton, factory, and state system. It was posed as the crux of the game, so all game flow occurs through it. Each state (GameState, MenuState, etc.) are defined as enum integers, and all are of the base type State. Whenever the programmer would like to push a state, all he would have to do is pass the appropriate enum identification as a parameter, and the StateManager would then create a new State of the respective derived class type endogenously. For example, to push a PauseState on top of GameState, the programmer would just have to call the push state function, and pass simply the word PAUSE as a parameter. StateManager then does the rest.
SM->PushState(PAUSE); //Function call.
Whenever the programmer would like to pop a state, he may do so at point in the program – even within a running state. For example, if WinState is running, and the player pushes the spacebar to return to the main menu, the StateManager can be called to pop the current state, which is the WinState. To avoid data corruption, whenever a state is popped off the state stack, it is not immediately deleted; although it is popped off the stack, it is then pointed by a temporary pointer. By the next frame, StateManager checks if its temporary pointer is pointing to a State. If so, it then deletes it.
//Delete “StateToDelete” if it exists.
if (m_stateToDelete != NULL)
{
m_stateToDelete->Cleanup();
delete m_stateToDelete;
m_stateToDelete = NULL;
}
Each State has its own scene pointer, and camera. The StateManager takes those variables from the current state at the top of the stack, and assigns them to the renderer and culler appropriately. The StateManager can also display the graphics of previous states on the stack though a simple bool parameter in the push state function. It connects the individual scene pointers of each appropriate state in a tree structure.
void PushState(StateType state, bool renderParent); //Function Prototype.
The StateManager was designed to be as robust and practical as needed, while offering an easy to use interface to speed up production of the game’s development.
PIVOTal Paper Prototype
Overview
The paper prototype of PIVOTal focuses mainly on the survival, exploration, and strategy aspects of the game. Combined with some Tactical RPG elements to create more in-depth combat, it most closely resembles a tabletop RPG. The goal of the game is to explore the factory and collect as many of the hidden keys as possible while attempting to stay alive. If the player collects at least 8 of the 16 available keys they can access the boss room. By defeating the boss the player wins the game. If at any time the player’s health reaches 0, the game is over and all collected keys return to their original positions.
Mechanics
In-game movement is primarily based on dice rolls (move the number of spaces shown), but is also affected by the area that the player is in. If the player is in a hostile zone, they may choose to move only 1 space instead of rolling a die. This can be advantageous if the player is close to an enemy’s line of sight and wishes not to move into it. While outside of a hostile zone each unit of movement allows the player to progress to the next marked space on the board. While in a hostile zone, each of the individual squares that makes up the game board count as spaces. This makes it so the player can get from zone to zone relatively quickly, and also gives the player more room to navigate during a fight.
The game also features a card system that affects each play session differently. After the player rolls they draw a card. The effect of the card is immediate unless otherwise stated. There are 30 cards in the game’s deck. 10 cards are neutral cards that do nothing at all. This is done to balance the deck, as there are more detrimental cards than beneficial ones. 5 cards restore the player’s health, 4 restoring 1 HP and 1 restoring 2. 5 cards provide benefits to the player, such as rolling twice in one turn, or crippling enemies in the next encounter. The remaining 10 cards are detrimental to the player. There are cards that augment enemies, hinder the player’s movement, and deal damage. If the game lasts more than 30 turns the deck is shuffled and reused.
The game features many hidden areas that are blacked out until the player reaches them. These areas are used to hide the keys needed to progress, as well as minor health upgrades to aid the player. There are also hidden areas that contain nothing.
Combat
When the player enters a combat zone, a second player positions one enemy at the opposite end of the hostile area. Every turn player 1 moves by either rolling a die or choosing to move one space and then draws a card. The second player then moves their enemy based on the move rating of the piece they selected. Player two must move the enemy directly forward. When the enemy hits a wall, it spends one turn turning around, and then proceeds forward on its next turn. If at any point player 1 movies into the enemy’s line of sight, or attacks the enemy, player 2 is free to move the enemy piece as they please. Turning in combat, for either player, costs one unit of movement for every 90 degrees turned. For example, if player one rolls a 4, they can move 3 spaces and reorient themselves 90 degrees. If player one wishes to turn around completely, it would cost them 2 units of movement, leaving them with 2 spaces to move.
Attacking for either player also costs 1 unit of movement. If either player moves such that their opponent is within their attack zone, that player can spend one unit of movement to damage their opponent. Damage is calculated based on each character’s damage rating. Stats for all characters are listed below.
When a character’s health reaches 0, they are destroyed. If player 1 is destroyed, the game is over and all keys return to their original positions. If player 2 dies, player 1 is free to continue the game.
Strategy
Movement ties directly into the game’s strategy element. The player needs to move efficiently in order to minimize the number of negative effects caused by cards. The player must also be able to effectively position themselves to damage enemies without taking damage themselves. The player’s health is designed specifically to be in short supply to force them to play strategically. In order to minimise damage taken, the player must attack from either beside the player (advantageous), or behind the player (most advantageous).
The player is also free to try and avoid enemies if they choose. If the player makes it out of the hostile zone without either falling into the enemies line of sight or attacking an enemy, they may leave the hostile zone and continue on. If the player alerts an enemy however, they cannot continue until all enemies are destroyed.
Character Stats
High Concept
While sipping his morning coffee, Mr. Hide reads in the paper that the local factory has become sentient and is holding the old workers captive. Now you must rise to the occasion, fight through the mechanical monsters and navigate the maze-like interior of the PIVOTal factory to rescue everyone within.
Demographic
The game is targeted towards teenagers and young adults because of its dark and violent tone as well as the feeling of isolation.
Key Features
- Exploration. The game takes place in a large twisting labyrinth of a factory, this requires the player to explore all the different path to find what is needed to advance and to search for ways to avoid the enemies
- Survival. The game requires the player to be careful of the paths they take in order to avoid the enemies and survive.
Signature Mechanic
PIVOTal’s signature mechanic is the fact that it is a free roaming shooter. This stands out from the crowd as it offers a more strategic aspect to the traditional shooting genre and allowing the player to not be constrained by how high they can jump and instead allowing flight this opens up a lot more strategies and exploration to the game.
John Gregory
John has been programming since 2009 and has work on a few games in the past 3 year. He first started on basic text adventures and later some simple 2D sprite based games in my first year. This gave him a basic understanding of C++ and the following year he started work in 3D environments with OpenGL. With this John worked on a racing game with his group and developed his own platformer game where you could create levels using a text file. He also created a unique style for displaying what was visible on the screen by fading the blocks that were on the edge of the screen into the background. This allowed him to greatly improve the games performance. During the summer from 2nd year to 3rd year he started work in Unity3D and have created around 10 games so far using this engine. The most recent game has been getting lots of positive feedback and he is currently developing it for release on the android, as well as on PC.
This year John began work in WildMagic, which is a very simple engine that required a lot of improving. He was also working with Havok and had to do a lot of implementation with adding Havok functionality to WildMagic. John worked on all of the Havok based gameplay and was required to implement a few functions that Havok had into WildMagic which includes phantoms, collision detection and raycasting. With these tools he was able to create a door system to enter and exit levels, enemies that be killed and can kill the player and a key collection system. The raycasting was used to improve the gun mechanics in the game, which allows for line collision detection into the scene to see what object you have hit.
Currently John is working part time with a Professor Nacke on some projects. During the summer he will begin full time. The current one involves simulating data on a graph from people testing games. John will be doing a variation of different coding projects within Unity3D to help grad students show and test there research.
Nathan Gale
Nathan has worked in a varied range from the programming side to the artistic side. During the first year of Game Development Nathan was the lead programmer in the games Bear Quest 64 and Bear Fighter. Moving into second year Nathan moved more towards the artistic side of development creating all the models and textures for Alien Racing. Over the summer between second and third year Nathan worked on improving his modelling techniques with online tutorials and workshops.
Throughout the third year Nathan worked mainly with modelling, texturing and animating. In addition to this work he also did some small bits of programming as well as increasing skills with scripting within the Unity Engine. For the game PIVOTal Nathan worked on the design of the main character and all of the levels and lighting. In addition to this he worked on most of the other artistic aspects such as the games poster and video effects in the cutscene.
Ryan Howse
Ryan’s previous games include the Bear series in year one, Bear Quest and Bear Fighter, as well as Alien Racing in year two. He served as the head programmer and co-designer on Bear Quest, and a supplementary programmer on Bear Fighter. He also provided additional art assets for Bear Fighter such as character and level design. Ryan was also the sound designer of Alien Racing, and provided minor art assets as well.
Ryan’s main contribution to PIVOTal was animation. He animated the opening cutscene, using his cinematography knowledge to make each shot look right. He also wrote the narrative that the game is based around, designed the cutscenes that the player sees throughout the game, provided art assets and design input.
Michael Nemeth
Even before university Michal has had a fascination with programming, especially when it was related to videogames. In high school he created a 2D game in XNA called battle pong as well as creating many other short games in Macromedia’s flash.
In Michaels first year at UOIT he, along with his group members created Caves, both the text adventure and the eventual 2D side scrolling version. His role in their creation was mostly programming but when it came to creating art assets he had his hand in creating some of the sprites.
Second year brought Alien Racing were Michael spent the majority of his work programming various aspects such as the PGM loader and working in OpenGL.
In the current year Michael has transitioned almost strictly to programming the game. He, along with John created many of the core aspects that make Pivotal a unique experience such as the level loading, gameplay, networking (lobby and multiplayer state) and parts of the State Manager.
Tinaye Dune
In the past, I have worked on a text adventure, a 2D arena style game, and a racing game. When I was working on the text adventure, and the 2D arena style game, I was doing quite a bit of programming. For the 2D game, I was the lead programmer for it. These were games that I worked on in the first year of university. I worked on a racing game in my second year of university. I started doing a lot of design work and presentations during this year. I really like working as a designer and the projects I worked on in the second year challenged those skills, however I believe that I overcame them and produced some really good work.
In this year of university, I did a lot of the design work. I’ve been working on the paper prototype of the design documents for PIVOTal which is the game that my group worked on during this year. During the school year, I’ve had opportunities to brush up on my design skills, especially with the game design 2. I’ve worked on paper prototypes and design documents for many of the projects that we were assigned in this course, and all of these skills proved to be valuable in making and organizing the finished design documentation and paper prototype for PIVOTal.
Mario Greco
Mario first started playing video games at two years old, and his love for gaming grew from there. When he graduated from high school, he decided to take his love for gaming to the next level, and became a game developer. Throughout his studies at UOIT, he improved his programming skills to keep pace with the curriculum. Although very comfortable with programming, his true passion lies in design. He’s been designing game concepts since childhood, and hopes to achieve a career in game design. Besides game development, he is also a skilled public speaker, and knowledgeable of business, marketing, and project management concepts. His hobbies include filmmaking, acting, karate, philosophy, and spending time with friends and family.
The original concept of PIVOTal was to create a game that took place in an abandoned factory which would eventually flip over as the player progresses through the game. The player would discover several different areas where he can change the orientation of the factory. The Factory would begin at 0° and would be able to rotate to 45°, 90°, 135°, and 180° as the player advances. The levels in the game were supposed to be split up into different rooms which would be similar to what is seen in 2D Metroid games. As the player got further and further into the game, the factory would be rotated to 180°, and at this point the boss area would become accessible. Once the boss is defeated, the player would have beaten the game.
Over the course of the first semester, a few of the ideas that went into the original concept of the game ended up being removed because of time constraints. We did not have enough time to make separate rooms for every level in the game. Therefore in order to solve this problem, we made 6 different levels as well as a hub world. The 6 levels ended up being 1 large maze like room. The hub world was inspired by games such as Kirby’s Nightmare in Dreamland. This would be the place which would allow access to all of the levels. The game play was also changed in order to accommodate the changes in the levels. Instead of the player being forced to stay on the ground and run and jump through the levels, the player has a jet pack which allows him to travel through the new levels with ease. The idea of rotating the factory was abandoned at this point.
http://tvtropes.org/pmwiki/pmwiki.php/Main/HubLevel
As time was passing, the deadline for the first semester was approaching. The main character ended up being a sphere since loading the characters in the game was proving to be a little problematic. Likewise, the enemy was also a sphere for similar reasons. The bullets used by both the player and the enemies were smaller spheres with physics attached. A new idea for progressing through the game had to be decided. This is when the idea of collecting keys was brought up. In Metroid Prime, Samus needs to collect 12 artefacts from across the game world in order to gain access to the final boss. In a similar fashion, we hid 2 keys in every level. Upon collecting all 12 keys, the Boss appears in the bottom of the hub world. Defeating the boss would allow the player to win the game. Unfortunately we ran out of time before being able to implement the boss into the game, therefore the win condition is collecting the 12 keys scattered among the 6 levels.
In the second semester, a lot of the production happened in the last month of the course due to a rather heavy workload early on in the semester. We decided to make some changes to our game for a few reasons. The sphere that was controlled by the player ended up being the model for the regular enemies, and was replaced with the main character used in the cutscene. The levels where changed in order to add more variety because the levels from first semester were all very similar. The bullets changed to an instant ray being casted from the player in the direction that the player wishes to fire. This was to make it easier for us to work with when implementing the networking requirement. We wanted to do a battle mode for the networking requirement, so if we kept the bullets as spheres with physics then we would have to track the location of every single sphere, whereas shooting a ray eliminated that problem. The other problem was the amount of bullets that could be rendered at once. It may potentially slow down the game if too many bullets are created. Using a ray eliminated this problem as well.
The final change was adding in a battle mode, which we added in order to satisfy the networking requirement. The battle mode has two players shooting it out in order to be the last one standing. Games like Halo inspired this player versus player competition. After all of these changes, we ended up with the product we have now. There is quite a bit more we could do such as implementing some of the ideas that did not make it from the original concept, however after working on the game during our 3rd year of university, we got it to a point where we could be satisfied.
The Plot
Plot Synopsis
A factory that has slowly become more and more automated turns sentient and traps workers that have revolted against the machines that took their jobs. Reacting to this act of aggression, the factory attacks a small nearby town. Using a flying machine with a mounted Gatling gun, Mr. Hide, a man from the now ruined town, braves the factory in order to free the workers and shut down the machines. As the game concludes it is revealed that two of the workers are the children of Mr. Hide.
Cutscenes
The following is the game script in its entirety as originally planned for. There have been amendments, as listed below.
START OF CUTSCENE
EXT.FACTORY.EVENING
The exterior of the factory is being shown. The camera zooms out slowly to bring Mr. Hide into the shot, flying away from the factory, his flying machine damaged, but still able to fly. The camera continues to zoom out until it is revealed that the top of the factory is on fire, and releasing a column of smoke into the air.
CUT TO:
INT.FLYING MACHINE.EVENING
CLOSE UP 3/4 shot of MR.HIDE from the left. His face is scuffed. ZOOM OUT slowly to show that his clothes are slightly burnt and torn.
CUT TO:
WORMS-EYE-VIEW shot of Mr. Hide from the right. His eyes are fixed on the horizon. They are slightly dropped at the ends, conveying how tired he is. As the shot progresses, the sun in the background tracks to the right until it back-lights Mr. Hide.
EXT.FACTORY.EVENING
The factory is now more in the distance than it was before. DOLLY BACKWARDS with the flying machine, making the factory appear to be traveling further into the background. After about 4 seconds of this, the flying machine starts to descend until it is out of the frame. Once it has been completely removed from the scene, the shot stays on the smoking factory for about 2 extra seconds.
EXT.HILLSIDE.EVENING
MID SHOT of Mr. Hide as he steps out of his machine, and turns to look at the factory in the distance.
CUT TO:
CLOSE UP of Mr. Hide as he takes out his pipe.
CUT TO:
MEDIUM-WIDE shot situated behind Mr. Hide as he watches the factory burn. DOLLY BACKWARDS slowly for about 5 seconds before the screen begins to FADE OUT. After about a second the text “10 Hours Earlier” appears onscreen.
INT.MR. HIDE’S HOUSE.MORNING
MEDIUM SHOT of Mr. Hide sitting in a chair. He is about to light his pipe when he picks up a newspaper.
CUT TO:
CLOSE UP of a newspaper. It reads, “SENTIENT FACTORY THREATENS TOWN! SOMEBODY SHOULD PROBABLY DO SOMETHING!”
CUT TO:
CLOSE UP of Mr. Hide. He raises an eyebrow in confusion.
CUT TO:
MEDIUM SHOT of Mr. Hide. He gets up and goes to the window and looks out.
CUT TO:
MEDIUM-WIDE SHOT of outside. The city is burning.
CUT TO:
CLOSE UP of Mr. Hide. He recoils slightly and raises both eyebrows in surprise. He puts his pipe in his pocket and walks over to his telephone (rotary with separate speaker/receiver). He picks it up and dials. The sound of rings going through can be heard. After several rings, he puts the receiver back down and sighs. He walks out of the shot.
EXT.MR.HIDE’S HOUSE.MORNING
MEDIUM-WIDE FRONT ON SHOT of Mr. Hide walking out of his house, locking his door, and walking into his garage via a small door on the side. The roof of the garage flips open and Mr. Hide rises out on his flying machine.
CUT TO:
MEDIUM SHOT behind Mr. Hide. He begins to move forward towards the factory.
EXT.BURNING CITY.MORNING
MEDIUM SHOT of Mr. Hide flying through the sky. He enters from the right. As he flies past the camera, it PANS LEFT to keep him in the shot. The shot continues for a second or two as he flies on into the distance.
CUT TO:
CLOSE UP of Mr. Hide. He is calm and collected.
CUT TO:
MEDIUM SHOT of Hide flying. He looks over the edge to see the city below him is burning.
CUT TO:
CLOSE UP of Hide. He sighs.
CUT TO:
WIDE SHOT of the factory in the distance. The shot is sustained as Mr. Hide flies into the shot from the bottom right corner.
FADE OUT
END OF CUTSCENE
This cutscene is played when the player first enters the factory. It establishes the interior look of the factory and also that there are thing inside the factory which Mr. Hide must destroy.
START OF CUTSCENE
INT.FACTORY.MORNING
The scene fades into a 3/4 MEDIUM SHOT of a leaky pipe inside the factory. TRACK DOWN for approximately 3 seconds.
CROSSFADE TO:
3/4 MEDIUM SHOT of a giant, rusty gear. TRACK RIGHT for approximately 3 seconds.
CROSSFADE TO:
STILL MEDIUM SHOT of Mr. Hide flying through the factory in his machine. The camera starts at a 3/4 MEDIUM SHOT and moves down and to the right to a WORMS-EYE-VIEW during the shot.
CUT TO:
CLOSE UP 3/4 SHOT of Mr. Hide’s face. He looks from left to right, surveying his surroundings, on alert for danger.
CUT TO:
MEDIUM-CLOSE SHOT of a pair of glowing eyes in the corner, shrouded in shadow. The eyes begin to leer at Mr. Hide.
CUT TO:
CLOSE UP HEAD ON SHOT of Mr. Hide’s face. He scowls and lowers his head slightly, casting a shadow on over his face.
CUT TO:
MEDIUM-CLOSE 3/4 SHOT of Mr. Hide’s gun. The barrel begins to spin.
FADE OUT
END OF CUTSCENE
The following cutscenes develop the backstory for the factory and the crisis. The player sees one of these every time they collect a key and exit through the door back to the hub area.
START OF CUTSCENE
INT.FACTORY.EVENING
FADE IN
MEDIUM establishing shots of the factory.
CROSSFADE TO:
Coal is being shovelled into the main furnace of the factory. All that can be seen of the worker is his hands on the shovel and his arms moving it.
CROSSFADE TO:
A factory wall is shown with a shadow being cast on it of a worker pulling a lever. As he does, a giant press comes down and then goes back up. He repeats this.
CROSSFADE TO:
CLOSE-UP shot of a conveyor belt. As it moves metal bars down the line, human hands remove them.
CROSSFADE TO:
A poster is on the wall. It’s a cheery propaganda poster that says the factory will become automated in 3 days. The number 3 is on a small card held up by a hook.
FADE OUT
END OF CUTSCENE
START OF CUTSCENE
INT.FACTORY.EVENING
FADE IN
MEDIUM establishing shots of the factory (different shots than before).
CROSSFADE TO:
Coal is being shovelled into the main furnace of the factory by a robotic arm attached to a huge shovel.
CROSSFADE TO:
A factory wall is shown with a shadow being cast on it of a worker pulling a lever. As he does, a giant press comes down and then goes back up. He repeats this.
CROSSFADE TO:
CLOSE-UP shot of a conveyor belt. As it moves metal bars down the line, human hands remove them.
CROSSAFDE TO:
A poster is on the wall. It’s a cheery propaganda poster that says the factory will become automated in 2 days. The number 2 is on a small card held up by a hook.
FADE OUT
END OF CUTSCENE
START OF CUTSCENE
INT.FACTORY.EVENING
FADE IN
MEDIUM establishing shots of the factory (different shots than before).
CROSSFADE TO:
Coal is being shovelled into the main furnace of the factory by a robotic arm attached to a huge shovel (same as before).
CROSSFADE TO:
A factory wall is shown with a shadow being cast on it of a robotic arm pulling a lever. As it does, a giant press comes down and then goes back up. It repeats this.
CROSSFADE TO:
CLOSE-UP shot of a conveyor belt. As it moves metal bars down the line, human hands remove them.
CROSSFADE TO:
A poster is on the wall. It’s a cheery propaganda poster that says the factory will become automated in 1 day. The number 1 is on a small card held up by a hook.
FADE OUT
END OF CUTSCENE
START OF CUTSCENE
INT.FACTORY.EVENING
FADE IN
MEDIUM establishing shots of the factory (different shots than before).
CROSSFADE TO:
Coal is being shovelled into the main furnace of the factory by a robotic arm attached to a huge shovel (same as before).
CROSSFADE TO:
A factory wall is shown with a shadow being cast on it of a robotic arm pulling a lever. As it does, a giant press comes down and then goes back up. It repeats this (same as before).
CROSSFADE TO:
CLOSE-UP shot of a conveyor belt. As it moves metal bars down the line, a robotic arm remove them.
CROSSFADE TO:
A blank wall is shown with a discoloured rectangle where the poster used to hang.
FADE OUT
END OF CUTSCENE
START OF CUTSCENE
EXT.FACTORY.NIGHT
FADE IN
MEDIUM-WIDE establishing shot of the top of the factory which is spewing smoke even in the dead of night, able to operate around the clock because of the factory’s automation. TRACK DOWN to see several men armed with rifles outside of the factory doors. TRACK UP to the smoke stacks. The SOUND OF A GUN going off is heard, followed by the sound of the factory’s alarm.
FADE OUT
END OF CUTSCENE
START OF CUTSCENE
INT.FACTORY.MORNING
FADE IN
WIDE SHOT of the factory from a distance. The sun is shining, birds can be heard, and everything in general is chipper.
CROSSFADE TO:
MEDIUM-CLOSE shot of the factory. DOLLY FORWARD to the door of the factory. The closer it gets, the louder the sounds of the factory become.
CUT TO:
The previous night, the factory alarm is blaring. A MEDIUM shot from inside the factory, facing towards the door. There is a large hole in the door where the handle would go. The door swings open to reveal the men from the previous cutscene.
CUT TO:
The morning, the door remains open and damaged. ZOOM IN to the factory. Factory sounds can still be heard.
CUT TO:
The previous night, alarm still heard. Shadows of the men are seen running across the wall right under a sign that says “Control Room” with an arrow pointing to the right.
CUT TO:
The morning, a CLOSE UP SHOT of muddy footprints across the factory floor is seen. Factory sounds can still be heard, louder than before. TRACK RIGHT quickly, following the footprints.
CUT TO:
The previous night, a MEDIUM SHOT of the men standing in front of the control room. The words “Control room” are written over an iron door. They try to open it, but the door is locked. The alarm stops.
CUT TO:
MEDIUM-CLOSE shot of the worker’s faces. They look around, but not behind them. Behind them, a robotic arm rises up.
CUT TO:
The previous morning, the camera continues to follow the trail of footprints. The camera rotates from being to the right of the footprints to being directly behind them, still looking down. The camera slows and the footprints end as a pool of blood comes into view. The camera stops when one foot is visible lying in the pool of blood (rest of the body is attached but off camera). The shot of the foot is sustained for several seconds.
CROSSFADE TO:
MEDIUM SHOT of the still open factory front door. The camera starts to ZOOM OUT. As it does, a robotic arm is seen reaching across the back of the door. It slams the door, and a bright light is seen running down the door’s seam, welding it shut.
FADE OUT
END OF CUTSCENE
This cutscene happens when the player has all 6 keys and approaches the final.
START OF CUTSCENE
INT.FACTORY.AFTERNOON
FADE IN
CLOSE UP SHOT of the ground, camera pointing almost parallel to the ground. The flying machine lands on the ground and Mr. Hide steps out (you can only see his feet). He walks forward and comes up to the dead body of a dead factory worker from the previous cutscene. There is only one body. Mr. Hide crouches down.
CUT TO:
CLOSE-UP of Mr. Hide’s face. He’s disturbed, but slightly relieved. NOTE: This facial expression is as such because the body is not one of his children. He’s happy, but still upset by the death.
CUT TO:
The previous camera angle. Hide stands back up and walks out of the shot.
FADE OUT
END OF CUTSCENE
This cutscene is used to explain why the factory attacked the town.
START OF CUTSCENE
INT.FACTORY.NIGHT
FADE IN
MEDIUM-CLOSE SHOT of the body of the dead worker, still lying in a pool of his own blood.
CUT TO:
CLOSE UP SHOT of the furnace, starting at the ground and TRACK UP, stopping at the “eye holes”.
CUT TO:
CLOSE UP SHOT of the worker’s gun lying on the ground.
CUT TO:
CLOSE UP SHOT of the “eye holes”. QUICK DOLLY BACKWARDS AND TRACK DOWN as the furnace roars to life, the fire reaching the “eye holes”.
CUT TO:
MEDIUM SHOT of the body. ZOOM OUT to reveal the remaining two workers being held by robotic arms. They are limp.
CUT TO:
CLOSE UP of one worker’s face. He stirs a little.
CUT TO:
CLOSE UP of the furnace (eyes and top of mouth). The fire quells a little, giving the appearance of a leer.
CUT TO:
MEDIUM WIDE SHOT of the dead body and the two remaining workers. Panels below the arms open up like flaps. The arms holding the workers pull them down into the holes.
CUT TO:
CLOSE-UP SHOT of the dead worker’s face. SLOW ZOOM IN.
FADE OUT
END OF CUTSCENE
This is the cutscene right before the boss
INT.FACTORY.EVENING
FADE IN
MEDIUM SHOT of Mr. Hide flying into the boss room. The room is cold, dark and quiet.
CUT TO:
The captured workers are slumped in a cage. When they see Hide, one stands up and weakly puts his arm through the bars, reaching for Hide.
CUT TO:
CLOSE UP SHOT on the furnace’s eyes. Fire creeps up into them, illuminating the room which is filled with robotic arms, which is seen during a ZOOM OUT.
CUT TO:
EXTREME CLOSE UP on Mr. Hide’s eyes. They glare angrily, followed by a CRASH ZOOM out to a MEDIUM-CLOSE SHOT of Mr. Hide in the flying machine with his gun spinning rapidly.
FADE OUT
END OF CUTSCENE
This is the cutscene after the boss.
START OF CUTSCENE
EXT.FACTORY.EVENING
Mr. Hide flies through the now burning factory towards the cage. The workers stand back and Hide shoots the cage door, destroying it. Hide throws them his house key and then run for the factory doors.
An abridged version of the opening cutscene is played again. This time as the camera TRACKS BACK, revealing more of the hill that Mr. Hide is standing on while looking at the burning factory, a bird flies down and steals his pipe.
CUT TO:
CLOSE UP SHOT of Mr. Hide. He closes his eyes and sighs. He pulls another pipe from his inside pocket and finally lights it. He exhales some smoke.
MR.HIDE
“Quite.”
CROSSFADE TO:
MEDIUM SHOT of Hide’s desk zooms into the framed picture. ZOOM IN to reveal a photo of Hide standing with the workers he rescued posed as a family would be.
FADE OUT
END OF CUTSCENE
Amendments
The game now starts at the point in the script where it flashes back to Mr. Hide reading the newspaper and discovering that the factory has gone rogue. This was cut down mainly for time, and ideally we would have started the game as we had originally intended.
The portion of the opening cutscene that remains is also different from our original design. Mr. Hide now reads the newspaper, drops a glass on the ground which shatters, runs out of the house and flies away in his flying machine. The machine flies into the factory via a large smokestack. The cutscene conveys the same information, albeit an abridged version. Again, the content that was left out was due to time restraint.
Inspirations
There were several plots and environments that inspired our narrative. One source that inspired us was the testing facility from Portal. The facility in Portal is run by malicious computer intelligence, whereas our factory’s control center is more of a supernatural entity. Given the nature of our setting, AI or computer intelligence wouldn’t make sense. The maze-like nature of the testing facility also shines through in our factory. This element also ties into another inspiration, the Metroid series.
Early concept of our main antagonist, the Furnace, powering its factory.
GlaDOS, controlling her facility via command center.
Metroid’s gameplay is highly focused on non-linearity and exploration, which was the focus of our level design. In PIVOTal you are forced to explore as many routes as it takes for you to find the keys needed to open the doors blocking your path. Although Metroid’s exploration has you finding a range of power-ups that gradually but vastly expand the game’s map, this was far outside of our scope which is why we went with the simpler solution of hiding keys needed to progress.
Level 4 of PIVOTal, comprised entirely of shipping containers.
Super Metroid’s map.
The aesthetics of PIVOTal comes primarily from a steam-punk style and is heavily influenced by games such as Bioshock that similarly adopt the style as a base for their design. Like Bioshock, our game favours a brass or metallic palette and is decorated mainly with pipes, gears and steam-powered mechanics, and favours a darker atmosphere that comes from an era not entirely reliant on electrical devices.
Our steam-punk inspired character, Mr. Hide.
The industrial make-up of Rapture.
http://www.visualwalkthroughs.com/bioshock/neptune2/neptune2.ht
PIVOTal also has some elements of a roguelike RPG. Rogue-likes are usually defined by their difficulty based on the player’s relative weakness to the game’s enemies. This frailty encourages the player to explore not only to find items that can help them overcome enemies, but also to find faster routes that can bypass enemies beyond their skill. Likewise, the player character in PIVOTal is much weaker than the larger enemies, and must focus on survival over domination. Exploration in PIVOTal is made tenser as the player splits their focus between navigation and survival.
Mr. Hide, about to turn around and run.
Izuna: The Unemployed Ninja, about to be killed for employing weak strategy.
PIVOTal is a free roaming shooter. The game encourages players to explore an abandoned factory while learning to defend themselves from it by shooting down anything that hinders their progress. There are various areas to explore, and enemies to defeat in order to discover the truth about a recent incident that occurred at the factory.
Character Background & Inspiration
The main character’s look is most majorly inspired by the dress of Victorian era men, as is much of the steampunk genre. To add more to the industrial side of the steampunk genre a mechanic monocle was added, this adds a slightly futuristic feel to the more classic attire. The game that inspired the look of the character most is Fable 2. Fable 2 takes place during a sort of industrial revolution in the land of Albion. Our group’s familiarity with the game helped keep our aesthetic constant throughout our design.
http://dmuantskilton.blogspot.ca/2011/04/trait-that-is-distinct-variant-of.html
Mr. Hide’s backstory
Original
Mr. Hide is an inquisitive, fledgling scientist whose penchant for exploration and discovering the unknown has got him trapped inside a large metal forging factory. Although he may love the unknown he is also quite fearful of it and always tries to study things extensively before getting a closer look. He has experienced a very troubled past that he has tried to hide from the world but it is quite often on his mind. The fumes of the factory have initially affected his memory but as he continues they slowly resurface and he must try to conquer his own psyche in conjunction with the terrors held within PIVOTal (the factory/game name).
Modified
Born into a life of near poverty, Mr. Hide was destined to be a factory worker for the rest of his life before it even began. As he grew, a fascination with mechanical devices blossomed into a desire to create. By the age of 32, he had what most around him would call a good life. He had a stable income that put food in his stomach, a home to retreat to when the day had beaten him down, and a family to pull him back to his feet. Still, he felt uneasy, like he was wasting his life by merely trying to survive it. As a child he had watched his father live and die under the unrelenting blow of the metal press. Stifled by the confining factory that took up most of his time, he did what many had dreamed of but few had ever pursued. He quit the job that had sustained him through good times and bad to follow his ambitions. Sadly, the world found little use for his inventions, and Hide fell on hard times. Unable to cope with their situation, Hide’s wife abandoned the family, leaving nothing behind. Her departure crippled Hide emotionally, and he became a recluse. Homelessness mere months away, Hide’s children got jobs at the factory that he had forsaken, leaving him home alone to toil away at his projects. Hide vowed that he would make something useful, or die trying.
Female character’s backstory
The female main character of our game is a nameless protagonist, to suit her role. She is a factory worker at a plant located near her hometown, a small, dirty place made of iron and cobblestone. Like the never changing tide, its generations come and go, all seeking refuge from poverty under the unforgiving weight of the metal press. She has been beaten down by reality, her mind growing stagnant from the monotony of everyday life at the factory. The factory itself produces metal. It’s hot and humid during the day as the bodies within struggle to quench the world’s never-ending thirst for gears, piping and bullets, and bitterly cold at night, as the wind moans through the empty, iron halls.
The main character is 25, though her birthday hasn’t been acknowledged, much less celebrated, since the stress of their lives took her parents from her; her only family. Her childhood was a modest one, spending her days playing with the other local children and seizing any sort of education she could out of her father’s collection of books. She enjoys bright flowers, pale-blue brooklimes mostly, the colour of her late mother’s eyes, and her favourite treats are the tiny chocolate cakes sold just down the street from her home. But above all else, she values fresh air and sunshine, a luxury not oft afforded to those who toil in the factory to earn their keep. She’s shy, keeping to herself mostly, although some days that’s more from lack of amiable company. Having succumbed to her fate, and knowing little of the world outside her own, her ambitions are mostly day to day. Her dreams are of short, quiet days where she can relax and be happy, as opposed to seeking the now forgotten freedom that she once craved.
Flying Machine Inspiration
The flying machine was inspired by multiple sources, the most major of which being the sketches of Leonardo Da Vinci’s flying machine. Our in-game machine uses the same copter-like blade as Da Vinci, which adds a sort of classical aspect to our machine which is something we wanted to show. The body of the machine was inspired by the modern bike but altered to appear like something out of the industrial era. The idea was to have the flying machine powered by foot-pedals as we didn’t want anything too technologically advanced for our pseudo-steampunk setting. The Gatling gun on the front was added because we needed a rapid fire weapon; it was decided to make it powered by a hand crank to add an older feel.
http://www.leonardo-da-vinci-biography.com/da-vinci-helicopter.html
The Rules of the game
The rules of gameplay differ depending on the game mode.
Adventure
The adventure mode takes the player through the main story of PIVOTal. The player explores several different levels in the factory in order to obtain hidden keys. The keys will open up various doors which allow the player to access more levels in the factory. While exploring, there will be enemies that the player will encounter. The player can either defeat the enemies to eliminate this hindrance, or try to avoid them completely. Once all of the keys have been collected, a final door will open which leads to the factory’s furnace room; the boss’s lair. The player will then have to fight and defeat the boss in order to complete the game. Adventure is a single player mode
When we were trying to figure out what to do for a single player mode, we looked at other games that inspired our game. Metroid is one of these games. Most Metroid games only have a single player mode, and focus on exploration, as well as combat in most areas. We decided to follow this style of single player game. The main objective when entering each level is to search for the keys, however there are enemies which can interfere with this. We designed our levels to promote exploration, while having designated areas for combat.
Combat in Super Metroid is as crucial to master as traversal
Combat
In this game mode, there will be two players battling against each other in order to be the last one standing. There are new levels specifically designed for the combat mode, which inherit the themes displayed in the adventure mode. The controls are the same as in the adventure mode; however the focus is put on shooting and less on exploration. Once one player is defeated, the other is crowned the victor.
In order to decide how to implement a multiplayer mode, we looked at the multiplayer mode of other games. Most games today and even those of older consoles have combat based multi-player, even if their core mechanics differ from that. Due to this we decided that combat based multiplayer could also fit into our game, even if our gameplay isn’t focused entirely on it.
Battle mode in Mario Kart.
Power ups/modifiers
Keys
There are 2 of these in every level. Collecting both of them allows the player to progress through the adventure mode since they unlock the paths that lead to the rest of the games levels.
Typical Game Play
In both the adventure and combat modes, the player will be controlling Mr. Hide in a flying machine. The player has the freedom to move in whichever direction they like, and the camera is set to follow them as they move through the levels. The adventure mode starts the player off in the first level, which allows the player to get used to the world around them. While the player is exploring the level, they will encounter enemies in certain areas. When this happens the camera angle changes from just following the player to following the player and all of the enemies in that area. This is done to emphasize the battle areas. The player can either move past the enemies, or defeat them. If the player chooses to fight the enemies, then the player must shoot at them in order to defeat them. The camera goes back to following the player once all of the enemies in an area are defeated, or once the player leaves the area that the enemies are lurking.
Once the player is finished collecting the keys, they must exit the level. Upon exiting the first level, the player will return to the hub world. This area connects all 6 levels, as well as the boss’s lair. The player must travel to all of the levels, and collect keys from them until they have the final set of keys from the 6th level. Upon completing this task, the player will have access to the final room. The player must then confront the boss and defeat it in order to complete the game. In combat mode, the player will be in the same game space as another player. The two must shoot at each other until one of them runs out of health. The last player standing is crowned the winner. The controls are the same as in the one player mode, so the gameplay is rather similar, however the goals are different.
Input devices and how they behave in-game.
The technology that the game is being developed for is a computer, and therefore the input devices are the keyboard and mouse. The WASD keys move the character, as is the norm for most computer based games. The left mouse button allows the player to shoot, while the character’s crosshairs follow the mouse’s position, allowing the player to shoot with 360 degrees of freedom. This is similar to both first and third person shooters on a computer wherein you point to click where you want to shoot. The R key allows players to enter a door. There are games such as Kirby’s nightmare in dreamland where you have to hold up to enter a door. We decided to make it a different alphabetical key instead of W so that a player may choose not to enter a door if they are simply hovering over it. This is similar to Zelda where you have to press a button to enter a door, however you can still move nearby a door without entering it. The final input we decided to add in the game was pressing the right and left arrow keys in order to rapidly revive. There needed to be a quick time event in the game so we looked at Mortal Kombat and how you were able to mash buttons in order to escape the stun. This could potentially keep you opponent from performing a finishing move.
We also decided to make the game compatible on an Xbox 360 controller. We felt that this would make the game more appealing to people who don`t normally play games on a computer. The movement on the Xbox 360 controller is controlled by the left analogue stick, aiming is controlled by the right analogue stick, and shooting is controlled by the right trigger. This is a similar control scheme to the one used in the Halo games, so we figured that it would be a comfortable control scheme for the Xbox 360 controller. The left and right bumpers are the rapid revive buttons, this way the player can use both hands while alternating button presses in order to rapidly revive. We figured that a face button would be appropriate for opening doors, so we decided to assign this action to the B button.
A similar control scheme to PIVOTal
Update by Nathan Gale
This past week has been very hectic in relation to our game. Once again, like first semester, we spent the weekend working nonstop. We came across many problems over the weekend, some we still need to fix, and did make a fair amount of progress overall, even if it may not show quite yet. The thing that took us the longest to implement was ray-casting, which we decide to use as opposed to our current ball-shooting physics based mechanics in order to lessen the information needed to send over networks for multiplayer. If anyone happened to play our game at Level Up they would notice that there are still many problems with this ray-casting that we will use the upcoming week to fix. Based on some feedback we received some of the changes we hope to add are:
- A visual representation of the enemies bullets in a different colour than the players bullets (as of yet there is a problem with the enemies bullets not even showing up). After hearing the problems with people not even knowing how they were dying we know this is a very important thing to fix.
- Visual (and possible physical) feedback for shooting. This is something we did in fact have before we implemented ray-casting, but was somehow disabled. We previously had a shader that caused the player or enemies to flash when they received damage. This ties in with the previous point of allowing the player to know how they are dying or if they are even hitting enemies. This should, hopefully, not be difficult, as the code is there we just have to figure out how to re-implement it. We may also try to add in a controller vibration if we can figure that out to further help the player understand what is going on.
- Enemies that can miss. Although the players of our game wouldn’t be able to notice this as there was no representation of the enemy’s bullets, there is in fact a 100% accuracy rating for enemy AI. This unrealistic and unenjoyable for gamers and we hope to change it by adding a delay to their shooting. This would make the enemies shoot where the player was one second previous, so if the player was stationary they would be hit, but if the moved they could dodge. Also, time permitting, we may try to add a spray effect to their bullets causing them to not always go straight for that point but have a few degrees difference to add more realism.
- Better Cameras. This one that has been plaguing our game for a while now, late in first semester we tried to implement a sort of battle cam that focused on you and the enemies you were fighting. All the feedback on this shows that it looks more glitchy than anything and unless we can make smoother transitions and fix all the bugs with it I believe the best choice would just be to remove it.
- Better player controls. People found problems with movement of the character, which I believe also ties in with the movement of the camera, as the constant jerkiness causes many difficulties with controlling yourself. If by fixing the camera this problem still remains we may need to look deeper into this. Also we want to add something to stop the constant rotation of the player and have them look where they are shooting. As of now the player just rotates with physics like a floating ball but we want it to look like you are aiming where you will be shooting.
- Better designed levels. The levels in our game are currently fairly plain and repetitive, filled with texture stretching and seams everywhere with no nice ambient lighting or shadows either. I admit that this is majorly my fault as the levels were created by me, albeit all six in about one day, but the problem here was that there are many new levels with better and more varied designs that were not included because of a problem we couldn’t figure out until we were on the train to Level p and by then it was too late. The problem was the texture names were too long for WildMagic to recognize.
Now on to the new level designs. These levels were still created in a time frame similar to the current levels, but with a better grasp on the skills required and a better knowledge of level design we believe the levels have improved significantly and offer much more variation than before.
This shows a close-up of an encounter between the newly designed player and the newly designed enemies in the corridors of the first level. Previously we had the same model for both player and enemy with just slightly different textures, which could get very confusing for players. Now we have something distinct for the main character and a visual of the enemy that matches our games setting.
This shows a currently, mostly empty, view of the second level. The idea going into this level was to create a maze that the player could get lost in, but for people that pay attention it would be quite easy. The level used lighting to effectively draw the player towards the keys of the level. We also want to try and turn this level into a top down view as opposed to our usual side view in order to add some more variation. This may be possible if we can determine how to stop gravity from acting on the player
This shows the cave-like design of level 3. In this level we offer the player a choice at each intersection, up or down. Both ways lead to many enemies but only one allows the player to continue on. In the HUB level of the game I plan on adding a map of this area that players can find to help them through the level and to reward the player for exploration.
This is the final new level that has been designed. It is representative of a shipping yard, built entirely from shipping containers. Although the level should seem very repetitive the variation in colours and positions of the crates makes the level look much more interesting, and the lights from the lampposts add a nice effect to the level.
Hopefully with a change in name all these levels can be added to our final game. We’re also trying to fix up the rest of the core mechanics in relation to what peoples problems were with it. The biggest goal to accomplish by next week is to make our game much more user friendly, beautiful and most of all fun.
Update by Mario Greco.
Good day ladies and gentlemen! This weekend will be a major stretch for us to improve the PIVOTal game for the LevelUp event which is held this coming Monday. Over the past week, we’ve been finishing up our last assignments, notably the group’s Prototype 3 assignment for game design (John, Mike, Nathan). We’ve also been working on business documents design documents (Ryan and Tinaye), networking (Mike and myself), and modeling game levels/cutscenes (Nathan). As you can tell, all tasks have been delegated to specific people, but we plan to give everyone a chance to contribute to each task so that everyone in the group is well rounded off. I also worked on a voice-chat function done over networking, and set up a repository on BitBucket to speed up production of the game over the weekend. Throughout the semester, the game wouldn’t work on my computer, but I recently fixed that, allowing me to contribute to the game once again. Sure, it may seem late to be doing this now, but I feel that I can give my maximum effort this weekend, now that I’ve completed most other obligatory tasks beforehand. We’ve all been meeting to work the past few days, so productivity has been on the rise.
Our current tasks as of now are to get ray-casting working, create levels and game animations, integrate the LUA scripting language, program dead-reckoning networking algorithms, and finish business documents.
We plan to build a multiplayer “Battle Arena” over the network, so in this post, I’ll focus on the design of the networking algorithm. Network latency will always occur, so it’ll be difficult to track each player’s position and their bullets’ position every frame. To overcome this, we plan to implement a dead-reckoning system, which requires the following five technical design goals to be met:
1) The velocity of the player will be shared with rivals, so that between the interval of packet received and packet upcoming, the rival character on the player’s screen will move based on the velocity of the most recently received packet. This is used to predict the actual position of the rival.
2) Whenever a new packet arrives to a user from a rival, the predicted position of the rival on the user’s screen will interpolate to the new position – not just instantly transport there. Additionally, the interpolation will not be linear, its direction of force will instead point at the new position, instead of the direction of velocity. This will allow a very smooth transition, as shown in the picture below:
3) If a player hits a rival on his/her screen, that rival will lose health, even if they slightly dodged the bullet on their screen. Although this mechanic is slightly unfair, we feel that we should choose the better poison; it’s not as bad as hitting a player and not knocking off their health – that would be frustrating.
4) To avoid total frustration in point #3 above, the latency must be as minimal as possible. We plan to send out only the position and velocity of the player and his/her bullets. We may also limit the amount of bullets the player can shoot to reduce latency further. The goal of this is to make point #3 happen the least amount of times as possible; and if it does, the space between the player and the rival’s bullet will be so minimal that the player will assume that the bullet-hit occured due to an oversized box-collider.
5) The data will be transferred by the most efficient means possible. Currently we plan to send the data using strings characters separated by semicolons. But once we figure out a more efficient way to send data, we’ll do that.
By next week, we should have a more robust blog post, as we’ll be augmenting the game like crazy all this weekend. Expect a bundle of amazing visuals, and possibly a video! 🙂
Thanks for reading, and until next week,
ProTesters
ProTesters 