How EVE Online deals with 3000 player battles

I read an interesting article about how Eve Online handles the server load caused by an unusual high number of players in the same area.

Their main trick is to slow down the gameplay when the server is overloaded (likely by reducing the number of ticks per second on the server). I could easily do the same, I just have to modify a few places where I assume that the tick rate is globally identical and I would have to inform the client that everything now moves slower. But I wonder if this would really reduce the load much in my case, because I assume that a player which has more time to do things will also try to do more things, and they will still send move- and action commands with the same real-time frequency.

Another thing they mentioned is the ability to temporarily move areas from a weak cluster machine to a dedicated server with much stronger hardware, but unfortunately this has a critical implementation flaw: It disconnects everybody on the server. It also doesn't happen automatically and needs to be triggered by an admin.

Currently my game is not cluster-ready, but in the long term I plan to make it possible to put each map instance on a different server, preferably fully-automatic to keep the administrative overhead low (I keep this in mind, but I won't do anything in this regard until I have a player base with a size which actually justifies the effort). When I do that, I should look into making it possible to also transfer the running instance together with its players to a different server, preferably without them noticing and fully-automatic.

Procedurally generated shop content

Item shops can now have procedurally generated stock. I also improved the user interface by adding scrollbars to shops, showing the rarity as the item name color and adding tooltips. Shopping now works adequately.

Selling implemented

I added the selling gui. Now all that is missing for the item milestone is stack splitting/merging and tooltips in the buy- and sell GUIs.

By the way: I need to fix the price calculation of spells. The high-level ones should be a lot more expensive. But in order to do that I need to come up with a wealth-per-level formula to make up good prices.

Wisdom capacity implemented

I was already considering to can this feature just because I didn't find an elegant way to implement it on the server  (bad software developer), but I finally found a nice way to do it. The purple bar below the quickbar now shows how much wisdom capacity your character is using.

The amount of different spells you can have in your quickbar depends on your wisdom stat. Currently you can switch you hotkey assignment anywhere, but I plan to restrict this to towns, so you have to choose carefully which spells to assign before wandering into the world. That means a high wisdom stat is a prerequisite for a wizard who wants to be flexible.

Each spell uses level / 10 + rarity wisdom capacity. That means that rare spells use a lot more capacity than common spells.

Rest system number crunching

I did some more number crunching with the rest system, and noticed the two constants which are most important:

1. the base of the logarithm
2. the reduction factor per minute

The reduction factor - how many percent of rest the character loses in each minute where it does something exp-worthy -  is most important to define the "cutoff duration" - the length of a play session after which the exp bonus becomes negligible. Due to the exponential decrease it doesn't matter much with how much rest a character starts out. This affects the duration just by some minutes. A reduction by 1% makes it possible to play from dawn till tusk until the bonus falls below 1.5%. A reduction by 2% gives you an afternoon of good exp. With 3% reduction, it's about an evening. When I put it up to 10%, the fun is over after less than an hour. When I set it to a whooping 50%, you burn through your exp bonus in 10 minutes.

a lower base of the logarithm makes the rest system more effective overall, especially after longer breaks. The lower the base of the logarithm, the higher the rest bonus a character starts with after a break.

Rest system implemented

I implemented my rest system the way I described. I still wonder if my rest formulas weren't a bit too conservative. I feel like my character should have more rest bonus after 4 offline days. Especially considering that a character which rested for 20 hours already got a bonus of 2.1.

On an unrelated note, I am making good progress with the animation system. The engine should be ready for turning and animated sprites soon.

Selling implemented

I implemented selling on the server-side. I actually did several days ago, but I forgot to post about it. Now I just need a GUI on the client for selling.

The day I discovered context.shadowBlur

Today I discovered the canvas shadow effect, which can be used to create a glow effect when drawing shapes or sprites. I used it to make the range marker look a lot better and to add a highlight to the object which is currently under the mouse cursor. The latter is an important usability improvement, because without it, it was really hard to pick individual objects when there were multiple ones overlapping each other.

Range marker and damage types

When the player is selecting a target for a spell, the range of the spell is now displayed in form of a circle. This is an important usability improvement, because there was no indication which targets are in range and which are not.

Another usability improvement I added, are damage numbers which indicate the element of the damage with their color. Also, ethereal damage is now shown with a "mp" suffix and healing with a "+" prefix.

I added a rotating heptagram to the circle as a little gimmick. I am not sure if I am going to keep it. It seems distracting without adding much.