VectorStorm Blog

Just a quick note that the bare bones animation system I mentioned before is now working.  ”Actors” are shared, so you only have one copy of each animated model in memory (although that detail is hidden from game code).  Each animated model can have any number of animations.  Each instance of each actor can have a different animation playing at any given time, or can be at a different position within each animation.

Stuff that’s still left to do on the animation system:

• Flagging animations as “loop”, “ping-pong”, or “play once then stop” (currently, they all loop).
• Consider spline-based interpolations between keyframes (currently, linear).
• Consider supporting material animations.

Sorry for lack of updates this week;  most of my time and attention has been going to the day job.  Haven’t had a lot of free time this week, so I’ve been spending that free time pretty much exclusively on coding MT2, rather than on updating this web site.  Hopefully back to more frequent progress updates this weekend/next week!

So I was hoping to get animations in and working today, but as it turns out, there was a dependency that I hadn’t thought about — to have animations work nicely, I really needed support for multi-part models.  That is, a single file which can contain a whole hierarchy of renderable objects, including their relative positions, orientations, and etc.  This wasn’t too difficult to implement, except that it exposed a bug in my file parsing code.  That file parsing code desperately needs a major refactoring, but I’m not going to do that until post-MS2 (or maybe never);  I’ve patched the bug, and will keep soldiering on with the current system.

Today’s screenshot shows the very first quick test model — several meshes loaded from a single data file, and arranged in a hierarchy.  I’ve also set up the file format to easily (eventually) support VectorStorm’s future rendering path that I’ve talked about a few times in the past.

Anyhow, now that I can load several meshes into a single hierarchy, I can start working on animating them.

Finally starting to feel properly better, today, though I’m still finding myself becoming easily winded under any sort of physical exertion.  But at least the flu symptoms have abated.

So I’m beginning to spec out what’s going to be in the MS2 build of MMORPG Tycoon 2.  It’s mostly gameplay stuff, but before I start on that, I’m going to be doing some graphic work — it’s been far too long since I did anything that could be seen in a screenshot!

Here are these initial graphic tasks:

• An animation system.  (Consider importing animation data from a 3D package)
• Modelled + animated PCs, NPCs, and monsters.
• Trees.
• Improvements to terrain system.

Today I’ve begun on the animation system.  Animation systems can be big, complicated things, depending on what features you want them to have.  Animation systems are one of my special subjects, so this one is going to be fairly full-featured.  Biggest issue is going to be where the data’s coming from.  I imagine that in the first revision, I’ll just be entering data by hand, but in the long run, I should definitely be reading the data in from data files exported from a 3D package, so that I can get actual animators to create assets, instead of needing to do everything on my own.  Hopefully I’ll be able to get the animation system finished up tomorrow.

On the topic of PCs, NPCs, monsters, and trees, I’ll just note that MT2′s graphic style is somewhat stylised, and I expect that these new bits of art will be as well.  Imagine hyper-deformed  characters built out of cubes, and you probably won’t be far off.  With the number of entities potentially visible on screen at once, they need to be very cheap to render.  But I still want to have them be animated, and nicer than the simple boxes that they are right now.

On the topic of the terrain engine, I’ve decided that the terrain system that I was using in MS1 won’t scale well to a full-size MMO, and that even if it would, it doesn’t provide as much terrain resolution as I really want.  I’ve identified two minor changes to the system which together should allow substantially higher vertex density for the terrain, but also should reduce MT2′s current memory footprint from around 600 megabytes down to about 50 megabytes.  I’ll talk more about these modifications in a few days.

But for now, it’s time to sleep.  Exhausted.

So I’ve been doing a fair bit of work on MMORPG Tycoon 2 over the past few days.  As I mentioned before, I’ve been prototyping up a “map mode”, which has been making promising progress.  I imagine that people will usually want to be modifying terrain from the map mode, since it gives a much more stable interface.  (That is, mountains rising don’t interfere with the positioning of the cursor, the way that they did in the MS1 build).  I haven’t yet decided on the interface to enter map mode, whether it should be an “anytime, anywhere” feature, or whether it should only work when one is on the graveship, or what.

I’ve also spent a little time improving the general heightmap smoothness.  I’ve fixed the annoying “crinkly edges” problem which would occur on the sides of some mountain ranges, for example (visible in the screenshot here).

I’ve been spending a lot of time on the terrain painting interface, trying to work out how to make it easier to get good results.  The big problem with the current implementation is that it’s based on applying an effect over time.  That is, brushes apply their effects repeatedly, until the user decides that they’ve got enough of the particular effect.  For example, when you click and hold using the “Mountain” tool, whatever’s under the brush slowly fades from whatever it currently is into mountains.  Which sounds okay, except that “whatever it currently is” is updated continuously.  So if you just click and hold on one spot, even though I’m doing a very slow blend at the edge of the brush, the edges will eventually become mountains as well, forming an extremely sharp cliff instead of a nice slope.  I’ve got a couple of ideas about how to fix this, but they all require using more memory, for remembering what the terrain was like before you started to draw on it.

Still plenty of stuff to do on this.  And then I’ll get to think about implementing the new combat system, which should be good fun.  :)

The cursor needs to be bigger when you’re up this high, and I should probably fade out the clouds.  But it’s even nicer to paint the terrain from this view.