I am about to embark on an ambitious game development. I am designing a Massively Multiplayer RTS. I wanted to get some opinions on some ideas for how to pull this off. First off, this is not a technical discussion, because I would rather not talk about the technical details of how I want to do a MMORTS, but I wanted some feedback on the interface and gameplay/resource model I envision which I list below. Before you read the details below, please consider the following problems I am having in my thought process. I want to add an element of persistence to this game with an item/trading element but I am having trouble fitting that into my model of single epoch battles and with fairness to newbies. I suppose I want each individual battle to play as below, but I want to have a Master Server controlling a persistent world. How can I add persistence? I am also having trouble with the concept of building in each individual game with so many players. How can I organize building? Thanks, Seedload. I just list stuff below with no particular order or effort for completeness. Comments on individual stuff welcome. The game is played with up to four hundred people at once devided equally into two teams (or more but it helps to think two for now). Each player controls only one unit. There are no computer controlled units. This is a first person perspective, 3D, outdoor game where players fight in configurable vehicles. Pace of the game is half shooter, half RTS. Players can see the tactical battlefield with a color coded minimap. The game starts with all players spawned into the game at the same time on their team''s side of the map. Players must kill the other team. Pretty clear. Players joining after the start of the game enter as reservists as described later. Each team is divided by ranks, General, Commander, Sergent, Grunt in a command tree organization. Maybe more levels but this will do from a conversational perspective. Rank is determined at the start of the game by experience, which is kept persistently at the server for each player, and slight randomness for the sake of fairness. Also, buddy lists can be created by the player. When possible players with buddies are placed with each other in command organization by the server. You can only chat to your superior or to those you command. Hopefully this will encourage a command heirarchy onto each team. As players die, others take their place in the ranks, giving the team a constant communication structure and giving oportunity to those who don''t have experience, to have command during the game. Resource for the game is energy. Energy is converted by mining gas. Each team starts with one gas mine. Additional gas sources throughout the map where additional gas mines may be built. Energy is transmitted, via microwave, to all units on the team. Repeaters can be built within range of gas mine to extend its range and prevent transmission loss. Strings of repeaters can be used. There is transmission loss, so the farther you are from a gas mine or powered repeater the less energy you get. You are always sent full energy even when experiencing lots of loss or full up on energy so moving far from repeaters is hazardous to you and team. Doing nothing on full energy hurts team. Energy is used by units for movement, for firing energy based weapons, and for the internal manufacture of ammo for non-energy base weapons. Units do their own manufacture internally using energy. Building is done by leaders (not sure which yet). Buildings may only build while powered, which requires them to be in range of another gas mine or a powered repeater. Drop zones can be built. A drop zone is used to call additional units into the game. Drop zones gain power. When they reach a certain level, then a unit is called into action. Replacements entering at drop zones come from a queue of waiting players. Waiting players are either those who joined after the game started or those killed during the course of the game. Replacements are picked on a first come first serve basis. Replacements start at grunt level always. Waiting replacements can watch the battle going on through the view of a teammate. There are light, medium, and heavy units. There are units better suited for different terrain. Lighter units move faster but carry less. There are light, medium, and heavy weapons. There are different weapon types that have different strengths. A unit carries multiple weapons. Depending upon the unit type, the weapons carried are limited. Each player outfits his own unit prior to joining the game. Before the game starts some time is allocated for chat (along command lines) to plan units. During the game, a unit can only be reconfigured while waiting to rejoin as a replacement (after you die). Well?

You''re worried that not all the commanders will have the same strategy for building, right? Every time someone wants to build something, you could hold a 1 minute vote.

How can you add persistance? Whadda ya mean by that. Seems pretty consistent to me.

This game should be pretty cool if you can pull it off.

humm.. ok, to break this down a bit.. it seems like you''ve got a pretty good plan for most of it.

I''ve played a game very close to this.. actually a couple games. One, the first, was Tanarus, which still exists. This game actually beta-tested the engine which now lives and runs Everquest. It had the same bugs then that it does now LOL. It was a 4-team arena tank wars game. You had up to 5 players per team. In the outside waiting areas was a chat room. The servers allowed players to make their own "teams" which the server would then keep the stats on. Each player had stats as well.. wins, losses, etc.
This made it a VERY competative game. Teams recruited the best. They formed plans and strategies. They even went to practices together.
Well, needless to say it was a great game up until they went live and started charging to play. LOL. 10 bucks a month just wasn''t worth it. It lacked enough substance for that.

