What a random placement schmozzle .
Learning from the past, we actually organised a play testing session after we believed we had fixed all the bugs from the previous play test.
The 3ds Max bug that affected my laptop last time, was still present, so I could not build from my computer. For some odd reason, Tim could still see the missing assets on his laptop. I could not explain this, and still can’t.
We were satisfied until we got to the venue and did a quick speed run of the level. That is when the camera gave up the ghost. It worked perfectly fine in the tutorial area and then had severe problems in the later stages of the level.
We tried to quickly trouble shoot this problem and then decided that for most of the final end of the level, to include another of Savik’s trigger boxes to try and keep the players aimed in the right direction.
We did another build and had to call it quits at that point.
Then Unity took over and nothing seemed the same again. Camera angles that were working previously, now didn’t work. Fog that had spawned in the exact same place since the beginning, suddenly spawned in one of two places, the place where it was designed to spawn, or at a place that seemed to be somewhere outside of the temple. Target points for the cut scenes suddenly seemed to move of their own volition and occasionally the camera couldn’t make it back to it’s starting position. The camera check for hitting objects seemed to be hit and miss, occasionally staying way high in the air. Most of these weird bugs could possibly be attributed to some error in the quick fix for the camera at the end, except for the random spawning of the fog, and the sudden maneuverability of the camera targets for the cut scenes at the shrines.
The game seemed to be pretty well received and it was a huge improvement over the first effort put up for play testing, but in the end, it still left a bitter taste in my mouth.
The secret of success for a good camera is to have no feedback over it. It becomes such a part of the game that it isn’t noticed. I realise that 6 weeks is hardly enough time to develop a fully evolved camera system, but I feel that this should have been better … at the very least, to point in a direction that it was intended. My only solace is that the guy bought in to work on the camera for Journey spent almost two years getting it right.
For the first play test, my responsibility was for the wind turbine trigger, that was never used in any iteration of the games, the mechanics of the headbutt trigger button, the player controllers, the fog and the camera. The main problem I had with the player controllers for the first play test was probably that I didn’t realise that the controllers had a .isGrounded function built in. I was achieving this through a raycast, that was probably not quite grounding the player enough. After the first play test, my main focus was now the camera and to a lesser degree the fog mechanics.
It wasn’t until after the second play test, when I was trying to explain how my camera was supposed to be operating, that I realised a serious mistake in working out my height and what the camera was looking at. I wasn’t applying a base y position for these applications.
After the second play test, my main focus was on the camera and the cut scenes at the shrines.
Things I have learned from this project:
Making time to play test as soon as you have a viable core game loop happening. That way you can identify bugs early and work to correct them sooner than we did in this project.
Clear guidelines from the outset as to the number of levels and the arrangement of assets/puzzles within those levels. This way, early testing of things such as cameras and character controllers can be devised and implemented before making it into the levels.
Just because a system will work in one part of the level doesn’t mean that it will work in all parts of the level.
Did I mention that full play testing will reveal what works and where it doesn’t, so make time for the team members to play test the systems within the game.