ASPEN CLARK
MISSION DESIGNER
Interstellar Racing League
Project Snapshot
Interstellar Racing League (I.R.L) is a high-speed couch competitive racing game for up to 4 players. Players race through futuristic tracks and compete against human and AI opponents for victory in four exciting races.
Development time: 10 weeks
Engine: Unreal Engine 4
Team size: 55 people
Role: Game Designer
Roles and Responsibilities
The role of game designer was split three ways for this project. I acted as the game designer in charge of communications and organization. This role allowed me to grow as a designer and exercise my organizational and communication skills in new ways. I developed a new appreciation for and understanding of game documentation and learned communication strategies that helped me navigate interactions with artists, designers, software developers, and producers.
During the project I worked closely with the other two game designers, and also collaborated closely with leads across all disciplines and sub-teams. My daily responsibilities included informing members of the team about decisions made by the game design team, holding meetings with leads and specialists, documenting the game through the game design document and other supplemental documents, and attending production and design meetings to offer my opinion on the game's progress.
After our First Playable and Alpha milestones were deemed successful by stakeholders and the need for game design decisions to be made on a daily basis was reduced, I also worked with the special effects and UI teams, where I helped replace placeholder materials and perfect the look of I.R.L's in-game HUD and menu screens.
Samples of Work
Much of my job as a game designer included creating documentation for meetings with specific leads and sub-teams and for distribution to the entire team. I was faced with the challenge of needing to communicate with 55 different people, all of whom think and understand problems differently.
I learned a lot about the importance of documentation while making I.R.L. The adage "a picture's worth a thousand words" proved true time and again, and my firm belief that images are the best means of clear conveyance in a document is reflected in the images below. Each of these images shows a single-page document I created for a meeting regarding a certain aspect of I.R.L's design.
Track Conveyance
This document about track conveyance was written for a meeting with the project's lead level designers and artists to explain the game design team's thoughts and ideas regarding using landmarks, hero pieces, lighting, and signage to convey information to players while they raced.
Using Concept Art
In addition to creating documents for meetings, I kept a log of all concept art created by our artists to be used for explaining concepts to the team.
When preparing for meetings, I often looked at this archive to determine which pieces of art should be used. I discovered that members of our team understood concepts and explanations a lot more fully when the images they saw presented alongside them were made by artists they knew.
Communicating Design Decisions
It was common practice during our project for the lead artists to collect every piece of concept art created during a work day. The game design team took on the responsibility of discussing and analyzing each piece of concept art and trying to gauge which best represented our vision of the game.
Creating these contact sheets with images the game design team preferred highlighted was an important part of my job. I was responsible for taking these sheets to different artists and members of the team to make sure that their future creations aligned with the images that best represented the game's vision.
Project Screenshots
Lineup of playable vehicles
Vehicle using the "Shield" power-up
The track design team focused heavily on multi-axis tracks
Special effects were used to help convey the car's speed
Designers used landmarks like these illuminated bridges to keep players oriented in the world
Project Post Mortem
Team Retrospective
Our team had several important successes during the project. Firstly, we were able to deliver a high quality product that impressed our stakeholders and met their expectations at each milestone. We also adapted well to working on a large team, and all of us grew as designers and developers. Everyone on the team fell naturally into our roles, and those of us in leadership positions worked well together. We were able to keep the team on track and developing a successful product by fostering a culture of open communication and transparency with one another and the people working beneath us. We had a strong understanding of the type of experience we wanted to create, and each member of the team worked to the best of their abilities to make sure our game was enjoyable at every milestone.
As all teams do, ours also experienced failures during the development process. Our main failure was a lack of buy-in and motivation to complete the project. From the beginning, many member of our team were vocal about not being thrilled to make a racing game, and that negativity pervaded the team and created a culture of disillusionment and frustration. This environment was unproductive, and personal differences and tensions were exacerbated by constantly working with a team of people eager to pick apart the project. Partially because of this buy-in and motivation issue, our team also developed for an exceptionally long time without actually getting anything on screen to test. Many members of our team struggled with perfectionism during early milestones, so by the time we reached first playable and alpha we still had little understanding of how our game looked and played. This was a massive detriment to our project's success. Additionally, from the outset of the project our team had a fundamental misunderstanding of what leads and game designers were supposed to do day to day. This led to blame and anger being directed at individuals who many saw as responsible for decisions or problems in the project, but who in reality were operating under a different understanding of what their job entailed.
Each member of our team learned a lot during the development of Interstellar Racing League, and all of us will be better developers for having worked on this project. Our first important lesson was that we need to have patience and grace with our teammates, and ask people why they make the decisions they do rather than taking offense. We learned that it is important not to take feedback personally, and that when a lead or game designer makes the choice to cut a feature or change the direction of the game, it is for the good of the project and not their personal opinion or gain. We learned that the most important thing a team can do is get a product onscreen as early as possible to be evaluated by stakeholders and playtesters, and also that assets don't need to be perfect to be put in a prototype. Finally, we learned the importance of transparency and communication, and that the best projects are made when everyone on the team feels a sense of ownership over the game. This leads to the type of productive, creatively-charged environment we all hope to work in in the future.
Personal Retrospective
I believe I was successful in fulfilling many of the duties of a game designer while working on Interstellar Racing League. Peer evaluations at each milestone show that the people I worked with found me easy to communicate with, bright, energetic, and willing to listen to concerns when they arose. I did my best to promote what I thought was the vision of the game, and to facilitate communication between subteams to make sure that everyone was working efficiently and effectively. I kept a positive attitude in front of my peers, and did my best not to take feedback on the game or on my performance personally. I developed an excellent working relationship with the other game designers and was always willing to offer my opinion when asked. I was exceptionally organized (many of my peers jokingly called me 'the walking GDD') and worked hard to set and keep to a schedule each day. I made time during working hours each day to walk around and listen to my peers' concerns and questions about the project, and to bring those concerns to the rest of the game design team to be discussed. Later in the project after my primary game design responsibilities were finished, I did everything I could to make myself available to my peers. I worked for the special effects, environment, and UI teams for several days each, and in that time was able to pick up new topics and practices very quickly.
In addition to these successes, I also experienced several failures during the project. Firstly, the rest of the game design team and I made the decision to drastically alter the design of the game after the initial prototype phase. This decision left us scrambling to come up with a new design and to explain these changes to our peers, many of whom were bought into the original prototype. I think this decision to change the design of the game at the outset was largely responsible for a later lack of team buy-in, and the project would have been more successful had we left the design as it was when the prototyping phase ended. I also need to improve in regards to volatility. I am an action-oriented person, and when I hear about a decision that needs to be made or a potential source of tension, my first instinct is to jump in and act on it as quickly as I can. I feel that if I took the time to carefully consider some of the things my teammates said to me about the game rather than immediately reacting or trying to solve the issues they were bringing to my attention, I could have avoided confusion and communication hiccups during the development process. I also failed to give myself time away from work during this project. One of the other members of the game design team is a good friend of mine, and he and I would often spend lunches and afternoons when we should have been focusing on other schoolwork or taking personal time discussing aspects of the project we found annoying or displeasing. This unhealthy work habit not only left me feeling tired during the day, but also kept my stress levels on the rise throughout the semester. By the time we arrived at our alpha and beta milestones I felt very wrung-out, and I think a large part of that came from my habit of discussing the project outside of school hours.
I learned an enormous amount by working on this project. I now understand the importance of open communication, active listening, and careful planning better than I did before arriving at SMU Guildhall. I grew a lot as a communicator and learned that it's almost
always better to listen than to speak when gauging whether someone else understood a concept. I learned that "design by committee" is incredibly ineffective, and that trusting my gut and listening to the advice of those around me is often the best way to avoid design problems. I learned the importance of respecting prototypes and making decisions that benefit the game, even though they may not be decisions I personally agree with. I learned about the importance of playtesting, and how asking the right questions during a playtest can lead to incredibly valuable feedback. My understanding of using the individual talents and potential of each member of my team greatly increased, and along with it my ability to trust tasks to those better suited to them than I am. Of all the lessons I learned while working on Interstellar Racing League I think the most important was that a game's quality doesn't come from its complexity or number of mechanics, but from carefully balanced systems and a team of dedicated individuals developing it to the best of their abilities.