Friday, May 25 2012
As predicted in the last update, Jeff Uriarte has gotten started on the team and is working hard on the tools for building out our scenes and landscapes in-game. We have been working out the technical details of making the scenes as seamless as possible whether it is depicting the traveling caravan, a battle, or a town. We have figured out a good way to make these all part of the same rendering system, and are now working toward that.
Victor is making good progress on the FMOD integration. We have FMOD up and running in the game on our Windows build. The initial prototype was done using Visual Studio (with which we are both very familiar). To support our multi-platform approach Victor hoisted the code into Eclipse CDT and configured everything to build properly there. We are using CDT in Eclipse Indigo (the newest) rather than in Flash Builder, because Flash Builder is still on Eclipse Helios (an older version).
We spent some time today talking about the soundbank loading strategy we would use, and Victor is very close to having sounds hooked up to our abilities. So very soon we should hear weapons clashing in-game. Once we get the basic functionality working, we will immediately create the Mac port of the FMOD integration.
I have been spending a large amount of time refactoring an old crufty library that formed the core of our original prototype. That library contained code representing half a dozen different systemic responsibilities. I laboriously teased it all apart, creating new dependency-clean libraries for animation, abilities, battle, pathfinding, and others. Of the various engineering sins I committed while working on the prototype, the one that came back to haunt me the worst was overuse of a generic sort of ‘context’ object that was passed to object constructors all over the code base. My context object was just a holder for various, and unfortunately unrelated, pieces of data and functionality like logging, localization, abilities, resource loading, and others. This was done in the name of convenience and to limit the number of individual objects that had to be passed around. However, this approach just leads to dependencies bleeding through into places where they are not intended. I’ve got that all cleaned up now, for the most part.
One of the things that really helps when refactoring is having plenty of unit tests to rely on. One of the most powerful programming techniques I have ever learned is that of test-first-development (also called test-driven-development). I could write an entire article about the benefits of that, but having unit tests in place while refactoring is one of my favorites.
I also got a gameserver up and running, after lots of different technology tests and evaluations. When I last spoke to you, I was planning on running an JAX-RS embedded webserver application directly on EC2. However, there turn out to be much easier ways to scale. I looked into using AWS Elastic Beanstalk, and got a gameserver running there. Elastic Beanstalk runs a Tomcat container for you, and you just install your Jersey web apps into that. However, I find that running apps inside a container to be a little clumsy from my point of view, and somewhat more cumbersome to develop, deploy, and debug.
So I went back to heroku, a service that I had experimented with last year. When I had used it before, it supported node.js, ruby, php, and other technologies, but not Java. Lucky for me, they now support Java. I created a new application there, built it out, and deployed it. It turned out to be way easier than using Elastic Beanstalk, and I can use an embedded webserver (using Jetty this time) and not rely on Tomcat. So far so good. I’m a little concerned about the more premium pricing on heroku, but we’ll have to investigate that some more. However, the great thing about web apps is that they are so standardized that you can run them just about anywhere, so if we need to switch cloud services providers, it shouldn’t be too painful.
We’ve also started discussing how to deal with game accounts. We want to integrate all the services that Stoic provides (blog, webpage, forum, and TBS) into a single user account. We are looking at various ways of linking the game user accounts with the form (vbulletin) user accounts right now.
It’s a real joy to be working in Java again. It’s a fully mature language with some of the world’s best development tools. Using Flash Builder to develop with as3 can be an annoyance, by comparison. as3 is pretty mature, but it doesn’t really compare to Java in terms of ease of use.
I could go on for pages about the deficiencies of FlashBuilder and as3, but here are a few of my favorites:
- An embarrassing lack of refactoring tools
- ‘open declaration’ sometimes just doesn’t work for symbols in another library
- cut-and-paste of code doesn’t carry any metadata of required imports, as it does when editing Java
- ‘Organize Imports’ doesn’t add necessary imports -- must be done one by one. it does remove unused imports, which is nice.
- ‘Organize Imports’ sometimes freaks out and removes all imports.
- absurdly slow compiler
- as3 does not support abstract methods, which leads to all sorts of contortions when trying to provide base implementation and an abstract interface in the same place
- The scope of local as3 variables bleed outside of their proper scope. Even more annoying is that I _know_ as3 is technically capable of properly scoping, because local variables for the caught exception in a try/catch block are scoped properly.
- as3 has no enums
- as3 has no parameterized types (aside from the Vector class which is special case)
Things are going really well right now. The 3 of us have a good bit of momentum and are making visible progress. In addition to ongoing work on the things I mentioned, we have the following tasks on the immediate horizon: improved animation timing support, implementing a Town scene, integrating with Steam, and PVP matchmaking.
In other news, the Texas summer heat is unrelenting and gathering power daily. So much that our little old AC unit can’t keep up, especially now that we have 5 men in a room with 5 computers, 8 monitors, and a fridge. So we replaced our AC with one a bit larger. This one comes with daylight streaming in from around the gaping styrofoam hole through which it is installed.
Previous: Technical Blog #0
Next: Technical Blog #2