|
|
Post by sultanofswing on Sept 12, 2006 9:13:05 GMT -5
I posted this in the planetunreal forums a day or so ago, and haven't gotten a reply yet. www.forumplanet.com/planetunreal/topic.asp?fid=4790&tid=1950229It's more out of curiosity than anything, seeing as all my potential projects never get anywhere, but I figured some of the people on this forum would probably have a better idea of what I'm asking about. Thanks in advance. |
|
|
|
Post by mrmedic on Sept 12, 2006 9:49:02 GMT -5
1) The engine can support an outrageous amount. More than an average mapper would ever use, I can't remmember the exact number it can support though....but you probably could. Optimizing though, 62(4?) zones limit. Might be laggy.
2) Nope, not without a random script and major lag with movers.
3) 32 man engine hardcoded, however...if you mean...zombies. Then its unlimited, as long as it's an actor(Sorry, may be completely wrong, I am still learning those areas)
Feel free to ask anything else.
|
|
|
|
Post by sultanofswing on Sept 12, 2006 11:22:24 GMT -5
Thanks for the quick feedback.
Unlimited zombies? That'd be awesome. Personally, I'm totally willing to sacrifice visuals for gameplay. I figure with very low poly models for the zombies and simple pathing AI, you could easily get a server to have hundreds of them on. Plus the players won't have issues with seeing loads of them onscreen.
I've just had this idea for awhile, and KF kind of kickstarted the brainstorming.
|
|
|
|
Post by zombieButcher on Sept 12, 2006 11:27:59 GMT -5
100's no, comps would be killed that way.
|
|
|
|
Post by Grim on Sept 12, 2006 11:28:26 GMT -5
Yeah, maybe with like, two polygons a zombie  |
|
|
|
Post by Abyx on Sept 12, 2006 11:46:30 GMT -5
Yeah, maybe with like, two polygons a zombie Which of course isn't possible considering it takes 12 or so polygons to make a box. |
|
|
|
Post by zombieButcher on Sept 12, 2006 11:50:33 GMT -5
My comp would like burst into flames if 200 zeds spawned ;\.
|
|
|
|
Post by sultanofswing on Sept 12, 2006 12:04:32 GMT -5
Hmm, guess UT2k4 wouldn't work than.. Thanks.
|
|
|
|
Post by mrmedic on Sept 12, 2006 12:07:51 GMT -5
Finding any engine which can optimize a battlefield of zombies for free is going to be tricky.
|
|
|
|
Post by sultanofswing on Sept 12, 2006 13:00:45 GMT -5
Well, I don't expect the concept to go anywhere anyways. I'm just toying with the idea, get a feel of the possibilities. The original idea was actually a tabletop game, which expanded to a single player ascii roguelike (I'm a fan of roguelikes). Than I thought about a topdown view game, but with first person aspects (meaning you can only see what your character would be able to see, with a sort of fog of war affect for what is out of your sight. A full blown FPS would be the best though. But, again, it'll probably never see the light of day.
An apocolyptic zombie survival horror fps multiplayer game with rpg elements? Pff.
|
|
|
|
Post by uwasawaya on Sept 13, 2006 5:30:25 GMT -5
The funny thing is, the game could easily deal with the 200 zombies... it's the AI and pathing that's the problem.
And that last sentence Sultan, that sounds awesome.
|
|
|
|
Post by sultanofswing on Sept 13, 2006 9:04:31 GMT -5
Doesn't it? But what's the chances of a commercial game company to make something like that?
As for the AI and pathing, I'm not sure what the load on a computer would be, but how would a "follow the leader" system work? Basically, out of the 300 zombies or whatever, one or two dozen are selected as "leaders" by the system, and the other zombies are grouped to a leader. Think of it as zombie squads.. You'll always end up finding zombies in groups. With a decent system, the AI leader could change on the fly in a group if necessary. When the leader makes a decision, the rest of the squad simply follow him around. He attacks something, the rest attack the same thing. Each squad of zombies would essentially be a single AI entity. It's an idea that crossed my mind, but I personally wouldn't know if the functionality would work.
Of course, there would be a few pathing issues with such a system that may or may not be tweaked out. But it seems fairly plausible. Heck, it could also even be a gameplay mechanic. Maybe some high skill would allow you to spot out zombie leaders.. you take him down, all the others following him remain motionless until another leader comes by and picks them up. Would be an interesting strategical addition, especially if players were seperated into classes, one being able to recognize the leader for example, than everyone else firing on his target.
I've really thought about the idea for awhile. When I come up with a concept, I also think about possible issues with technology limitations, balancing, etc... Never learned to code.
|
|
|
|
Post by faust on Sept 13, 2006 9:32:28 GMT -5
The AI has nothing to do with the lag that comes in place when there's lots of zombies in the play. The AI is procedured only serverside which means, that the only restriction on number of the zombies is the actual processing power of the server. And the simple AI that KF uses does in fact cover up a very small ammount of performance.
The problem is the processing on the client's side:
- The mesh of a zombie is a playermesh which means processing of many polys simultanously, processing of a whole bone-structure, textures, all kinds of animation (walking attacking etc.)
- The engine does not procedure common meshes very well because they get their lighting in realtime in a very inefficient way. Albeit having the complexity of a staticmesh, common meshes are constantly rendered by an outdated, unefficient system that causes massive lag if there's too much actors in the scene
- The coding of the zombies itself should use as few and as simple code as possible. There's functions like Timer() and Tick() which use performance because they get executed sometimes indefinite times. The Tick-function is espescially performance-hungry since it executes every frame. So a good code should not have this in the first place.
- The actor class itself which all things that you can see ingame are made of (And even more things that you can not see), is by itself a pretty large class with a lot of variables, which might not be used for every single actor, but are stored, which in reverse each performance in the sum. This is not that crucial however. The effects come into play when you have thousands of actors spawned.
So, a perfect zombie-code (In terms of performance) would indeed be a zombie that has no mesh, but is spritebased (Hello, Doom1), has little to no timer- or tick-calls and a low-res-texture. You can have thousands of those.
|
|
|
|
Post by sultanofswing on Sept 13, 2006 10:09:02 GMT -5
Again, I've thought of that. Even with a low poly count, the massive numbers involved could still kill a system. Which, of course, is why I'm asking.
But, if the gameplay is good, I have no problem sacrificing graphics. I originally thought about looking into DOOM for the game, but some of the engine's aspects wouldn't work, namely the inability to have an actual 3-dimensional world. If I had the choice of about a hundred polygonal zombies, or a thousand sprite zombies, I could tell you which I'd choose if it would improve gameplay value. With a some good artistic work, you could do a decent job of making sprites actually work well, and maybe even be appropriate.
Bad graphics or outdated graphics still have their uses.
|
|
