The Team
-
15 Developers with 3 different disciplines.
-
3 Level Designers
-
4 Artists,
-
5 Programmers,
-
A Lead Game Designer
-
2 Producers.
For this game we had a three month pre-production period followed by a little less than four months of development.
Overview
Engine: Unreal Engine 4
Tools and Languages: Unreal Blueprint, C++, Perforce/Helix, Jira
​
Role: Lead Game Designer
Skills: Sprint Planning, Agile Development, SCRUM, Small Team Development, Team Management, Interdisciplinary Communication, Game Design
Kibbi Keeper is an open world virtual pet-management game where the player sets out to explore a beautiful environment set in a Studio Ghibli-esque art style. In order to clear obstacles, the player must befriend and command adorable elemental companions called "Kibbies" to discover what happened to the civilization that once inhabited the area.
​
This game was an incredible learning opportunity. We had only four months to design and publish a compelling open world all while developing mechanics that are relatively unexplored. Due to the lack of source material to deconstruct and learn from, we had to go to extensive lengths to "find the fun" that the adorable Kibbies had to offer.
Post Mortem
We're Making A Game
As a programmer, I find it's easy to get wrapped up in technical details. It's easy to spend work on mechanics, features, or optimizations that lead to diminishing returns. It's even easier to think that the more complex something is, the better it is.
​
The image on the right shows an overview of one of our earliest implementations of the Kibbi's behaviors. It consists of six differing states that are managed by the Kibbi's "patience." This is an example of myself still thinking as a programmer and not thinking as a game programmer. I wanted to make a complex state system that the player could feel in their interactions with the Kibbi, but it was too much! How were we supposed to communicate six different states to the player given our tight deadlines? How were we supposed to make these artificial states feel natural and alive?
​
One of the reasons I loved my role in this project was because it forced me out of my "box" of being a programmer. I had to understand the game at a high level and know how to lead our programming team to achieve that vision. By the end of production, the graph on the right was a distant memory.
Earth Kibbi used to be able to shake a tree and drop fruit!
We were considering adding more verticality by letting players platform with the Earth Kibbi pillars.
Earth Kibbi used to be able to shake a tree and drop fruit!
It's not easy to communicate to the player
Something I continually underestimate is how difficult it is to communicate with the player. There are concepts that just make sense to the developers and this fact plagued our development from beginning to end. This is most apparent with our tutorial. We tried to adopt a mentality of "show don't tell" for our tutorial, but there was just so much we had to teach the player and not a long development cycle to do so.
​
What you see to the right is our finished tutorial. We went with the simplest implementation after multiple milestones showed we wouldn't be able to achieve the idea we originally thought of. You may notice that we often have to stop the player completely to tell them what buttons to press and how to interact with the game. I would consider this a failure in development. If we had more time, we would have invested more resources and playtesting into making the tutorial teach the player without them even realizing it. However, I learned that it takes a significant amount of time, effort, and resources to be able to interface with your players in a way they understand.
Know Your Core
From the first “Awwww” we heard when presenting the concept of Kibbi Keeper, we knew that these adorable little creatures were the core of our game. We got laughs when they didn’t do exactly what we told them, we heard "Ooh’s" and "Aah’s" when they did something cute, and we always left people wanting more. From there, we knew to develop our game entirely around them.
Throughout the development of this game, we had to make a lot of difficult decisions of what to cut and what to keep. But from the very beginning, we established that the Kibbi were the core of our game. Anything that interfered with their development should be considered non-essential. On the left are two examples of mechanics we had to cut. Both of these were fun concepts, but in the end we knew it would take more time to communicate to the player than it was worth, which would inevitably subtract from the time we could spend on the Kibbi.