What a schmozzle.
While people did have a lot of fun playing our game, it was for all the wrong reasons. When the player controller hit the edge of a mesh collider, it had the possibility of becoming airborne and bounce across the scene on the edge of the cloak mesh. In conjunction with this, semi-skillful use of the jump mechanics would make the controller float across the terrain to the point where one piece of feedback called it a NASA sim.
The “Tutorial” area of the game was buggered because while the test elements worked on our individual test levels, they didn’t work in in the game proper, because Tim and I didn’t account for the puzzles being childed to one or more empty game objects. We were using transform.position to move our puzzle elements, when we should have been using transform.localPosition.
This would have been identified had we organised play-testing before hand. There was also miscommunication about how many levels there would be in the game. I was working under the impression that there would be only one level and that the fog would be moving, or chasing, the players through a “valley”. I found out on the Thursday or Friday night that there would be 3 different levels and that the fog would be chasing the players over open area.
This caused a major revision of how the camera, and fog would have to operate. As a stop gap, I had the camera always facing towards the end of the level. I then compensated by having a List of targets that the camera would move towards and a function to receive a message that would move the distant target to a new location. One problem with this was that the targets were set up for the players to gain a collectable to activate the shrines, but this collectible wasn’t ready for the game. The camera would move once the players were in a certain distance of the collectible, but as it was a short radius to achieve, the camera wouldn’t move on. The feedback was that the players wanted control of the camera, which was never going to happen, as part of the camera mechanics were used for jumping and who should have control of the camera. Two players battling for control of the camera would tend to break the Trust mechanic that was the intention behind the design of the game.
Things that I have learned from this play-test is that there need to be a very clear understanding of the game, it’s design and how the levels are going to be created and laid out. This understanding needs to be gained in the very early stages of development. That way, I would have had a clearer understanding of the level well in advance of the play-test. Any changes from that design need to be made in consultation and agreed with by all the members of the team
As has been a problem with other projects in the past … play testing is vital before trying to demonstrate our game. This iteration was never play-tested by us as a group before we tried to impose the first play-test on our “public”. Many of the bugs that were in this game would have been easily identified and could have been corrected, if we had the opportunity to play test. In that way, we, or at least I, would not have been so embarrassed by the bugs that became apparent during this test.
richarddanielstein 