Enemy Territory + Cube 2 = wOOt?

by ezombie on 01/19/2008 16:25, 258 messages, last message: 04/03/2008 21:39, 195362 views, last view: 09/29/2024 12:24

I made an actual thread for this, since we are still yacking about it. To bring the others up to speed:

"Some of us weirdos have been kicking around the thought of making a community edition of Enemy Territory (the FIRST one). I suggested the Cube 2 engine might be a good base...

This would be a straight port of ETPro gameplay to a standalone open source game, using new 'HD' assets. Nothing too fancy, just better graphics and netcode are what we would be looking for."

   Board Index   

#100: Re to ezombie's post

by smartalco1 on 01/28/2008 18:30

that would be awesome, the /only/ thing as far as im concerned that sauer is missing from the standard corporate fps is interactive environments (although I hear there are barrels and such in the latest release, I have yet to see them)
im not sure how this would work into the sauer physics engine, as adding objects that move around and act realistically with the environment is a considerable step above making your character unable to pass through walls, but it might be possible

reply to this message

#101: Re: Re to ezombie's post

by MovingTarget on 01/28/2008 19:06, refers to #100

There are barrels, and moving platforms and elevators, and pushable barrels in the Assassin edition.

reply to this message

#102: ..

by ezombie on 01/28/2008 19:11

Well, the movable objects would need to be seen as 'dumb monsters' by the engine I suppose, so they get the proper shadows and whatnot. No baked-in shadows.

But these would typically be the 'movers', or simple, scripted, non-piloted vehicles. I think I will add them as a seperate class/list in the code, using the monster one as a base. We would then need to multiplayer enable these, either through syncing or running the scripts server side and reporting everything to the clients. The first is easier by far.

The static ones (md2) are relatively easy, and the fixed animated ones (control panel, door, animated light switch) aren't too bad either.

reply to this message

#103: ..

by ezombie on 01/28/2008 19:16

Yes, are those *are* pretty cool, and quite useful. The movable platforms are cubes, and the barrels are fixed behavior. This is very handy when that is what you need so I think many mappers will use them even in ET:CE.

But they do require a game update whenever you add/change one. We need a more flexible system that can be customized per map for the objective stuff.

The 'trigger + script' approach that ET used can be difficult for the mapper at best, and downright clumsy for the coding after awhile.

I am looking for one approach that solves any current and future need we might have. I would rather do one really hard thing, then ten difficult things.

reply to this message

#104: ..

by ezombie on 01/29/2008 04:52

Well, we just finished some client/server testing.

Got some great compliments for you guys. One old time pro player compared it to the Quake series, but WAY smoother. We are all dutifully impressed by the netcode. Not even a hint of lag at almost 200 ping. The higher spec guys got 200FPS constant at max resolution/settings.

One of my favorite quotes was "Holy @$#!"

So it passed the performance test ;)

reply to this message

#105: Re: ..

by demosthenes on 01/29/2008 07:40, refers to #104

The higher spec guys should try /maxfps 500. :D

reply to this message

#106: ..

by geartrooper2 on 01/29/2008 11:17

Woohoo!

reply to this message

#107: ..

by ezombie on 01/29/2008 14:46

LOL - I was thinking about that. But then I was like 'naaah, no point in going higher then that'.

This is great, just what I was hoping. ET:CE might be able to attract a decent group of RTCW and pro guys, since ET comp play is almost dead, and ET:QW kinda ticks alot of them off.

This is a very big group (latest RTCW/ET stats place global userbase at around 220K, with thousands of clan/pro players), and would love Suaer performance, but are so picky about polish. We will see if we can grab their interest.

reply to this message

#108: RE: Test Server

by ezombie on 01/30/2008 00:23

Sorry about that fellas.

Some of you might of seen the 'ETCE' server on the browser, it was just us running a few quick netcode tests (from around the world). Some of you tried to join, which of course didn't work.

We won't be polluting the list anymore. There is a master server up now, using Hungerburg's nice perl script until we get some permanent, SQL-powered, FastCGI goodies running.

BTW, I'd be happy to host a seperate copy of it for any group that needs it.

reply to this message

#109: ..

by Temp user on 01/31/2008 00:05

Hi again.
Just in case you were still not sure about the engine.
Here is a quake 3 based engine with some nice aditions. Quake 3 based is nice, because you could use ET maps more or less directly.
But take a look:
http://xreal.sourceforge.net/xrealwiki/
http://xreal.sourceforge.net/xrealwiki/ScreenShots

reply to this message

#110: Re: ..

by MovingTarget on 01/31/2008 00:17, refers to #109

That was mentioned earlier, I think.
Can you say "Resource hog"?

reply to this message

#111: Re: ..

by demosthenes on 01/31/2008 01:42, refers to #109

Uh, he's sure about the engine, I think. Why are you so opposed to the use of the C2 engine?

reply to this message

#112: ..

by ezombie on 01/31/2008 02:26

Xreal is what I started with when doing engine evaluations. Very impressive, and great work (I like your use of Lua). But it's against one of the primary goals of this project: A new ET that will run on the older hardware that most of us old-time gamers have. Xreal slapped my poor 6600 AGP upside the head.

And why do people keep bringing up using ET maps? That's sounds great, until you realize that the vast majority of textures and models used even in custom maps come from the stock set that is included in the game. That is called 'illegal' in this country. A nasty cease and desist letter we don't need...

So sorry, we cannot use ANY textures or models from ET. We can't use one strip of code (maybe the SDK, but that's not worth much without the original engine - which is not Q3), one smidgen of audio, one iota of art from our beloved W:ET.

We can only take from it some inspiration and guidance.

reply to this message

#113: ..

by ezombie on 01/31/2008 02:31

Oh yeah, and according to cold hard numbers:

C2 IS TEH PERFORMANCE BOMBZ, D43L WIT IT

How about the other engines, great in there own way, borrow some of that speed demon blood from C2. Then everybody will be happy :D

reply to this message

#114: Re: ..

by Aardappel_ on 01/31/2008 03:21, refers to #113

the day a quake engine switches its bsp to sauer's octree format is the day I will declare us the winners :P

(hint: not going to happen)

reply to this message

#115: ..

by makkE on 01/31/2008 13:58

I think already a successful and widely noted mod of Sauerbraten would be a win.

Don t get me wrong, but with the current game´s flaws, it´s no wonder Sauerbraten is percieved in the way it seems to be. Add the way the community acts as a whole, and you´re there.

If someone comes onto the forums with typical suggestions/questions of someone comming from a diffrent game, the pack usually goes on him and shouts him down, and I don´t mean those "wiil u add vehicals liek in bf2 coz that will so roxorror!11!lol!" kind of posts..

Even if indisputable flaws are being adressed by outsiders, they will be silenced by a sheer mass of people defending said flaws until the topic initiator gives up.

I myself have participated a lot in that, but by now I see that many of the points these people made would have been worth thinking about, at least accepting them, but I was going with the crowd then, I admit.

After all it makes me understand why Sauerbraten and it´s community are percieved like that. The "us against them" attitude comes from both inside and outside if you ask me.

reply to this message

#116: ..

by scasd on 01/31/2008 15:17

I have browsed the Sauerbraten code a bit now and i must say from my point of view it is very weak for cheating. I have also seen guys damaging me while they are invisible or guys flying around like birds so Sauerbraten is weak for cheating. The community is small and will be small in future if there is no anti cheat implementation. Ok - "There are more players then cheaters and more servers then players..." (wiki) - but there is not only one player per server - they are all on one server (mostly The Conquerors) and the cheater can see his victims just on the server browser. So that could be one big reason why is rated worst often. I mostly play on LAN and are not afraid of cheaters. The fast server code is perfect there by the way.

Online you may run into trouble with the server code as a mod/t.c. base.

reply to this message

#117: Cheating

by hfsdjkconorhfsdkj on 01/31/2008 15:27

Find me a game engine that people can\'t hack into and cheat in...

Sauer is always been like this, but cheating right now is at an all time low.

There are methods that can be used to combat cheating, but they probably just aren\'t implemented right now to prevent it, because it is not needed yet...

reply to this message

#118: ..

by freegamer on 01/31/2008 16:02

Stick to your guns ezombie, you are using the right engine. Sure, sauer has it's flaws, all game engines do, but sauer also has incredible benefits which are far greater - performance, cross platform, rapid content development, good development community, etc - and the flaws are easily addressable (cheating, the few missing features).

In the short history of my blog Free Gamer and Sauer, I've been a strong proponent of starting new FPS games using Sauer as the base, because it gets away from the normal pita standard of developing game content and brings it together in a way that is focused on being easy to create content for and easy to mod and not obsessed with outdating everybody's PC but still having the ability to look great.

reply to this message

#119: ..

by ezombie on 01/31/2008 19:01

I already have plans for the cheating issue, thank you for the concern though.

As far as 'anticheat' is concerned, I have read a zillion white papers (include some doctoral thesis) and opinions on the subject. I am also an embedded control systems and network/DB programmer by trade. I know microcode and various other 'itty bitty computer' tricks like the back of my hand. I'm sure we can figure something out that will be sufficient to discourage dorks.

Of course it won't be foolproof. NO anti-abuse system EVER is. People need to accept that fact of gaming life. You use a super strong anticheat system, you also get mass lag and a bunch of crap slowing down your system and/or the servers.

There is always a tradeoff. The biggest protection against cheaters is actually YOU. It's a social thing.

There is nothing to stop us from modifying the netcode, but we are trying to avoid that if at all possible. We LIKE the '250 ping' = 'no lag smooth as butter' online gameplay. Perhaps some people don't. Go fig...

reply to this message

   Board Index