Category Archives: 2013 Class Work

Nice looking Cinematic Cameras in Unity

A challenge you may face in your little programmers life of programming and Unity stuffs, is that you might be making a 3rd person game…. or even a 2D platformer… You know what, any game – mainly 3D, and you want a cinematic camera to do things.

Implementation 1

Touch: Something dark happening. A cinematic is needed.

Basically, the camera really needed to just sit there and move slowly in one direction. Originally, I made it start not moving, once it’s activated, it rotates in one direction and after a few seconds, cuts back to the player.

This was all well and good, but it meant that I couldn’t control easily WHERE the camera would end up afterwards, and it didn’t give much freedom in positioning the camera.

Implementation 2

The second idea was that the cameras LERP (Linear interpolation) between one transform and another. This was what it ended up being (with a little extra magic) but instead of just using plain transforms, I used actual cameras. The reason being is because you can SEE what the cameras can see at the start and end, and it made it a lot easier to position the cameras artistically (or cinematically, whatever).

All but a mess of camera frustum wires, but oh so useful it is.

But, the cameras were a bit jerky, (they went in a straight line and jerked to a halt at the end of their journey), so let’s make a curve LERP!

This was done by easing in the “t” in the “Lerp(t)”  function from 0 to 1 (so, it’s not linear any more). The following code is what was used to do this:

float normalizedTime = m_timer / m_lerpTime;

if(normalizedTime > 1) normalizedTime = 1;

m_lerpProgress = normalizedTime * normalizedTime * (3.0f - 2.0f * normalizedTime);

m_cameraObject.transform.rotation = Quaternion.Lerp(m_lerpStart.rotation, m_lerpDestination.rotation, m_lerpProgress);

m_cameraObject.transform.position = Vector3.Lerp(m_lerpStart.position, m_lerpDestination.position, m_lerpProgress);

So as you can see… we Lerp the rotation and position of the camera based off the rotation and position of both a starting camera and a destination camera.

  • The “m_lerpProgress” is what is used as “t”
  • “m_lerpTime” is how long the camera needs to take to complete its journey
  • The “m_lerpProgress” needs to be from 0 to 1, so we need to use some calculations to figure this out based on our known time variables. This formula is… I can’t remember but it’s a popular easing formula for LERPing with a curve, and it works perfectly.

The last touch of magic is a lerp back to the player. To control this, the camera uses a finite state machine, because why not? And basically uses the EXACT same formula to LERP back to the player rather than to another camera within the cinematic camera list.

Ladies, form a line.

One thing of difficulty and noteworthiness is that each camera you use as the destination or start cameras needs to be DEACTIVATED, and also are not allowed to have any audio listeners, or anything really. They are simply references. So strip them down to their bones.

The other thing is that (despite me not doing this is the end game) is that there should really only be one camera in your scene. If you’re good, and you plan your game well before creating the camera system (like I wasn’t) you should be using the same camera your player uses as your cinematic cameras use. This is because a camera needs to have its settings correct (like fog colour and frustum distance). So design your camera systems around a single camera.

Touching cameras

Friday was my first day of programming something and I have been assigned the camera.Today I was aiming to get the basic camera controls working, which included:

  • Following the player
  • Orbiting the player
  • Being smooth

I managed to get all this done within my time limit, plus add some more functionality which was wall collisions and even a script that fades out smaller objects between the camera and player.

Gantt chart of days to spend on camera

Here’s the technical breakdown:

I started with an invisible transform that the camera was parented to. This transform will not be locked to the player, but be free and then seek out the player on an easing LERP type of movement. I pushed the camera out on it’s Z away from this transform, and kept the rest of he offsets at 0. This worked well because it meant that the Z could act as the “distance” from the player (or the target).

The camera had an issue with gimble lock, when the 2 axis rotates around the player, the camera would lean sideways and go around the wrong X axis. To solve this, I created 2 cubes (that are made invisible when the game starts), 1 is the X axis, and the other is the Y axis. the Y axis one is parented to the X axis one. This way I can use the X axis cube to only rotate around the Y axis to orbit the player, and use the Y axis cube to only rotate up and down (on the X axis).


20130805021259As you can see, the tree structure of the camera system is parented to each other.


This system worked perfectly.

