Surface Tension Game

[surface-tension-game]

PPJ Mark S Week 8 ( LATE )

I apologize for the late response on this one.

This week I recall making scripts that would pattern the textures onto surfaces, although we later found a better way to do this directly in unity without requiring horizontal, vertical and diagonal tilling.

At this point I sort of figured out my place in the team as more of an artist than a programmer, as we already had three on programming and I decided from this point forward that my personal experience with programming was not enough to keep up with the group. In retrospect, helping out with art was a much more meaningful contribution.

[surface-tension-game]

Game Development Journal 4 Drew Graham

This week I spent my time on implementing sound effects/music in the game. I think I over-engineered it a bit considering the end-of-the-line nature of Week 11, but it was good practice in implementing a feature properly to make it easy to tweak and extend the functionality of sound in the game.

This Audio struct allowed us to organize important information about each Audio clip in the game.

I also spent a lot of time making sure the build functions properly. A lot of things that looked/worked fine in the editor did not come out the same way in the build. Most notably, many textures did not show up in the build. It turned out to be an issue with the pre-compiled shader settings in the Project Settings > Graphics Settings. We had to check all the types of shaders used in our materials/textures, than make sure those types of shaders were being pre-compiled in the build process so that they’d show up in the build.

These changes don’t entail much that’s screenshot-worthy, so you’ll have to look at the final build to see them in action.

[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]

Mark S PPJ Week 11 ( Final)

In addition to other art assets such as goal and pit gradients, I worked on tutorial  and hint assets to liter around our game to help the player figure out controls as well as basic concepts, as the game progresses we decided to leave less and less visual cues as to what the player can do as well as making a greater percentages of the surfaces the default color.

Additionally, I continued working on the games beats sheet and was in charge of organizing the full final build of levels, keeping in mind how much information the player would know, what difficultly to expect from a certain point in the game and continuity of a puzzle mechanic over a couple of levels, such as bouncing cubes or wall bouncing.

Eventually, the types of levels began to merge together at the end where we really starting finding a lot of interesting combinations from a few isolated puzzle solutions.

[surface-tension-game]

Ian Morales

This week I had to work on textures, and title screen assets. 

[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]

Product Production Journal Week 3 (Jacob Dixey)

This week I was tasked with “figuring out tiling” as direction. This lead me to the tilemaps and palettes, wherein I cut up Ian’s sprites and decided their colliders by editing their physics shapes individually, and turned them into palettes which I used to paint over the old levels.  I decided to leave changeable surfaces as quads as surface changing was not playing with tilemaps very well. This makes some more advanced level ideas impossible, such as two having surfaces change at the same time.

Here’s our first level that I redid:

Here’s an example of tiling paint (the palette is empty because of a known bug in Unity, and yes, it does make it a far bigger pain):

Other than tile painting, I also conceptualized and created 5 new levels. They’ve been playtested by me and Peter but definitely need more playtesting from others. I focused introducing a mechanic or new way to use that mechanic, and then using it in a more advanced setting or combining it with a previously introduced mechanic. I also tried to link level architecture and give a sense of continuous location. For example:

Level 6 holds the bottom of level 8

Level 7 starts in the bottom left, seeming to connect level 6. It leads upward and to the left to level 8.

Level 8 involves boxes and shows that boxes could fall through, explaining Level 6′s blocks. This is the kind of thinking I tried to convey in each level.

Additionally, Level 9 branches into Level 10A and 10B. 10B is just a silly branch that leads to the same level, except because you followed the box down, you actually follow the box down into the next level. The important part is that I tried it because it was extremely easy to do with the way I implemented the level ends and their scripts, so real branching level could be a genuine part of our design.

[surface-tension-game]

This week I worked on  the background art. We wanted to convey the sense of an ancient temple with details of ruins. To keep from the background form being to distracting, I kept the palette muted and we planned to make the surfaces and other foreground objects more vibrant from the start of the the project.

If time permits, I plan to add supplementary texture to the wall and floor, as well as push the contrast from front to back to create the illusion that the main calendar object is both far away and massive.

-Mark S

[surface-tension-game]

Drew Graham - Week 10

This week I spent my time focusing on the appearance of the player.

I’ve finished importing Ian’s 64x64 sprites into the game. We were previously having issues with sprite clipping - the front of the player sprite on one frame would overlap with the back of the player sprite on the next frame. The jump to 64x64 fixed this, and I also fixed the strange color issue on the imported artwork (it was caused by Unity compressing the sprites)

I added Ian’s jump animation to the game (it can be seen in the gif below), which required me to rewire my Player animation controller a bit. We now have jump states triggered for when the player is ascending, at the peak of a jump, and then descending.

