Kyle here! Thierry had some stuff come up, so we had to change things up a bit this week. He started the blog, but circumstances pulled him away and the task of writing the majority of this blog fell to someone who usually just edits it, me!
I shall rule this blog with an iron keyboard! MWAHAHA!
We’re going to be talking about our next patch, problems and solutions with our sound engine, objects, the tutorial, the road-map, localisation, and an update on address verification for our backers. Lots to write, let’s jump right in, shall we?
The Next Patch
We’ve been hard at work on our next patch, and we sent it to our testers Wednesday. We’re giving them an entire week to test it out as thoroughly as possible, since we have some pretty substantial changes to data structure in this one. It shouldn’t break anything, but you never know.
So, what’s in this patch? Well, no new features, since our primary focus is still refactoring, more on that further down. But we do have some good ole’ bug fixes that should help with stability and performance.
It also comes with a fix for our penguin friends who couldn’t load the game if their system was set up in any language other than English. That bit’s already been tested and seems to work now. But, since we had a further issue with saving and loading, we pushed back the release so we could get that fixed too.
And we did, so that problem will be resolved with this patch as well. Unfortunately, there is a possibility that saves prior to this version will be broken. We haven’t personally encountered that issue, and we hope that won’t be the case, but these are the types of changes that would break them, so we wanted to make sure to toss that out there.
Sound Engine Memory Breakthrough
It seems like every time we solve one problem with the sound engine, another one pops up somewhere else.
We’ve discovered that the sounds we have in game end up taking 3-4 times as much space in RAM as the entire file itself takes on the disk. This is a result of the compress-decompress dance that Unity does with sound files. Unity automatically compresses audio files that are imported into the game, and then decompresses them when they’re needed.
Normally, this isn’t really a problem, and many games do it this way. But, we have clearly encountered an out of the ordinary issue here. We’ve spent quite a bit of time with FX investigating the issue, not to mention a lot of back and forth with the guys behind Fabric, and we’ve isolated what’s causing the issue.
We still aren’t sure exactly why it’s causing the problem to pop up, but we have learned what not to do, so we can avoid it in the future. It’s been reported to Fabric now, and they’ll certainly work on resolving it. And now we can start moving on to more interesting audio-related projects, such as the localized ambiance.
The Switch From Coded Objects to Modular Objects
We’re working on making a big change to the way objects of all types are handled in the game. You may recall that, quite awhile back, we started to work on changing all our objects into dynamic objects. Well, that was the first step towards what we’re doing now, which is going to make our dynamic objects much, much better.
So, let me explain how the objects in game are handled right now. Every block, tree, structure, and rock is essentially an isolated object. Everything about how that object acts and behaves, about what it can store, what can move through it, and how it interacts with pathing, is contained inside that singular object.
This is not ideal. It means that every time we want to add something, we have to manually write in all it’s behaviors, even if other blocks use the same behaviors.
For a hypothetical example, let’s say we want to add a new 2×1 block. Everything about this block is the same as the 2×1 block we’ve already got. Same placement method, blocks paths the same, same health, everything. The only difference is that it looks like it’s made of candy, delicious delicious candy. Well, even though it’s the same, we’re gonna have to write all those behaviors into it too, which wastes space, performance, and memory. Which sucks. This is how it works now, and this is why content additions have been so very sparse.
Now, here’s what we’re doing to change that. We’re taking those behaviors and pulling them out of the objects, giving them their own little place to hang out and wait until they’re called. This means that our 2×1 block, instead of having all the programming related to how that block interacts with everything attached directly to that block, it simply references those behaviors.
This is very, very good news. It will mean we can make changes to the way an entire type of objects behave by changing one bit of code instead of a half-dozen bits of code. It will make changes more consistent, more stable, and easier to carry out, all while saving resources and space that the game takes up.
It’s also good news for modders, who might want to add in some new blocks or structures, but might not have the expertise to manually write out all the behaviors associated with them. Now, they’ll be able to simply call pre-defined behaviors. It will also make adding or modifying behaviors much, much easier. Essentially, it will make everything about the game more versatile and flexible, which is never a bad thing.
We haven’t implemented it project wide just yet, but we’ve got our first usage case up and running, and it’s looking very, very good.
Isn’t This Still Refactoring? When is it Gonna End?!
Essentially, yes, this is refactoring. Those of you who’ve been with us awhile know that we’ve been spending the last few months with the refactoring process as our primary focus. The big question we’ve been getting over and over is when are we going to be done refactoring? When are we going to start adding stuff?
Well, as far as the refactoring goes, we’ll be done refactoring when the game is done.
Wait wait! Put down the torches, I’m not done!
Simply because of how game development goes when you have a team of more than a couple people, there are always ways to improve and optimize the code. We have no intent of getting it to a point where it’s passable, going ‘eh, good enough’, and then just leaving it in that shape. Just like with the AI, we’ll always be glancing at ways to improve it, to make it more solid, reliable, and efficient, especially whenever we add anything big and game-changing.
That being said, we will reach a point where refactoring isn’t our priority, but instead something we do whenever we see a place where we can improve things. Right now, we’re about halfway through the entire process, and our tentative goal is to be at the point where we can start shifting our primary focus to content additions and actual mechanic improvements after PAX.
Note that this isn’t a deadline, or a promise, or a release date. This is our personal goal, and if the foundation isn’t ready for it, then we aren’t going to shove things in just to be able to say we did it. We did that once already, and it’s caused more headaches than it’s worth. We’re going to be doing the job right this time, even if it takes longer than we like.
This isn’t to say we won’t have any content additions before then. We’ve been watching the community closely, and it looks like one of the biggest problems with the game right now is that people simply don’t know how to play it. That’s not the players fault of course, the game isn’t terribly intuitive and there isn’t really anything out there that’s like it. It’s like throwing Starcraft at someone who’s never played an RTS before, they simply aren’t going to know what to do, and it’s up to the game to teach them how to do it. Which brings us to our next topic.
How Do I Even?!
We’re still working on putting together the needed system to put a proper, playable tutorial in game that will handle teaching new players all the basics of the game, from resource collection to structures to building a castle and spawning new Bricktrons.
Like with the refactoring and the focus shift to content additions, our plan is to take our time and get it right. It won’t do any good to put in a tutorial that’s broken, unintuitive, or boring. We plan to have it up and running by the time PAX East rolls around, but if it’s not ready, we aren’t going to rush it out the door just to have it. We’d rather not have it playable at PAX than have it be junk.
We’ve also gotten questions many times over about the road-map that we talked about putting together ages ago, and I gave my word that as soon as I knew something, I’d make sure you all know it as well.
First off, why did it take this long? Well, we’ve been waiting for an opportunity to meet with our webmaster to start designing the page and putting it together in such a way that we can easily update it as we move along. But then he had to go and become a father, and he doesn’t have as much time for work as he used to, what with being a father and all. We had been waiting for things to calm down a bit for him so we could meet and start getting this thing knocked out, and eventually he told us we needed to go ahead and get in touch with someone else, in spite of all the solid work he’d done for us in the past.
Fortunately, he had a recommendation, and the new guy is great. We met with him earlier this week and spent a fair bit of time going over what we want from this. He told us that he had some pretty good ideas, and left to start working on a couple of mock-ups to show us so we can see what he can do and we can seal the deal. We should be getting those mock-ups this weekend, and then we can advance to the next stage.
While going through the comments in our last blog entry, we noticed that there were tons of requests for localisation of the game. So, we figured we’d comment on it. We most definitely want to have the game translated in the future. But, at the moment, the system simply isn’t ready to accept it. We do have plans for it though, and there are a lot of options and methods to do it. So, stay tuned, and we’ll eventually send out requests to help make our game available to as many languages as we can get translators for!
So… Many… E-mails…
As mentioned in our blog about the t-shirts, I’m in the process of e-mailing all our t-shirt backers, one-by-one, and verifying their addresses. So, here’s an update on how that’s going as of this writing:
Total e-mails to write: 848
Total written thus far: 303, or 35.73%
Total backers that have responded so far: 216, or 71.29% of the backers e-mailed so far.
Total backers that have moved: 47, or 22.69% of backers that have responded so far.
Total backers that also needed their shirt size changed: 4, or 1.85% of backers that have responded.
We’re working alphabetically by backers first names. So far, I’ve gotten all the way through G. So, if your first name starts with A-G, and you backed for a T-shirt and haven’t gotten an e-mail from me, please send an e-mail to email@example.com and I’ll get it taken care of.
Note that we’re specifically going through and verifying people that pledged at the $55 and $100 levels right now. Anything that included a poster should have gone out already.
If you backed for a pledge level that included a poster and haven’t gotten your stuff, please submit a ticket on our support site at http://support.castlestory.net and we’ll make sure to take care of it.
If you are in the $55 or $100 level, and your name doesn’t start with A-G, just hang tight and keep an eye out, you’ll get a verification e-mail from me soon.
Community Game Night
As you may recall, we had a community game night last weekend on Starbound, playing on a server generously provided by www.mpserv.net. A lot of you joined in, and we had a pretty good time. I even ended up chatting with a couple community members over Skype for awhile.
However, we did have our issues. It was very hard to coordinate, and I had absolutely no admin control. The server on Starbound is still very bare-bone, and doesn’t even tell me who is connected, or even how many people are connected. There’s also no ability to kick or ban anybody. So, we likely won’t be having another game-night on Starbound until the server controls are a tad more complete.
That being said, I most definitely want to have another game night with you guys, and I want to turn it into a regular bi-weekly event.
The fallback game, so to speak, is Minecraft, since it was second in terms of votes. Unfortunately, I don’t have a Minecraft server handy, so our next game night is going to have to wait until I have the spare resources to get a server setup for it that will be able to handle the amount of players we’d have. As soon as I can manage that though, I’ll be posting an announcement to let everyone know when our next community game night is.
Soundtrack of the Week
I’ve been listening to loads of chiptunes on Pandora while writing all the e-mails this week. While listening, I stumbled across a new group that I rather like, Approaching Nirvana, and I’ve been listening to their stuff for the last couple hours. So, I decided to share them with you! Enjoy!
Banner image credit to Steam user saromir.
And, as always, thanks for reading!
36 Comments for Dev-Diary Seventy-Nine: A Box, a Programmer, and a Sound Engine Walk into a Bar…