## I couldnt sleep – Hyperdrive

It might be the 4 espresso drinks i drank earlier. But i couldn’t sleep. My brain was chewing on ways i could do a hyperdrive.

The idea is like .. a condor? big bird, floats on drafts/currents. Starts off on feet and wings, expends a bunch of energy getting up into the air, but once its there, it floats.

So, earlier, i wanted thrust in a direction to keep on building velocity. I would make it encounter a kind of resistance that goes up, so that there’s a terminal velocity that gets approached. Lets call that V=1.

Upon getting to that V=1, you kick in the … insert science fiction name here, but its the “flapping” part of getting flying. Say it kicks you into hyperspace, at V=1.3. If you get below V=1, you exit hyperspace. Maybe its the Hyperspace actuator. You can get better hyperspace actuators.

In hyperspace, there’s a different engine available. Its a directional “push” – you can push against what would normally be gravity sources in normal space. The closer the thing, the better the push. you aim your pusher beam against the target, and apply push power. This speeds you up well beyond into much better V’s.

However, there’s “friction” in hyperspace .. probably map-based. I’d probably do it as a function of how close you are to a star .. basically gravity wells have cleared out the friction stuff. So depending on where you are, you slow down. If you go far away from all stars, the distance to the stars = less push, and friction, makes it impossible to stay in hyperspace.

Would have to play with the numbers, but lets say that it would take 10-30 minutes to get between most stars at V=1. Lets take the 30 minute case, D=30 between them. Assume stars have mass M=1.

1. Line up your current star with your destination star. Speed up towards your current star, getting to V=1. Gravity pulls you in as well. Beginning your run as it were.
2. When you get close enough to V=1 kick in your hyperdrive actuator to boop over to hyperspace, maybe at V=1.5
3. Pass through/past the star and then use your hyperdrive vector engine to target your star, and push against it. At distance D=1, you get a nice M/D push of 1 bringing you up to 2.. i did a quick excel thing to expound on this …

I lost my bullet numbers. I get a transit in T=10 instead of T=30.. I’ll probably have to make more oomph available at longer distances, so its more like a pole, but i really wanted it to be “if you’re caught between the stars, its hard to get oomph.” Also, with the above setup, your max distance from a star works out to about 60-70 units if the star has mass 1.

If i change it to be Mass/sqrt(distance), i get still 4 minutes, but the distance greatly increases. Hmm.

But, anyway, that’s the idea. As you get close to the target star, you push against it bringing your velocity back under V=1 and you pop back into normal space. And avoid those “dense” areas where max-v is lower if you want to float longer.

Okay, now maybe i can sleep.

## Space Mud/Game Ideas

Long time no update .. a codebase. https://geekygulati.com/2016/03/12/dotnetmud-spacemud-optimizing-network-traffic/ is when I talked about it last.

I was playing Starcom Nexus, and it reminded me that once upon a time i was playing with flying a ship around in gravity. I looked, it was 7 years ago. I cloned it, I updated it, I ran it. I was amazed.

I’m not going to kid myself with “I have time to work on this” .. but, if I did, what would I make? This is like “If I win the lottery”, giving space for some creative stuff to sparkle. I would have planets that (slowly, unrealistically) orbit their stars.

I would have planet and sun gravity that draw ships in

But the ships won’t crash against the planet. Instead, there will be a “autopilot” bump that happens that assists the ships into a non-crashing orbit over time. (so a few times they’ll go through the planet, but eventually would end up orbiting)

ships can do a “land” feature if they are close enough to a city, goes into an automatic “shrink into the planet” type of thing. At that point, the game switches over to text mode of having landed, getting out of the ship, n/s/e/w to visit whatever places.

At first i wanted real thrust type stuff. But that can be very unmanageable.

So make it manageable. Choose an object to travel to. Accelerates towards, the decelerates. Can be planetary. Can be a ship. Different levels of autopilot around this can be purchased. Fuel cost for the big accelerations, free small ones to prevent stranding. Standard given autopilot = bring self to a stop relative to object (so you can end up at your target)

But i don’t want acceleration to be good for interstellar travel. Not without putting in 10 minutes of game time or more. For that, i want a hypertravel mode, but with a twist:

