A Short History of KAG
(Pictures and additions to come, stay tuned!)
King Arthur's Gold is the game that consumed my life and confirmed I wanted to make games for a living. I was commissioned in May 2011 to make some medieval art by a mysterious internet person. The rate was $15 an hour.
Long story short, he turned out to be Michal 'MM' Marcinkowski, the man who made Soldat, one of the influential games of my childhood.
While I was taken aback at that revelation, working with him was good. We communicated via email and occasionally gtalk, and got the first build out quickly (within a month).
KAG is a multiplayer medieval team-based building and fighting game for windows, linux and OSX. The first build was windows only.
If you'd like to cut to the chase and play it, off you go
Getting KAG onto Desura was quite a big step for us. We'd started selling it about 100 days in, and sales weren't exactly terrible, but it was hardly enough to cover my hourly rate, let alone put food on the table for Michal.
Eventually it became clear that we were in for the long haul, and that we needed larger distribution channels. MM and I became partners on KAG, I opted to get a percentage of revenue rather than my hourly rate, and we got in contact with Desura and Valve.
Because of this, I was suddenly quite low on money, as MM had been for months now - we were both quite desperate and worked tirelessly towards getting it on Desura. We heard bits and pieces from valve but they seemed very overworked and unfamiliar with what we were doing. It was finally approved on Desura and we breathed a little easier on our new meagre wages.
In hindsight, we worked on a "zombie fortress" mode for KAG for way too long.
The zombie mode really pushed the technological envelope for KAG - we had to find a way to make 100s of zombies pathfind around, sync them all in way that didn't kill the server, make their physics behave, at the same time as managing gamemode design, creature design, and keeping the community up to date (there was an update drought of like 3 months in here).
It was at this point that we really started seeing the cracks in the engine and in our workflow. I had started doing some of the programming, and needed a lot of showing around the source. There was a lot of it that MM realised he didn't really understand any more - KAG stuff that had been implemented at midnight half a year ago, or legacy stuff in the engine from the past 3 years. There was a lot of dust in there, but for now we just worked around it and dreamed of better days.
We had discovered component oriented programming and scrambled to implement something akin to what we had read about. While it wasn't perfect, we found ourselves moving a little faster on development. This is one of those things though where hindsight says we really should have made a bigger effort on understanding the tech. As of 2016, the architecture we implemented then is one of the things contributing to the "death by a thousand cuts" optimisation issues in KAG.
We also had a big source control screw up over Christmas 2011 - SVN died. The only source we had was the source on each of our computers, which was out of sync as well. We looked into distributed version control options and eventually went with mercurial as it seemed easier to learn, and MM already had a bad opinion of git.
KAG Zombies were finally released through March 2012 - just as we were getting ready to head off to GDC.
It seems like every nontrivial game goes through the same thing at some point; a turning point where you have to decide if you'll just trudge on through your crappy code, or if you'll clean things up "for the better". We had hit the 200k SLOC point with KAG and decided we needed a different approach - sick of 10-30 minute rebuilds we started looking into scripting languages.
After much ado, we decided to fork the repository. We kept this quiet from the community, because we had no idea if it would be successful. We kept working on KAG (what we were now internally calling "KAG Classic") alongside the new engine, but it was becoming clear that we either had to "quickly finish" or some major changes were needed.
KAG Changes were visibly slowing down, the community was getting frustrated. It was quite a hard time for us, and though we tend not to argue too much, we were burnt out, and very worried about the amount of work it would take to pull off the project. That put quite a lot of strain on the team.
Reshuffling the Team
We reshuffled the team a little coming into 2013. We took on Lucas as a dedicated support guy and Tom as a programmer to work on the API with Ryan. Joe was a little less involved for a while through here as well I think, though he's always been an "around when needed" kind of sysadmin.
Michal was scheming in the background, getting multiple pots on the boil with Storm and Transmigration. I wasn't really a part of those discussions though.
We got a significant amount of work done on the fork and started letting in testers. By a significant amount of work, I mean the game booted and you could move around a partly broken map. It may have been a mistake to bring in testers so early.
Feedback was very negative. Everything "felt different" or "was broken" or "didn't work". We didn't really have multiplayer, the physics were all inside out (particularly character movement), and without multiplayer we couldn't really test things like combat at all.
It was hard to keep going at this point, we were questioning each day why we didn't just knock out the promised features and move on.
As a side note; for most of this time, we couldn't use the auto-updater with the new tech. There were no separate branches of development, and making a "test build" basically meant zipping up your dev copy and sending it off to the testers on IRC and the forums. It was incredibly time-consuming and laborious, especially if you wanted to test on anything other than your native platform.
At some point, we got a continuous build system working (Hudson, followed by Jenkins), and it was able to push out builds to a few separate update channels separately. For anyone feeling like their release workflow sucks - look into some form of automatic system like this. It comes with its own set of headaches, but it means you don't spend an hour or more just on preparing a distribution for testing.
The internal testing period involved scrapping a lot of the "planned" direction for the game as ideas were tried and shown not to work.
"War" mode, a plan for a deeper game with a focus on progression, technology, and crafting, turned out to be a totally un-fun slog where rushing was the only sure-fire way to win. The movement code took many, many iterations to get into a fun space, and at that point it had diverged so much from the classic movement that it still alienated older players. There was no Capture the Flag mode. The Team Deathmatch mode was "different" to the classic one. The maps we had really sucked.
All that said, we decided we needed more eyes on it, and the Beta release was a bandaid that needed ripping off at some point. We had multiplayer working "well enough", so we released the game publicly on the forums, but didn't announce the release anywhere major. We only wanted community feedback.
Chaos erupted. Many were very unhappy with how the game had changed. Some thought the game hadn't changed enough, and wanted more of a sandbox experience. It was often hard to find a game for lack of players.
The Public Beta period was one of many concessions to reality. The "Take the Halls" replacement mode for War was not much better in terms of strategy, but at least had a clear goal. Capture the Flag was added, with a much simpler "Coin Based" economy. Knight combat was changed to be more familiar to classic players. Bomb jumping was reworked and simplified. The archer went through many complete re-designs, at one point having a high-damage backstab attack, eventually settling on a grapple.
THD Development as usual; it was a very iterative process based on feedback from the community, playtesting, and issues we saw developing with the meta-game. We had "the end" in sight as well, a release on steam.
The release on steam was a very lively time for the game. We got some front-page space, and the chaotic battlefield promo art worked wonders. Player numbers peaked to new highs. Sales finally hit the "we made it" point.
There were also, of course, lots of issues turned up by the new players. Changes were introduced for newbies that rubbed veterans the wrong way. Long-time players had weeks of celebratory kill-streaks, clearing whole servers and heavily discouraging the "steamies".
However, it was impossible to dampen our mood. We'd done it.
"Modern KAG" and Closing thoughts
A few years down the line (2016), we continue to maintain the game. We have a few (paid) interns taken from the community to work on projects that they see as important. A few features have been added, a Tile-based Mechanism system being the biggest intern-sourced addition, but a fair bit of back-end and bug-fix work has come from them too.
The game still sells quite well, the user churn rate isn't wonderful though. A lot could still be polished up; the menus, the in-game interface, finicky interactions and obscure mechanics, the usual culprits. Some simpler game-modes, more maps, and more customisation options would all probably help hold people's attention a little longer too, but we have a several thousand strong player-base in any given week, so it's in no danger of immediate "death".
If I could do it all again, the one big mistake I'd avoid is the rewrite and change of direction. We should have shipped the game as it stood back in classic, and done the rewrite as a sequel. This would have avoided splitting the community so seriously, and allowed us to give the rewrite more time and thought. It probably would have led to a better game.
We don't get our time over though, and I'm happy with how the game went. It was my first success, and I'm proud of it.