MICROCOSM POST-MORTEM

August 29, 2017 Post-Mortems 0

A game made with a custom game engine I developed from scratch using the XNA/MonoGame C# framework in Visual Studio. Development took 1 month and was completed by just me in the Fall 2015 semester at Arizona State University. The game revolves around a shrunken engineer surviving the onslaught of office supplies in a cardboard box while floating in zero gravity. You can check out the game here.


WHAT WENT RIGHT

the game ran smoothly

Since the game engine was developed from scratch, albeit with some hands-on assistance by the instructor of the class, there was always the fear of all the interconnected pieces putting a strain on the performance of the game. The game was designed around an endless gauntlet of objects being spawned in a small box; a feat that is easily doable by a capable game engine. How would my ramshackle engine do? Fortunately, with plenty of playtests by others and myself, the game remained at a solid 60 frames per second. In all those playtests, not once did the game jitter or spaz out.

I partly attribute this to the hierarchical structure of the game engine. For example, a “tennis ball” is a class derived from the GameObject class. It extends the basic nature of the GameObject class by adding a time component to its speed. At every 15 second interval, the speed increases, which means the tennis ball will get drawn across greater distances. However, none of those lines of code are unique to the tennis ball class. Existing classes like rigidbodies and renderers perform all the processing while the tennis ball class is meant for number tweaking and special instances like power-ups. The simplicity in this coding structure reduced the inevitable complexity custom game engines tend to have, which would drastically reduce load on the engine and frame rate.

progression system

When I conceived the idea of the game, I had learned from my past experience with another “survival game” that if you don’t give the player something to do while they are surviving, then they will get bored. Furthermore, while drafting design documentation for the initial plan of the game, there was an intuition that the player should be able to do something more than move around. Essentially, that intuition is what led to the genesis of the power-up idea. Golden “pellets” would spawn at random locations around the insides of the box that the player would then need to grab and earn enough for an effective power-up. Being a huge fan of Mario, I also knew collecting these “pellets” needed to have a satisfying tune to it– otherwise, it feels empty and worthless. Combining this satisfying tune with the constant abundance of golden “pellets” scattered throughout space led to quite an addictive collecting minigame.

Plain freedom is not fun; it gives the game an incomplete feel. Collecting pellets allows for a guided experience that does not force, but encourages the player to move to designated locations. Instead of “what am I supposed to do?”, the player thinks, “how am I supposed to…” and that answer propels the player to keep playing. The added UI bar at the top signaling the ever growing progress toward a power-up and toward their stash of pellets continues to accentuate that encouragement. Needless to say, this progression system added “fun” to my game.

sense of impending doom

Even though I am not a big fan of horror films, I am incredibly fascinated behind the mechanics of scary movies– what makes a situation suspenseful and tense, for instance? One such mechanic is making the antagonist hidden or invisible. This allows the audience to draft up horrible concoctions of possible gruesome scenarios in their head about what is behind that foreboding door. That “not being seen” mechanic is used intentionally in Microcosm. The objects are so huge to not only make the player feel like a tiny person, but to also have part of the object’s material impaired by the boundary of the screen. It is purposefully impossible to see two game objects in its entirety on your screen, which then makes the player think, “Is the other object near or behind me?!”. It doesn’t help that the signal of a new object entering the box is a blaring alarm with a warning sign flashing in the middle of the screen. All of these mechanics keep the player on their toes and accelerates the amount of fun they are having. It is also part of the reason why all of the base classes are extended to include a time component. Every tick of the clock is not only another second alive (which adds to the player’s score), but a second toward making the hazards faster and more dangerous.

WHAT WENT WRONG

it’s ugly

The game does not look appealing. In fact, it looks like a PlayStation One game. The biggest challenge with designing and developing a game engine from scratch is being able to conform the physics and collision detection to a particular shape. Initially, I was planning to add multi-polygonal playing jacks as an object to dodge. However, since I did not have much development time to add collisions to each individual edge and point, that idea had to be scrapped. The extent of my collision detection rested in box and circle colliders and, consequently, the only objects the player sees in the game are spheres and cubes.

I used 3dsMax to model not only the tennis balls and chocolate bars the player had to avoid, but the cardboard arena they would be in. Due to time constraints and my programming abilities vastly outweighing my artistry, I did not have time to learn how to bumpmap my surfaces and add higher resolution textures.

player movement

Almost everyone wishes they could fly and, I would assume, it would be an exciting prospect to tell players that would be the major way to traverse the game. However, I imagine that excitement dissipating when they try to control the character. Since the game engine was from scratch, a lot of 3D math was used to direct the “forward-space”, “left-space”, “backward-space”, and “right-space” of a player’s actions. I binded them to standard first-person controls in any computer game: WASD to move, SPACE to ascend, SHIFT to descend, and the mouse to control the camera. All of this was fine until I had to program the way the camera worked. I ended up with a “screen boundary” approach where the game would detect whether or not the mouse pointer was near the edge of the screen and then move the camera accordingly. However, the edge cases were neglected. When the player places their mouse pointer at the top-right corner of the screen, for example, they are greeted with a sporadic top-right motion where both the top and the right try to tug for control. When the player would then try to recover by placing their mouse pointer back in the center of the screen, they would often overestimate and hit the bottom-left corner, throwing them back into chaos. If I had more time, I would investigated the problem more, but I had to prioritize finishing the game in its entirety first.

lack of a tutorial

As one can most likely see, a majority of what went wrong involved a fast-approaching deadline. The biggest oversight I had was forgetting to put in a tutorial and relying on players to be familiar with typical first-person PC games. The closest I had was a screen with text listing the controls– an ugly screen at that. When having classmates test out my game, they almost always needed my help with traversing the anti-gravity. However, once they got the hang of it, they immediately began enjoying the freedom of moving around.

WHAT I LEARNED…

… as a programmer

When I signed up for the Game Engine Development class at Arizona State University at the start of my junior year, I thought we would primarily be dealing with 2D game engines similar to GameMaker. Little did I know that we were going to be thrust almost immediately into advanced linear algebra and Calculus concepts… and I loved it! As an active user of robust game engines like Unity3D and Unreal Engine 4, I take for granted how intricate and elaborate all the different components need to be to make a fully functioning game. For instance, a GameObject. I would have never guessed that to make anything appear in a game, we would need to attach transforms, renderers, rigidbodies, colliders, and cameras, and each of those objects have their own attachments and subclasses.

Additionally, the class was one of the first where I saw the true impact of math on game development. Collision detection, especially. Imagining a 3D surface interacting with vectors still boggles my mind. The fact that taking the cross product of two colliding objects can then give you the reciprocating direction of velocity upon impact is astonishing. Linear algebra is as significant as ever when it comes to game engine development and the game definitely allowed me to harness and master those skills. Now, when I look at any game, I cannot help but see the various vectors interacting with each other.

… as a developer

This project was the first time I ever experienced “crunch time” for a game development venture. Much to my chagrin, the project was assigned near the end of the semester. Having a limited amount of development time made me realize the value of having proper design goals and documentation. Without them, I would not have been able to prioritize my work and have an end in mind. Even though the stress at times was overwhelming, without it, my vigor and determination to finishing the project would have been nonexistent.