Nearly a year after the game's announcement, the Crowfall team is one of the busiest in the MMO game space with regular updates and packed with community involvement. ArtCraft is excited to talk about all that's happened over the intervening months since the Crowfall project began and we're pleased to host this exclusive developer Q&A.
Q: For those of us who might have missed the Kickstarter, can you describe Crowfall?
Sure. Crowfall is a Throne War Simulator, which is a name that we just made up because there really wasn’t a good genre or acronym to describe it. Our goal is to create a new type of MMO that feels more like Game of Thrones and less like Lord of the Rings – in other words, a clash of great noble houses rather than the traditional Heroes Journey.
Q: How does this idea play out, in the design?
The core difference in our design is that each server represents a single Campaign. Players will have a variety of campaigns to choose from, selecting the one that best suits their playstyles. Each campaign is a self-contained game – like a giant, massively multiplayer game of Civilization. Every world has a unique randomized map (mountains, rivers, castle ruins, etc.) and the players start the campaign surrounded by the Fog of War. You’re dropping into a random location and you have to explore, survive, fight monsters and collect resources to rebuild castles and claim virtual territory.
Of course, unlike civilization, each player is only controlling a single character (a knight, an assassin, a scout, or whichever role they find most interesting) -- so the kingdoms that emerge won’t be hundreds of NPCs, they’ll be hundreds (or thousands) of players working together to conquer the other player kingdoms and rule the world.
The campaigns don’t last forever. A typical campaign will take about three real-world months, or until one faction or noble house wins the game. After a victor is declared, the world is destroyed -- meaning that server (and that map) will go offline forever.
The characters are persistent, however – you don’t lose your advancement. When one campaign ends, your character (and the spoils of war, if your team did well) move on to the next campaign you select.
)
In this way, we keep the feeling of persistence that is the cornerstone of an MMO, but with the sense of completion (in victory or defeat) that comes from a strategy game.
Q: Your Kickstarter ended successfully back in March, amassing just under $2 million. Can you catch us up on what has happened since?
Sure. We decided that our first major area of risk was combat: in a game about player conflict, we felt that we had to get combat right or the game just wouldn’t work. We did our first combat playtest in September, letting in approximately a thousand of our backers.
We felt like it was important to give our backers a sense of context for the early combat testing, so we created a specific game mode – just for testing – that we called The Hunger Dome. Basically, it was a slimmed down survival match (like H1Z1’s Battle Royale) geared towards groups.
Players were dropped randomly into groups of three, and forced to fight in a single-elimination tournament until only one team was standing. To add some interest, we scattered loot chests around and surrounded the map with a sphere of death, the Hunger, which slowly collapsed into the center of the zone so that the teams would be forced to fight each other.
Q: How was the test received?
With our backers, the response to The Hunger Done test was universally positive. There was a meme going around on our forums taken from an old Dave Chappelle skit, with the tagline “Ya’ll got any of that Crow-caine?” because the players found the game so addictive.
Outside of our fanbase, however, the results were somewhat mixed: they didn’t understand what they were looking at. First, it’s a death match – which is very different from the game we’ll eventually be shipping. Second, we didn’t have time to flesh out the 3D environment, so instead we started with a greybox level for testing. People who weren’t familiar with this approach were confused, some of them actually thought our intended art style was “featureless and boxy.”
Of course that isn’t the case! So we’re resolving it in our next round of testing. The overall wrapper is similar to the first one (meaning it’s still a Hunger Dome match) but with a leap forward in terms of features, content and visual fidelity.
Q: What will the new test entail? And when does it start?
Invitations for the next round of testing started going out earlier this week!
This version is a jump forward in terms of visuals: the test environment is 90% done, and we’ll be finishing out the remaining 10% in the coming weeks.
Additionally, we added a few more significant elements to the game: a new archetype (the Champion), monsters and customized groups/teams.
Q: In a game that is so player-focused, why add monsters now --instead of other elements like crafting, or stealth?
It’s always tough to decide which elements you want to tackle first.
We felt like monsters would add a level of danger to every match – and that dealing with them would open up a new array of tactical decision-making that wasn’t present in the last test. We also moved most of the equipment drops onto the monsters for now; in the final game, most of the items will be crafted -- but since we don’t have crafting yet, this approach made the monsters feel more relevant. It makes the fight-or-flight decision more meaningful when you encounter a monster spawn.
When prioritizing features, there are other considerations, as well. It really depends on your long-term project goals. You often learn things during the course of implementation that force you to adjust your pipeline (poly count, bones, technical constraints, etc.) In this case, those unknowns mean increased project risk: to get the game launched, we needed to get to work on our monster library as early as possible. The longer we put off that development work, the higher the risk that we will have to do lot of rework later.
Q: Did any of your plans change based on player feedback, after the first round of tests?
Yes, actually – that’s why we included a grouping mechanic. In the grand scheme of things, customized teams could have been something we put off until later – but this was probably our most requested feature coming out of our first playtest.
In the previous testing phase, the teams were random. That’s certainly workable, and interesting, but it decreases the feeling of competition because pick-up-groups are…. well… they’re pick-up groups. It’s hard to be effective when your team composition is largely left to chance.
For a PvP-focused game that centers on faction and guild coordination, it seems important to allow the players to team-up however they would like. So, we listened to our players and moved this one up in priority.
Q: How long do you expect this test to last? How many players will be involved?
Current plan is to run the pre-alpha 1.1 test for at least a few weeks, and we will invite all of our backers with the Pre-Alpha, Alpha 1 and Alpha 2 pledge rewards. All told, that’s around 5,000 players.
)
Q: Now that combat is playable, where do you expect to go from here?
Combat was just the first piece of the puzzle. Our approach to developing Crowfall is a bit different than what other games have done.
Some projects develop in modules, isolated components that are developed individually and then “tied together” later in the project. This works well for very large projects with a lot of disparate systems but it doesn’t work as well for games where everything is interconnected and interdependent.
Other projects use a “totality” approach, meaning they carve up the overall vision and order the pieces based on what is most efficient overall with very little thought for bringing risk forward. This works best for games that have minimal design risk (i.e. sequels and clones). It’s cost effective, but to make it work you really need to have all of your funding lined up at the beginning. If your goal is shortening the overall timeline of your project, you don’t want to stop along the way to create playable demos just “to keep the money people happy”.
Our method is more organic: we know what we want to build, but there are some core elements that haven’t really been done before. We need to plan for as much iteration time as possible on those high-risk areas. From what I can tell, this approach is similar to how Notch created Minecraft; you have a firm idea of what you want to create, but you “grow into” the details of your game vision by trying things out and iterating over time. This approach is best for handling risk (i.e. things that haven’t been done before) and it works really well for customer engagement, because your players can really be a part of the development process.
Given that approach, our thought was to start with combat, then move on to the other areas that are risky (world building, passive training, campaign rules, castle sieging) and “grow into” our overall design.
Now that we have a firm foundation, we can build those other systems on top of this base, and know that the eventual game will be fun.