Another thing that I tried to do was to limit the amount of editable variables in the script. I did this by only including things that would make sense to the artists so that they can tweak it for the game. These were the values that controlled the speed up and speed down of the camera when you rotate it.

20130805021343These values were used with Delta time to make the camera smooth and dreamy (not too fast). It took a lot of tweaking to get right.

The next task was to get the camera to not hit walls and floors. After a lot of looking on Google, I couldn’t find much of anything to help with this apart from one article saying that I should cast a ray from the camera to the player and if it hits an object and not the player you know that there’s something in front of the player. This made sense to me and I spent a while implementing it. Once it worked, I realized that it was a stupid method because as soon as the camera goes through a wall and casts a ray, it won’t hit any object because it’s INSIDE IT. I had to re-think this method.

After about 2 minutes of thinking and annoying other programmers, I went and tried another method which was the same ray method except instead of casting a ray from the camera to the player, I cast a ray from the player to the camera, using the direction the camera is pointing but negated. If this ray hits a wall and NOT THE CAMERA, then we know there’s something blocking the player’s beautiful face. I managed to make a system that eases the camera into a “target distance” that is set when the ray hits a wall. So imagine panning the camera up a and you run into a wall. The target distance will change and then the camera will ease towards this target distance. In the end this effect was really nice and the camera was coming along really well.

I then implemented a way to stop the camera from orbiting over the top of the player and back down resulting in a dick-head roller-coaster. I can imagine play testers doing this and laughing their stupid heads off, and that made me shudder. I did this simply by checking the euler angles are not going above or below a certain threshold and if they do, take over the button that they are pressing and perform the opposite reaction which is pull away. This appeared like the camera was slowly bouncing away from the position rather than jerking to a stop like it would have and it looks nice.

Another thing I took into consideration was when the camera is on the floor looking at the player, the user can keep rotating the camera down until it is right up the player’s crotch. We don’t REALLY want this, so I added some code to detect this and force the camera to rotate up. I did think about this and thought that the camera would explode if this happened in the opposite direction, IE, the camera is hitting a roof and gets too close to the player… I’m just going to hope that this doesn’t happen because I don’t know what would happen to the camera, poor thing. If it does, I’ll just detect if it’s above or below the player and then just send it rotating towards the middle.

So now the camera is perfect (lol, not really) we now had another problem: When some bastard chunk of wall or anything decides to get in the way of this ray, the camera jerks in front of it. This is kind of what we want because we want to be able to always see the player, except if say a bit of dust or a blowfly goes in front of the camera, we are going to give someone an epileptic fit.

The solution I came up with was also part of the same article which went something like “IF there’s an object in front of the player and the camera and is a close distance make the opacity of the object 30%”. I thought this was a dumb idea until I saw the camera in action, and then I realized I could use part of this in my camera.

The thing I ended up doing was to create a script called “Seethrough”. When adding this script to an object in the scene, if it gets directly between the player and the camera instead of jerking the camera in front of it, the object between will go half transparent, still showing the player, but also the wall or dust or whatever. The only issue I found with this apart from having to make sure this script is added to every object like this, is that the shader needs to support opacity. The default unity diffuse shader doesn’t. I will have to make it clear to everyone that this is important or things might start going bad. I did think about using tags but because we couldn’t tag things more than 1 tag, It wouldn’t have worked as well.

Here’s the “Seethrough” script in action:

20130805023738 20130805023746

A problematic thing I took into consideration was that if the player was up on top of a flat platform with a gap below it and the camera went down below this gap and it blocked the player, the camera would jerk up to the position just below the player’s feet. This was part of the floor issue when the camera got too close, I’d push the camera so it rotated up. I’m hoping this will not become too much of an issue. It’s an indie game for feck’s sake. I’ve seen worse camera systems in games. But we’ll leave that for when the issue comes. If it does.

Happy programming.

Reality check on puzzles

Today along with my programming of the camera system (Which is coming along amazinly) we had Sam (an art teacher) come and ask us how the game was coming along and to see how the puzzles were going.

The artists began to explain this one puzzle that included the player carrying a boulder, and pulling a rope to get an object down from something. Sam freaked out and said that this was ridiculous because the effort needed in programming and art would be too much for a simple puzzle game. I’m glad Sam did this because it came back to the other day when I told the team how hard these sorts of puzzles are going to be and that we should be keeping them as buttons and switches.

