The Making of Physox

At the time of writing this post, I'm a sophomore game design student. I began my journey through college last year, and Physox is the result of my first programming class. It was developed from late September to early December; within just a little under three months, this game was made from start to finish. It was my first extensive project within Unity. While it may not be the most fleshed-out game, it is quite important to me as a designer, since it's my starting point. I wanted to share my thoughts on how it came to be.

After I was introduced to basic coding principles, such as classes, vars, and scripts in general, my class was given an assignment to make a 2D platformer within Unity on our own. From the start, I wanted to make a puzzle-platformer; I've enjoyed playing puzzle games and seeing puzzles in games outside of their genre such as RPGs and platformers, so I wanted to give it a try on my own.

Something I admired from puzzle games was their extensive use of repeating assets. While a particular puzzle game may only have a handful of assets, with their functionality simple, developers can put those same assets into a large number of unique situations to provide fun challenges to players. In my case, this is why I ultimately settled upon a puzzle-platformer; if I spent the time to make a few reliable assets, I could stretch them out to make various new levels without needed unique code for them all. To me, this thought was appealing, especially since I was struggling with code at the time; after assets were done, I figured I would be able to have fun just designing challenges.

Originally, the game's concept was one in which the player would press a button to change the theme of their current level, and to alter its assets accordingly. For example, one level's themes may be "hot" or "cold"; the "hot" theme would feature water assets which the player would phase or swim through, and the "cold" theme would make them turn into solid ice, which would act as a platform.

While I did like the concept I initially pitched, I was profoundly unsure of how I would be able to make dynamic assets such as water and ice, and so I scratched the concept into a more traditional puzzle-platformer which involves the player moving objects to solve puzzles. I thought that such a game would be easier for me, as a Unity newcomer, to make, but no less enjoyable to play.

I used Unity's innate physics system for object interactions, rather than making a new one from scratch. Once I knew how to reliably provide velocity to objects, I decided that two basic types of objects should exist: boxes (which are rectangular or square-shaped), and balls (which are just circles).  I created sprites for both, attached Rigidbodies and colliders to them, and just began playing with them to see how moving them felt. I tweaked their mass and size throughout development, but I liked the simplicity of their core mechanics: boxes are reliable platforms which don't move too far from a push, while balls can be rolled down slopes and walked upon to avoid hazards. I think just by their looks alone, their purpose is clear to players.

Another aspect of puzzle games I wanted to give a try was their increasing complexity over the course of their campaign. The first level with a mechanic within a puzzle game typically introduces its core functionality, and then moves onto the next level, only to bring it back with a more complex goal in mind. After one mechanic's simple functionality is exhausted, a new one can be introduced, and the cycle would repeat, with the previous asset's capabilities mixed in. Physox follows this procedure of introducing an asset, exhausting its capabilities, and then repeating the cycle with past assets staying in play; as stated before, once I had assets programmed, I could enjoy designing levels while testing their limits.

I locked three of the seventeen levels in the game behind collectable keys. This is because to me, they are much more difficult and/or unfair to the player than the rest of the game's levels, and I was hesitant to keep them in the core campaign but still wanted them to be playable. By having the keys out of the way for the player, I hoped to allow players to only try these levels if they really wanted to.

Early on, I decided that I wanted the player character for the game to be a fox. This is largely where the title "Physox" comes from: a portmanteau of the words "physics" and "fox". This actually made developing the game quite a bit harder for me in its early stages; not only did I have to figure out how to properly let the player jump when they're supposed to, but I also had to take into account the player's primarily horizontal body for detecting ground. I also had to, with no prior animation experience, attempt to animate the fox because I didn't want only a static sprite to exist for them. As I was new to Unity's animation system as well, some animation state errors exist, particularly if the player becomes grounded too early after jumping.

In terms of music and sound, there are none within the game. This is because at the time of making the game, I did not know how to make them, and I also didn't know how to use licensed assets; it's fine in terms of the assignment I did the game for, but it's unorthodox for published games to be completely silent. Nevertheless, I chose to not add sound between when I completed the game and when I uploaded it here because I want to show the actual state of what I made at the time I made it. Even with all of its flaws, I want it to be here so I can look back at the start of my journey. 

I hope Physox can provide some insight into what a game designer's first challenges may be like, and I look forward to making more games in the future. Who knows what may be created?