Blaugust, day 19

Today’s post is inspired by Tanek’s comment to yesterday’s post. He didn’t specifically ask about what it’s like to work on a crowdfunded game, but I figure this might be of interest to you guys out there.

As most of you probably know, I’m currently a Senior Engineer working on the crowdfunded game Camelot Unchained. I technically started working on the game about a year after it crowdfunded, but I was in contact with studio founder Mark Jacobs during the campaign to offer a bit of advice based on my previous experience. So, here are my experiences actually working on the game.



In the glass house

One of the biggest changes from “traditional development” is that there is a significant focus on communication with the playerbase. This means that the development team is always in the limelight. This makes sense, as people have given the company money and they want to see that money is being put to a good purpose.

In traditional development, you often don’t talk with the outside while doing development. You certainly have to communicate with the people who write the checks to fund your company, but for the most part you work in seclusion from your future playerbase.

But, now there’s an emphasis on getting out in front of the audience. The developers working on Camelot Unchained do a lot of streaming (where you sometimes see the back of my head as I’m working), lots of newsletters, lots of interaction with current and potential future backers. This interaction does take some time, though, which is always a precious resource in game development.

It’s not necessarily good or bad, but very different that what I’ve experienced in development before.

Your mistakes on display

Because of this emphasis on communication, everything is out on display. This includes bugs in the game.

In traditional game development, you might have some flaw in the game system that you just endure. Maybe for some reason it crashes the game when characters move backwards; the simple solution is to tell your testers not to do that for right now. But, when you have backers interacting with your game, a flaw like this will generate a lot of reports about the bug. You kind of have to fix it sooner rather than later so people aren’t distracted by the flaw.

It’s also harder to have code or design that is in transition, half developed and not quite finished. For example, few games are even close to being “balanced” during development. You might code abilities to test out the system, with the intent of adjusting the values later. If something is truly overpowered and broken, you can tell the team “Don’t use that for right now.” Players doing quite cooperate so well.

But, the great part is that you do have people crawling through your system looking for problems. You will have a larger group of people testing your game than you would otherwise be able to afford. This can help you find bugs and flaws that would otherwise go unnoticed. I usually the first part of my day going through the forums and putting bugs people report into our bug reporting system. This is a great boon if you’re doing something far out of the ordinary with your game systems, and you need a lot more testing than usual.

Learning the Greek alphabet

One issue with most game development is managing expectations, and working on a crowdfunded game this is a great example of the importance of doing so. The definitions of “Alpha” and “Beta” have been shifted over the years, particularly in MMOs. By the time an MMO opens its doors to people in Beta, it’s actually fairly well polished. An “Open Beta” is often more of a pre-launch marketing exercise rather than an actual time for testing. By this point, it’s often very late to make many changes, let alone fundamental ones.

But, when you have an actual “old school” Alpha, the game isn’t in a polished state. In fact, it’s more likely to be the exact opposite of polished: very rough and with the underlying structure exposed. Camelot Unchained was really more of an engine test for the past year than a game. Gameplay systems were mostly stand-in, generic versions of what other games had done and not really related at all to what had been talked about in presentations.

But, I don’t think people really understand what it means to “play” a game that is still in the middle of development, despite repeated information about how the game is not finished and the game is not using the marketing terms for Alpha/Beta, etc.

Keep improving every day

The decision was made to let a select group of testers have access to the test server where the bleeding edge of the code is. This means our work is always available to the users, and as a consequence there is a lot of iteration in development. I’ve worked a lot on the ability system, where we let people craft their own abilities out of components; the prime example is using the “Fire” component and “Ball” component to make a fireball, and perhaps adding a “Far” component to make the ball travel further but perhaps lowering the damage. It’s a pretty cool system, very unlike what MMOs have done previously.

Behind the scenes, components are defined out of different “effects” that have various stats applied to them. As I said, the first iteration was a simple system where you pushed a button and a few pre-defined things could happen, such as damage applied. The next step was to define a bunch of effects that could be strung together, so you might have a projectile effect that has a damage effect to apply damage to a target (whatever the projectile has struck), and create a bunch of abilities that use this new effects system. We created different abilities to test out different, hopefully interesting combinations. Then we defined components that contained the effects and when combined would create a full ability like we had created before. Players then put together those components and gave feedback.

One drawback is that things like crash bugs are a lot higher priority to fix than they might otherwise be. A bug that happens once in every hundred thousand user actions is an annoyance when you hit it when running a local server for testing, but it becomes a constant problem when you have a few hundred people on your server playing in earnest.

It’s still about community

One great thing is that there is a passionate and enthusiastic community. They’re much more involved with the game than they would likely be under a typical development system. One of the best things about being a game developer is seeing people use the systems you’ve worked on and having fun. I’m seeing this much sooner than I would in a game developed in the old way.

But, then I consider one of the questions Tanek asked in his comment yesterday: Are we at risk of seeing the growth cycle skewed to the point where we burn out the interest in games before they are even complete?

That’s a really good question, and one I don’t have a good answer to yet. I know that when I relaunched Meridian 59 years ago, some of the most passionate testers showed a lot less enthusiasm for the game after it launched. But, there were still plenty of people who were overjoyed to play the game when we actually did launch. I can’t say for sure if this situation is similar enough; one difference might be that people have invested money into the project now, which usually gives people more investment into the game.

But, given that community is so important to an MMO, this might be the best part of a crowdfunded game.

Just as a note, I’m still rather limited in what I’ll talk about as far as the game goes, so specific questions about Camelot Unchained will probably be ignored.