Kakatte Koi Yo! is the first major project I’ve worked on with a team. As such, my contributions to the project are deeper, more specific elements as opposed to the broad strokes of an entire project. My primary roles on the project have been level design and asset implementation, though I’ve also been responsible for some project management and scripting as well.

The level design and its process has evolved substantially as the project has gone on. It didn’t start coming into its own until most of the mechanics were in place—the early “levels” served simply as test environments to confirm that they functioned at all. However, even the early levels needed to include one-way platforms and critical gameplay elements such as a pond to fish at and baskets to score in. These first iterations were made with primitive Unity sprites, scaled to fit and applied with the proper components for their function—usually 2D platform effectors, to prevent players from sticking to the sides. When the early levels were complete, I moved over to asset implementation until mechanics were developed enough that they outgrew the test areas.

Asset implementation wasn’t an overly complex process; it was more particular and time-consuming than anything. Each sprite from our artist, whether a single sprite or a spritesheet, needed to be imported into Unity with the same settings to keep it all at a consistent quality. Sheets then needed to be cut apart into individual sprites, which varied to a degree based on how many a sheet contained, but always came in multiples of 16, which made the process smoother. More complicated was the creation of animations, particularly for the player.

The player characters in Kakatte Koi Yo! are cats, and all their animations vary slightly depending on one significant variable: whether or not the player is holding a fish. This meant essentially creating and linking each animation twice—once with a fish and once without—and testing and checking time and time again to make sure each animation flowed to and from each other animation in the same way across both states. Adding to that, the animations had to be properly triggered in player scripts, though the process for this was simplified by the presence of a state manager. Even so, any changes to one set had to be exactly replicated in the second—then all four animation controllers, after new palette swaps were drawn to give each of four players a distinct cat.

After animations were implemented, my primary task shifted back to level design. Mechanics had grown, and the game needed more space to keep gameplay interesting for four players. Though the needs of the game changed over time, the process I’ve used to conceptualize level layouts has kept some of the same steps. Before working with tilemaps, I draw a basic layout to scale on graph paper. This helps me get an idea of what to put together early in the process and allows me to visualize each piece as part of an overall environment. With graph paper finished, I put the level together in Unity, with a few different tilemaps depending on the draw order and collision of the terrain: full collision, one-way collision—which also allows drop-through—and three background layers to give the level a slight bit of depth when it’s done.

Throughout the project’s lifespan, I’ve taken a lead role in keeping files, data, and tasks organized for the team. This started with the creation of the Unity project, GitHub repository, and Trello board, and I’ve continued to post and record tasks and manage the repository since—including a change midway through to require pull requests and reviews before committing to the master branch. When we published the game on itch.io, we used my account, which has put me in charge of reporting analytic information and distributing funds for the few times people have purchased the game. I’ve made a spreadsheet to track purchases and subsequent payments and have made it available to the rest of the team for the sake of transparency.