Later on in the day I had a look at some of the puzzles and they are coming along really well. Although they are not finished and I haven’t seen them (I hope to on Wednesday) there was one good one where you had to figure out a path along a set of square platforms and if you get it wrong, a door shuts at the end and you have to activate a button again at the start. This is the type of thing that’s both easy to program and also uses elements like buttons and switches that we can slowly introduce to the player throughout the game.

Serious team work

Hey there. So are you ready for a very serious and long article? Really? You are ready? Oh good. Because it’s very long. And very serious.

The last 2 days were interesting in the Touch team. I spent the first day doing some management and planning things like organizing Asana more, estimating time for each task and making a gantt chart. Because this sort of thing is important for teams to work in a timeline on a project, I find it an essential thing to do. It’s basically what we are being assessed on for this project; planning and completing a project from start to end. This is the most important part.

The documentation process is important but not very exciting. I was shown a gantt chart tool and used that to plan out a rough estimate of times and bars that we could use to make sure things get done on time.

Towards the end of the day we were discussing with the artists in the team the ideas for the puzzles they had. Some of them had inconsistencies in the main back-story of the game that Dexter (our team leader) had written. The puzzles were going to be placed in the centre of a city and you were supposed to figure out the puzzles throughout the city. This to me didn’t make sense as why would there just be random puzzles thrown into the center of a city? The solution Dexter had was that the puzzles would be part of the landscape and you would need to move object and activate switches that pushed buildings and collapse parts of the landscape to remove rubble. I didn’t like this idea because firstly, we discussed puzzles and agreed that they would be made modular with small switches and buttons activating lifts or moving doors / boxes, secondly, Matt (our programming teacher) said that we should be designing the puzzles first and build the artwork around them, not design a bunch of art assets like crumbling buildings and then try and make a puzzle out of that. Thirdly, this would require the artist to design an model complex unique puzzles around the game  that would require a lot of physics and animation which will add time, bugs and will be really hard to make it look right. I tried to talk them out of it but it seemed like absolutely everyone in the team thought it would be okay and that we have plenty of time to do it. The argument was that they could just make each puzzle play an animation when you activate something. This would be okay for things like the bridge puzzle, but there’s just so many variables and things to consider that it makes me uneasy to think of what I would be expected to program when the original puzzles were so hard to program in the first place. Especially since we don’t know what the puzzles will be.

After everyone basically shut me down and then complained that I was wasting time when people could be using that to actually do work, Dexter took me outside and told me that I was wasting time and not doing the work I was supposed to: IE programming and not trying to interfere with the design and artwork. He told me that he had to speak with the teachers about me not putting any effort into the team and also doing the incubator work. Firstly, doing the incubator work didn’t have any affect on the prototype at all apart from a 1 hour period where a meeting with them went late, and with the rest of the “slacking off”, that was just half a day where we had the exam which was unavoidable, and 1 whole day that I took off to finish an assignment that was taking too long to finish. All and all, I completed everything I was assigned to do in the prototype in time for the presentation, and thus our team got through. I can’t see what the problem is.

He also said that the code that I had done in the prototype was not sufficient enough for how long we had for the prototype because I was “messing around” with his designs and doing things I was not supposed to do like adding buttons where they shouldn’t be in the puzzles. He also said that that other people have said I should have been able to write better code in the time that I had. I think this was not fair and that it seems like Dexter just sees me as someone that’s trying to take over the project and wants me to stay out of it and just do the programming that he needs. I told him that I just want the project to be done well and that all these complex puzzles would be hard to do. He seemed to have the mindset that we should just build everything we need to and we will fix problems when they occur. I think this is a retarded way to work, and that he’s doing a really bad job at managing the team. Everyone needs a concrete thing to do and he’s just been assigning artists to do their own assets without a reason to use them. The programmers have been kept out of the whole process and been told to just program what’s needed. But how can we program what’s needed when we don’t even know what the puzzles are or what mechanics are even going to be in the game, as it keeps changing?

