Difference between revisions of "Elder Game: November arrives! Notes about stuff"
m |
m |
||
Line 1: | Line 1: | ||
'''This Blog Post was part of the Elder Game blog. It was posted by Citan on November 3, 2013.''' | '''This Blog Post was part of the Elder Game blog. It was posted by Citan on November 3, 2013.''' | ||
− | + | : Previous Post: [[Elder Game: Racial Game Systems]] | |
+ | : Next Post: [[Elder Game: Cheesemaking]] | ||
'''Additional Blog entries can be found on the [[Developers]] page or in [[:Category:Game Blogs]] ''' | '''Additional Blog entries can be found on the [[Developers]] page or in [[:Category:Game Blogs]] ''' | ||
Latest revision as of 14:43, 22 January 2024
This Blog Post was part of the Elder Game blog. It was posted by Citan on November 3, 2013.
- Previous Post: Elder Game: Racial Game Systems
- Next Post: Elder Game: Cheesemaking
Additional Blog entries can be found on the Developers page or in Category:Game Blogs
Well that was a quick month… October went by a lot faster than I expected! But we got quite a lot done, and laid the groundwork for a pretty huge November. Here’s what’s going on.
Serbule Zone Redone
Aaron and the rest of the Legends of Etherell team has been helping me for the past couple of months. One of the first noticeable improvements was the town of Serbule (previously known as “The Forest Zone” in-game). I think it looks a lot better, and players have given it pretty high marks. Check it out if you haven’t!
The new area is much larger than before, which has given us some trouble. It’s been hard to get the monster density back up to the level of the old map. I added twice as many monsters, but the area still felt deserted of monsters. But when I added enough monsters to make it feel really lively, client performance went to hell. Which was a surprise, since I expected the monsters to be completely cost-free if they were really far away from you. (The game client loads them all up, so that they can be turned on at a moment’s notice, but it turns off the rendering if they’re far away. So loading gets slower, but once the area’s loaded, distant monsters should theoretically not have any performance impact.)
Due to lots of bugs and gotchas, it turns out that distant entities did have an impact on performance. Most of those bugs have now been fixed, and the density is back up pretty high. (And as I fix the trickier bugs, more spawns will get added.)
The loading time for Serbule has gotten pretty expensive, though — so expensive that I added a little hourglass icon on your status box to help you understand why your client may be sluggish. The problem is that I use Unity’s “coroutines” to make the code extremely clean and elegant. Each coroutine is in charge of setting up one monster or item in the world. The problem comes when you have thousands of coroutines running once — it gets really bottlenecked. I think the system was probably optimized for, like, twenty or thirty coroutines, not a thousand.
So I’ll have to rewrite the loading system soon. Not a big deal, it’s just a lot of boring grunt-work. So I’m putting that off for a bit, because I just did a bunch of other grunt-work:
AI Navigation Rewritten
I rewrote vast swaths of the monster AI system. Previously, monsters would switch between Unity’s pathfinding system and Unity’s physics engine as needed. They would walk on the path maps, which let them maneuver around obstacles. But once they got close to the player, they would switch to the physics engine, which let players do stuff like knock the monster off of cliffs or fling them up into the air.
The trouble is that Unity’s pathfinding system doesn’t play well with the physics system at all. Despite a million workarounds that really should have worked, I was never able to 100% keep monsters from “falling through the ground” when they switched modes.
The thing is, players switch between these modes all the time. If you move with the arrow keys, you’re moving with physics, but if you right-click to auto-move, you use the path maps. And players don’t generally fall through the ground, so what’s different about monsters? I don’t exactly know. They used the same code! But when the server was moving hundreds of monsters simultaneously, it didn’t always work.
It makes no sense, and it’s most definitely a bug in Unity, but it’s very subtle. For instance it might be that the path-finding system doesn’t turn off quite when I tell it to. Or maybe there’s some sort of round-off accumulation going on. Anyway, I decided that I needed a completely new approach, because I was sick of hacking on that one.
The new system is much more robust (and internally it’s quite elegant), but it has a serious limitation. Since it only uses path maps, monsters can never leave the path maps. This means you can’t kick a monster off a cliff anymore. Instead, they’ll slide along the ground when you kick them. If they reach a cliff, they just stop at the edge of the cliff instead of going over. This kinda sucks. It sucks even more for swimming creatures, which are glued to the bottom of the lake, or for flying creatures, which simply can’t fly.
I’m not at all out of ideas — my next approach will always use the physics engine (and never use Unity’s NavMeshAgent), but will calculate the path maps in the background and try to apply them to the physics terrain. This will make the monsters a little clumsy, and they may bump into walls and things. But that should actually work out well for underwater combat. And it might be okay for flying creatures too — have to see how it looks.
If that doesn’t work, I’ll just keep trying things. I’m completely confident I’ll find a good solution eventually. But I couldn’t stand to deal with it anymore right now, and the current solution is pretty robust and reliable, which is nice.
(Actually, having flying monsters is pretty uncommon for MMOs. The classic MMO way to fake it is to have monsters on ”invisible poles”. Conceptually, the monster has an imaginary extendible pole underneath them, and they can extend and retract this pole to move up and down. They’re still being driven from the ground, but they can reach up higher. This works when the game is mostly flat, but the more complex the world, the worse this works. Imagine seeing a bird that flies around a building instead of flying over the building, and you’ll see the problem. So this approach is really far down my list of solutions.)
New Player-Character Art Coming
The LoE team has been kicking ass for me and creating a new generation of custom avatar assets. Aaron’s integrating them into the game client as I type this, so hopefully we’ll get those live next week! You can check out some of the artwork on our Facebook page.
For the new models, the Gorgon engine will use dynamic rescaling techniques to give the different races subtly different body shapes. I can also use it to cheaply add several more races, and the LoE team went ahead and made some Dwarven and Fairy artwork for me. I’m pretty sure I’ll get fairies as a playable race eventually, because those are pretty well thought out in my design docs and game lore. I’m still struggling a little with why it’d be fun to play a dwarf. But odds are pretty good we’ll find something for them.
Engine Improvements
I’ll be letting the LoE team reuse Gorgon’s code for their game. They’ve also been talking with another indie MMO team making a game called Valiance, a supers MMO, and we’re looking at the possibility of hooking them up with the Gorgon engine also.
This is actually really useful to me as an engineer, because when I’m planning new Gorgon features, I can take into account all three real-world MMO designs. This makes the tech a lot more robust, but without adding a bunch of bloaty stuff that wouldn’t actually get used.
(Of course, each MMO team will still need to write a lot of their own game code. But I want the “engine” to work for everybody.)
Planning ahead for reuse has made the game better in lots of ways, such as the bone-rescaling tech mentioned above. You may also have noticed that there’s now Potions of Super Jumping and Words of Flying in the game. I coded those as example “movement powers” for the Valiance team, to make sure the engine would be able to support lots of different movement modes. And then I figured, what the heck, I might as well use them in Gorgon.
I’d been planning to add flight eventually, in the form of druids who can turn into ravens. But I hadn’t actually planned on ever having super-jumping. It’s kinda fun, though, and Gorgon’s the sort of game where it doesn’t seem out of place that a potion can let you leap 30 feet into the air. (It’s not exactly a low-magic world, after all.)
Music
I’ve asked Conor to create some new music for me. I’ve heard the rough versions of the new boss-battle music, and it’s really going to make those fights a lot more fun! We’re avoiding having all-the-time combat music, though, because in an MMO that just becomes too repetitive, no matter how great it sounds. Instead, I’m focusing on the major encounters, trying to make those as exciting and engaging as possible.
It’s crazy to realize that some of the sound effects Conor made for me over a year ago haven’t made it into the game yet! I really have to get animal taming and necromancy into the game. And will soon! I postponed them while I work out some issues with pet logic (and the falling-through-the-ground thing), but those are mostly figured out now.
All the details are coming together: the first “epic boss” I’m implementing is Khyrulek’s True Form (the place where there’s just some “Placeholder Bosses” right now). It’s where I’ll be testing out the new Epic Boss Music. And the reward for beating Khyrulek is access to the Necromancy skill. So I’m expecting all of that to make it into the game this month.
(This blog post went on for many more pages, so I’m breaking it up into two posts. I’ll put the other half up Wednesday. It’s about crafting changes.)