In hyperspace mode, gravity is inverted at d^5 or something silly like that. So to send yourself to another star, you get close to your current star, switch to hyperspace, and get catapulted out that way. If you aim wrong you can still use your hyperspace drives to point yourself in some direction, but they can only slow you down or speed you up to some absolute value. (the stellar launch can exceed that value). spend more money for better vectoring and acceleration and maximum controllable velocity. You would learn about stellar launch the hard way, you could just go into hyperspace and start accelerating towards a star.

So you would theoretically line up against a star, go into hyperspace, get catapulted, get close, and if you did it just right you would get slowed down by the target star but if not you would drop out of hyperspace somewhere around your target star. You drop out of hyperspace only when your hyperspace velocity gets slow enough.

The rest of the game would be similar, i guess, to Starcom Nexus. You visit planets, you solve things, you get resources, you fight baddies, you mine stuff, etc. That’s the game built on top of the above. Except that planet visits are text adventures.

I’m writing this from a hotel in Phoenix, where i’m on vacation with my wife. Its only taken .. 2 days? of vacation time, to get my brain clear enough to where this stuff starts coming up for creativity. yay!

## dotnetmud: spacemud: optimizing network traffic

I spent some time getting the network load produced by the game down.     The rest of this post, I test out the changes to see how much better everything became.

## Methodology

Two ships connected; I’m going to leave their starting locations as random.  I’m going to have them turn in circles and constantly fire.  This will yield some explosions against the planet, and others against each other, but most of the missiles will be flying out into space.

Running against a deployed web server in the cloud

Using WIFI and my home internet connection.

Collecting data via portal.azure.com’s App Service Monitoring graph set to minutes.  (This didn’t work, I had to go with my local wifi connection)

### https://github.com/sunnywiz/dotnetmud2015/tree/chatty1

This is where we started at.    Sample packet and network load:

### https://github.com/sunnywiz/dotnetmud2015/tree/chatty2

The main change was to give custom JsonProperty names, as well as to reduce the number of decimal places being transmitted.

I use Decimal  instead of Double because in double’s, there’s a chance that the underlying representation isn’t quite so digit friendly; decimals are exact for every digit.  However, decimals are harder on the processor for doing math – supposedly.   I haven’t tested that.

The result:  Not too much better.   5.5 MB came down to 3.1MB on the receive side.

### https://github.com/sunnywiz/dotnetmud2015/tree/chatty4

chatty3, which I’m skipping, changed the method signatures to two-character method names.  Not too much saved there.

chatty4 added “blanking out” data that doesn’t change much.  It does this by keeping track of what it believes the client thinks the state is, and doing a diff:

In order to pull this off, I had to go to a dictionary of objects to render, rather than an array.   I also kept a “full” frame every 10 frames, similar to MPEG encoding G vs I frames.

I thought I’d get fancy and send nulls if various values (DX, DY) had not changed (for example, they do not change for bullets) – however, JSON sends a “:null” which can be longer than just sending the value.  The more advanced version of “don’t include the property if it hasn’t changed” is possible, but it got too complicated, so I ignored that for now.   So this version only does the image and name attributes, but that’s enough to get a nice reduction in size:

The savings:  another 30%.  Its still a lot of data.  Not quite the gains I was hoping for.

At this point, an average entity on the screen is taking 100 bytes or so, instead of the 500 they were before.

## Network Optimization: Where to go from here?

I’m going to call this good enough for now.  The directions to go from here for network optimization:

• Instead of using the system JSON serialization, write my own serializer.   This could do things like “If It hasn’t changed, don’t send it”.
• “dx17.109dy299.512id341r446.7x37y1474.8”   that’s about half the size.   But needs a lot more code to massage it.
• Could use a binary packing method as well.   Quick search doesn’t find anything that is happy in both C# and Javascript.
• Put some logic in as to whether something needs to be sent every time or not.  For example,
• bullets pretty much go in a straight line once fired.  They don’t need to be sent every time.   In fact, if the current X,Y is approximately where the previous update X,Y + DX,DY would put it, then there’s no need to send those values.
• Planets currently don’t move. (That will change).      This is a broader case of “nothing has changed in this object from what the client expects, so just acknowledge the object still exists, nothing more”.

## What’s next?