Adding the extra platforms to the bridge puzzle during the prototype was to keep the design of the 2 puzzles the same. The issue originated from the gate puzzle where there was no clear way to activate the triangles to the user so I added the platforms that lit up as a way to show that they were being activated at the same time as showing which face on the triangle was the one that was active (Otherwise there was no way to show which one was). This was a design issue with the puzzle its self and this is why in the planning stages of the main project we agreed to have both a programmer and an artist involved with the puzzle design so they both look good artistically and also make sense mechanical and user-friendly-wise. I showed the activate-able platform idea to the artist that designed the gate puzzle and he basically said “Whatever helps make it work man”. I then added them to the bridge puzzle to keep the puzzles similar to the gate one because 1. it was easier programming-wise to re-use already programmed pieces of the level, and 2. if we just used the buttons you’d be introducing the concept of the buttons on the bridge and then a whole new concept of the platforms. Dexter didn’t like this and then told me to remove the platforms and leave the buttons there instead. This was the reason why I took so long with the puzzles; because I had to remake things he didn’t like. The end result was that we used the buttons in the gate puzzle without platforms which worked well although I mostly made the choice to do it this way based on Dexter’s disagreements because the other artist didn’t care how his gate puzzle worked, as long as it was working at the end, and it was, and now everyone was happy.

All and all, I think I need to stop being so pessimistic about all the ideas the artists come up with but at the same time try and stop major problems,otherwise the team will just end up hating me.

Planning Touch

Today we did another planning session. We used the whiteboard and plotted out what we would like in the game as an entire team.

Some of the ideas passed around were:

  • Children being commanded to walk / stop
  • Children getting distracted and walking off or getting scared and running to MOM
  • Cutscenes for the game
  • Having the darkness cloud move on a path instead of a wall of smoke
  • changing the enemies to a cloudy hand or hands
  • Discussion about the hand holding
  • Children pointing out useful parts of a puzzle
  • Using the darkness in sequenced events to come into a room
  • Having a sequence of keys to save a child from being grabbed by the darkness

I think a lot of these suggested ideas were a bit ambitious for instance, commanding the children to do things. This example in particular, because we haven’t done anything like this before, we don’t know if it will work. For instance, if the mother commands a child, how will she do it? Will she point a cursor? Will this require some sort of HUD? or a crosshair? Will that take away from the game and make it seem like an action game? The main reason I wouldn’t want to do this is because you’d have to have advanced pathfinding, and where’s the limit to how far the children are allowed to walk?

The button sequence of freeing a child from the grips of the darkness seemed to me like it was also taking away from the main feel of the game. I mean, it will feel more like an action game to me if you had to press the correct combination of keys. I also made note to the team that this might not even be something a player will see in the game if they can do puzzles with ease, so do we really need to spend time on it? I felt that having the children just be pulled into the darkness would be a good idea.

We also discussed the scope of the game and agreed that we would be releasing a polished “demo” of the game. This will be the form of something we can show people to get funding or for getting the game out there. If we have a nice polished demo, people will want to play the full game, and then we can make it. So the aim for us is to get 2 or so “levels” with various puzzles in them that will lead to some sort of cliffhanger (like Limbo) where the player will be left with wanting more.

Another idea I suggested was that if a child is taken by the darkness / falls of a cliff / whatever, it displays on the screen “Press B to reload last checkpoint”. This will stay on the screen until you press it while the game is still playable. However, if you don’t press B in a few seconds and start walking this message will disappear and you can play the game without the child or children. This goes back to the original idea of the game where Dexter wanted the player to make a “moral choice” whether to continue with or without the children. The up side of having no children is that you are presented with easier puzzles, and you move quicker, but you don’t have the warm company of the children by your side. We really want the player to connect with the children and we will do that by giving them a personality and having them helpful in the game. However, doing this would require us to create puzzles that can be done with or without the children. I suggested that later on in the game, the player learns that they can send either blue or orange energy to buttons and activators with their mind (using a button and a left or right trigger) this way most puzzles that would normally need the children to activate can be done by just the mother. We didn’t discuss this fully yet, but I think it would be an easy way to implement the game so that people could dump the children without having to create puzzles that can be done multiple ways.

Another thing I’ve been noticing about this game is that the idea of most stuff in it are stolen from either Ico or Journey.


For instance, looking at Ico, it’s in an old ancient city, it has a mostly white character *the mother / the princess in Ico), it has dark shadowy creatures in it (like in Ico) that attack the useless players (the children in Touch, and the princess in Ico). You have to solve puzzles (Ico) and you have to take someone to a distant land (I think.). I just hope we are not accused of blatantly ripping off a game idea.

