I am going to take a break from development of my game, titled Relativity, for the next few days to 1) reflect on the project and get an overview of the game so far, 2) plan out a course of action for the next few months, and 3) catch up on all the life things I’ve neglected for the past several weeks.
I should warn you now that this blog post will be quite long and convoluted, and will likely reference many things that probably don’t make any sense. This is because this post is intended mainly for myself to help me make sense of the project. However, if you’re interested in game development, you may find a few bits here and there that are somewhat useful, or at least interesting.
State of the Game
I have been working on the game full-time for a little over 7 months now. My initial intention was to create a small practice project to get myself familiar with the Unity engine, but alas, I am now knee-deep in development of a game I’m hoping to release publicly sometime in 2014.
By now, I’ve rewritten the entire game about 6 or 7 times, although the exact number depends on what would be considered a “rewrite”, as some versions contained major modifications from previous versions, but were not changed from the ground up. Both the game mechanic, as well as the visual aesthetics of the game, have gone through significant changes in the course of development, and will likely continue to do so. In fact, I would say that even the latest visuals are nowhere close to what the final game will look like.
Currently, these are the features I have implemented in the game:
- 28 puzzles
- 1 environmental hazard
- 2 different kinds of objects to interact with
- Various visual cues to assist with interaction (allowing the player to better sense distance)
- Some sound effects
- Various environmental cues to assist the player with determining the objective of each puzzle
- Some placeholder background music
- Title screen and in-game pause menu
- Xbox 360 controller support.
While it is very difficult for me to estimate how far along I am in development, as this is the first game I’ve ever made, I would venture to guess that I’m about 30% of the way through. I have ideas for 5 more kinds of objects that the player can interact with, each of which will lead to 10 puzzles. By the time I finish implementing all the different ideas I have for player capabilities and object types, I will probably end up with around 80 to 90 puzzles. I will then select around 40 of the best levels from this group, and refine them over the course of a few months.
Evolution of the Project
The core idea of the game centers around changing the orientation of gravity, and in this way, the player gains new perspectives on how to solve different types of puzzles. Without going into too much detail about the game play at the moment, I want to show you some screenshots of how the game has evolved. I no longer have the project files for the very first prototype of the game, but version 2 is pretty close, so I will start with that one.
As you can see, in versions 2 and 3, I put a lot of focus on the visuals, spending a tremendous amount of time looking at different wood panel and concrete textures to try to pick the right one. This was a bit of my mistake, as I should have spent that time prototyping different game play mechanis and puzzle designs.
Another mistake I made while working on these early versions was that I caught too caught up in creating a narrative for the game when the game play itself hadn’t been fully finalized. When working on version 3, I had written an entire elaborate backstory, including what the style of architecture should be, and even a new language system. Much of it was irrelevant to the game at this point, and used up valuable time. Also, by having a story set in place, it forced me to design puzzles around the narrative, instead of trying to create puzzles that explored the game play mechanic.
After having some people playtest the game, I realized I needed to rework the core mechanic and the puzzle design. It was hard to let go of the old ideas at this point, as I had already invested 4 months into the project. However, I knew that if I didn’t do it now, it would only get more difficult down the line. Also, around this time, I watched this talk by Jonathan Blow, in which he talked about the importance of constantly prototyping, and the willingness to ax an idea as soon as you realize it’s not working out.
With version 4, I decided to start from the ground up, and to focus on the game mechanic without worrying about the visuals at all. As you can see, pretty much everything in the game is white, with only a few colors here and there, and almost all the objects are basic primitive shapes. This allowed me to focus on the game play itself, and it was here that I began to find another mechanic that led to much more interesting and diverse puzzles.
From then on, I began to explore the potential of this mechanic, and would only introduce visual elements to the game when they played a function role. As such, there are no unnecessary visual elements. Everything, from the shape of objects to the color of the wall, exist to convey certain information to the player. The game may not look as “exciting” as the early versions, but the visuals are more carefully designed, and in this way, much cleaner.
Through various small changes here and there, I arrived at version 6, the latest version and what the game looks like right now. It is still nowhere close to finish, and I have a lot of ideas to add. Consequently, I don’t think I will get to the final polishing stage until early 2014.
Problems I Am Having
During the first few months, I was able to keep track of the number of bugs in my head. But now, it seems like every feature has at least one or two minor bugs, and every time I fix one thing, something else seems to break. I thought this would be a good place to list some of the problems (in both design and development) that I am currently facing:
- The game looks too much like Portal. While it does seem like you can’t make a first-person puzzle game without people inevitably comparing it to Portal, I think the visuals at the moment do draw a little too heavily from that game. Most of these are placeholder art I’m using to prototype levels, so eventually they well be redesigned. But when I show the game for playtesting, the first thing that springs to the player’s mind is Portal, which ends up influencing their expectations. Right now, this isn’t necessarily a negative thing, but I do want the game to have a unique visual aesthetic and style, so I will have to spend some time on this aspect of the game later.
- Collider objects intersecting with one another. I think this problem is mostly due to the native physics engine in Unity, which requires objects to intersect one another in order to calculate collision. For most circumstances, the intersection is minor and doesn’t affect game play. However, because stacking boxes is a pretty major component of my game, intersection of the boxes is a bit of an issue. I’ve found a way to minimize the intersection by playing with the min penetration value in the project settings menu, and making objects kinematic when not being used, but collisions are still not working as well as I would like.
- Odd physics glitches here and there. The physics in Relativity is heavily restricted. For example, there is no rotation and no bounce. While this is unrealistic, I found that it was a huge improvement with regards to the playability of the game. This is because the game requires very precise placement of objects, and if the physics is too realistic, it actually becomes very difficult to position objects in the desired positions. By restricting the motion within a certain range, I can minimize player frustration. As such, I am overriding a lot of the native physics functionality in Unity and writing my own. For example, sometimes, for collisions I am using triggers placed on the surface of objects, and using the trigger to detect whether something has come into contact with an object, instead of the default collision detection functions. This leads to unexpected bugs here and there, like objects going through walls, especially when the objects are used in a new situation. I haven’t quite figured out a good way to tackle this issue yet except to try everything I can think of when playtesting, and see if any odd behavior arises.
- No narrative. This is not really a problem at the moment, as I’m still trying to refine the game feel, and to work out all the puzzles and player capabilities. However, at some point, I will need a narrative structure for the game in order to provide incentive for the player to keep going. It gets a little boring to keep solving puzzle after puzzle without knowing why, and with no end in sight.
- OnTriggerExit function on some of my triggers are called when it is not desired. Specifically, when I have a kinematic collider sitting on the trigger, and another objects hits the kinematic collider, OnTriggerExit will be called, and the trigger will think that the kinematic collider has left even though it hasn’t. If I make the collider non-kinematic, then I get major problems with colliders intersecting one another, as stated in problem 1 above.
- Player occasionally rotating out of the room. I think this can be solved by using a ryacast from the back of the player’s head and determining the distance from the player to the wall to make sure player rotation doesn’t cause the player to flip out to the other side of the room. However, in my experience so far, these small problems are usually deceptively difficult and end up taking a ton of time to fix.
I spent the past few days adding decals to all the levels in order to better communicate puzzle objectives to the player. In the next few weeks, I will begin to create various new capabilities and design new levels accordingly.
While the interaction design and the feel of the game are not completely finalized, I’m pretty happy with how it is at the moment, so I will leave it as such for the time being. I do need to implement a way for players to save the game, and also to adjust the sensitivity of the mouse and the controller while they’re playing. I also need to implement a background timer so that once I begin playtesting, I can get an estimate of the game’s play length.
I will also start to brainstorm ideas for a story, and ways to communicate the story to the player, whether via in-game text, cut scenes, or voice-overs. However, I don’t want to get too carried away with the narrative at this point. I want to have the game structure pretty much set, and then use this as a foundation to create the narrative, instead of the other way around.
Finally, it has been a while since I pushed to Github, so I need to get around to doing that. Soon.
A Few Lessons I’ve Learned So Far:
- Always be prototyping.
- In the early stages of development, focus on game mechanic, not narrative and visual aesthetics.
- Playtest often, and early.
- Don’t be afraid to let go of ideas that are not working.