This week has been very intense. All of our legal papers are now sent. All that is left for us to do is wait for AmazonPayments to confirm that everything is in order. Hopefully… hopefully monday. Then, we’ll be in Kickstarter’s hands.
Yeah, I hate bureaucracy. The most recent horror story: We needed a bank statement to complete the registration of our AmazonPayments account. It’s some sort of document that the bank sends you that says your bank account actually exists. The bank sent it to us by mail. 5 business days later, we get the document. Everything is good except that the account number that Amazon needs is NOT ON THE DOCUMENT! We call the bank, they say they don’t usually put that number in the bank statement. We call Amazon, they say they need a scan of a physical piece of paper with the number on it. We call the bank again telling them we need the number, they say that they’ll scan a document for us and send it by email. We wait 2 days for this to happen. When we get the email, the scan has a big vertical line where the scan failed, and the number we need is smack in the middle of that line. We call the bank – at this point both people on the phone understand that this is getting ridiculous – they agree to scan the document again immediately. We got it now. End of story.
So yeah, it’s sent. It’s out of our control now. All we can do until then is work on the game. Speaking of which, here’s what we did this week (and last week too):
Started implementing a slice/X-ray vision system to be able to look inside structures or even down mineshafts. This System is a major gameplay element that we have been struggling with for months now. But we finally got time to sit down and figure out an efficient way of making it, and we’re surprised to see that it already works really well! Our main concern at the moment is to remove the ability to see what the ground is made of to avoid making the task of finding precious resources too easy.
Added a few nice tools to our cinematic scripting engine such as ease-in and ease-out curve functions. Until recently, we only had access to linear movement options, but now we spent an afternoon refining our code, and the result is pretty neat. We also added the ability to tweak the time scale during a cinematic. This means bullet-time effects and pause will be possible in the near future. Combined with an ease-in-out curves and the possibilities are endless. :D
Finally found the source of our massive memory leaks. Turns out the current version of Unity has problems Garbage Collecting large arrays. Garbage Collection is a system that is called periodically by the engine that analyses the content of the game and finds the unused resources. Variables that are no longer accessible by anything, arrays that are not useful anymore and procedural mesh objects that are no longer used are all things that the Garbage Collector should find and eliminate, freeing memory in the process. Unfortunately, the Unity Garbage Collector fails when scanning large arrays, and does not scan assets (which our procedural mesh is part of). These two elements make up 80% of Castle Story’s memory footprint, so solving this problem is absolutely critical to be able to release a playable game. Fortunately, we have found a few functions in the .Net framework that allows manual memory management.
Added a bit of randomness to the archers’ arrows. Until now, the archers would have uncanny abilities and would shoot bad guys from kilometers away. Now the effect is subtle, but the arrows will have a cone of accuracy so that faraway targets are harder to hit.
Found and fixed a few bugs, some of which are pretty funny. The ragdoll was acting weird so we looked into it and found out objects within the hierachy would be duplicated without their meshes. So a dead Bricktron might drop his sword, but he would also drop a duplicate invisible sword. The ragdolls would then fall on those invisible objets and it would look weird. We also found out that some character animations would not play if the camera wasn’t looking at it. Generally this is good for CPU performance, but some of our code depended on the animation being played. This resulted in characters not picking up objects unless we looked at them, and all sorts of equally annoying nonsense.
In the process of wrapping up the trailer, here’s what we have to say about it:
The trailer is almost done. The most complex scenes are finished, the main timeline is pretty much set in stone. The only remaining scenes are gameplay scenes, and these are the most simple ones to make. Here’s a screenshot of what the trailer looks like (as seen from our point of view):
Something tells me there will be at least one explosion in this video.
We also have a few screenshots from the trailer itself. Complete with the storyboard sketch that was made beforehand.
So anyway, soon, you’ll get to see the actual trailer. It’s going to be worth it. We showed the first draft to some friends of ours this week. My favorite comment was “I just shat brix!” Funny thing, Castle Story was originally named “Brix” when we started working on it 2 years ago, and we scrapped the name because it was too close to the aforementioned expression.
Soundtrack of the week
A real shiny treat this week. TrentemÃ¸ller is just insane. Just please listen with the volume at max, your neighbors will thank you, no kidding.
82 Comments for Dev diary number twenty : Brix & Storyboards