So anyway, today we started using Asana, which is a task management app. At the end of the day we had quite a few tasks up which is great. The next step is to refine these and group them, and then we can start figuring out how long each one will be. Finally, we will then create a gantt chart of the timeline, complete with milestones for finishing certain elements.


First day as lead programmer

Today we got into our groups after the games were culled down. Luckily our game got through the industry panel which is fantastic and I’m looking forward to working in the team.

At the end of the day we discussed some basic planning of the game and got everyone in the team (including new people) up to speed with what the game is about and our aims for it.

The general gist of this is that we want the game to be like the prototype but extended. The game so far has the walking, basic children dropping off and picking up, camera, and puzzles. The look and feel of the game is basically all don, we now just need to re-make it with a fresh perspective and a bit more organisation.

The team got together and discussed some parts of the game we needed to do. This included what characters we needed to add, what animations would be needed, what sound effects, how we’d like the puzzles and a bit about who will work on what.

Dexter is the project leader. He has some big plans for the game and I’m a little worried about the scope of it creeping. Especially with the new artists wanting to add their own bits to the game. So, I am assigned lead programmer. This is a great position for me as it allows me to do a lot of manager roles for assessment and learn more about team management. I will be expected to do a lot of organization work. Generally the artists are very motivated and seem to know what they are doing which is great. But I feel like I have to shut down a lot of their ambitious ideas sometimes if things seem too hard. I think generally the idea would be to stick to things we know work otherwise we could end up wasting time on something that is ultimately not part of the game. Shutting down the ideas of some of the artist might make me look a bit like a party pooper, but knowing the time it took to make the prototype and the potential issues we have already foreseen like the IK system in the children / mother’s hands will take up a lot of time, and I don’t want to end up with a rushed game that doesn’t have any polish. Therefore my main aim of the game development process will be to try and get everyone finished the main game halfway through the time period we have. This way we have time for polish and a bit of time for any unavoidable added features and bugs.

One thing I mentioned to the team, especially for the puzzle creators, that people should have a look at other games for puzzle ideas. One of the best examples of puzzle games was Portal. The puzzles are clever and they are introduced throughout the game gradually, and without interrupting the flow of the game and its story. With the developer’s commentary, is a great resource.

We created a Facebook group with all members of the team included. This is where the main discussions will take place and we posted videos for all team members to watch for puzzle ideas, and some other games from where we’re getting our inspiration. (Journey, Limbo, and Ico).

Behaviour tree

There are many different behaviour trees. Some that have been shown by teachers, some that are online done by people working on major titles. But they do basically the same thing by the looks of it. The AI will need a behaviour tree. So the first thing I’ll be doing is making a list of all the things the player will need to do. I’ll start with the bare minimum for combat (without capture the flag). The basic flow of the AI according the the brief is as follows:

  1. AI stands for a random count “Idle mode”
  2. After count is up, AI picks a random nav point and creates a path with A*
  3. The AI then walks the path and goes back to idle mode and this is repeated
  4. If the AI sees an enemy in any of these steps, it switches to attack mode
  5. In attack mode the AI will walk directly towards the enemy, shooting his gun
  6. If the AI kills the enemy, he will switch back to idle mode
  7. If the AI dies, he will switch do Die mode
  8. In die mode, the die animation will play, and then the AI will respawn and the process is repeated

To break down into smaller actions, the AI tree would look something like the following:

  • Guard (selector)
    • ChooseRandWait
    • StandGuard -> complete
  • Hunt
    • CreateRandomPath
    • WalkPath (check for enemies -> Attacking) -> complete
  • Attacking
    • FacePoint
    • WalkPath
  • Die
    • Die
    • Dead

I may refine these even more but this is the basic tree I’ll be creating.

For these to work, they will need to be arranged in a way that the tree can choose which one in order of importance. The order would be:

  • Is Dead? Do die sequence (first priority)
  • Can see enemy? (do attack sequence)
  • Has Guard time? (do Idle)
  • Otherwise do roaming (pathfind mode)

To make this tree, I will first make a main “BehaviourNode” class. This will be what all nodes derive from.

From this, I’ll make a “CompositeBehaviourNode” class. This will be used as either sequences or selectors. Each will be assigned on the creation of the object in their constructor.