I think that authorization / identity of clients (and dealing with disconnection better) is in order.

Then I can do the “single person logged in, multiple clients” code

And then we can launch a spaceship from the text game.

And then we can design an actual playable game.   (oooo!)

## dotnetmud: spacegame: Timing Loops 1: Client / Server timing loop

I feel stalled in my project.  It might be that I need to write about the important stuff done so far before I continue to redo/optimize the game; setting the stage to understand the need for some of those optimizations.

Reference code for this post (tag): https://github.com/sunnywiz/dotnetmud2015/tree/blog20160302.

The playable game (which might be updated, not frozen to this post) is: http://dotnetmud.azurewebsites.net/Home/SpaceClient

Game state at this time:   Multiplayer, can shoot missiles, missiles hit things, score is kept.

## Client / Server Update Loop

I made the client “in charge” of this.  Starting in Javascript, the client requests an update from the server:

Along with the request for game data, the client is also sending the state of controls for the user.  I went with “how many ms has the thrust key been pressed” as my input – there’s a separate set of handlers which watch key-up and key-down events and long how long keys have been pressed for.

This then travels up through Signal/R, and shows up at the server 20-50ms (an eternity) later:

The SIgnal/R side of the hub takes the connection, looks up which server-game-object that connection is tied to, and asks that game object (which happens to be a Ship.cs) to craft what it thinks the world looks like.

The Ship has several things it has to do.

First is to look at the keypresses and turn those into thrust amounts.  I went with a % of thrust:

There is similar code for “can I fire another missile yet” (not pictured).

Then, it makes a copy of all the stuff that the client needs to draw the world:

It records itself, all the other 2D objects in space, some scores, and what the current “Server Time” is (and rate of change of server time, which is a YAGNIY for when the server gets overloaded and has to go into bullet time).

It packages all that into a return (of type object, which gets JSON-serialized), and SpaceHub happily sends it back to the client:

Then, 25-50ms later (another eternity), the client receives the game-update:

• Green – the client updates what it knows about what’s going on on the server.   I tried to keep this in its own “object space”, to indicate that the server is the authority here.
• Blue – the client updates various things that are of interest to the client
• Purple – there’s some bulk copying going on that isn’t very sexy and is very network-inefficient.
• Red – and the client immediately requests another packet.

## Places to Improve: Network Traffic.

The server sends ALL the data, ALL the time.   A network packet looks like this (raw, pretty printed):

There is a LOT of stuff in there that is needed once (like image URL’s), and then does not change.   Also, many property names, while nice for humans, is not optimal for network traffic (words like “ClientREquestsPollFromServer”) for example.

“No Big Deal?”  — Doing a test, holding down the fire button and shooting the planet, for a few minutes, in Azure Data:

Doing some math:

If I have a successful game, and there’s about 1 combat going all the time, we’re looking at \$18 per month.

The solution for this is to only send diffs across the network.  That’s on my list for pretty soon.  But it will require some hand-crafting detail.   And some before/after testing.  This will be its own blog post.

## Places to Improve: Network Lag

This model is similar to how Kermit used to work – there is a LOT of dead time between updates.

One way to improve this might be to have the client keep track of the lag between server updates, and then, in its request to the server, ask “please give me additional packets at the following times, until you hear from me again”.    So, the server could send 2 game-updates for every 1 client-inputs-update.     Its on my list, sometime after sending diffs.   Have to be careful and mark the intermediate frames as intermediate, so that only the major frames cause the cycle to continue.

Another direction we could go is completely decouple the client-input from the server-response.   I’m not going to do that, because I like how the client has to constantly remind the server of its existence – if the client goes haywire, I don’t need to write additional server code to detect that and shut down the server sending stuff to the client.   I’m also lazy.

## In Conclusion

So, there’s the ugliest timing loop in the game so far.   The other two are relatively easy, may not get written about soon.

## dotNetMud: Its Alive! (on azure)

From there you can either get into the old-fashioned text-and-chat mud:

(Valid commands are who, look, shout, say, and east and west)

Or you can get into the space-mud side of things:

(Valid controls are W for thrust, A and D for rotate)

Neither of these are really interesting until you have more than one client (browser, tab) logged in.  In the case of the latter, perhaps from different computers, with different network speeds.

