Shader engine mmofps capablility

#1 You would need a team of netcode programmers to modify the engine to do what you are proposing. In fact, you would need it for Unreal 3 as well. You're looking at a hude investment in network programming, bandwidth, and master server manipulation and tweaking. It is an EXTREMELY non-trivial thing for any engine.

#2 The polys of the characters is (largely) irrelevant to the server, it's a matter of what your clients are going to be able to handle. Doing a 1k person fps with boxes would be difficult as far as networking goes. But the odds of you making an FPS that many people will be playing at once are none to none, so don't worry about it.

#3 1k players is probably a gross exaggeration of what you actually plan on having in a small area. You are probably only going to have a few thousand players on any given server, but at most a hundred on a single battlefield. And even then many will probably be on different areas of the battlefield. Hopefully only a couple dozen will be viewable at one time.

That is your main problem; how many players does the client need info about to update its game state? They could be 5 thousand poly detailed characters or 1 polygon triangles and it will not make a large difference in the networking code. You can have as many characters as your servers' processors can handle on a server, but you need to make sure that your client doesnt need to know what 1000 different people are doing at any one time.

#4 You can most likely make it so it doesnt kill the server (lots of different architectures to support that) but it would most likely kill the client trying to render all that and handle all the networking, physics, particles, terrain, etc.

if all of them are in a tight area and in your field of view it could get pretty chugie on the client.

lots of lods', visual obstacle culling, etc and tons of tweaking to make it run smooth on the client.

server wise, you can do it, ive had 2k players on a tge server before, ran fine, bandwidth friendly, but the client crapped out (didnt do anything special to the client so that was the expected result).

other problems are potentially art related, if all those thousands of players have different and unique hi resolution textures most people wont have the 500mb video card needed to run it. on lower end video harware it would start swapping hard from system memory to video memory and just destroy your framerate.

lots of factors to take into account, constraints to keep in mind, and limits to pay attention too.

can it be done, sure, will it still run on the average game players computer, good chance it will not unless you fake a lot of it, reuse textures, etc. have lower resolution mode for lower end computers, etc, etc.

#5 So what about 400 players? could handle that without doing a whole lot to the network code?

#6 Yes 400 is definately do-able, but there is still some concern. Like how many other object will there be?
whats the poly count of each of those 400 models? are you using lods? how much texture memory will it use? (you using low or high res textures). You still want twitch game play of something a bit more sane for that many players?

getting 400 or more onto a server is one thing, but making it a fun playable game with smooth framerate is something else :)

but in terms of the server with plain vanilla TGE install, definately.

#7 Cool good info,Well talkin some pretty high poly chars ive tried to get rid of as many polys as i can get in around 8000-9000 with per char per vehicle basicaly like bf 2 just can't get the shape without them gear and such.But it will have some flying vehicles lower then that.Didnt want to use lod on the chars and vehicles but definatly with buildings.But could always be done. really there should be no reason for those 400 to be in the exact same place at one time is going to have to be big enough as to fun factor you could move and flank without nessisarly being detected.and wanted to make it so vehicles get destroyed and are removed from the map almost imidiatly.

#8 Although im not a graphics guy I think you can get rid of those high poly characters and use normal maps(that sound right?)

the technique was used in crytek (polybump technology they called it). where you take a 2 million poly
character, unwrap it as a texture and put it on a 2500 poly model and they would look really close.

I believe this same trick as used in half life 2, project offset, far cry by crytek(probably a bunch of others).

so you could get that high poly look(and all th details) with relatively low poly models.

still has a texture memory impact but you could swap that out if they are far enough away.

you sure they poly count in bf2 is that high? never seemed like it but when your getting spawned killed by the apc you dont have much time to look lol.

#9 Funny yeah spawn killed that's why im try make somthing that slows game play down and gives players a chance to use team work and strategy instead of respawn as fast possable thanks again for your comments i will look up polybump technology and see what i can find.Invaluable info.One other question if you might know what about running 2 maps on one server with 400 on each side of course making so if one map is full then you cant spawn there like planet side or would i need 2 servers with the same name and create spawn gates.

#10 Hmm well, server resources(memory/cpu) and bandwidth become larger concerns as you put more and more players on a map (in this case 1 map = 1 server), once that server is buried working on all those players
you would need another server to hold another group. Think of it like 2 different zones.(2 different servers).