Finally, I’ll make an “ActionBehaviourNode” class that all my main actions will be derived from.

The reason I’ve decided on this approach, especially with keeping the selector and sequence in one class, is for simplicity’s sake. From this there ill be less code and also less files laying around. I am also concerned about me forgetting which is which.

The nodes will all have a method called “Execute”. This function takes in deltaTime for it’s measurement of time. It will also need to access the world some how. I plan to do this by referencing the Player in the constructor of each BehaviourNode. Normally the best practice for this sort of thing would be to use a “Puppet” type of object, and the player be derived from that, but in the case of this simple game, where there’s only 1 type of actor, I’m going to do it this way.

I strongly believe the best way to learn how to code is to jump in and do it, and then make mistakes so you can write it better again. That’s what school is for. I’m not going to be able to make the perfect behaviour tree no matter how hard I try.

Below is an attempt at a diagram of the structure of the tree if we implemented the capture the flag mode:


And here’s the class diagrams:


I’ll also need to create some sort of Blackboard class to communicate with each leaf node and also so the player knows when to die. I’ll probably use this also for decorations as I don’t plan on doing any decorator classes until I see a fantastic advantage to doing them. For now I just want a working tree so I understand the basic concept.

So on with the code!

Changed AI Assignment

What? Yeah. I changed it a bit. After completing the network project I found new things. People change, Sarah, and so did my code. I’m leaving you.

Unfortunately, the code is mostly in int main(), and the entire project probably should have been bundled into an Application object that had a Renderer to control things like drawing Marv. Because I didn’t do this, the main.cpp file ends up having many globals.

The good news is, the globals aren’t very numerous.

The other good news is, I know what I’m doing now.

The other bad news is, main.cpp is long.

Some people like it long.

So far since this change:

We have Marv on the screen, much like the Network assignment. Except now Marv is smart (sort of) well. Not yet. I still need to do pathfinding and a Behaviour Tree. Do I know how to do one? No. Will I figure it out. Yes. Because they look awesome.

I also fixed a lot of rendering bugs. The AI assignment had weird things happening to normals on the walls of the castle. – speaking of the castle walls, I changed the FBX image loading code to include an image name instead of a pointer to the scene, so I can stick all the images belonging to that FBX model into its own folder in the images folder. THis looks nicer. So back to the images – I found on the internet some wall and grass textures, so now the FBX of the game world doesn’t fail when trying to load these 2 images.

On next week’s episode: we will create a behaviour tree and an A* path finder thing.

Networking assignment


For the networking assignment I plan on doing a really simple League of Legends (LoL) style game with multiple players and a set of about 3 different spells.

I’ll be using the “Arena.fbx” (converted to AIE format to help loading times) and Marv as he character.

Arena level
Arena level preview. The red glitches are the nav mesh (I’ll hide it in game)

The characters will be sort of “Space adventure” rather than the genre of LoL because it suits Marv better.

I’ll be texturing the entire level with a space looking metal texture (maybe tinted blue or something) and the players will just be tinted their colour.

I plan on making it similar to LoL.


So because I had actually not played much of it before I decided to play it, and got dragged into a game with friends (when I say dragged I just mean easily peer pressured because I’m a chump and I’m just procrastinating).

The results were a bit sad:


So after enduring that escapade, I figured the game will appear as follows:

  • Camera’s Z and angle will be locked at a 45 degree angle looking down at the player
  • the player will move around independently of the camera’s X and Z position (the player can move the camera around)
  • The player will use a* to move around a nav mesh when clicked on a certain position
  • The player will have various abilities assigned to certain keys

The players can attack and do spells. Each spell costs mana and has a cooldown. Each character will have the same spells and attacks as I’m going to focus on the networking rather than the depth of the game.

