Corona-cation (Day 24)
Plagiarizing Valve
(not actually please don't sue me)
Yesterday I played Portal as research for the step back game. I went in looking for a few key features and trying to figure out how they were done. I didn't exactly want to copy Portal one for one, I really just wanted to get ideas on how Valve approached certain problems.
The first was general movement. From the beginning of our game I was getting complaints about how the movement didn't feel good. I started to remedy this with air control but that improvement can only go so far. I found a few things about portal's movement. The crouch is really, really low. The jump is surprisingly short and does not adjust for the time you hold down the space bar. Air-control is similar to what we already have in the game (if you jump at a direction on flat ground you can almost but not exactly get back to your original jump position in air).
The jump height and length surprised me the most. I didn't remember it being so short but it's probably good that I don't remember the game for its jump. I couldn't really emulate this in the step back game, nor would I want to, because some puzzles rely on a specific jump distance. I did however make our jump more snappy like Portal. Increasing the gravity multiplier and the jump velocity proportionally meant that you would still get the same jump height and distance that were needed for the puzzles, but would also return you to the ground sooner so it felt less floaty.
I also noticed that when the player stops giving input the character will glide a small amount before coming to a stop. I had originally thought this would make movement feel imprecise, but when I was playing it felt more natural, especially when combined with the acceleration when you give input again.
Box-flying:
The second thing that I looked at was how in the world they stopped players from flying or glitching out on the boxes. I did the same things in Portal that would glitch out our game to find similarities or differences.
The first of these was standing directly on top of a box and picking it up. In Portal, it will not let you pick it up. Our game does this now too, but I'm not exactly sure how Portal does it. Our game says that if the box's z value is lower and you are touching it then it will not allow a pick-up. I don't know if this is how Portal does it or if they have specific case conditions that will allow and not allow interaction.
The second thing was grabbing the box, jumping, looking down to get the box under you, and landing on the box. Both games will immediately drop the box when this happens. Similar situation to the first test though in that I am not sure how exactly this works. In our game, this and the previous problem were taken care of by the same code, but Portal may have separate conditions.
The final test, similar to the second, was standing on the box looking down, jumping, grabbing the box, and landing on it. Our game handles this in the exact same way as the previous situation; grabbing it then dropping it when you come into contact with it. Portal on the other hand did something unexpected but very interesting; when grabbed, the block would move out from under the player's feet and in front of them. This is super cool and I want to copy it. My current theory is that it creates an area of exclusion around the player that whatever the box is attaching to (or maybe the box itself) cannot enter. I tried and failed today to recreate this in our project. I tried to do it by changing the behavior of where the physics handle is placed when looking around. I tried to clamp the value into not coming close to the player but nothing worked. I will continue to look into this as the possible missing piece to our box-flying problem.
Other box stuff:
I noticed for one that the weighted cubes in Portal were bigger and also held closer to the player's screen when picked up. This could have something to do with the box flying as well.
In our game if you whip the mouse around and let go of the cube it will continue on with the same velocity it had while you were grabbing it. In Portal the cube almost drops straight to the floor. I don't think that the cube is just heavier but rather when the cube is released its velocity is either capped or in some way deliberately reduced. I decided to follow this lead with our game as additionally my friends that would speedrun our game would often complain that there was no reliable way to throw the cubes. To fix all of this I capped the speed when the cube is dropped and also added a throw mechanic. You are still able to whip the cube to throw it, but it is slower than throwing and less precise. I don't really like capping the speed but for now it will work. In the future I would like for whipping the cube to have diminishing returns, that if you want to just give the cube a toss by releasing it by moving forward almost all momentum will be carried while if you whip it really hard it will go faster but not terminal velocity.
A feature that I noticed in Portal that I have been meaning to implement into our game is the player automatically dropping a box when it gets too far away. Portal does this well and will also drop a box if it gets out of your field of view. This makes it more fair to the player as the box might get stuck behind a prop, but it will only drop if you ignore the problem and keep trying to pull it through the wall.
The final small detail I noticed about the boxes was that when you would pick one up it would rotate to face you but only around the z axis and it would use the closest face. It looks much better than our game did as in it the box would rotate around all axes and always have you looking at the same face of the cube. It is interesting though that the cube will only rotate to face you if you are close enough to the center of the face, otherwise you will be left staring at a corner of the cube. I want to eventually implement a similar thing but as an aesthetic feature it will be pushed later down the development road.
Comments
Post a Comment