Return to the Skyway

'Return to the Skyway' was a project built by a team of thirteen individuals coming from six different disciplines (programming, design, art, and audio), creating a true cross-disciplinary team; and, by far, it was one of the best experiences of my life. It all began with a dream about a fantastical island with cute creatures and through the hard work and dedication of all involved, this project has become something I am very proud of.

Personally, I was fortunate enough to work as both a programmer and producer on the project.

PROGRAMMING ACCOMPLISHMENTS

Entity Management in Engine

For the first portion of the project, the main role of the technical side of the team was to create a custom C++ engine, which we opted to name CloudEngine. My first task was helping to create a foundational system in charge of creating, tracking, maintaining, and eventually deleting all entities within the engine. Each entity was created from a base class that contained basic information relevant to all entities (i.e. name).

From there, different components could be attached to the entity, allowing for the creation of unique behaviors. For example, each entity was created with a Transform component which was responsible for the placement, scale, and rotation of the entity within space. Each component had its own logic and update criterion which was all initiated by the entity's own update cycle. Each entity (and its associated components) were updated every game loop with the help of a manager that served as the supervisor for all entities. The manager would store, update, and delete entities, properly managing all entities within the game in the background.

Each component was derived from the base Component class, allowing all of the programmers the capability to create different components pertaining to the systems they were working on (e.g. Renderer for graphics, Behavior modules for the AI aspect of the game, and even Particles). With this abstracted model, the object creation and management could accommodate the future creation of components and be easily integrated into the editor.

Saving and Loading of Entities Within the Engine

My next task was the serialization of entities within the game so that designers, artists, and sound designers could work in the engine and have their progress saved. Using an interface created by a teammate, I created based serialize and deserialize (utilizing JSON formatting) protocols for all entities and components that could be adjusted by programmers relatively easily. Each component would have the base serialization and the programmer responsible for that component would have free reign about what was being saved/loaded into the game, making the saving of future components very easy to integrate.

From there, whenever the game was loaded up, the deserialization protocol would parse through the data, create entities based on the specifications, and add them to the manager. This resulted in an efficient and simple system that laid the foundation for different pipelines to be established between the engine and the art disciplines.

Gameplay Mechanics and Entity Behaviors

In the second half of the project, my focus turned toward helping the designers develop the experience that the player of our game would have. Initially, my task was basic - transferring the mechanics present in the Unity demo into the custom engine. These mechanics included the movement of the player, the grabbing and throwing of the creatures, and the obstacle destruction. Using a state-based approach, I created a behaviors system that performed different logic on the entrance, update, and exit of a behavior. This system would go on to support animation and audio linking to the entity behaviors.

For the player movement, I tied the desired input to the necessary action (i.e. Pressing down the D button would move the player to the right) and mapped it in a way that would allow for keybinding later on (this was later scrapped in the final project). From there, all of the internal variables that manipulated the movement (i.e. speed) were made public to the editor so that the designers could go into the engine and adjust the character behavior as necessary.

Using the physics system created by a fellow teammate, the interaction between the character and the creatures around the level was possible. With basic collision logic, the player could pick up and throw the creature at variable throw strength in the direction of the mouse. While the creature is in the air, if they impacted an obstacle that they could remove, the obstacle's behaviors were adjusted accordingly. Thus, using this system, the core gameplay loop was created and all internal variables were open to the designers within the editor.

Once the base gameplay programming was established, I began to work closely with the designers about the overall layout of the level itself. Through playtesting feedback and personal playthroughs, I was able to help restructure the tutorial section of the level by lengthening it and separating it into sections dedicated to teaching one mechanic at a time. For instance, you start off with simple jumps over ditches that won't result in play death to familiarize the player with the base movement speed and horizontal coverage. Then a step is introduced, still a single jump, to get the player comfortable with the vertical coverage. From there, the double jump was introduced in a similar fashion with the tutorial ending with the player's introduction to interacting with the creatures. Through this utilization of patterns and repetition, we found that players were a lot more confident in their movement capabilities in the game.

PRODUCTION ACCOMPLISHMENTS

Communication and Collaboration Between Disciplines

With this project being the first cross-disciplinary venture that anyone on the team had been a part of, there were many instances where disciplines didn't have the tools or experience to communicate with others on the team. Whether it was not understanding the vocabulary of another department or having trouble discussing features in a way that everyone understood, communication was the first obstacle that the team faced (and continued to face).

As the producer, I took it upon myself to figure out a way to streamline this communication and establish a common ground between disciplines. Through multiple encounters and frequent questions to the team's department leads, we were able to establish policies on how departments could discuss topics. For example, none of the other departments knew how to access the output from the art department passed "That looks good" or "That looks weird". As such, I sat down with the art team and asked them to describe their assets to me. Through this collaboration, I was able to construct a foundational guide on how to access and provide feedback on the art.

There were many more instances of this close collaboration in reference to communication that I was fortunate enough to be a part of, as well.

Work Environment and Culture

With the team being first formed off of the want to work in a good team and not off of a game concept, the culture of the team was set very early. As the producer, I wanted to make sure that we remained true to this core belief that we had all started with; as such, the priority was not making a great game but making a great team. As such, I worked closely with my art producer to schedule team bonding sessions (i.e. movie night or potlucks) which served as events where the team could get to know one another outside of the project and form friendly bonds. These exercises increased collaboration between team members and maintained the united culture of the team.

Outside of the bonding session, the team wanted to have a physical space that was "ours". From there, we worked together to create a vibrant team space that was both functional and comfortable to work in (see pictures of this in the Project Gallery). My contribution to this was a physical sprint board that gave a physical representation of what tasks were being taken on. Separated into different tasks categories and color-coded by department, the sprint board proved to be a useful reference point for the team.

Documentation and Meeting Policies

Early on, the team knew that due to our size and general composition, we would have to hold frequent meetings and have established written communication to pass on information between departments. As such, I worked together with members of the team to create templates for multiple documents (i.e. weekly work logs, meeting notes, etc) to be used throughout the departments. This documentation proved essential as we progressed further in the project and allowed members the capability to look back and reference items discussed before.

Alongside documentation, the team and I structured the weekly team meetings using agile development techniques. The meeting served as a point for everyone on the team to touch base, address the current progress of the project, and project future tasks. Each meeting began with a stand-up where each member introduced themselves, discussed what they were working on, what they were blocked by, and how they were mentally and physically. These stand-ups provided very important in understanding the bandwidth and capabilities of the team; they also made sure that everyone had a chance to know what tasks were currently being worked on and by who.

After the stand-ups, each task that had been completed in the last work cycle was taken off of the sprint board and celebrated by the whole team. This served as a very large morale booster on the team and by the person whose task was being completed and served as a driving force in enthusiasm towards the project. Each department would then show off what they had accomplished and were currently working on which served as another point of common understanding among the team.