Very glad to hear of the advancement of the develeoppement. I hope you guys have as much fun developping TBS as we will have playing it.
I take it you're the model for hte Varls then.Originally Posted by John
Thread: Technical Blog #0
Very glad to hear of the advancement of the develeoppement. I hope you guys have as much fun developping TBS as we will have playing it.
I take it you're the model for hte Varls then.
We use JIRA in the application (not game) development team I'm a part of. It does the job well enough.
Hello, thanks, and I'm working on it
! Thank you for the interesting und informative post! Makes me even more excited for the game (if that's actually possible). :)
Great update! makes me glad i'm a backer. Here's another vote for another one whenever you can post it...
I will agree with the crowds that more Technical Blogs would be great, but I'm of the opinion that I'd rather have them when there's something constructive to put into 'em, instead of on a set schedule. Having TB#2 be "Well, we wrote code. It compiled. Cool." just seems like it's taking your time away from, well, writing code (and having it compile). :P
Thank you very much for this one, however!
This is exactly what Alex from the Starfarer devs wrote on the blog when people asked for more frequent updates. And that is totally true, give us news when there are, and not the way the TV does when nothing happens.
Last edited by Troll; 05-14-2012 at 10:31 AM. Reason: typo
I really enjoyed reading this. Thanks!
#29
I'm actually the Dredge. Alex is the Varl.
How does John stand up from his desk without banging his head into the ceiling???
I'm looking forward to thoroughly testing your UI. Nothing drives me more bonkers than a buggy UI! I was convinced that the creators of Hellgate: London's UI were all dyslexic!
Leslee
PS Not sure how my forum name got truncated? I guess that third letter 'e' decided to take a walk?
Last edited by Leslee; 05-15-2012 at 02:04 PM.
It all depends on how John feels about it, in my opinion. I agree that a seemingly superfluous blog entry written on a schedule might use time that could be spent on other tasks, but if John (or any Dev) just wants to geek out with us for the fun of it, then I don't have a problem with it. The game will get made and it will be better if those developing it are having as much fun as possible.
So, thanks for the info, John! It's great to have an update that shows us so much! Keep doing them as long as you're enjoying it. Please don't make it into a chore, though.
Also, make sure that you have your workstation set up as ergonomically as possible. I know it'll be rough, but you need to consider your health... most things aren't designed with 11 foot tall supermen in mind.
I'm a big git fan but I can understand the issue of size restrictions on github. We use Pivotal Tracker for our bug tracker. We like it and their staff has been very responsive. They were just purchased, tho, so I don't know how that will change things.
Please keep these tech blogs coming!
I'm a programmer myself and I thank you do much for this. I love reading the coding side of the development.
PS: if you're looking for more volunteers, I wouldn't say no. I learn quickly.
If I understood correctly, you're writing the core game in as3? Are you writing everything from scratch or using a framework/library? It's an interesting choice, when most people seem to be flocking towards tools such as Unity. Would love to hear what made you choose as3.
Out of interest how did you choose your libraries? As an informatics researcher I'm curious how the real world makes decisions like this.
Nice update, and welcome Victor.
The more technical the blogs, the better in my opinion.
I occasionally use Git on Windows, but it feels like a bit of a nasty hack compared to Mercurial, so I prefer to use that for all my personal projects. I have a couple of open source projects hosted on Google Code, a couple of private ones on bitbucket, and even more I just push/pull to my Dropbox folder.
We also use Mercurial at work, which is handy.
How do you find Mercurial stands up with large binary blobs? I've head that neither Git nor Mercurial handle them very well.
I've also used FMOD a little (a very little, and a old version too), and found it to be a very nice library to use.
I shall look forward to the next update.
Thanks for doing this tech blog, John. Always interesting to hear about others' system architecture, toolset, processes, etc.
I'm curious what were the deciding factors that made SimpleDB stand out over the other options in the key-value/non-relational/schemaless space?
#38
The decision to use as3 was based on a combination of 2d vector animation support, the availability of 3rd party libraries that pertain directly to the game, the ability to make native GUIs in Flash, and cross platform capabilities.
The de facto standard for creating 2d hand drawn animation is the Flash toolset. For cartoons and films you see on Cartoon Network or Nickelodeon, the scenes are pre-rendered out to video of course. Being able to take the vector animated output of Flash and render it at runtime, natively on our engine, is quite powerful.
Now, runtime rendering of vector animation is computationally expensive. For scenes with many characters animating, such as battle, we will pre-render the frames, and render them at runtime from sprite sheets. This technique will work in any engine, including Unity, although you do pay a heavy memory price. However, for many other incidental animations and scenes where the vector rendering is not a performance issue, we can choose to use the native animation format and save memory. The data structures for the frames of vector animation are far smaller than storing the rendered frames as bitmaps. For instance on the dialog scenes there should be few enough characters on the screen at once that we can get away with runtime vector rendering. This will be a big memory win, because sprite-sheeting those animations (which take up most of the screen) would consume a massive amount of memory.
Regarding 3rd party libraries, using as3isolib for our isometric scenes really speeds up development. I've written my own isometric libraries before, but I prefer in this case to just throw those out and use as3isolib. Greensock tweening library is something we use as well. The as3 libraries themselves provide a pretty rich set of functionality which we leverage. as3 has a powerful unit testing framework that works like any other xUnit implementation.
Native Flash GUIs is pretty compelling as well. Being able to craft GUIs in Flash and just run them in our engine is a powerful technique. You can use ScaleForm to accomplish this in other engines, and this a very common technique in AAA games these days. The GUI in SWTOR is Flash running in ScaleForm, for instance. Unity and ScaleForm are currently working together to make this available in Unity, but I don't know what the ETA is for that.
Adobe AIR allows you to take as3 code in the flash runtime, and compile it to native code on PC, Mac, iOS, and Android. It uses various techniques to accomplish this, including pre-compiling the as3 bytecode with LLVM and generating native code. As of last fall, you can write Adobe Native Extensions, basically a native library which you can call into from as3. So with that, the sky's the limit. Any platform-specific stuff you need to deal with (e.g. Steam, iOS GameCenter, whatever...) can be exposed through a Native Extension. This is how we are linking FMOD into the game, among other things. This is also a technique for optimization -- if something is just too slow running in as3 bytecode, we can just re-write it in C++ or Objective C, compile it natively, and away you go. I wrote a 3d engine in Java on Android a couple years ago, and the ability to just punch through to handcrafted native code (using the Android NDK) was a huge win for getting the performance I needed.
For additional platforms, such as consoles, ScaleForm comes into play for creating native applications.
All these considerations make the platform sort of a perfect fit for the particular game we are making. I am able to take quite a few technical features for granted, and focus on the game itself. The code that goes into creating our travel scenes, dialog, and combat scenes is a bespoke creation regardless of the engine chosen.
JW
Last edited by John; 05-16-2012 at 09:13 PM.
#39
Mostly just ease of use in the AWS ecosystem. SimpleDB is built to interoperate easily with EC2, S3, and IAM, all of which we are using anyway. It has an https API, native APIs (in our case, Java), and supports SQL queries as well. It seems to be the simplest route for us.
JW
Thanks, looking forward to more posts like this!
Reply With Quote
