#peter eldredge

[surface-tension-game]

Product Production Journal 4 Peter Eldredge

This week I focused primarily on making bouncy surfaces work on walls. This ended up being quite difficult as I needed to balance when I took away control from the player, and how to smooth out speeds as I gradually give it back. What I was ended up with was a system where once a player bounces (hits a bouncy surface with enough horizontal velocity) they lose control for a brief period of time. Once the period of time is up, they can move but it only slightly affects their velocity until they reach a velocity very close to zero, in which they are back in control. Boxes were easier but still a bit of a problem, basically their horizontal velocities are reversed on impact, but unity made that a lot harder for me then it should have been.

Once I was done adding features, I got paid off for all the variables I made to tweak physics the last few weeks. I was able to mess with values until the physics worked as needed for the levels we designed.

Once tweaking was done I focused primarily on polishing up other parts of the game and making levels. I worked on some sounds for the game with my roommate, which Drew implemented and then I debugged. I made around 4-5 levels from scratch this week, and tweaked a bunch of other levels to make them more fun/more consistent.

Overall we are submitting a solid project thanks to everyone in the group’s contributions and I am very happy with it.

[surface-tension-game]

Product Production Journal 3 Peter Eldredge

This week I focused a lot on cleaning up player surface interactions and I added object surface interactions. Players now have a minimum bounce height, and they should remain around their bounce height infinitely, they will not drop. Blocks are the same, they bounce entirely on their own, maintain horizontal velocity when bouncing. This works well individually, but also means that the slick surface combines well, maintaining a fast horizontal speed while bouncing. This code required a lot of polish and while it still has some interactions that need to be gone over,  but it is a good start and works well.

I also went over a lot of miscellaneous stuff, I laid out the plans for the jump animation. Helped with a lot of the in game decisions, and organized a lot of the team’s activities. 

[surface-tension-game]

Project Production Journal 2 Peter Eldredge

This week I ended up doing a big rewrite of the raycast and state systems. Now, game objects are returned when the raycasts hit them, and added to the current state. This means that everything surrounding the player is easily accessible through the current state structure. This specifically allows us to easy see what surface the player is standing on or next to, and what material is on that surface (bouncy, slippery, sticky, or normal). It also reduced the number or raycasts per frame from a variable amount (10-20) to only 5, and removed about 100 lines of code, so it was a large optimization.

The other big thing I tackled this week was using this new state based system to have the player interact with the bouncy surface. This was challenging because the player has a higher acceleration when they fall vs when they are flying upwards. This required some kinematic calculations to figure out the upwards velocity required to get to the same height. I did this by looking at the player’s y velocity the frame before they hit the bouncy surface. then calculating the speed I need to launch them up from. The problem with solely using this approach is that using the frame before the “collision” the player has a slightly lower velocity then when they hit the bouncy surface. I also cant use the velocity of the frame when the player collides with the bouncy surface as it is zero. This means that I need to do a downwards cast from the previous frame to find the distance to the ground, then I need to use that distance to calculate what the player’s exact velocity when they hit the ground, and use that velocity in the equation. As of now, I didn’t have time to do that, so I added 1 to the velocity I calculated from the previous frame to “cheat” it. That served well enough to demo the game, but the player currently gets a little lower after each bounce, which isn’t necessarily a bad thing, but also isn’t very consistent.

Other than those things, I made some prefabs to make it easier for those designing the levels to put their levels together, and overall just touched up a lot of the mechanics and code that was added this week. Hopefully next week the surfaces will all interact with the player and objects flawlessly, but I think we ended this week at a good state. 

[surface-tension-game]

Project Production Journal 1 Peter Eldredge

This week I worked primarily on smoothing out the movement in game. This involved developing a system of states. Each state affects how the player acts for that frame, and that state is set at the beginning of the frame. This new system allows for new states to be added easily and will hopefully make player reactions to different surfaces much easier. It also should make things easier for Drew, who has been handling most of the animations.

A few smaller changes were also added. Pushing and pulling has been added. Jump was changed so it takes 4 parameters now, each affecting the feel of the jump in a bit of a different way. All inputs were moved to Update to be more responsive, but anything utilizing physics remains in Fixed Update. I updated the function that stops players from getting stuck between boxes so that it is always consistent. I added some helper functions to reduce the size of the code and make it a little more clear to read. I have mad tons of small optimizations and updated ray casts and collides to make the game play more smooth.