An Mmo? - Really...

Published April 12, 2016
Advertisement

Well... not really.
I'm not envisioning creating the next WoW-killer.
A MASSIVE multiplayer online game is obviously outside the scope of a lone wolf as myself who is only prepared to spend a few thousand $ on assets (in the foreseeable future), and isn't able to commit to working full time on the project.

I just don't know any other word that covers a shared online world supporting hundreds (or perhaps a couple of thousands) of concurrent players.

I guess "graphical MUD" would in fact be the best term - but it might discourage players who might think it's just a shallow graphical layer on top of a text-based game - or players who don't even know what a MUD is.

So what is the vision for this game?

The technical side:
The game will be a 3D game rendered in an isometric-like view (Like Diablo 3). Unity is the chosen game engine for the client, while the server is written from scratch using C#/.Net. Performance benchmarks will determine at a later time if Mono/Linux or .Net/Windows is to be used for production servers.
While the game is rendered in 3D the logical spatial model is just a 2D plane - this simplifies a lot of server logic but of course also restrains the client - no 2 locations can be on top of each other.
The server will be fully authoritative, but the client will implement smoothening logic to hide lag to some degree.
The server code must take full advantage of multi-core architectures. The game will not be finished tomorrow. Quadcore dedicated servers are already accessible at a reasonable price - octacore might very well be the norm soon. Contrary to the golden rule of "code first, optimize later" I believe this is better handled in advance by having lock-free and low-lock concurrency in mind when developing.

Gameplay:

The gameplay will be very Diablo-like, except taking place in a shared world.
Combat will be real-time, and collision detection will be used to determine hits, as opposed to the typical WoW "homing missiles" where hit/miss is a simple dice-roll determined as soon as an arrow is fired. This means a skilled player will be able to sidestep an incoming missile.
Obviously this will put a strain on the server - but it is an important feature and if it means limiting the maximum allowable number of concurrent players on a server to a few hundred then it's a price I'm willing to pay - time will tell.
A lower player count will also increase the chances of meeting someone you've met before.
Monster density will be lower than Diablo and individual enemies will be challenging - don't expect to take on hordes of monsters (If you want to live). This is a conscious decision for gameplay reasons - although it might alleviate some of the server strain the real reason is that I want the players to be forced to concentrate on the immediate oppenents and use their wits to survive.
Powerful items are very important if you want to be a powerful player, and are mainly obtained by killing monsters or from trading with other players. Basic items that will get you through the first levels along with somewhat adequate items for higher levels will be available in shops.
Account-bound and character-bound items will not appear - at least not as drops. Perhaps some quest rewards should be personal but it's not a priority.
Trading is crucial in developing a community - therefore drops will not be tailor-made for the class you're playing.
Main "official" currency is gold. Inflation is probably something that must be accepted - I won't mind too much if the economy in player trades shifts towards bartering (think "Stone of Jordan").
Crafting is not a planned feature - although it's on the wish-list it's not important enough to delay a release.

Clans on the other hand is something I really want to see happening as soon as basic gameplay is implemented. An online multiplayer game depends on the community and I really want the game to be a place where people feel they belong.

Previous Entry Why an MMO?
Next Entry So Far So Good...
2 likes 2 comments

Comments

ApochPiQ

The server code must take full advantage of multi-core architectures. The game will not be finished tomorrow. Quadcore dedicated servers are already accessible at a reasonable price - octacore might very well be the norm soon. Contrary to the golden rule of "code first, optimize later" I believe this is better handled in advance by having lock-free and low-lock concurrency in mind when developing.

Don't fall into the trap of expecting a lot of threads to give you magical scalability.

A better strategy is to design your simulation for [i]horizontal[/i] scaling - many small areas of the world simulated independently. So one part of the map/universe/etc. might be on one thread, and another part could be on a totally different machine, and so on.

Writing single-threaded code is much, much easier and safer than trying to get fancy with multithreading.

April 14, 2016 03:54 AM
Polydone

You're absolutely right - single threaded code is much easier to work with.

At the moment the update logic - the game loop - is in fact single threaded.

Horizontal scaling - I'm not sure if we understand this term in the same way, but simulating independent areas in parallel (using a thread pool or similar of course - no need to have more threads than cores) is planned and this is what I'm structuring my model to support. I'm delaying this until I am where I want to be because working on actual game logic is much more important at this stage.

Horizontal scaling on separate computers: I don't really want to go there unless I have enough players - and a big enough world - to support this.

Parallel simulation of contiguous regions... I've done some very promising prototypical work on how to handle that situation. The structure of my code is designed in a way not to conflict with this goal but I have no intentions of actually implementing this feature until:
A: A fully functional demo version is completed.

B: I can't squeeze out any more performance from individual threads using profiling.

C: I'm sure there are actually gains to be had after horizontal scaling has been done.

D: The world size/peak player count is actually large enough to mandate this.

All database IO is being done in a single thread. The gameloop will never wait for the result of a DB operation.

Networking code is done with asynchronous IO (BeginRead/BeginWrite) and deserialization / validation / interpretation of received messages is done in the receive callback.

Operations crossing these boundaries are implemented using queues.

April 14, 2016 12:11 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement