2014/04/24
Hello everybody! We’ve been very busy over the last month.
We got word today that the translation is partially complete. 3 of 6 languages are completely translated. There were about 99,000 words of text that got translated. I will be taking the first delivery of that, and integrating it into the game. We’ll plan on sending it back for a revision if we find anything of issue. I’ll also need to do some work making sure everything fits in the space allotted. Some of our GUI elements are already pretty smart about shrinking the text if it would not fit otherwise. Some of the elements I’m sure will have text overruns, and will require a little GUI rearrangement. Once we have it ready, I’ll open a beta for anyone who would like to come in and do some testing in their native languages to let us know if we’ve missed anything or gotten anything wrong.
The wheels of console porting are turning steadily, but slowly. I am currently evaluating 3 different development organizations that can help us do the ports. The way our game code is structured is fairly esoteric, so finding the right people is a challenge. The task requires previous experience with a fairly specialized piece of technology (Scaleform). However, I am in discussions with some people with very strong backgrounds in that area.
Autodesk, the company that owns Scaleform, has been very responsive so far. We encountered some early problems doing a rudimentary wrapper for our game, and they were very helpful in identifying the problem and possible solutions. We have been using the next generation ActionScript Compiler (ASC 2.0) for some time, but it turns out that the ActionScript Bytecode it generates (ABC) is not compatible with scaleform. We have found a way to switch back to the legacy ActionScript Compiler, and those options are starting to yield results.
The iPad port is coming along slowly but steadily as well. One of the first issues to be resolved is the problem with loading all the GUI elements into the game. Currently we load the GUI elements as Flash SWFs at runtime, as they are needed. However, a bug with the way the SWF Loader works on iOS prevents this from working on iOS. Basically, the SWF Loader throws an error if the loaded SWF contains any ActionScript Bytecode (ABC). Even though there is zero actual functional ABC included in our GUI SWFs, the ‘exported symbol’ functionality creates boilerplate empty class definitions, which are technically ABC. Instead of being sensible and recognizing the difference between actual functional ABC and empty boilerplate definitions, the Adobe Loader just craps out.
The solution that we are taking is to link all the GUIs with the game executable at compile time. This has the potential to increase the size of the executable by 100 MB or more, but we have implemented a system that allows us to strip out the large bitmaps from the GUI SWF, and load them dynamically at runtime. The work of changing over the GUIs in this way is something that has to be done one by one, with a good bit of manual labor and testing at each step.
Another issue that has arisen is the limitation of iOS application size. The iOS application file, called IPA, has a maximum size imposed by Apple of 2 GB. Our game with all its assets is around 2.5 GB in size. Some of the biggest assets are the videos and sound, followed by the numerous massive bitmaps used in all the scenes. We deliberately made our textures large to support retina displays and future large displays. The GUIs and scenes are all authored for a native resolution of 2731x1536 (that would be the resolution of a Retina iPad if it were extended horizontally into Cinemascope aspect ratio). We can probably reduce the resolution of the cinematic videos, which will save us quite a bit, and increase the compression of the sound and music. If this doesn’t buy us enough, we can evaluate whether _all_ our scene textures really need to be at retina resolution.
Another issue we have hit is that our video playback doesn’t work on iPad. We are currently using flash.media.Video, and I think all we need to do is convert this to a new technique called StageVideo. This is pretty low on the priority list at the moment.
We have been investing a lot of time planning and scheduling the work for TBS2. Alex and Arnie have hashed out the details of the story and the characters, and artwork is underway on that. I’ve built out my schedule for the new features and improvements we want to include.
At the beginning of our project, I invested in a top of the line 27” iMac with maxed out RAM, CPU and SSD, which was a great investment and really helped me get the project done quickly. However, one downside is that although the SSD is very fast, it is also very small in modern terms. So I was always struggling with keeping space clear on it. As our project size has grown, and we are starting new projects, it becomes more difficult. Additionally, I need to have a natively installed Windows development environment. Rather than settle for the inelegant solution of simply attaching an external drive (which I did do for a long time), I decided to take the whole thing apart and install an additional hard drive. It took me quite a bit of time to find the correct cables, but I finally did and everything works like a charm!
Earlier this month, the internet was hit by the Heartbleed exploit. We spent a good bit of time upgrading and hardening our own servers against it, which involved some Factions and Website reboots. Heroku had some rolling downtime while they patched their services against the problem as well.
Until next time!
JW
Previous: Technical Blog #5
Reply With Quote
I do have access to a Mac laptop whose RAM died on me (again), so I might do some meddling with i-hardware too, in the near future 
), with their love of the genre. I lived in Japan for a few years (and have a Japanese degree), so I often think of their culture: many themes in TBS match really well with Japanese culture (for reference: 
Originally Posted by John
)? Also, what would happen if I edited an ability or created a new one? It seems to me that most units exhibit some sort of "class-specific attitude", e.g. Raidmasters, Strongarms or Stonesingers etc, all act in way that feels "personal" to that class. Consequently, creating/editing an ability assigned to enemy units means that the corresponding "sub-module" of the AI should also be created/edited, to make proper use the ability...
] and (b) when I melee-hit the Scourge, i didn't take back any break-damage [that's probably due to the fact that BtP acts in complement with RtF]. It seems like I'll need to do so more research on those. It's true that the ability files are much trickier to "read" than the rest of files I meddled with, mostly due to the use of your jargon (e.g. "autolevel", "caster", "ops", "phantasms" etc)
