It’s been a full year since our Kickstarter campaign ended, so it’s time for us to do a nice recap of what’s happened in the past year. All the highs and lows of the development. If you aren’t interested in reading through the recap, we do still have a standard entry of what we did this week down at the bottom, and you can skip straight to that. For everyone else, grab some popcorn, this could take awhile. It’s a biggie.
Here’s a little menu to help you navigate through it:
Let’s start at the beginning. In January, 2012, the team was composed of just François and Germain. This is when they posted the first demo video of Castle Story to Youtube. That version of the game was hanging together with nothing more than duct tape and patience. Lots and lots of patience.
Somehow, in spite of bugs at the time, they were able to put together that little video of what they wanted to make. Nobody could have been prepared for what came next. At this point, that video has almost a million views, which is incredible for a first time demo video.
The company didn’t even exist back then. No trademarks, no twitter, just a temporary blog we scrapped together. It didn’t take long at all before the domain we originally wanted, castlestory.com, was bought up by someone else. There was also an entire community built around the game. On top of that, Benoit was working at his PHD, and Thierry was studying bio-informatics at the time.
None of us imagined in any way that we’d be working in the game industry just a few short months later.
Benoit joined the team full time. He decided that the rocky adventures of Castle Story were just more interesting than his PHD, for the moment at least. So, he put all of that on hold, took his sword, and threw himself into the incredibly messy code base that was Castle Story at the time
Thierry was then asked to help the team out part time. His full time job didn’t require too much attention, so it wasn’t a difficult thing to do.
This was also when the dev diaries started up.
From that point, the team started to put together, piece by piece, the puzzle that would become Castle Story. So now, let’s jump forward to the Kickstarter, shall we?
This is when the Kickstarter campaign began. Due to the fact that Kickstarter wasn’t available for us in Canada, it took quite a lot of work to make this happen.
July 26th… 2 hours later
RHOMAGAD! Already funded O_O
Thierry moved to Montreal, joining the team full time. The scale of the project had changed radically at this point, so it was simply impossible for him to continue working part time.
Our office, and we use the term very, very loosely, was actually François’ appartement. Since our team was growing, the space was getting crowded very, very quickly. Thierry suggested moving over to his place, since he had quite a bit more space to work with there. Thus, we relocated.
The Prototype release!
That day was incredibly chaotic. Almost everyone on the team worked for 40 hours straight to get everything working, and some pretty serious bugs worked their way into the game in the last few hours.
Thierry ended up having to run to François’ place to get the most current build on a USB key. We had been trying to send it online, but it turned out it was quicker to drive somewhere with faster internet and start over. We threw it at Humble Bundle, and then went straight to bed.
Our inbox got flooded by literally thousands of e-mails. It took us easily a couple of weeks to try and answer them all. It didn’t help that our pathfinding was so horribly broken at the time that you could rarely play the game for more than a half hour before all the Bricktrons just plain stopped listening to their orders.
Apart from the building and mining mechanics, there wasn’t much more in the game. But it seemed it was plenty for some of you. The challenge of trying to build something with all those bugs present was huge, but that didn’t stop you guys from building some truly awesome castles. We were incredibly impressed, and it helped encourage us quite a lot.
Without the help from everyone over at CastleStoryOnline, the day could have gone much, much worse. They were incredibly helpful with giving support to the community. So, thanks again guys!
The first patch for the prototype was released this month. The initial release had so very many issues… Some of the problems resulted from our rushed last few hours before release. We had to patch those, at the absolute very least. You can see the full patch notes from that first release right here:
We also had two other newcomers to the team that month, FX and Paolo. Of course, they needed a bit of time to acclimate themselves to the code.
In the midst of that, we had started our first major overhaul on the borked pathfinding system. At the time, one of the major issues with pathfinding was causing some intense frame rate issues. We also started redesigning the phantom blocks. We had so many visual issues that we had to completely rework the shader.
The first steps had been made for the new studio. We couldn’t continue to work out of an apartment forever, we had to get a new place. We found one, but there was still a lot we needed to do to make it viable.
We started to explore some new GUI systems. The one that came with Unity3D was far too bulky for our needs. We tried implementing Awesomium first, but unfortunately, the results weren’t what we had hoped for.
This is also the month when we started to design the new radial menu for the game, intending to completely overhaul the way the player would interact with the different elements of the game. We also did a ton of research for a patching system. We had the choice between doing it ourselves, and handling all the costs if the development and all the bandwidth, or to try something that already existed. Fortunately, after a lot of exploration and research on our side, the people at Humble put us in touch with some people at Steam. Since that day, everything has gone much more smoothly on that side of things.
We migrated and moved from server to server multiple times over this period of time, because we needed something that could be scaled easily once we started getting high traffic. We finally ended up on Amazon.
A lot of recording for the sound implementation was done. We registered voices, footsteps, and many different hit sounds for collisions.
We finally moved into our new office, and started to set up tables, chairs, and desktops to start working again. Most of the furniture ended up coming from IKEA, so we had to take some time to set it all up. Thankfully, we had some friends to help out, so things were a little easier.
The radial menu went from drawing board concept to development mode to full implementation in the game.
Since we were in the process of reworking a lot of the main ideas of the game, we also did a radical overhaul of the blueprints for wooden structures.
The ladders returned to the game as a dynamic object. And, it became much easier to build one thanks to the new radial menu.
This is also when the new shaders for the phantom blocks went it, getting rid of some of the graphical issues the previous system had caused.
We also made our first attempt at compiling a working build for linux. That’s when we discovered that the sound engine we’d been using, Wwise, just plain wasn’t compatible with linux. So, we had to find another solution for our penguin friends.
A lot of icons were produced for the new radial menu. We needed at least one icon for each different task you might need a Bricktron to do.
We also started work on the pre-orders that month. We wanted to have a working landing page with pre-ordering ready for when we’d go to PAX and the DGC.
We had a big win this month too. We were able to push the game through Steam, and get the updater running properly. In additon, we also sent out steam keys, allowing players to add the game to their Steam library.
We started adding dynamic sounds, such as footsteps on different types of terrain.
Since the game was starting to grow, and it’s almost impossible to thoroughly test your own game, we put together a team of twenty volunteers who would help us test out each new build before sending it out to all the other backers. That way, we could fix any major issues without breaking the game for everybody.
We also optimized the servers so they could handle the high traffic that was coming into our website at that point, so that took a bit of time too.
It was this month that Thierry took over the blog, with help editing from TheBox (Hi guys!)
We added in the new beacon system, and spent some time tweaking it a bit so the opacity would be right when it was hidden. We also had to remove the collision detection, since it was blocking paths for Bricktrons.
We also started work on a new system that would gather all the debris lying around on the ground and take it gradually back into the ground. Sadly, the result wasn’t that grand, and it resulted in the “popcorn generator” that we showed you.
We had several major memory leaks that were gamebreaking, and we worked constantly on them so we could fix them before leaving for PAX.
We added ladders into the construction system, and did a lot of pathfinding debugging since the ladder opened up a lot of potential paths.
And, of course, we went to PAX East. It didn’t look like it, but there was a ton of organisation that had to happen, and we were completely drained by the end of it all. But, we also saw a ton of our fans, and it was a really fantastic experience. Some of us also took the rest of the week to go to the GDC, where we learned a lot from a bunch of different developers.
We jumped straight back into the coding, and managed a major fix on the AI. We increased the fluidity of the system, and that resulted in a substantial breakthrough for the Bricktron’s AI. From now on, we could handle much more complex structures without having some characters that stopped working for no apparent reason.
We also implemented a support system (http://support.castlestory.net) that could also be used for in game support. That helped us a whole lot in working with you guys on debugging and keeping track of all the different little issues.
We created a new API for all the Castle Story accounts. That will allow us to handle everything related to user accounts and multiplayer much, much more conveniently.
We implemented the deferred rendering that will allow us to eventually add in multiple lights. This was really crucial for the day/night cycles in the game, since it enables torches and such.
Finally! We got a decent internet connection in the studio. Thanks to that, we could push new builds to Steam in less than 10 minutes, rather than an hour and a half like before.
We added in a new AI behaviors for the Corruptrons that will allow them to chase down any Bricktrons they see. Since we were just starting work on Survival mode, this was incredibly important.
We were finally able to build the game for linux. Unfortunately, it came with the caveat that most of our sounds weren’t available for that version. For every sound, we needed to do a version for Wwise and another for Fmod, the sound engine we use for linux.
We created a system to fill all the empty space in the world. We called it distant islands. It wasn’t too complicated, but adding it helps get rid of that feeling of being all alone in the game’s universe.
We created a small team of volunteers to help us out with support. They helped us burn through the hundreds and hundreds of support tickets that we already had in our system, a task that simply couldn’t be handled by a single man. Thanks again for all your hard work, guys!
We finally found the fix for the black screen issue we’d been having with OSX. It really incredibly difficult to figure out, because we couldn’t reproduce the bug on our systems in the office.
We started working on some new shaders for the crystals. This was the first step towards the overhaul we wanted to carry out on all of the textures.
We did a few experiments with height maps to try and create very large islands more easily. We had some pretty awesome experiences with it, but we encountered a few problems that held us back, and we decided that we should return to that idea later.
Luc joined the team to help us flesh out the animation system. Later, we plan to hire an animator that will work with him to combine all the animations and the new system into something more robust.
This was the month that we sat down and put our goals for the future releases of Castle Story on the blog. We had the overall idea of it, with plenty of drawings and text on the whiteboard, but the community asked us to gather everything together into a blog so they could see clearly what we were doing. You can see the resulting ‘Roadmap’ here:
For the first time, we tested out Arena mode. A lot of features weren’t there yet, but we could connect four plays together, build little castles, and throw explosive barrels at one another. The hardest part of it was trying to sync all the clients on the server, but it worked out.
We also started implementing combat mechanics into survival mode, so that you could defend yourself against waves of Corruptrons, the first time we had them spawning naturally in the game.
We introduced the new normal mapped Corruptrons, making them look much more like what we had in mind initially. A lot of work was done on texturing and normal mapping the swords and shields of the Knights as well. In addition, we implemented wooden plank stockpiles that will be used later for construction.
We did a bit of exploration concerning ‘Bundles’. Those bundles would be used later for implementation of different features, and possible modding support later on.
We finally released the linux version of the game on Steam and Humble. There were still a lot of missing sounds, but the game was at least finally playable.
It was also around this time that we started thinking about joining the Steam Early Access system. So, we asked you guys what your thoughts on it were. Apparently, 75% of you were in favor of the idea, so we started seeing what we could do to make it happen.
We started implementing actions for the Knights, such as defending a position, or an area. Those actions will be vital in Survival mode, since it will allow you to set up all your guys on the map in a much better way to protect your castle.
We introduced a new material, the red crystal, to create things other than Bricktrons.
The torches begam dynamic objects. From now on, it was possible to create torches using the radial menu.
We started working with some new shaders to add a little more life into our world with the ‘puff’ shader that would be used when a Bricktron runs, when something falls on the ground, or with explosions.
We had a new asset to the team in the form of Pascale, who joined the team to lighten the weight of administrative issues that had previously been on François’ shoulders.
We worked on the tree a bit by reworking the textures. We also did some exploration on NGUI, which will eventually replace the old system in full, since it was getting too tricky to maintain.
We created some new explosions based on our new puff shader that we’d created a couple weeks beforehand.
We packaged an executable to launch a multiplayer server, making it much easier to start up a multiplayer game with lots of controls.
We built our new refactored catapult, and it works 100% better than the old one. The targeting system changed a little, and it now gives the result of what you will hit when you aim at something.
So that’s it, a full recap of the past year. Please note that we left out a lot of things thats where either not worth mentioning or that we are not ready to reveal yet, but it gives an overall idea about what’s been happening in our offices over the last year.
So there you guys go, all the ups and downs from the start of it all until now. We decided to share a few of the features we’ve worked on, but that never made their way into the game for whatever reason. Some of them aren’t completely abandoned, but we’ve had to work on our priorities. Some others gave us a lot of headaches. While we have solutions for some of them, we are still tearing our hair out on others.
So, what’s Dropbrix? Well, that was the name of our first crazy attempt at multiplayer in the game. We didn’t have Paolo at the time, and we were trying to figure out a way to make multiplayer work properly. DropBrix, or Dropbox-Brix (Brix was the original working title of Castle Story) was an idea we had to mix the game with a sync system such as Dropbox. By syncing the save files for each player in a certain folder, it was possible to make each player’s blueprints and bricks appear in both clients. We managed to get it working really fast, but it wasn’t nearly as much fun as having the players actually interacting with one another. In the end, we abandoned the idea altogether. Now we have a much more complex and interesting system working, and it’s very nearly ready to go into the game.
The ‘Biftron’ is the big Corruptron that you guys saw in the trailer video. To be entirely honest, he never really worked very well, and just making him throw a rock was a massive pain. But, we needed a big baddy for the trailer, so we tweaked together something that barely even looked like what we wanted him to eventually be. We recently tried to add him back into the game, and it worked a fair bit better than expected. Eventually, we’ll add more enemies, but for the moment we want to focus our efforts on one thing at a time.
Remember the popcorn generator? We never really explained what it was for, but some of you figured it out. In current builds of the game, when you mine or blow up some terrain, there are a bunch of particles being generated. You can collect those to create bricks, but if you didn’t, they’d just sit there on the ground forever until you reloaded the game or hit Delete. Over time, they could radically slow the game down, and we only had two solutions for it. Make them disappear after a certain amount of time, which would mean losing that precious resource forever, or make it go back into the ground to be mined back up later. Our attempt didn’t… Go as planned, let’s say, and we got what you saw. There is probably a good solution for it, but we really didn’t want to spend a ton of time on it since there are much more important things to work on.
The Large Island system was an experiment we did trying to figure out a simple way to build new islands. Sadly, we encountered tons of different problems with that idea, and we put it with the rest of these ideas on hold, at least until we have some time to think a little more about it. The idea itself wasn’t really bad, but it would require a ton of work to have it work properly so that islands would actually be usable. So, it’s something we still want to work on, but there are other things to handle.
We’ve broken, unbroken, rebroken, then broke the broken one so so many times now that we can’t count them. This dynamic object has been hell to maintain, and we were constantly having to tweak something to make them work with a new version. Pathfinding was horribly damaged by them, and it’s just recently that we’ve found a more permanent solution for them. The bug of the week is also related to that solution.
This was probably one of the worst development issues we’ve had. We’ve always had an issue with pathfinding in the game. Thankfully, we’ve finally got a solution. We think. Probably. That’s why we’d started working on a cell pathing system for a bit. But, after a few weeks, we realized the amount of dedicated work that would be required to get it working, not to mention making sure the system would be robust enough to be acceptable. It became clear there wasn’t any way it would be ready in time for our next release. We had plenty of other tasks that needed our time, so we had to put this one on hold. Thankfully, the work that we did do on it isn’t lost, and we’ll eventually get back to it.
Like we mentioned earlier, doors have always been a pain to maintain, and usually needed tweaking with every little change we made for pathfinding. That’s why they’ve been implemented and removed multiple times throughout development.
So, here’s how they used to work:
They used to block passage and create an artificial link. Only one character could go through the door at any given time then. That way, we could do a specific animation for when the character was moving through the door. It was doing sort of a slow teleportation between the outside and inside of the door. But, that required adding more nodes into the path node, and it was incredibly fragile. As a result, it was constantly breaking pathfinding.
So now the door is simply considered an obstacle. A Bricktron can go through it, and Corruptrons have to break it. It’s a much easier and stabler way to approach the problem. We might have lost out on our nifty little animation, but it’s much more robust and playable.
But, as always, we ran into a funny little bug in the course of reworking it:
We’re still continuing our work with NGUI, and Benoit is digging through all the documentation so he can have a perfect understanding of how it works. His plan is to ‘NGUI-ze’ the entire menu system. The main advantage of doing this is that we’ll be able to push assets to the menu much more easily. The current GUI requires a massive programming effort, so that’s limited us a lot. We always needed to have someone sitting down for a long time trying to completely code GUI elements.
Sounds for catapult
FX created and implemented a few new sounds for the Catapult. It’s much easier to just let you hear them than to try and explain. So, enjoy!
So what’s next?
We thought that this would also be a good time to make a bit of an announcement. We’ve decided to join the Steam Early Access system, and to push our latest build of the game at the same time, with a bunch of new features!
And when is that going to happen? September 23rd
How will it work?
We’ll be updating the client on the Humble Bundle store, and on Steam as well. Nothing new for anyone that already has the game now, just downloading the new client. I also suggest you verify that your Castle Story account is working properly by trying to connect on it. If you have a problem logging in, please contact us at firstname.lastname@example.org .