I’ve added a nice trail particle effect for the player. Unfortunately it isn’t very clear in this gif (my laptop gets slow while recording and running Unity), but if you look closely you’ll see a gradient in the trail. I’m setting custom parameters for a color gradient to match the player’s equipped material. The trail effect does a good job of conveying the player’s motion (especially while moving fast and jumping), while also giving the player information on what material they have equipped. We’re thinking of removing the material indicator in the top right corner, as it might not be necessary anymore.

I like organizing my data in neat structures, so I created a Dictionary containing materialTrail structs that hold the parameters needed to customize the color/transparency of each material gradient. The parameters are shown below:

[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]

ART

Art This week I completed a pulling  and jumping animation as well as the null surface and the bouncy surface. Ian Morales

[surface-tension-game]

Project Journal 2 (Week 9) Drew Graham

This week I worked closely with Peter on implementing surfaces in the game. I handled the Slick surface, while he tackled the Bouncy surface. I developed a fairly functional Speedy surface (Slick surface, but without the low friction) as you can see below:

Ian provided me with 64x64 spritework, so I began importing them into the Player animations. The glitchy pixels on the edges of animations are gone, but the colors are a bit weird:

I’ll have to come back to this later and see what’s going on there.

Next steps: implement slippery friction on the slick surface, move on to the sticky surface.

[surface-tension-game]

Project Production Journal 2 (Jacob Dixey)

This week I worked on adding some relatively easy to implement functionality, but functionality that was needed for our playable demo nonetheless. All in all, I added killboxes which will be used for if the player falls out of bounds (and later if the player in the case we decide to include something such as spikes), reaching the end goal of a level and moving to the next, and replaced the temporary colors for the materials and using the tiling function Drew created to make a modified version for tiling the materials of the surfaces as they come into the scene.

Here I show the killbox I made, which I implemented by creating a collider with a “Kill Box” tag, and so the Respawn script on the player will look out for this tag and on using OnCollisionEnter2D (which took far too long to figure out it needed to be 2D at the end) Respawn will now check if the player has collided with the kill box, and in the case this is true, will reset the current scene just like the reset button.

Similar to the kill box, I used a collider to figure out whether the play touched the goal point; however, this time I put the script on the goal rather than the player and made it an OnTriggerEnter2D (another necessary 2D that lead to a lot of wasted time). This trigger will check to see if an object with the “Player” tag has triggered it, and if so, loads the next scene that has been named as “Next Level” in the inspector.

I took away the colors and changed them for the materials of which we have decided to use. I declared an array of materials and from the inspector I can decide how many and which materials, which corresponds to four materials we have, so in the script I can access the array and switch the objects material in the same switch statement that Drew and I used to change the color. There is no sticky texture yet, but I still made it its own material.

[surface-tension-game]

PPJ Week 9 Mark S

This week I handled level design and building. I first started with a beat-sheet that lays out how quickly new content would be introduced to the player on a per level basis. For example, this weeks levels consists of only puzzles that use the movable cube and the bounce surface ( although we do have rough functionality on the slick surface)

The main goals of these early levels is just to quickly ease the player into the controls and rules of the surfaces. The first combined usage of two separate surfaces comes in the second level, where the player has to realize to jump on the higher bounce surface, then onto the lower in order to progress. This formula of combining the interaction of different surfaces is what we want people to appreciate from a game-play and puzzle solving standpoint.

[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.

[surface-tension-game]

Project Production Journal 1 (Week 8) - Drew Graham

This week I worked on refining the existing game code, as we prepared to implement some of the surface functionality. We made sure to be very careful with how we wrote our code so that our physics would work as intended and deliver the experiences we drafted out initially. 

Peter added support for both pushing and pulling boxes, so I implemented a new animation for box pushing (pulling doesn’t have artwork yet). 

We experimented with several ways to implement the bounce feature, but none have come to fruition yet (our player behaves differently in physics than our box, so we have to devise a way to make both bounce the same way.

I started working on a design for a Surface class that will allow us to easily create different surfaces. It should function as a base class that shares common functionality between all surfaces, but also allows specific behavior to be programmed for each surface specifically (ideally a base class to be inherited). However, me and Peter are prototyping our surfaces individually (he’s doing the bounce surface, and I’m doing the slide surface), so we’ll have to be careful and make sure our work comes together nicely.

[surface-tension-game]

Project Production Journal 1

This past week, my first goal was to create the ability for the player to respawn by resetting the scene. As the player will always be in a situation where resetting the entire level would be best for the sake of the puzzle, loading the scene once more felt like the best choice. For now this functionality is tied to the “R” key for the sake of testing, but the code for it will be ran when the player dies in other ways, such as falling down pits.

My second goal was to build the framework by which we can change the quality of a surface just by clicking on it. For the sake of testing it and showing it works, I did so by changing the color of the material the script was applied to, which is accessing the same component that we will when the time to change the objects actual material to our surface materials comes around. By pressing 1, 2, or 3, different materials can be equipped as shown by the makeshift UI I made in the bottom left of the screen. Clicking will then change the specific surface to the color we have chosen to represent it for now.