Someone recently asked if I am developing KeyStone solo or if there is a team behind the game. The short answer is “mostly solo, but there used to be a small team”. The long answer is the rest of this post!

I bet some of the confusion is because I’ve written some blog posts using “we” and some using “I”. The explanation is simple: the “we” language is from when KeyStone was a team, and “I” is from when it wasn’t.

The Current State

KeyStone is currently a solo project with contractors. This means that I do everything myself, but occasionally I may bring in a specific person for a specific task.

This approach is largely due to the fact that I’m treating KeyStone as more of a product now… in other words, money is involved. I’m not willing to accept help without giving a fair cut of the project’s funding. And although the funding has been really generous so far (seriously, thanks everyone!) it’s still too low to pay a permanent team anything close to fairly by the standards of the game development industry.

At the moment the only contractor I’m working with is a guy who goes by Shiraq on Discord and StarCraft. He is the one responsible for the recent terrain update (the one that more clearly outlined the buildable zone) and the Indiegogo cosmetics.

He has a skill for environment art that far surpasses my own, so I’m excited to have him working on the project. For example, that Xel’naga Crystal cosmetic looks like a single Blizzard-quality asset, but it’s actually made up of 6 separate Blizzard assets that he placed with precision to make a single coherent piece.

Going forward, the plan is for Shiraq to create a new environment for each new expansion, with a theme matching the expansion’s. He will also continue designing cosmetic decorations whenever the need arises. Because this work has a really limited and well-defined scope, and because Shiraq can quickly produce far better results than I, I can afford to give him a fair cut of KeyStone’s funding.

Depending on the success and lifespan of KeyStone I may bring on more help some day, but at the moment I have no definite plans.

The Old Team

Now for a bit of history!

When I kicked off the KeyStone project, I thought it might be fun to try to work with a team. I ended up bringing on three people to help out. Two were supposed to focus on designing cards and mechanics, and one was supposed to focus on which parts of StarCraft’s lore we should capture and how.

Eventually each member of this original team either lost interest or had more important things come up in their life. That left me where I am today, flying solo.

While I definitely want to remain as a solo creator for now, I did learn some valuable lessons about working on games as a team. For the rest of this post, I thought I would share some of those lessons.

Lesson 1: The “hobby project team” is a really fragile structure.

I’ve read this advice elsewhere and my own experience reaffirms the point. If you aren’t paying people to work on something, there is no guarantee as to the quality of work or the long-term interest of the team members.

While the original KeyStone team lasted, they produced some great work that made it into the game, but ultimately they all moved on. Even while they were on the team, some members appeared and disappeared based on interest and life events.

I’d like to stress that I have no bitterness for any of this, it’s just the reality for hobby projects. You can’t expect people to keep investing time into a hobby if something more important or interesting comes up.

Lesson 2: Project management is time consuming.

I built out a Google Drive directory full of design documents for the team. I tried to keep a steady stream of design tasks available in a “to do” list of sorts. When people posted their designs, I would accept or reject them. For most rejected designs, I tried to explain which design goals weren’t being met.

This process achieved some decent results, but it was really time-consuming. There were weeks where I spent more time explaining why designs didn’t work, than actually designing things myself. Even if this weren’t the case, keeping the “to do” list populated and keeping everyone going in the same direction took time and energy.

Lesson 3: Don’t add members to a team until you actually need them.

I really liked the idea of trying to form a team with a lot of camaraderie and passion, so I brought on three people all at once. But at the time I was designing and implementing the Core set of the game, which didn’t have much focus on lore, so our lore guy didn’t have anything to do for months.

Luckily he stuck around through the early stages of First Contact’s development, helping develop some of its themes and ideas. But I think bringing him on before I really needed him was probably a bit demotivating.

Lesson 4: I am really particular about the design patterns of KeyStone.

I expected to spend some time teaching design concepts to the members of the team. I had learned a lot when designing Battlefront Card Game after all, and I had a pretty specific set of design philosophies for KeyStone that I wanted to stick to.

While the team had some successful designs, the rate of rejected designs was pretty high, despite my teaching efforts. I think these were the major factors:

I didn’t communicate the design goals of “to do” items as effectively as I could have.

The team didn’t have enough experience in the problem-solving and focus it takes to develop ideas while following restrictions.

There were not yet that many examples of “good” designs for cards, since we were working on the Core set.

There were some fundamental disagreements over whether the design philosophies were even correct in the first place.

There was never any drama, but these issues did lead to some frustration at times.

I hope this post clears up the “KeyStone Team” confusion, and offers a little glimpse into the history of it’s development! As always, if you have any thoughts or feedback please share in the comments below.