So this is what the players can do:

  • Level up – they start at level 1 and each level takes twice as many points to reach. you gain more and more XP the more you kill players and get hits on players / not dying for ages (multiplier)
  • Attack (more damage per level) (click on enemy)
  • Medkit – heals player over time, has a cooldown (A) (requires level 2)
  • Throw Mine – explodes when player touches it does lots of damage – get 1 every time you die and respawn (S) (requires level 3)
  • Shoot Destroyer Blaser- does lots of damage depending on your level, has a cooldown (D) (requires level 5)



  • Right clicking places a target for player to walk to
  • When a target is places, the player must perform an A* pathfinding search to get to it
  • When the player has found this path, he will have to walk towards it in nodes
  • Once the player is in the last node’s triangle, he will seek out the point directly
  • Player will animate and face the direction he’s walking
  • I won’t worry about player colissions, but if I do, I can check to see if there’s an enemy in the current tri, then check the distance


  • Camera will be locked to a good distance and angle
  • When player moved mouse pointer to a certain distance from the screen’s edge, the camera will move in that direction
  • The camera should have a limit to how far it can be moved in certain directions so player doesn’t get lost (There’s no minimap)


  • Clicking on an enemy will do a spherical collision and attackes will be dealt to that enemy
  • The player will send attacks constantly 1 after the other like a gun
  • Each bullet will fly towards the enemy, if it hits it, it will take damage (spherical collision)
  • The big bullets will move the same speed but will look bigger
  • The mines will basically be the same as big bullets except they won’t move. They will also do the same damage


  • Healing will just be done with a timer and heal a certain amount of player health over time
  • When a player has no health, he dies and is re-spawned in 5 seconds
  • The game ends after a 5 minute timer runs out (or 10 minutes, whatever). The winner is the one with the most kills
  • Or first to 20
  • Player is spawned as far away from the opponent as possible on a random nav point (loop through each nav point and get distance)


Yeah I know, all that other stuff is fluff, but here’s the juice to the orange of assignment:

  • First time you run the program, it asks to be a server or client
  • if you are a client, the client will ask to connect to a server. Once connected, the client will send all player info to the server
  • On the server side, when started the game, the player is put in the game and assigned as player 1. Their colour is random.
  • The server will listen for connections, and if there is one, it will add the new player with its data to the game, and then send the client the server’s player info
  • When the client is connected to the server, it will wait for all players on the server’s info and add all these players to the list on the client side with unique IDs.
  • The client will update its positions and send the server every action that is performed and also the position. Each client or server will then animate each character and move it to the new position. Animations and effects will be done on client side.
  • If a player’s client decides that a player has been hit with a bullet, then that info is sent to the server, the server then tells every client this so it updates its info
  • This info is sent at about 12 times per second (every 0.083 seconds)

Apart from these points, the only other thing would be end game state which will be controlled by the server. The timer will also be synced with the server.

That’s it for now. Happy everything.


Let’s make Marv do things


Today I updated the scaling part of my vertex shader because it seemed wrong. And it was wrong. Before:

mat4 newmodel = Model;
newmodel[3][3] = Scale;
vWorldPos = newmodel * PosWithBone / Scale;
// output position
gl_Position = Projection * View * newmodel * PosWithBone;


// for scaling
PosWithBone.x *= Scale;
PosWithBone.y *= Scale;
PosWithBone.z *= Scale;
vWorldPos = Model * PosWithBone / Scale;
// output position
gl_Position = Projection * View * Model * PosWithBone;

The vWorldPosition is set so the pixel shader knows easily where the world is so I don’t have to send it as a uniform.


I plan on adding flags for capture the flag. I spent a bit of time on TurboSquid finding some free flags but only one was free in FBX format and it didn’t import properly, so I decided to go with using the dragon FBX, despite it being extrem,ely high poly count. I believe this won’t be a problem but if frame-rates slow down then I’ll just use another random object like soulspear.

Lights and scenes

The light were originally just structs, so I moved them out into their own header and class files for better code standards.

So far here’s what we have:


Playing with fog. Using the z buffer to darken the fragments depending on distance from the camera.20130528000839

Got a nice specular effect using a normal map created in crazybump.20130528001303 20130527232639

Marv ready to be animated.20130527232702


Testing fog colours. Here we have red fog.20130528001501

Using different textures on the level. Lava texture looks a bit too bright.20130528030046

Here we see the result of what Marv animated like before I removed the 4th bone transform from the indices. I’m going to assume that that last one is for the transform of the gun Marv is supposed to be holding.20130528030328

Using emissive textures to light up areas that are not lit. I couldn’t figure out the formula though so I removed it.20130528030358

Go home Marv, you are drunk.20130528030522 20130528032217Trying with only 1 bone index. Marv hated that.