Cat is still doing some contract work, so I am going to write the blog post again.
Last weekend my older brother was in Houston, it's only 3 hours away so I decided to visit him and obviously have him playtest our game. He does not play consoles or PC games so I wanted to see how he would handle the first section of the game. He was able to complete the tutorial so that was good! I think that was because of all the feedback we got and changes we made from previous playtesting, but there was still some things I noticed:
- I had to tell him about using the right stick to manually control the camera. I noticed that for people that don't play games with a controller they seem to intuitively use the left stick to move the character but don't ever touch the right stick. Maybe we could pop up some text if the player never uses the right stick?
- The camera still needs more work, it's getting better but it does end up at bad angles/clips objects a lot of the time. I feel like I am noticing how bad it is a lot more when people that don't play games often play our game. I wonder if it's because more experienced gamers intuitively avoid bad camera situations (like trying to move the camera around the chameleon when he is facing a wall)?
- He is the second person that ask for the chameleon to be faster or to have a run button. This is a hard one, because it might be more of a problem with people not enjoying the world and trying to rush it versus the chameleon really being slow. I am not a big fan of having a run button because I noticed from past experiences that people just end up always pressing it; we might as well just make the default speed faster in that case but then it might change the feel of the game.
- He was another person that had trouble with doors that already have color on them. Those doors are not there to be puzzle (you can just open them because they already have the correct color) but I noticed that quite a few people get stuck trying to figure out what to do with those doors. They don't even try to press the open button, they just directly go to a "puzzle-solving" mode. A good piece of feedback was that perhaps we need a lock animation like we have for the sentinel when they don't have the correct color, so you know that a door is locked or not. This might also be solved if we ever implement the hint system we wrote about last week. Initially I would have thought that it would be fine for people to be blocked until they figure it out, because then they would learn it - but I did notice that even after they open the door they get stuck on the next one, meaning they don't really know why the door opened.
The rest of the week I was working on jumping height. One of the things we noticed was that it was hard to stop people from jumping to high places that are supposed to be impossible to reach. I spent time this week making sure our jump is limited but still feels good.
Cat gave me 2 cubes that she sized to represent the height of the jump. The shorter cube represents the highest the chameleon should be allowed to jump and the taller cube represents the height that the chameleon should never reach. It sounds like it should be the same thing, but because of the way collision works in physics engine it's always better to have a buffer between what's possible and what should never be allowed for gameplay reasons.
Initially I thought this would be easy to do, but after a while I noticed a few problems with the way we do our chameleon movement. We use the Character Controller system from Unity to handle collision with the world. One of the problems was that during a jump if this system detects collision at certain angle it could end up pushing the chameleon up to keep from penetrating the collision. That's fine when walking but when jumping this means that the player can reach higher than we wanted to allow them to. We handle this now by looking at where the chameleon is going to move in the next frame when jumping, and not allowing the forward movement if it will end up hitting collision. It ends up looking the same as colliding with a wall 1 frame before the character is supposed to, but it seems to work well.
The other problem we had was that our movement was calculated based on how long a frame took. Most of the time when running at a constant 30 fps this was fine, but when running at low frame rate the time between each frame was higher. It's always a problem with any discrete realtime physics system, most of the time you want your calculation to be at the same timestep. What we do now is run our movement code at intervals of 33ms ( = 30 fps). At slower framerates we run the movement code multiple times but still at 33ms each time, which guarantees that whatever the framerate is our jumping curve will end up being the same.
Miles showing me how jumping works: