CivCraft – A Postmortem

For those who have been following things related to CivCraft, you’ll already know that I’ve released the source code to the CivCraft project and now consider the project completed. More or less, so I’d like to take the opportunity to do a postmortem on the entire project and give an overview of what went right, what went wrong, and lessons learned for the future. First a quick overview of what CivCraft is when it started and what it’s now become.

Initially, CivCraft was nothing more than a simple Minecraft server that ran a few slightly customized mods in order to bring more meaning in to the game. Simple things like converting ores in to currency and then using that currency to purchase land, pay upkeep, and buy upgrades for your town. As time ran on we wanted to find more uses for the currency to keep players interested in gathering it, so we added functional structures to the game. Once the plugin started to get big enough we did a major rework and created the CivCraft plugin as it exists today. Today CivCraft has over 500 active users and is running on about 20 or so servers. There has been more players online in the past, but we’ll get to that later. You can find the current server list and player count for CivCraft at civcraft.net. The project has been quite a roller coaster and the source of much stress in my life since it’s gotten popular but it’s also been very rewarding in terms of lessons learned and knowledge gained.

Lets start with what went wrong.

What Went Wrong?

Not Enough Planning

A great many things went wrong during the course of this project, too many to count. Most of which however were either directly related to or greatly exacerbated by a lack of planning on my part. I can’t beat myself over the head too much for this, since the original goal of the project was to just run a fun Minecraft server. Which we did, quite successfully, but since the project and it’s additions were added slowly over time it wasn’t until much later in the project did we sit down and actually design any of the features we were adding to the game. Up until that point it was mostly a Hodge-Podge of things we thought would be fun to add or needed at the time.

A great example of this is our city building mechanics before beta5. Take a look at this diagram which maps how the different city mechanics interacted with each other. (Open the image in a tab to more clearly read the text).

 

At the time, culture did almost nothing for you except maybe bring in trade goodies in to range, but building another town was a much better way to obtain those goodies anyway. Structures were primarily used to generate coins and culture but had little effect on science. The asymmetric interactions you see here are a direct consequence of implementing each of these features one at a time in isolation rather than sitting down and coming up with a coherent strategy for how city mechanics should interact with each other.

There was also a significant amount of wasted effort due to not sticking to our goals in the face of shiny new toys. A constant wildcard throughout the development was changes coming down from Mojang, and nothing hit us harder than the Minecraft horse update. When we first heard about the horse update we were very excited as adding horses to CivCraft seemed natural and would mesh well with the gameplay. We also had to update the servers live without resetting them which meant we had to be on the ball when the horse update came out and prevent players from obtaining horses so we could hijack them and make them work inside CivCraft’s paradigm. We spent a lot of effort making stables, working on horse code, testing horses, and locking the feature down only for a few bugs to slip through and negate a lot of our work. On a large TPS strapped server with a smaller view distance, horses did not perform as well as we had hoped they would. We also priced horses outside the range of what they were worth, so in the end they became quite useless and represent a lot of wasted effort for us. Why did we price them so high? That brings me to my next big issue with what went wrong…

No Resident Content

Resident content is the term we used for content that would be available to average, non-leader and non-mayor players of the game. Average citizens needed more to do than standard vanilla Minecraft survival if the game was to remain interesting for them. Many of the costs and balances in CivCraft are based around needing to lead a group of residents, but who wants to be a resident if it means being bored? Having spent a lot of time working on city management, civ management, and town management in the pre-beta phase, we seriously underestimated how bored residents would become in comparison to the mayors and leaders who ran towns. Vanilla Minecraft was not enough to keep them interested any longer.

While we always recognized that this was a problem, we didn’t treat it with enough respect until it was almost too late. The reason why horses were priced so high was because we wanted to give residents something to strive for that they could then show off. If horses were expensive, then they’d at least have a goal they could obtain. The problem with this approach however was that horses cost coins, and the best way to get coins is to generate them in a town, so horses were pretty much just play things for the rich mayors and leaders. Not resident content.

We again tried to patch this problem by adding the global market. This was a lot more successful than we thought it would be however it still wasn’t enough. At beta5 we spent a lot of time reworking the crafting system to give residents something to do. This turned out to be a controversial decision of sorts because it certainly changed the meta-game for how people obtained gear. Gear was harder to obtain and would benefit individuals, and that worked, but because of the global market rich mayors and leaders could just purchase the materials with coins. And again the best way to get coins was to own a town in a civ so again gear became more exclusive to the rich and powerful. The global market was, in theory, supposed to become more and more expensive until gathering became a viable alternative. However we never reached that point due to a serve lack of supply.

Since prices were so inflated in the global market due to a lack of supply, we needed to make it easier to gather the materials rather than purchase them from the global market. So beta7 added powerful custom mobs to both increase the supply and to add resident content. After a bit of balancing  this seems to work ok and strikes a fair balance between buying and gathering materials, however due to not having the proper tools in Minecraft the custom mobs are quite glitchy and the experience is not as great as it could be.

All of this could have been avoided if resident content was more thought out and planned out a bit. However since I’ve reached a point where my tools are fighting me more than anything (Minecraft doesnt like to be hacked at this much). I feel like the amount of effort required to fix this problem is beyond what I’m willing to spend At this point I feel like more drastic changes are required, such as removing some key materials from the global market, removing the civs ability to generate coins, or making coins generated by civs a difference currency from the coins spent by residents. Civilizations should rely on residents not residents relying on civs.

Competitive Players vs Causal Players

It turns out that CivCraft appeals to two different types of players. Casual Players want to build a custom civilization and make it look nice and visually impressive. They essentially want to play Minecraft in survival mode but with the extra addition of civilization building. The other type of player is competitive and wants to create a civilization with the main goal of “winning” and besting out other civilizations. This conflict is inherent to CivCraft’s overall design and while we attempted to strike a balance between the two, I think we landed too heavily on the competitive side rather than the casual side.

The ability to capture cities and civilizations instead of vassalling them really takes a psychological blow against the losers of the battle. We misrepresented the amount of dismay this would cause players and rather than work on and keep playing most players resigned themselves to defeat and quit playing or waited for a reset to try again.

Another slap to the casual players virtual face was victory conditions. The competitive players wanted a way to “win” the game, and I also wanted a way to reset the map so that bugs could be easily fixed and large scale changes implemented at set times. This had the terrible side effect of erasing the casual players’ work which gave them little reason to play on a competitive version of CivCraft.

We addressed these issues by adding casual mode, which personally I think, in retrospect, should have been the primary focus of CivCraft from the beginning. By trying to make competitive players happy we neglected our casual players and causal players are the foundation upon which competitive games must rely.

 

What Went Right?

Now that we’ve got the Captain Hindsighting out of the way, lets talk about the things that went right in this project.

CivCraft Is Popular

Sure more people could be playing, but when I started this project never in my wildest dreams would hundreds of players be actively playing the game at any one time, nor would I have imagined running in to people in real life who have played the game and are suddenly star-struck when they realize they’re talking to the creator. As a game designer, you always wonder if your ideas are really going to have any appeal to other people and it’s nice to validate that yes, there is demand for the kind of game that I want to make. There is still a lot of work on the implementation of concept and I’m happy to see that server owners are experimenting with new ideas and trying to come up with solutions to some of the design problems we encountered.

I think something that’s often overlooked is that CivCraft doesn’t have another game to copy it’s design from. If we were making another MMO, we could look to Lineage 2 and World Of Warcraft to determine how they solved problems. However CivCraft’s design problems are unique since the players have so much more power and control than they do in other games. And I think for charting unexplored territory we’ve managed to come out ok. We’ve got tons of ideas to improve the game, but doing it Minecraft is counter-productive at this point. Hence why we’ll be incorporating the lessons learned in to our standalone.

CivCraft War is Really Fun

Like almost too fun. It only happens once per week for logistical reasons but we’ve heard tons of requests to allow war to happen twice per week since it’s by far the most interesting and fun part of the game. For many, the day to day playing of the game is all a lead up to the cataclysmic war and the drama that ensues in it’s wake. Making the day to day gameplay of CivCraft more fun is of course a goal, but it’s important to take a step back and realize that it’s overshadowed by just how fun war is. A lot of the momentum for catering to competitive players rather than causal was based around how fun war is, and other than some balancing issues I think that CivCraft’s war mechanic is one of the best reasons to play it. For making it better, if we had the time and resources it might be nice to try and find ways to have wars scheduled on a per-civ basis so that they don’t all have to occur on a single weekend and so that players can get some action in during the week day. Additionally other skirmish like activity would be nice if it could occur during the weekdays so that the weekdays are more interesting.

CivCraft’s Anti-Cheat

