Difference between revisions of "Elder Game: Notes From The Coding Pit"

Latest revision as of 12:18, 22 January 2024

This Blog Post was part of the Elder Game blog. It was posted by Citan on July 29, 2011.

Previous Post: Elder Game: Go Big or Go Home

Next Post: Elder Game: NPCs as Systems Nexus

Additional Blog entries can be found on the Developers page or in Category:Game Blogs

[This week I haven't done any design philosophizing... I've been busy coding game systems for the MMO, so I haven't gotten a chance to write anything too clever. These are just some notes that you may or may not find interesting.]

Transforming into beasts is inherently kind of fun

One of the game systems I’ve been working on is the transformation system, so that you can turn into something you aren’t. This turns out to be a lot of fun to play around with. There are some wild pigs and deer in the forest that I’m working on, and I often find myself absentmindedly turning into a wolf and chasing terrified pigs through the trees. There’s something inherently cool about being low to the ground, attacking with jaws and claws.

I think being a werewolf will be a lot of fun if I can manage to capture and enhance this underlying “feral” vibe. The problem is that when killing something more ferocious than a deer, the wolf suddenly feels like just another DPS class, as you stand there trading blows with your enemies. I have some ideas on how to avoid that fate, but I really don’t know if they’ll work out yet.

Sometimes sample code gets around

I mentioned that Gorgon is based on an earlier MMO project. My earlier MMO’s client synchronization code (that lets players see and interact with each other) was borrowed from an old SmartFoxServer demo. It worked okay under optimal conditions… but in certain lag conditions, clients would get permanently out of sync. That old demo code was always meant to be a temporary thing anyway, so this week I finally got around to rewriting it.

But as I researched other implementations on the web, I kept finding the same demo code I’d borrowed. It’s a simple algorithm, so not every implementation was borrowed from the same source, but I could tell that four or five Unity demo scripts must have been direct descendants. Some of them literally had the same problem, but most of them had a band-aid hacked onto them to fix it.

This made the code kind of silly: it has a fancy buffer system, and the idea is it will speed up or slow down to play the data back in a way that makes it seem smooth. But this code doesn’t do the speed-up part right. When it’s getting out of sync, the band-aid fix is to just dump data out of the buffer until it’s back to normal. This means that people end up appearing to “blip” around more than they need to. (Or walk through solid objects, depending on which version of the band-aid you used.)

After talking with a friend who’s done a lot of this sort of thing for other MMOs, I started over from scratch using a slightly different approach. The net result isn’t much different from the old code, but my code’s a lot easier to follow, since it doesn’t have all the vestigial stuff lying around.

There are some tricky timing elements when doing synchronization, so I certainly think it’s smart to study existing code. But I find it kind of funny that someone must have swiped this demo code wholesale, then realized the code was buggy, but not really understood precisely how it worked, and just slapped a band-aid on it. Then they released their code, and it got ported to other APIs and versions and so on, propagating around. I guess the moral is… be careful what you swipe off the internet?

Mixamo is cool, but glitchy

A few months back, a Unity3D newsletter proudly announced that they would soon have a whole bunch of animation data available for free from the Unity Asset Store. (I think this is old mo-cap data that was made public by MIT a few years ago.) Unfortunately… that newsletter seems to have been premature, as there’s still no sign of all this cool free animation data.

On the other hand, Mixamo.com has a very nice Unity plug in that lets you shop for animations directly from within Unity. You can apply the animations to your model right in the editor, tweak various sliders until they look good, and then buy the animation. Each animation costs $10 if purchased through the Unity store, which is a steal considering that they’re more than twice that much if you buy them from Mixamo.com directly.

I certainly don’t feel that $10 is too much per animation, but I do wish I could tweak the animations for free after I buy them — or at least get some sort of discount for re-buying the same animation. Once I’ve paid for the animations, I inevitably want to adjust things ever so slightly this way or that… but once it’s bought, it’s over. If you want to change anything even slightly, you have to pay $10 again. That payment model is really frustrating. But given the quality of the animations, it hasn’t stopped me from picking up an animation or two, and planning to pick up more in the near future… if I can get my elves to sync up with Mixamo’s system.

See, the tricky part with using Mixamo is that you have to get your 3D model to sync up with their server, because their server will bake the animations to fit your particular model. This is sometimes very easy, and sometimes not. I often buy models from people who don’t speak English natively, so their models aren’t rigged using English names. This confuses the automatic mapping tool, which seems to use bone names as heuristics.

But even on models that look very standard to me, the importer is just not super robust yet. It can get really confused and spit out error messages that I can’t make heads or tails of. In these cases, the tech support guys have been phenomenal, though, so I can’t complain too much. Hopefully they can fix my female elves — the male ones imported without a problem, but I can’t get the females in for some reason.

Groovy: the only cool thing about Java?

The server code is written in Java. I prefer C# by a large margin, but Java is just a lot more “everywhere”. It’s easy to find different socket-level implementations to plug into my game if I use Java — and more elaborate solutions like SmartFoxServer or ElectroServer. A lot of cool technology can be dropped into Java apps that don’t have good C# analogs yet. (I’m also a little scared of running a linux server farm with the game written in the “Mono” version of C#. Mono seems great, but I still worry that it’s going to have weird problems under linux that take tons of time to figure out.)

I don’t especially like coding in Java, though. It’s missing a lot of conveniences, and it can be pretty ugly to code in. I’m still irked that it doesn’t support unsigned integers, too.

There’s one thing I do like about having written it in Java, though: the Groovy programming language. Mainly what I like about it is that it compiles to Java bytecodes. This means that I can use it as a simple scripting language for my NPCs and other behaviors, but it gets compiled to run at the same level that the actual server does. (Instead of other scripting languages, where they get interpreted by Java code, so it’s a VM running a VM.) It’s still not as efficient as regular Java, but it’s not bad either, and Groovy has a lot of syntactic tricks that make it easy to kind of “sculpt” it to fit particular scripting situations, such as for NPCs in my game.

(Where a game written in C++ might use Lua, I think Groovy fits that role for Java games.)

Next week: NPCs

My last post lamented that I don’t have time to do everything I want to. Several people let me know that if I needed to cut something, it should be NPC features. I don’t think it’s so easy a choice as that, and next week I’ll explain a little bit about what I have in mind. (It’s less about stuff like scripted movement or animatronics, and more about how NPCs can be the heart of interesting game mechanics that we just don’t see often in MMOs.)