Kevin Jenkins' Blog

Blues News was awesome enough to post a news link to my alpha, and I got 30 new testers signed up today. I owe them a big thank you because like 10 other sites I sent the news to ignored me. I need to reach a critical mass of about 500 testers at which point I think word of mouth will take care of the rest.

I think tomorrow I can let everyone in at once so there will be players online throughout the day.

I’m trying to find more testers for Galactic Melee. Originally, I was going to go with a small team of like 10 guys. But what happens is someone will check in once a day or so to see if someone else is online. Since this kind of game is totally multiplayer, there’s nothing to do with nobody else around, so a few minutes later they leave. As a ball-park estimate I need about 100 testers such that at any given time someone is likely enough to find enough players to stick around. Since my map is so large it’s not worthwhile unless there’s really 8 or more guys online.

Right now I have maybe 10-20 testers actively looking to play. So today I did a bit of marketing and tried to hit some game review sites for a news link. If I can just get one good link that will solve the problem.

I need to reach a critical threshold of playerbase and awareness to launch. After that point word of mouth will take care of the rest of my marketing.

Galactic Melee is turning out pretty well.

From the game side

Graphics: All positive compliments My goal wasn’t to make the best looking game in the world, but to make something marketable, and in that I succeeded.
Performance: Every one I’ve tested with has gotten over 60 FPS even with lots of bullets on the screen.
Sound: DSonic did a good job for a fair price. The game still needs tweaks and polish but I have no complaints.
Music: I bought a few songs, they are all pretty good. My original goal was to get something very memorable and distinct (like the SMB music, or Zelda music, or Star Wars music). While I don’t have that what I have is good enough. By buying premade songs I saved a lot of time and money and got something higher quality than I likely would have through direct contracting.
Gameplay: Most of the features I wanted have made it into the game. 5 game modes, about 20 items + weapons, a leveling system, and a database to store stats. The only major missing feature is the command screen, where you could give orders to your fellow pilots. However, I don’t see this missing feature as losing sales. It’s still to-be-seen how people like the game design but since I control this it’s not a major risk factor. Peer to peer voice chat is also missing but it’s also not an issue that will lose sales.

From the business side:

Website: It looks good, but lacks content. I think with content it’s good enough to drive interest, which is the whole point.
Cost: Massively overbudget and over time. On the other hand, if the game does well it can make it back. This is the risky part. I’m definitely out of time and money so it’s time to ship or die.
Art development: Late, overbudget, but things got done in the end. This was in large part because I learned how to do everything myself, so was able to and did fix everything.
Programming: Late, overbudget, plus had incredible difficulty finding good people. With the exception of my excellent programmer in Portugal, I was consistently disappointed. As with art, I eventually had to learn how to do everything myself, and was able to and did fix almost everything.
Marketing: Big risk point, we’ll see how well word of mouth does. I believe that marketing is what businesses do to deceive people into buying products that are not good enough to sell themselves. Plus, I don’t want a million customers at launch because I’m not able to support that yet. I’m looking for a few thousand sales to pay for further development before really branching out.
Server hosting: Hypernia‘s service was mixed at first, but once they moved their data centers things got much better. Now that they know I’m going to be a huge customer the service is really good. I have a game server and a database server and it’s easy to replicate game servers.
Billing: Aria is helping me here. It’s a good service because developing a billing system is more than just taking credit cards. You have to provide a way for users to manage their accounts, it has to be secure, and you have to be verified by various third parties. It would cost so much to do all that it wouldn’t be worth it for small games. Word of advice: I got very bad service from my original representative, so asked for another. I then got very good service. Don’t assume the service you get from one guy is representative of the whole organization.

All that’s left to do is get the game running bug-free, polish it so it’s fun, and then hope people like it and draw in sales.

My “slippery tail” interpolation worked well for rotation. Rotation has no inertia (start and stop immediately). The magic number to lag behind is half your ping to the server. This definitely wasn’t obvious why and it took me an hour of thinking to really see it.

It doesn’t work for position. Theoretically it should work, but in practice small errors in timing, ping variances, and high latency all cause failure. On the front side, when I am finishing a prior interpolation, if my new extrapolated position doesn’t match exactly, I get a position warp. This happens easily from ping variance. On the back side, with very high pings the extrapolated position differences are so large it just ends up looking like a warp.

For position I’m trying what I call trajectory intercept interpolation. When the datagram arrives I store the current visual position and physics velocity. The start interpolation position is where you would normally be (visual position + original velocity * elapsed interp time). The end interpolation is the intercept when we stop interpolating (real position + real velocity * remaining interp time).

This method doesn’t jerk (jerk is a change in acceleration) which I do get if I were to not count original velocity. It also gives me an accurate visual position. Hopefully it will work.

Other problems fixed:
PhysX jitters using fixed timesteps. Fixed by changing to variable.
Stopped using per-datagram timestamps. Just use half the average ping. This also removes a potential cheat.
I was previously allowing you to accelerate past your maximum velocity, then clamping the next tick. This caused inaccuracy. Now I have to duplicate the physics calculations and determine the force to apply to make you reach your maximum velocity exactly.
Previously network packets were processed after the tick update, so clearing acceleration didn’t take until one tick too late, resulting in slightly too high velocity.

These bugs were massively difficult to find. This has been a very painful day.

I’m having a problem with high latency players jumping around a lot.

Originally, I would extrapolate your position when a message came in. I would then do a lerp over some fixed amount of time between your current visual position and your new extrapolated position.

This is accurate in that you see where the object currently is. The problem is that when you suddenly change directions there is a hop.

Suppose I am moving y+10 per second and 100 milliseconds later I move y-10 per second. If the sender’s plus my own latency is 1 second, I would see that object 10 units up, then 100 milliseconds 10 units down. A huge hop.

I thought about this a long time and I came up with what I call slippery tail interpolation, although likely this isn’t novel and there’s a real name for it. But it just gives me the impression of holding onto a snake with oil on its tail and the tail keeps moving around.

I keep a transformation history of your position, orientation, and velocity for the last second. I also locally update your transformations based on your current velocity, acceleration, and rotational velocity. However, when a network message arrives, this negates part of the history (the slippery tail). So I recompute where you should have been over that amount of time, and rewrite history. My movement is complex, with a maximum velocity and a constant rotation which changes your thrust angle. I can’t think of any mathematical way to calculate your final position, so I just integrate over a fixed timestep.

Visually, I lag behind by half the sender’s average ping plus half your own average ping. This is the edge of the tail, just before the slippery part. So as history is rewritten, it is not likely to change what you see, only what you will see, and hence there is no popping around. However, if due to ping variances a message is so far in the past that it changes what we see, then I do linear interpolation.

Hopefully this will work. The hard part is going to be testing it. I’m also a little concerned that if you see everything slightly in the past it’s going to make gameplay less accurate. I might have a tweak where I move up the tail a bit so there’s some hopping but then visual positions are more accurate. Another possibility is to hit detection based on your past state.