While maintaining the anti-cheat is going to be a pain, while CivCraft was on the ShotBow network it’s custom anti-cheat client made Civcraft the most hacker free Minecraft server in the world. Barring of course small time servers where everyone just trusts each other, no other Minecraft server has ever implemented a custom anti-cheat. And to be fair, there is a good reason for that. Forcing your players to download and install a custom mod to play prevents many players from entering and it’s counter productive to the server’s overall health. However I feel the way in which we implemented the anti-cheat was a perfect balance of the costs vs the benefits. Players who didn’t want to install the anti-cheat could play on the casual server, and on the PvP server. The only difference was they could not participate in WarTime on the PvP server if their civilization was at war. So at the times and places were it really mattered, CivCraft’s Anti-cheat made it very difficult to play with hacks. Thanks to projects like Forge the mod is very easy for players to install and having client side detection was certainly the way to go.

If I were to continue working on the project, adding additional incentives to the client side mod would be something I’d like to do. Adding visualizations for culture borders, menu driven GUIs instead of commands, and other conveniences to entice players to install it so that it didn’t feel like legit players were being punished by having to install the mod. Paradoxically though, by having to install the anti-cheat all players increased their confidence that the game was being played fairly. So the anti-cheat was a win-win in my book.

Casual Mode

As mentioned before, casual mode was a great idea since it appeals to the more longer term players. I wish that I’d implemented it sooner and focused more on casual mode, however this will be something we’ll do in the future.

Global Market

While it caused some problems with the resident/leader power dynamic, it really added a whole new element of strategy to the game and was a great addition. With the global market residents could earn money quickly early on by farming things like sugarcane in mass and selling it at the market. While the market didn’t become the full economy we’d hoped it certainly gave us a lot of interesting gameplay and information on how digital economies function.

Floating Structure Validation

This one had a rocky start, and there are still some UI stuff that Minecraft can’t easily solve for us but overall I think that the floating structure validation was a huge success. We went from needing admins to police every structure (and sometimes not seeing the problems because they were hidden or changed after a structure was OK’d) to zero floating structure complaints after the bugs were fixed. There was at least one controversial phase in which the floating validation was not working right and we chose not to intervene. But afterwards things have settled down quite a bit.

Having the floating structure validation did indeed bring forth an interesting construction restriction on basements, although this was not as important as we had hoped due to the tunneling meta-game strategies in war. Placing structures was still a PITA though. In the future and given full access to the client side I would have made the visualization of conflicting caves in the ground more apparent and probably added an option to start building the structure while it was not validated or an option to “fill in” the cave at an extra cost. Just to prevent the annoying structure placement problems that exist.

Custom Material System

Gameplay wise, this had only luke-warm effects due to many different issues. However from a technical standpoint the custom material system was marvelous. By using components we were able to create many different items quite easily and admins today can add new items with new effects at very little cost. If an admin wanted to, they could create an entirely new tier of weapons and armor without having to touch a single line of code! Only YAML manipulation. Since I made the storage of custom information generic enough I was able to use it to store many different types of data, not only custom tags for item id’s but also custom enchantments and tags for things like arena items.

Asynchronous Tasks

Another technical success was the use of asynchronous tasks in a non-thread-safe environment. Everything in the world must be accessed and set in a synchronous thread in Minecraft which can significantly slow down the game and drop TPS. I needed a way to run slower tasks asynchronously but call synchronous functions when I needed to. The internal framework I created had a rocky start, but has stood the test of time quite well. I’ll explain it in more detail in a later post.

Lessons Learned

• Just because something sounds fun, doesn’t mean it will be.
• Running a live server and making live updates to the code is very hard. It can double or triple the amount of effort you need to put in.
• A bug causing problems on a live server which can’t be reset is way harder to fix than a bug that can be reset. Cleaning up the problems caused by a bug is often more work than fixing the bug in the first place. Having to do it all over again I would certainly have a testing server and find a way to get people playing on it to find bugs faster.
• Component systems are worth their weight in gold. Use them.
• Administration and community management are a lot harder than it looks.
• Players will give you suggestions and criticisms which must be viewed as raw data, not requests. Players don’t really know what they want in most cases and you have to interpret them.
• Don’t underestimate the negative effects of petty politics.
• Design gameplay elements from the start and focus on the ability to reuse mechanics as much as possible.

And that concludes my postmortem analysis of the CivCraft project. There is a lot more I could say about it, but these are the key things that stick out in my mind as being the most important. The standalone version is going to take the failures, successes, and lessons learned in to account and will be a much better game for it. I can foresee many changes coming to it, you might not even recognize it by the time it’s finished. 🙂