I have written 200 blog posts on the development of The Imperial Realm::Miranda. It turns out developing an MMO is a complicated business!
When I started the blog back in November 2009, I wrote:
I'll state up front, I realize how ambitious a project an MMO is. Even a small MMO is huge, I get that. But I still want to try. Chances are at the end of my time on the project, there will be nothing resembling a game. I think the value here will be what is learned along the way.
While what I have learned has been amazing and valuable, the biggest benefit has been the opportunity to watch my little girl grow up in person instead of over Skype. Developing Miranda has been thousands of late nights, constant budget analysis, a small fortune, stress - and a much closer relationship with my wife, who has been amazing in her support of Miranda. Miranda is a game. We built her and I am thrilled.
I kind of wish I had a big announcement to make to celebrate this milestone, but if you've been following along you already know that I have a trailer and some big game features still to finish... Pre-Alpha Release 4 will be out by New Years. There, nailed it.
[New Lightning Gun - Note the weapon flash at the target.]
Speaking of the trailer, work continued on weapon effects this week. The first effect I wanted to add was a flamethrower. I figured out the size of particle I wanted, figured out how many particles I needed to emit every second so that there would be enough particles to make a continuous stream from gun to target, created a simple fire texture and off it went. What I got was a few fuzzy blobs flying between gun and target. Headsmack! Particle emitters are updated each frame, debug mode is sort of slow some frames, so I was getting three or four clouds of about 80 particles all on top of each other. So I tried it again in release mode. At full frame rates the effect looked much better, but it still wasn't the perfectly regular stream effect I wanted. What I needed was a feature that would figure out how long it had been since the last particle emission and figure out where the particles should be if they had been emitted at the right time. The actual mechanism for this is quite simple, just add velocity * lateness to the initial position of the overdue particles. It turns out this works like a charm and I now have perfectly regular particles even in debug mode.
I wanted to have a burst of flame when the flamethrower strikes the target. Unfortunately the flame burst happened as soon as the fire left the gun muzzle. I had already added particle effects at the weapon target, but what they were failing to take into account was the weapon transit delay. I added that in and it worked great - as long as the attacker was really close to the target. When the target was far away it didn't work at all. It turns out that when the target was far away, the transit time was longer than the time between shots so each new weapon burst reset the delay timer resulting in no effect at all. Adding a queue of scheduled effect times solved the problem. I bought some nice fireball spritesheets from the Unity Asset Store and done.
Next I wanted to add a machine gun with a spray of muzzle fire. Oops, muzzle fire always shoots left. I needed to apply a lookat transform to properly orient both sets of particle emitters along the line of the weapon track. I used the same cross product trick I used
to orient tanks on the terrain. I used the weapon vector as forward
, plus a (0,1,0) up
vector to orient the particle emitter.
I bought a new spritesheet fire animation (Unity store again) to use as the muzzle flame. Once I had that I realized that with particles that lived variable lifetimes, I didn't have a way to make sure that no matter the particle lifetime, it would play the entire fire animation from fade in to fade out. I needed another new feature: the ability to calculate animation playback speed based on animation frame count and particle lifetime.
The fire animation came with some more nice fireball animations, so hopefully I can find a use for those next week.
Beam weapons in the game were rendered using two rectangles oriented in the shape of a + sign. That worked alright for the laser beam, no matter where you looked at it you saw the beam, but that was because the beam texture was perfectly symmetrical. This didn't work too well for the lightning - two lightning beams were visible simultaneously. The obvious solution was to change the beam to an axis-aligned billboard that faced the camera. Ugh, math.
I struck out with an evening of Google research on how I might do that. Next day I spent the morning doing other stuff while I thought about the problem. Suddenly I realized I could use the same lookat trick as I used on the particle emitters! Beam is forward
is from the start of the beam to the camera! Easy peasy. Beams look great, cross product is the coolest thing ever.
Guild Wars' Server Tech Talk
An 8 hour video
of this weekend's Handmade Con
has been posted on Twitch. Most of the talks are interesting enough, but the networking talk by Pat Wyatt at the 4 hour mark particularly piqued my interest. He offers a lot of good details on how Guild Wars was built. If you're building an MMO it is well worth the hour. I was quite encouraged to discover that a lot of the design decisions I've made with Miranda are the same ones they made for Guild Wars. Unfortunately at this point I don't believe Miranda will be able to have the zero downtime that Guild Wars enjoyed. Such is the price you pay for a non-sharded world.
(P.S. Actually this is post 202, I noticed a teeny bit late.)