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.

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).

As 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.

These 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:

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.

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.

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.

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.

[youtube=http://www.youtube.com/watch?v=i1AK4fJp5uU&w=560&h=315]

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.

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).