planetside is fairly sophisticated, requiring a bunch of servers, router like processes that route messages where they need to go, game server/proxy processes so that you can see players on other zones and they can see you. If your referring to that type of architecture often times referred to as a seamless world, then your
really steping into some significant difficulty. Its not a simple to implement seamless worlds that work properly (easy enough to get somethingup and running but working right, scaling properly, etc is no small task).
you also run into load balancing issues where players want to pile up in one section of the map while other sections remain unused, often times wasting server rsources.

but its up to you, zoned is easier to build, support, load balance, and game play balance but can feel artificial if not done right.

seamless opens a whole can of problems, from scalability issues, load balancing problems, world building difficulties (and they your usual assortment of crossing server boundary problems) but makes your world feel more whole and continuous.

To put it in perspective, it probably took anywhere from 10 to 20 programmers 3 or 4 years to develop the tech for planetside and even longer for similar tech in games like star wars galaxies (way more people as well).

whereas a small handful of people, maybe 3 to 5 programmers wrote the zoned world for city of heros, they spent much less time, and much less money. The complexity goes way down with zoned, and the number of players you can support on a set of hardware goes way up.

but it depends on your vision of the world, in some designs a seamless world would look and feel better but fair warning, your likely to spend a lot more time trying to solve that problem(seamless) then actually working on your game play.

there are other alternatives, such as giving the perception of seamless with better client transitions (like how they do it in parts of worlds of warcraft). there is the perception of seamless even though it really is not completely seamless, but gives a nice illusion of seamless with nice transition screens instead of the obvious and boring loading screen.

so to answer your question put two maps on two different servers and spawn gates between them. Then you can also load balance between them(one has more load on the server then the other transfer the player to the less loaded one when they start).

anyway, just some things to think about :)

#11 Wow....Hmmm was thinking maybe one quater size of a planet in like in SWG utilising ATLAS technology in the up comming TSE for that.Then by virtue of the game rules disgouraging players from battling in larger groups.Talkin 50 or smaller. whereby it's unessary. It is conieveable you could have some sort of server mutiny where everyone runs to the middle to try to crash the server, and may well have happened in SWG a couple of times.....LOL I hope to avoid that.Hmm...is it possable to come up with a formula to bring balance to a game lvl in size=objectives=players of about 400?Then perhaps offer an expansion at later date using the same formula offering a new theater of battle?Like European then zone over to pacific loading screen and all.Bringing the maximum number of players per server about 800.Without doing whole lot to the Torque code Actually at this point just the first map would be great.
these are the specs on the server i was thinking of using.
Dual AMD MP 2600+ 1536 DDR Ram 12 IP Addresses 40 Gig Hard Drive 100 Mb Full Duplex Windows Server 2003 3000 GbMonthly transfer

#12 "Then by virtue of the game rules disgouraging players from battling in larger groups.Talkin 50 or smaller"

if you dont want players playing in larger groups then you restrict how many players can be on one map at one time. but you dont want to have to introduce weird game play features that try to break groups apart, that might be rather awkward.

"It is conieveable you could have some sort of server mutiny where everyone runs to the middle to try to crash the server, and may well have happened in SWG a couple of times."

if players can, they will, and yes they do :)

question about the desire to have 400 player battles(game design question), game designers seem to have a pretty hard time just making a 4 on 4 or 8 on 8 game fun, how will 400 players be fun? (honest question)

usually with large battles there is too much going on to even see it all, battles usually break up into little 4 on 4 groups anyway since you just can't deal with 400+ players moving around, the particle effects, projectiles, etc. its just too much.

plus when you get into big numbers like that you usually have to sacrifice graphics quality, limit texture use, limit poly use, etc. (although you could do things like battles a little further away are more like dust clouds so you really cant see all 400, just the closest 10 or 20).

the alternative is a smaller group experience with the feeling of being part of a larger battle (things you can see off in the distance). provide more detail, more textures, more effects because there are fewer people.

but the big one, is how do you balance a game where 400 players can interact with each other? (rhetorical question just something to think about).

(eamples scenario)
so I imagine I jump in a battle with my axe or whatever, there are 400 players fighting it out, 30 of them turn to me and kill me in once shot with all there combined damage and go back to beating on each other.

big battles like that have a tendency to turn into total chaos, no stragtegy, no planning things out, just blam, blam a bunch of players are dead. so something to consider addressing in your game design.

so not saying you cant do it or should not do it, but I am saying its not easy and it adds a lot of complexity to your game design. definately makes things more complicated, harder to balance, and just adds to an already difficult task of trying to make a fun game.

but even with all that said, it would be great if someone could solve those problems and get it all fixed so it is fun.