On to the other game.. a WW2 sim. You had a variety of planes from that era.. B-25s, ME-109''s, P-51''s.. the whole bit. Well, it was a two-team game, like you''re looking to make. Anyone could join on any side at any time. You took off from the "home base" airport of that team. You could land at any team-controlled airports and get rearmed and refueled.
The object was to capture all the airfields in existence. By doing so, and then taking the other team''s airfield, you got a point for your team. Scores reset daily.
To overtake an airfield, you simply landed there after destroying all of it''s support guns.
This game was great, you could actually have 8 people in a B-25 bomber. Pilot, Bomber, tail, nose, belly gunners.. the whole works! It was pretty sweet. They''d started to work on streaming voice with the game when i left it.

It sounds to me like you''ve got a good thing going, but you need some tweaks.

Four hundred people is a bit much in a single battle. And it would quickly overload the server you ran with all the updating of the planes, etc. It''d be better to have 50 people per server, with a single server running each game. Again, you''d hafta make sure teams were balanced.. 25 per side.
The reason for this is sheer size and complexity. To incorporate 400 people, 200 per side, you''d need a MASSIVE map. This means more server time taken. Now, add in all the people.. and you''ll end up with like 20 servers to keep everything flowing well.
Now, you break this down to 50 or maybe even 100, and you''ve got a more manageable system. The problem is that the server load gets exponential when you add in that many players.. so you''ll hafta find a good medium.
You can also work on making different arenas. Perhaps there''s one arena that''s a newbie one.. with more gas mines. And then there''s the expert one with much more empty space, where you really have to use a great deal of strategy.
And then you can have challenge arenas.. where one side perhaps starts off with more gas mines. Then you get to having fun things.. LOL.

Anyways.. for more.. the whole command structure. I think there should be a tree, and everyone starts out as grunts in the beginning. You become a higher rank through more battles, and less deaths Working out a math equation here would be nice.. something like battles won/battle loss - deaths.. if greater than 10, you go from grunt to .. etc.

I like the microwave transmition idea.. it really adds a realistic element to the game

I think the player should be able to change ships at home base, and reconfigure a ship at any outpost. However, the outposts only have a limited supply of items.. and therefore you can only exchange for what they have avalible.
This opens up a WHOLE new doorway into the game.. merchants. You have players for each side who buy weapons at a factory, and then deliver them to the outposts and sell them off.. or players can choose to dock with the merchants en route and buy some weapons if they''re in need.. but they''re gonna cost them. Fighters gain money for kills, and for destroying enemy outposts, etc. All manufacturing is done by the "government" from each side. So in essence, they''re mercs fighting for one side or another.
Players on one side can destroy merchants on the other side, but not their own merchants. However, if a merchant way overcharged you, you might think twice before saving their hide from enemies in the future.. heheh.

I, personally, am in favor of some AI troops. This would make arenas with fewer people in it still attractive for players to go to, assuming you follow the whole arena idea. This also adds a bit of a "stable" element to the battles, like you were seeking. Of course, if you need some help on the AI, let me know. You''d want to make sure to get the right ammounts of novice and expert AI.. and you don''t want them to just generate one after another ad infinitum, right landfish?

Well.. if you do this, and the whole merc idea, you can actually drop the military ranking and go with a more mercinary-styled command chain.. little fish and bigger fish.. hehe. It''s up to you, though.. but it makes it a little easier to flesh out, i think.

Drop zones.. that''s an interesting concept. I''m thinking of it used more for a wormhole-style transit. There are certain "ripple" areas in space which, when distorted properly, form a wormhole. To make the appropriate distrotion requires a grativy-manipulation device, known as an (insert technobabble here). A merchant ship brings one of these from home base, and places one by the ripple. The machine then aligns itself properly with the one at home base, and any ships approaching the ripple are now wormholed to home base, or vice-versa. This allows fresh reinforcements to zoom in and adds a new strategic element to the game, with a cause and effect relationship, and a stable element as well

Now, merchants are taking on a bigger role.. so why not expand on that. If a new planet with gas mine is found, a merchant can bring out a gas factory in a box kinda thing. When it arrives, and deploys.. it builds a gas mine, and begins transmitting energy. Merchants are also responsible for setting up energy transmitters.
This opens up new avenues for money gaining for the merchants. You have to assign values to things. Obivously, an energy transmitter is only needed so far appart from another one. If you place them too close together, you really aren''t doing a lot of good.. and thus you shouldn''t be paid as much.

Now, you continue on with this kind of stuff.. and you''ve got a great game, both offline and online. If you want anymore help with it, do gimme a call.. heck i''d love to help you out with this.

J

Niphty,

Thanks for the well thought out reply. I think you are going a different way then I envision, but I like your ideas for the most part. You seem to be picturing a space based ship to ship combat game. My vision is a land based tank/mech/hovercraft type of game. OK, with that little disconnect out of the way, I will go on with the conversation:

