6 replies to this topic

[Celledor]

Hi,

I'm working on a design document for a MMO Manager Game (you will manage your own civilization of aliens) which will take place in a galaxy where every player will create their own race and start with thier own homeplanet in thier own a solar system and the build an empire.

The only grafical stuff will be planets, stars, asteroidbelts, spaceships etc. and a GUI. Battles (that can take on groud, in space, underwater etc.) will not be some kind of RTS, they wil be simulated and the player will only set the overall strategy. There will be no limit on the amount of ships or players in the same battle.

How will this differ from say an MMORPG if we talk Server - Client traffic and data that needs to be sent/recived? My guess is that its much less.

How may player can a "cheap" (50-100$ a month) dedicated server handle with a game like this? I know it depends on how the game is made but lets say it is made in a good way (when its done) ;)

I know I give little info but I'm still in concept stage and working on how the game play will be, but I'm still interested on the other practical stuff. I tried to search on MMOs but all info I find are on MMORPGs not on a manager type game (the game is more or less just a GUI with nice 3D rendered planets and stuff).

What techniqes will be most suited for a game like this in tearms of protocols, should I use UPD or TCP/IP etc.

[ville-v]

You may use TCP instead of UDP since it is way simplier and that game does not sound like +1 ms here and there would matter player at all.

If your maps (planets etc.) are client side, there is no need to send information on those to the clients. If you want moving planets and such, then you have to send obstacle locations to client, which means you will spend more bandwidth as opposed to MMORPG that has static maps. ( Or do you mean player does not see anything else than his planet and does not command anything real time, like in oGame? In such case the bandwidth will be lesser, unless it is browser based (like all multiplayer strategy games of that kind I have ever heard of) and you send complete pages in HTML. )

Chat and sending locations of other players will be in your game, right? Most likely it will not make difference to any other MMORPG.

If battles are not real time and not even shown to player, that means you have to send less information on other players (no combat stances, no spell casts, ( no need to show stats like health? )).

If you will not send battle results in raw texts but develop instead some tighter way to send them (I mean, not sending constant string parts like "Battle was won by: " as they are same for all such messages), you are saving a lot in this. But if you have dynamic environment, you might be losing more you gain, but that does competely depend on how detailed the world will be.

[alphadog]

Celledor said:

How will this differ from say an MMORPG if we talk Server - Client traffic and data that needs to be sent/recived? My guess is that its much less.

Your guess is correct. If you do not traffic 3D data, the amount of bandwidth need drops drastically.

Celledor said:

How may player can a "cheap" (50-100$ a month) dedicated server handle with a game like this? I know it depends on how the game is made but lets say it is made in a good way (when its done)

The main problem is bandwidth, not so much processor, in your consideration of operational costs. But an average "today's" COTS server for a 3D MMORPG seems to range from 1000 to 4000 concurrent users, and is highly dependent on a ton of factors such as architecture, code quality, the server's configuration, etc... You could theoretically see more than that for your "simpler" game.

Celledor said:

What techniqes will be most suited for a game like this in tearms of protocols, should I use UPD or TCP/IP etc.

TCP. UDP can be tricky, esp. for a beginner. Most current games use TCP, or a mix of TCP/UDP. The latter is found in the more "twitchy" kind of games, where movement and position data is flying like spam. Given that your game as stated is not of this type, TCP would be probably better.

As for the larger question of techniques, that's waaayyyy too open-ended a question for any answer to be meaningful!

Also, you may be starting a little low with that POV. What platform will you use for your servers? Windows, Linux, something else?

[alphadog]

alphadog said:

TCP. UDP can be tricky, esp. for a beginner. Most current games use TCP, or a mix of TCP/UDP. The latter is found in the more "twitchy" kind of games, where movement and position data is flying like spam. Given that your game as stated is not of this type, TCP would be probably better.

To add, as I understand it, most high-demand, stable MMOs use a custom UDP solution. For example, WoW has moved from TCP to TCP+UDP to help manage their scalability. UDP allows the programmer to better manage which part of the communication gets some level of control, like sequencing of packets or congestion control. On the flipside, if you don't what you are doing in, you can end up with a horrible custom UDP solution.

In your case, this does not seem as stringent an issue, though.

[Celledor]

ville-v said:

If your maps (planets etc.) are client side, there is no need to send information on those to the clients. If you want moving planets and such, then you have to send obstacle locations to client, which means you will spend more bandwidth as opposed to MMORPG that has static maps.

Planets and systems are procedurally generated (the client recives a code on how to generate them) and no more info is really needed to be sent unless new planets and such are added (but this will be fixed in patches). Planets rotate around the sun but this is just a vísual thing and can be done client side (perhaps is is syncronized at startup). Information on what is built on planets, moons, asteroids etc. who built it and info like that is the main thing that is needed to be sent, but only for planets that are being viewed by the player.

ville-v said:

...Or do you mean player does not see anything else than his planet and does not command anything real time, like in oGame?...

The game will be similar to oGame but will incude much more and as a downloadable 3D game (but no 3D data is needed to be sent as you don't move around). Almost nothing is done real time. The player gives commands and orders. Ships do travel between planets but I don't think this is anything you will actully see, more get info on when they arrive, how it went etc.

Battles will be simulated, and the players can see the simulation but I think this will only be a visual thing. All players (clients) that are in the battle will simulate the same things. But unlike oGame you can set strategies and tactics for the battle.

alphadog said:

The main problem is bandwidth, not so much processor, in your consideration of operational costs. But an average "today's" COTS server for a 3D MMORPG seems to range from 1000 to 4000 concurrent users, and is highly dependent on a ton of factors such as architecture, code quality, the server's configuration, etc... You could theoretically see more than that for your "simpler" game.

Thats interesting, if I get a dedicated server can it be customized to my type of game? To get more bandwidth.

[alphadog]

Celledor said:

Thats interesting, if I get a dedicated server can it be customized to my type of game? To get more bandwidth.

Avoid the need to customize a server. Concentrate on the game design and optimize there first. Create a game that 1) optimizes how it communicates, and 2) is scalable over multiple cheap machines based on need. In that order.

[Celledor]

alphadog said:

Avoid the need to customize a server. Concentrate on the game design and optimize there first. Create a game that 1) optimizes how it communicates, and 2) is scalable over multiple cheap machines based on need. In that order.

Ok...

The game will (atleast in thought) be devided into diffrent galaxies where each galaxy is its own server.

But is it much extra work (problems) to allow a player to own planets in more than one galaxy (server). I still want the galaxies to exist in the same universe and not just be a copy that can't interact with the rest.

This will give a more real feeling to the game and also act as a part of the story by itself. New galaxy-gates are opened to new domains to be explored and new worlds to be conquered.