Brick^2
Brick by Brick, aka Brick^2, is a unity project that turned into a 'playable' prototype. After my 'first' project in Unity, (see "First Steps"), I wanted to make something from the ground up. I began with writing my own movement code. Then moved on to making textures, models, materials, prefabs, simple environment objects, and more. (Note that the videos on this page accidentally have audio, my apologies for the annoying keyboard)
I referenced some of the calculations used in some unity projects for movement. I took the best working aspects of the systems I looked at and wrote my own. I specifically used the Unity Input System Package Add-on to handle player inputs.
Movement is calculated as a 3d vector. First the script takes a 2d vector from the player input system, (using the wasd keys), and turns it into a 3d vector by adding an 'empty' vertical component. This new player input vector is combined with the players current velocity vector. This calculation references the player's current world state, which determines what parameters/modifiers used to actually calculate the movement frame to frame.
Once all of the relevant information is acquired, the last component used in the movement calculation, is taking in the normals of the surface(s) the player is above and/or touching. Thus all forces acting on the player are changed in such a way to interact properly. Specific examples are the constant downward force the script applies to the player mid air, and the force resulting from player input. This will be very relevant to future topics later on this page
Player and camera rotation are handled simultaneously. First the input handler takes input from the mouse, separating the x and y axis's from each other. The intention behind the separate horizontal/vertical axis's is so specific x/y sensitivity/inversion options can be added later.
I included crouching and sprinting functionality in the player movement as well. To practice the basics of both game 'tropes' as well as gain more practice with the input system manager add-on. Sprinting simply triggers a number in the movement calculation to be changed by the sprint multiplier set in the inspector. (Default value is 1.5). The crouching functionality changes the height of the character controller by changing the position/scaling of the top hemisphere relative to the bottom hemisphere. The default target heights for the standing and crouching states are set in the inspector.
Above is a map of the play scene. The layout of the scene started with the 'starting area' and eventually expanded outwards as I wanted to add more testing elements to the scene. (The start area is pictured below)
The first thing that was made in the scene are the three parallel hallways in front of the player and the orange texture applied to the terrain. The halls were used in my tweaking process of my character controlling script. The texture was so I could personalize my workspace as well as start learning a little bit how textures work.
Several ramps/blocks were also present but have since been removed.
On the right side of the image is the "ha" door as I call it. On account of it being on the layer labeled as "ha". The player character prefab I made has two cameras, the main camera and the weapon camera. I removed ha from the main cam's visible layers and added to the weapon cam's layers. That cam can only see up to a max of 10 meters away, resulting in the doorway being invisible until the player gets close.
The 'ha' door is indirectly visible via the left section of the start area.
Here on the left side is a better executed 'mirror' concept compared to my first attempt in my previous project. This object occupies several roles. Both as a part of the scene, as well as a display of the scene.
The first role the mirror plays is as a means of giving the player a sense of 'self' and scale. Showing the player: the player, 'telling' them that they're a cylindrical objects with rounded ends. Why do this? Why is this important? While tweaking the movement, walking around and interacting with geometry, I found that when landing on, or jumping into edges of objects can sometimes cause the player object to bounce off at an angle, the same way a ball would. Obviously it does this because that is the shape of the player. But that's only obvious to me because I made the shape. If someone else played this, and bounced off edges the same way I did in testing, they could hypothetically guess what their shape is. The problem being that 1. There are multiple hypothetical conclusions a player could come to that would get close to what the actual shape is, but would still be incorrect. Such as the ends being conical, beveled, etc. 2. This is making the assumption that the player is willing to make these deductions in the first place. 3. players would only be clued into what their shape is when colliding with edges. If they cared enough to try to figure out what their shape is, it would be a tedious process to test. 4. And even if players wanted to guess what the shape is, and they were to correctly guess it. They would have no concrete proof.
The 'model' is a collection of two spheres and a cylinder. Each sphere is parented to the top and bottom hemisphere of the player controller, matching their placement and scale. The cylinder is attached to the top sphere and points in the direction the player's main camera is facing. This character can definitely be improved. I could get rid of the two spheres and edit the character controller script to resize a 3D capsule the same way it resizes the controller component. But as a quick way to visualize the player as something other than just a floating gun, it gets the job done.
One important thing about the mirror, is though I call it a mirror, it really isn't one in the technical sense. Technically it is just a camera's render texture applied to a 3D quad object had it's x scaling component inverted (x = -3). This inversion is what causes the image to be flipped horizontally, imitating the way real mirrors flip images horizontally. While a 'realistic' mirror could be made by having an orthographic camera render an accurate 'reflection' (angle of reflection == angle of incidence). This however would not fulfill the roles I wanted the object to have. To quickly give the player a sense of self and for a little bit of experimenting with rendering textures. By having the camera's position be fixed, this allowed the player to look at themselves without being distracted by the entire image constantly changing.
While experimenting with rendering and the mirror, I wanted to make something using these systems that a player could interact with. First was having the mirror camera see the 'ha' layer, and then placing the mirror in a place that can see the 'ha' door. I expanded on the idea of the camera seeing things the player can't. I added a cube in view of the mirror and moved it to a new layer that only the mirror cam can see. Now the cube was 'invisible', the player could physically interact with, they could bump into it, jump and stand on it, etc.
Next I wanted to deliberately arrange the scene in such a way that wordlessly prompts/teaches the player to interact with the invisible cube using the mirror. Originally the cube is placed to the side of the mirror and not directly in front of it. This meant that even if a player found the mirror and looked at themselves, they aren't directly made aware of the cube's existence. They can see the cube in the mirror, but they might not immediately register it consciously. And even if they consciously notice the cube, they would have to make a leap to guess that they can interact with it. By moving in front of the mirror, and making it high enough to block view of part of the player, it results in any player that notices the mirror will run into the cube before they run into the mirror. This sudden change in movement will often cause someone to closely examine their surroundings, especially the mirror. Beside an individual's innate curiosity, this could be expanded on by creating a way to somehow reward the player for interacting/investigating the area. Maybe by placing a visible 'coin' above the block. That way the player can always see the coin, and the only way a player can grab it is by jumping on the 'invisible' block.
This mechanic of the mirror being the only way to see parts of the environment is a concept interesting enough and deep enough that I believe a whole game could be built around it. Possibly some kind of puzzle platformer?
After the mirror was in a reasonably 'complete' state that I could return to later. I moved to spending some time learning how to make, then import: 3D models, materials, and textures into unity. I used blender for this. Setting a goal of making some kind of object for the player to hold. The result ended up being the 'gun' the player is holding and the textures you see throughout the scene. The gray and arrow textures were part of my attempts to figure out how materials are applied to objects. The last texture of a white box with black outlines is a 'clean' texture I plan on using as a standard prototyping texture going forward.
Player object
Free body diagram of a
player object 'surfing'
-Red arrow: The horizontal component of player movement (Results from player input)
-Green arrow: Vertical component of player movement. (Results from the player control script applying a constant downward force to the player)
-Orange arrow: The horizontal force the slope applies to the player. (The players vertical component is partially converted into a horizontal force when the player collides with the slope. This force scales with vertical momentum.)
-Blue arrow: Remaining downward momentum after the conversion.
Having spent time modeling and making textures, I returned to unity by doing some more tweaking and testing movement. I did some tests involving the character controller's slope limit. Beginning with creating a large block with a slope of 46°. (This block turned into the 'training slope' closest to the starting area). After walking and jumping onto the slope, I immediately realized that holding forward while on the slope resulted in my fall being slowed. Having played games such as Counter Strike and Team Fortress 2 I was aware of the potential that was present. I had just discovered surfing in my game, although I had no intention of having it be a part of what I was making.
Surfing is an emergent mechanic in games wherein a player slides on angled surfaces by moving perpendicular to the slope, this causes the horizontal force the slope applies to the player to be cancelled out. This mechanic is associated with Source engine games (TF2, CS:GO especially), as there are many community maps made exclusively for surfing. Surfing in Source games is a mechanically deep skill with a very high ceiling. Although this skill has very little to no use in Source game competitive settings, that has not dissuaded players from investing hundreds and even thousands of hours into surfing. Why? Because it's fun.
After discovering that I can surf, I began to try to find the best angle for surfing. I created copies of the block I was using to surf on as well as some raised platforms. The raised platforms acted as a goal when surfing. Making sure I could get from one platform to another. I spent a decent amount of time changing and testing slope angles. I started with a range of 47.5°-50°, eventually narrowing the best surfing angles down to 49°-49.5°. I found this range to be the best balance between being fun and limiting the max height a player can reach. (Slope angle could use further investigation when it comes to larger terrain.)
Surfing in Brick^2 has some major differences from surfing in Source. The most significant one being that you can't stay on a slope without eventually slipping off. My hypothesis as for why this happens is due to how I programmed mid-air movement. Surfing on a slope counts as being -mid-air, the downward force from controller script is constantly being applied. It is then converted to a horizontal component as shown in the figure above. This affects net horizontal movement more than player input can. Resulting in the player always eventually sliding downward. This could theoretically be changed by altering any combination of player mid air acceleration, downward force being applied, or slope angle.
Having found what I felt as a good range of slope angles to pick from, and coming to at least a partial understanding of how surfing works in my game, I started to build a curved slope. My hopes were that I would learn how to build a slope section to use as a way to get around corners/obstacles that are otherwise impossible to get around with normal movement. What I didn't realize however is that I would discover an entirely new emergent mechanic. This is where my understanding is not as complete compared to other parts of my prototype.
The first curved slope I built (pictured on the top right) was a couple of 49.5° slopes incrementally rotated 15°. I extended the slope (pictured below the first pic) on account of that the player would eventually slide further downwards. Starting from the top more or less worked as expected, I was able to use the curve to make elongated turns, reaching the bottom platform. Wanting to fully test the slope and get a better feel for my surfing mechanic, I started a surf from the bottom platform. Whether by blind luck or just being able to pick up on game feel, I realized that I wasn’t falling off the slope as fast as I should have. In fact, I believed that I was somehow gaining height. Though I had no idea why or how exactly. Not only did I notice this unexpected property, but I also observed that I was getting surprisingly close to reaching the top platform from the bottom one, something that wouldn't be possible with a straight slope surface (See the video on the right as a small sample of attempts).
I could tell that it was at least theoretically possible reach the second top platform, but since I’m the first one testing this obstacle, I had no idea if I actually could reach the top. I had no idea why or how I was going so high on this curved slope, so I had no way to empirically measure what the hypothetical max height was. And because I made the code that controls player movement, this emergent mechanic isn’t something I could even theoretically find another game to compare it to. This game’s surfing was already significantly different from other games that have surfing. Now I found something that I don't entirely understand without any point of reference whatsoever. At the same time, this wasn't just a ‘different kind of surfing’ anymore. This was my mechanic. Now I needed to understand it and prove that I could test and build around it. What better way to do it than to reach the top platform.
Above is a video showing some attempts to reach the higher platform by surfing on a single, straight, slope. It is not possible to reach the top platform in this way, even with the use of sprinting and/or bhopping
Before I began my first attempts to reach the top, I made a few decisions as to what my process would be. First was that I would not change any values regarding player velocity, acceleration, or movement in general. I had already extensively tweaked these to get a desired game feel. I did not want to compromise the movement’s feel for the sake of reaching an arbitrary ledge. Second is that I wanted to reach the ledge without using the sprint functionality at all. This was done for several reasons. I did not want to add another variable into an equation I did not have a complete picture of. By being able to do it without sprinting, it should guarantee that it is not only doable, but also easier when sprinting. Third was that I wanted to recreate this ‘level geometry’/’game mechanic’, I needed to identify where this behavior is emanating from.
After a significant amount of attempts to reach the top, I eventually was able to reach the top platform. And after some further practice I became able to reach the higher platform with a fair level of consistency. Though not much else exactly happened from moment to moment during my attempts to reach the top, the few things that did occur were substantially significant. The first result I became aware of was that I was consistently improving throughout my attempts. Not every attempt was better than the last of course, but the average performance was steadily rising. The second result of interest, which is probably the most important all things considered, is that I was having fun. The combination of these two factors, as well as my vested interest in what I made, were what motivated me to continue testing in spite of me not initially knowing if it was possible to reach the top or not.
“A funny thing happened to me as I was building this mountain:
I'd have an idea for a new obstacle, and I'd build it, test it, and... it would usually turn out to be unreasonably hard. But I couldn't bring myself to make it easier.
It already felt like my inability to get past the new obstacle was my fault as a player, rather than as the builder.”
-Bennett Foddy (Getting Over It)
This last part of the page is under construction!!!! Come back later please
Textures, Gun Models, prefabs, scripts, materials, etc- Calvin Hilgert