This postmortem is expanded from an original version written for the Champlain College Game Studio Capstone course on 12/6/19.
Looking back on this past semester, I feel that I have grown in so many ways as a programmer and a game developer as a whole. I’ve learned many lessons big and small and had a lot of fun throughout the process. From my first team voice chat meeting over the summer to concepting and the final pitch, I have been stretched creatively in ways that have served to make me better at making games, both in the technical programming sense and in the wider sense of the craft of building a game from start to demo pitch. This semester I have created three game prototypes in Unity on constrained timelines and flexed my technical efficiency. I’ve seen three prototypes and I know how to compare and contrast implemented examples against a central guiding vision for development. This semester I built gameplay systems and I built tools for designers. This semester I have become a better communicator and a better listener.
Box Voyage
The centerpiece of my capstone experience this semester was the production of our pitch demo for Box Voyage. Box Voyage is a light puzzle game set on a cruise in a box that requires you, an overworked & under compensated corporate employee, to complete puzzles to fill your fun meter and have an enjoyable, legally required vacation. In a box. At the end of the Fall semester, our team presented the game to the faculty and our classmates through a pitch presentation, a trailer (the one below!), and a demo. I am happy to say our game was one of eight selected to move forward into the Spring semester. It was a long road to get there and a lot of work from art, design, and code. In this section, I'll be talking a bit about my contributions as the game's programmer.
Box Voyage Tech
I worked as the team's sole programmer in the Fall, implementing everything from gameplay systems to a node-based map editor tool for our designers. As a programmer, Box Voyage presented a number of technical challenges that were met and overcome, as well as some issues that remain roadblocks going into the Spring Semester.
Cube Rotation & World Traversal
One of the central aspects of the gameplay is rotating the cube in order to move to a new room in the cruise ship. The team decided to handle traversal in this fashion early on to try and avoid pacing issues between core gameplay interactions. If you watch the video above, you can see the cube rotation in action accompanied by signs that note adjacent rooms. The process for rotating the cube was an early challenge in the development of Box Voyage, and it is one that will likely need to be tackled again this coming semester. As the cube rotates, the previous room is destroyed and then next one is spawned. This is done so that rooms themselves don't have to be rotated and instead only the cube is rotated with every room spawned and deleted at the same coordinates. In essence, cube rotation presents the illusion of traversal moreso than a one-to-one rotation. The current solution is not the ideal one for us going forward because the visible spawning in and out of puzzle rooms break intrudes on the fantasy of the game world. Work was started on a more seamless cube rotation solution in the Fall, but was cut for the pitch demo. Next semester, the team will continue work on that seamless solution to really solidify the fantasy of the game's vacation in a box.
Looking back on this challenge and the solution we reached, I am happy with the functional nature of the solution. It works well enough to function and communicate traversal clearly to the player. I do wish we had reached a more immersive solution though. Going forward, I want to work with the programmers we've added to the team to ensure a seamless solution can be implemented. In my mind, the cube rotation/room traversal is one of the major technical areas of the game that missed the bar we set for the game in terms of setting and is an area I want to revisit with further research and resources to get it 100% right.
Compass Map Editor
A technical aspect of Box Voyage that helped form the foundation of our production pipeline was our node-based map editor Compass. The editor, built using Unity's Editor library and the help of a tutorial, utilizes JSON to store and load the layout of the game world. The puzzle rooms in Box Voyage are laid out on a grid with nodes that can hold up to 4 connections each. Nodes in Compass contain input entries for the name of the room and the name of the puzzle prefabs. Nodes can be linked up, down, left, and right, and connecting nodes means that the two rooms in-game will be connected. To delete nodes, the user (probably a designer) can use the context menu and can click the small rectangle at the center of a connection to remove node connections.
Compass was integral to our ability to iterate rapidly and to create test levels for gather data and feedback. It is also a useful abstraction to present to the designers on the team to allow for easier level creation with minimal time spent communicating between the design and code teams. From a technical level however, Compass and the underlying map system do have one weak spot in my mind and that is in the construction of the data structures that hold information on room names and puzzle names. Those fields are currently strings which was done primarily with designers in mind. With that said, I am wary that it could cause performance issues down the line as the size of the game world grows and the number of strings to search through when finding the proper room to load increases alongside it. Worst case, the current data structure layout could hamper the player's ability to seamlessly rotate between rooms. Best case, our game specs call for marginally more RAM/CPU usage than they would otherwise. Looking forward, one method to avoid these scenarios would be to refactor the way map data is stored to move away from strings to something more performant such as enums.
Interaction Object Base Class
The InteractionObject class forms the basis for all gameplay interaction in Box Voyage. Any object in the game that the player can interact with through the cursor uses InteractionObject as a base class. The base class contains virtual functions to be overrode in derived classes specifically in the cases when an object is first select, deselected, and hovered over by the player's cursor. The InteractionObject class also contains a base input processing function that derived class can access and poll the inputs required for that specific derived class.
The InteractionObject class has been a life saver for our team's ability to implement new levels in a timely manner. Thanks in part to this base class we were able to take our demo from one room to 2 tested, playable puzzles rooms along with a playable intro in less than a month's time. The InteractionObject class allows for individual interactions to be implemented with little worry about the boilerplate code that makes up the interaction between player, cursor, and gameplay object.
Over the course of development in the fall, this helped me implement gameplay features rapidly and in a way that was easily testable and modifiable. Looking to the Spring semester, it will be important for me to make sure the rest of the programming team has a good understanding of this base class. Through hands on work and our team wiki, I feel confident we will be able to onboard other technical team members when it comes to understanding how to implement gameplay objects into rooms across the game.
As a whole, I am very happy with the code work I was able to produce for Box Voyage in the Fall. I think we have a solid foundation from which to ramp into full production and to bring on new team members in a way that doesn't require us to have to produce a lot of overlapping or repeat work. On the flip side, I do have concerns about game world traversal when it comes to the technical side matching the expectations of our game world. I also want to keep an eye on our performance when it comes to loading and unloading rooms within our current framework. In all, I feel that we are technically in a stable place, and I have been able to put in place systems that boost our productivity and set us up for a semester-long production cycle. The tricky part will be ensuring the systems continue to meet and exceed the teams expectation and the needs of the game itself.
Now, onto more general developer postmortem topics.
The Power Of Prototypes
Looking back on the early portion of the semester, I think that time of early concepting, brainstorming, and technical tinkering was my favorite phase of the semester. All our ideas felt unique to our team and presented interesting and worthy technical challenges. The prototyping phase really forced me to code towards a minimal viable example of what our vision for the given game idea could look like. I was forced to work smarter not harder in order to present technical rough drafts that moved our ideas from speculation and specification and into reality.
I think often about the process our team went through to cut our prototype game, codenamed R.A.T. I really believe that was one of the most valuable weeks for our team and for me as a developer. As a team, we were confidently able to measure our prototype against our core team pillars and goals for the semester and then determine that the prototype did not align with our vision for the type of game we wanted to make. I came to the same realization on my own too as I was in the process of building the prototype for R.A.T.. I learned what many game developers say often. I was introduced firsthand to that not-so-old axiom about not knowing if a game is good enough or worth it until you put fingers to keyboard and gameplay on the screen.
That experience was eye opening. I could feel myself learning in real time and it was a motivating moment to know that I had the tools both technically and creatively to help judge the viability of a project. The process of uncovering of that knowledge, of setting a vision, building something, and then critiquing the paths explored, is something I want to take with me, both for my personal projects and into my space in the industry.
Communication Is Key
I am really proud of how our team at Capture Point Stone gelled early on and hit the ground running to start the semester. We presented every week for the first month, and that process of preparing to show work and thinking critically about the past week and the discoveries made really helped our team coalesce into a productive unit. That momentum propelled us through the rest of the semester. That early success came from our shared goals and creative pillars. We wanted to build a small, tight experience that was unmistakable a game with all of our creative fingerprints. We also laid out games and designs we didn’t want to explore to constrain our focus in ways that added to our productivity during prototyping and into production.
The biggest thing I will take away from this past semester as a developer is the necessity for honest, long-term production scheduling. One of the many reasons I lobbied our team to make Box Voyage over our other prototypes was because Box Voyage felt like a game we could envision, scope out, and plan in its entirety from day one. For me that said something about the strength of the game’s premise, our execution on the prototype, and the game’s fit within our team’s core design pillars. We felt that from the outset, we could project a roadmap for the game’s production that wouldn’t necessarily be accurate, but would give us as a team goalposts and milestones to shoot for leading up to the creation of a complete, ready to market game demo. The initial schedule we drafted was fluid and changed almost weekly, but that felt like a good thing and not a cost of poor planning. Every week we revisited our workload and our goalposts and adjusted accordingly. This mix of long term and granular sprint to sprint planning allowed for us to constantly see the end in sight while feeling confident that we wouldn’t be overwhelmed week to week.
Between the lessons I learned through prototyping, and the experience of production set to a well-managed schedule, I feel this semester has given me the tools to go forward and make my own games whether those games are made by teams of ten or teams of a thousand. Our team will continue on to next semester, now thirteen strong, to continue development on Box Voyage. As we move forward, I feel confident in bringing the lessons I learned as a developer forward into next semester and sharing what we’ve learned as a team with our new Capture Point Stone members.
Conclusion
As I look ahead, I would be lying if I said the task didn’t seem a bit daunting. In the spring, we move from a production scoped for the creation of a demo to production scheduled towards the goal of building a releasable product. My team and I will bring all our knowledge and experience to bear, but I have a feeling we’ll need to learn some new tricks (both technically and logistically), adapt quickly, and keep our eye on the timeline.