other then that I dont think tse is production ready at this time and is a ways off from being complete so not sure your time frame on your game.

you may want to just have 400 player maps and those servers/maps only allow 400 players (zoned) so no worries about too many players on a server since it just would not let anymore on until the battle is over.

(if players can come and go at will you run into other game design issues, like zerging where one side runs over to the next battle and blows the enemy away and goes to the next battles, etc. so you need to keep the sides even if possible).

lots to think about with a massive deisgn like that. especially since no one likes to lose, everyone wants to win and it needs to be possible for anyone to win and lose otherwise it gets boring and players quit.(and players need to feel they can contribute to the outcome)

I dont envy all the stuff you need to figure out lol, but I wish you the best, as it would be a solid accomplishment :)

dont take my comments as discouragement, more like just some things to think about has your writing your detailed game design, things to keep in mind and be aware of, but by all means continue on.

#13 Hmm....Just couldnt explain how the game works I'd spill all the beans.But the game rules are made. I forgot what that was called aside from a game doc.Somone else called somthing elese on an artiicle called How to make game.The point was write down what the game is gonna do and don't add anything else later just what it will and won't do ive done that already.But yeah if you think of an army and the units within in it have specific jobs so depending what your job is your gonna want to do things diferently some will want to avoid confrontation while others will be wanting to confront every enemy they come across see.It's not by force to force people away form each other but if u ever played planetside which was fun fun fun for about 3 months.But what was great was the huge battles for the huge bases and ud look for a huge battle to go get some.then we look at BF2 where the spec ops guy had the c4 and blew up infrastructure turned off the enemy'sradar and fun stuff like that but you didnt get any credit for that.It has rules to satisfy both i think.as far as server populations could do 2 maps on one server 200 a peice on a map bring the total on one server to 400.Really the point with server population is less servers to lease more people playing.so could go even lower poulatoins yeah the point is to feel like intracle part of a huge battle with an important job to do and the sides would want to communicate with each other to use strategy to accomlish the overall goal.could even have smaller server populations too but like vastness vastness when it's unessary cause the poultoin is small is contrived would end up looking for people to fight with to break up the montiny of travel.what if you couldnt find anyone....lol hello hello hello just was thinking of somthing more vast than BF2 but not nearly as vast planetside.

#14 Oh and the servers cause want to offer servers and not peer to peer tho cause i think the game would just be too demanding for somone to serve and play at the same time 64 is great but 200 would be better i heard that with some pretty nifty network code they were able to get 200 players on tribes 2.So was what got my head going wow i could make my game.

#15 Cool, well my comments would then focus on the difficulties of have a 200 player twitch FPS game with everyone on 1 server.

BF2 barely handles 64 players (gets kinda chunky).
Planetside (huge technical challenge, expensive to make, trusts the client too much so easy to cheat but is the only one Ive seen support pretty damn big battles) lot of servers and technology behind that accomplishment though.
Tribes2 i have never been in a match larger then 64 and at the time it was barely playable. needs good bandwidth and some pretty decent hardware.

fortunately hardware has gotten a lot better since then and bandwidth has definately improved over the years.

but its still tough to balance too. Think about it, if you had 200 players in BF2, 100 of them were spec ops
how many things are there for them to blow up? most maps inly had enough stuff for 1 or 2 spec ops.
you didnt need anymore so you would have to take all the combinations into account.

most likely supporting 200 players is going to take additional processes, for example, a seperate thread/process that doesd asyncronous player movement/firing/etc validation.

so they way planetside seemed to work is it lets the player do whatever they want, meanwhile it sends a check off to another process if all is well things keep going, if the check fails a message is sent back to the clients to put/reject/alter the player movement/projectile/whatever.
letting everyone know that event was illegal.(so move the player back, or whatever).

my usual suggestion is, if you have never made a game before, you might want to shoot(pun intended) a little lower and try to make and test out your game design(protoype) with something smaller, like 4 on 4.

if its fun and it seems to work then start to grow the techonology and the game design and scale it up.

but if its not fun then keep working on it but at least you dont sync all that time and energy into a massive design only to find out its not going to work right.

so do it small first (so you could use plain vanilla tge or tse to do that since it supports even more then you need for a prototype) and play around with your design and see if it works like it does in your head :)

will save a lot of time and help you to better flush out the design before you go big.(money,time,etc).

fine tune your game design in a smaller environment first, it wil help you firm up and refine your vision for the game.

#16 Yeah was gonna make a prototype first.Good point