Corresponding source code:  approximately here (as of these screenshots):  https://github.com/sunnywiz/dotnetmud2015/tree/blog20160220

## Where to go from here?

I could try to make the space game more fun – adding missiles and lasers.   More realistic game.   You can’t have a space game without combat.. can you?

I could try to make the space game more single-player interesting – adding gravity, multiple planets. (your mission: try to get into orbit around a planet).  This lends itself to “more realistic server side computational load”.

I could try to make the space game more efficient – optimizing network traffic (right now, VERY large messages).

I could try to make both clients work better – by having “session” be the unifying factor, and the text game launches the space game, both in the context of the same player object, somehow.    This would probably involve hooking up to a database for persistence of user information as well.    This is complicated…  this is probably where I should go if I’m focusing on the “sample game” side of things.

I could try to make space more interesting – by voronoi’ing it, so that it can have 10000 or more objects, but its very easy to find the objects that are within, say, 100000 units of you.   So that I can do hyperdrive between star systems that you can drop out of and be in the middle of nowhere.  Also complicated.. probably comes after multiple planets.

I could try to stress test it – get a bunch of computers attached to it, see how it performs on the azure side.  I have it running on a Free web-node at the moment, and its surprisingly happy – 1.9% CPU.

## DotNetMud: SpaceGame: Autopilot

After an aborted run at Rares Trading in Elite Dangerous (idea: pick up rares, go to Fehu, sell them, and then pick up missions there.  Problem: takes many hours to get enough worth selling), I took a look at writing an autopilot in my javascript space game (the part that is not yet Mud-like, but I intend for it to be).

Nice: Javascript has a Math.atan2(y,x) which _possibly_ avoids the x=0 problem that normal Math.atan() solutions do.  (arctangent gets you the angle to something so you know where to point the ship).

However, my code doesn’t work.  My ship very often points AWAY from the target, and applies FULL THRUST FOREVER.  This is NOT how you go somewhere.

There’s another aspect – I’m simulating “keyboard control”, ie, IsThrusting, IsLeft, IsRight.   For the ship to feel responsive when playing the game, need to have good numbers for these.  But with autopilot, there’s a lot of jigger (LRLRLRLR) because it continually overshoots its target.

So, here’s what I have to do for the relatively final solution:

• Set up the ship so that there’s a finer gradient of control.
• What I’ve seen other games do is, the longer you have it pressed, the more thrust you get, up to max.
• This means I need to swap out my current keyboard handler (keyup, keydown) to change to a dictionary of “when was it pressed”, so that I can calculate how long its been held.
• Or, I could go with W = 12.5% thrust, Ctrl-W = 25%, shift-W= 50%, and ctrl/shift = 100%.  Almost 8 stops.  More instantaneous full thrust available.
• I want to avoid something where the autopilot can take a shortcut that’s not really available to a player.   So if I did the slow build up, I’d have to have the autopilot also do a slow build up.
• Change how I do the maths for the autopilot.   Inputs to autopilot:  Who to go to, and what distance to orbit them at when we get there.
• I see a few major layers.
• First one is “close the distance”.   This would use the calculation of … http://physics.info/motion-equations/  … ouch, my brain hurts.   Basically, I need to find a solution for:
• If I start at the orbit distance, and accelerate away at 75% thrust, what velocity am I at when I get to my current distance away?   Reverse that.  That’s the velocity towards the object that I want.   Call that V1.  I want it to shut off as I get close to the destination so that orbital stuff can kick in.
• Second one is orbital force.   Skip this if I’m more than 2x the desired distance.
• Figure out if I’m going clockwise or counter clockwise from the destination.  OR, just assume one direction for now.  clockwise.
• Figure out the vector I need to be in a perfect circular orbit around the object at the desired distance.   Magnitude is known (previous post on orbital mechanics has link to the article), and Direction is 90 degrees from where the destination is.
• That’s my desired vector V2.
• Combine V1 and V2.  This is my desired vector V3
• Look at my current vector V4 and figure out the change that needs to happen V5 = V3-V4.
• Do a left/right thrust as needed to point me at that vector (do a smoothing function here).
• if I’m pointing in relatively the right direction, do a thrust along that vector (do a smoothing function here).

This could be really fun.

Image: wikipedia