I understand the exponential server loading issues with typical unicast client/server games. However, to give a ridiculous example, if this was a lan game then you could broadcast the same data from the server to all of the clients. You wouldn''t have to duplicate any data to different clients, avoiding scalability problems. The clients would be given a slight extra burdon of filtering the data for what they are interested in. In this silly example, you could run this game with one server. When reading my points below assume, for the sake of arguement, that this is a LAN game, although it most definitely is not. Say no more, nudge nudge, wink wink.

The selling point of the game is the number of people who can all be engaged in battle at once. I want more people rather than fewer. Outside of server network loading, I don''t see a technical reason that many hundreds of players could not be supported on one server. If there is no AI chewing up resources, then a lot of players should be no problem. If you suspend disbelief long enough on the network side of things, I don''t think your arguements on the loading due to running the entity movements hold up.

You said:
"You can also work on making different arenas. Perhaps there''s one arena that''s a newbie one.. with more gas mines. And then there''s the expert one with much more empty space, where you really have to use a great deal of strategy.
And then you can have challenge arenas.. where one side perhaps starts off with more gas mines. Then you get to having fun things.. LOL."

OK... This I like! I think that several battles going on at once, each at a different level is a good idea to give lesser players a start in the game. Thanks. I think I will use this.

Expanding on my earlier post and using your idea above, I think that my basic architecture would be this. One Master Server. Several game servers. Players log into the Master Server. They can chat, trade, buy stuff, or enter games from that server. Players are persistent, have inventories, and have cash. They are playing the parts of mercinaries. The Master Server launches the game servers creating scenarios for different games based on a intelligent cross section of the players logged in. Each scenario involves hiring the players to fight a battle for a certain objective. Players may be hired individually or in teams. Some scenarios involve small teams, some scenarios involve large scale combat, with smaller teams joining together to make a larger team. If the player accomplishes the mission, then he is rewarded with cash or an item (weapon) of some kind. The games are still played in the way I described before.

Weapons and items persist. There are unique and rare weapons. Although some weapons are definitely stronger than others, encouraging collecting, none are so overpowering that skill is not inportant in winning.

I like your worm hole idea. Very good. If I have allow teams at the master, and those teams carry forward to the games, whether allied with other teams or not, I think that it would be good to have the teams stay together throughout the battle. Basically, they would be one branch of the command structure when part of a bigger team. In this situation, a team should have its own ability to recall teammates. I am thinking that a portable wormhole creating item would be cool to allow the teammates to recall their buddy.

Your ideas about merchants don''t appeal to me for this game. My main problem with the merchant player is "who would want to be a merchant?" I''d hate to spend a few hours carting goods back and forth to the fighters with their cool guns and big bad wheels.

You said you favor AI troops. I do not. The reason is this, AI eats up processor resources. I would rather spend those resources supporting more clients then running another bot. Again, if you imagine the broadcast downstream LAN model I put forward before, you can probably support 5 clients to any one bot in the game.

Again, thanks for your comments, keep em coming.

-Seedload

Ok.. sorry, i didn''t get the whole planet-based warfare idea before.. lol. Yeah, that changes thing a lot

I''m still slightly in favor of AI.. but not in terms of tanks, perhaps. I think that players should be able to build defensive guns. AI would run these, unless a player was wanting to take it over, and then the AI would give way to the player. The AI would be simplistic.. just a "it comes within range, shoot it" sorta like the cannons are on autofire, and linked to the radar network. Should the comms relay or radar go down.. the autofire capablity of the cannons is lost. Adds more strategic depth to the game, if ya ask me

Now, seeing as you want this to be a ground-based warfare.. i can easily see this being spread over servers and working out well. I was more concerned with having a large space field which was populated with massive troops.. that would be a lot more difficult to pull off in my opinion. However, ground based warfare is a lot more 2-d, and a bit easier to code for massively.

To explain the arenas with different levels a bit better in terms of in-game viewpoint.. what commander would send fresh troops to a massively hot zone and expect them to win? LOL. so they send them to less difficult areas, and viola!

I''m agreeing with your server layout now.. my point in mentioning it before was that many people fail to realize just how difficult some ideas are to put into action on a client/server basis.

I don''t think the merchants apply anymore.. since it''s ground-based warfare. I still think you need to find a way to incorporate the transportation of gas factories, etc. Perhaps people have some cargo room on the heavier ships, and they can do battle, as well as carry loads. This way they don''t miss out on the action, and still get something more important done. In games like this i always loved playing the go-to guy I would always get something like that.. a bigger ship hauling something nessicary for the mission, and then let people duke it out and clear me a lane, so i could dump my cargo, then join the battle

As for the wormhole idea.. hehe.. i''m actually reading a book on quantum physics (interesting hobby, eh?) and i thought it seemed a bit more realistic, and kinda cooler.. I''m actually working on some more far-fetched ideas.. lol. Well, that''s about it.. let me know if there''s anything else you want looked at.

J