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.