Enemy Territory + Cube 2 = wOOt?

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

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   

#93: ..

by ezombie on 01/27/2008 22:27

This is a long post, but here is the plan (that I am coding as we speak)

Mapmodels need scripts. These scripts should be event-based. Hear me out:

When you shoot/use a model, a script should be run. The script should be able to start an animation. Once the animation ends, a script should be run. This script could turn clipping off for the model, and set a timer to run another script. This last script could turn clipping back on, and start a different animation.

Here we have made a door model. It can open in any fashion, from sliding doors to standard doors to french doors. Even trap doors and giant castle gates. No future engine changes would be needed to support ANY possible door.

It's gets better. With this you could make any model fully interactive. You want windows where you can shoot out the glass? Well, make a window mapmodel with a 'shattering glass' animation. Then set it play when the model gets shot, and unclip the model before starting the animation. This also works for a destructable board nailed over a door.

If fast enough, these script do not even have to be threaded.

A simple command, such as mdlscript <event> <scriptfile> could be made that registers a script with an event. These would be stored in a simple associative array along with pointer to a bytecoded cache of the script itself. Various bindings to the engine would need to be made.

If it supported custom events in addition to the default ones, then full objective gameplay would be realized, along with a much more interactive world to boot.

Everything can be done this way, from building a bridge, to blowing it up. Machinery can be operated, tanks can be repaired and move along their preassigned path. Spawnpoint can be changed, even a big rocket launched to blow up a wall.

reply to this message

#94: ..

by ezombie on 01/27/2008 23:31

Oh and here is why I am pushing Cube 2 for this project:

http://www.usef-et.org/images/temp/window2.jpg

That is at 1152x864. Nothing else can come even close to that FPS at that quality.

reply to this message

#95: ..

by freegamer on 01/28/2008 02:36

I like the notion and the energy so far. You should:

1) check out the bloodfrontier changes to Sauerbraten (http://www.bloodfrontier.com) as they are fixing problems they encounter which are not necessarily (at least, not yet) making it back upstream.

2) register a project on Sourceforge or somewhere else, maybe a google group for discussion. The sauer forums are a bit rubbish for collaboration really just because single threads move on so fast.

Once you have your own space, get places like my site (http://freegamer.blogspot.com/) and happypenguin.org to mention your project and you\'ll get lots of interest too. I\'ll definitely mention it some time if you get a basic project or site going.

reply to this message

#96: ..

by freegamer on 01/28/2008 02:38

Another reason cube2 is just ace for, well, almost any project is that mapping is so quick and collaborative. Everything else is a PITA compared to it, even those with good map editors.

I'm not sure why people (esp. in these Sauer forums) are trying so hard to talk you out of using Sauer...

reply to this message

#97: ..

by ezombie on 01/28/2008 03:08

Erm, got #2 done... check the thread:

http://sourceforge.net/projects/etce/

and forums are at:

http://www.usef-et.org/forum/viewforum.php?forum_id=11

And for #1, I have been keeping an eye on the BF sources, so I don't have to reinvent the wheel.

Yes, even I can make maps with Cube 2, and that is saying something!

Which is good because I will likely be making the first map or so...

reply to this message

#98: Re: ..

by demosthenes_ on 01/28/2008 07:51, refers to #86

The problem with a model-based mapping approach in the C2 engine is bullet passthrough. Specifically, there is none, at least with the tree mapmodels I've used. Rockets explode in your face, riflerounds stop when you can clearly see your target. It's annoying, to say the least.

The easiest way I can see to fix it is to make projectiles stop anywhere a player would be stopped, and nowhere else, which means tree trunks, not whole trees.

I really don't know where I'm taking this post. I guess it's just something to think about while you're mapping and coding.

reply to this message

#99: ..

by ezombie on 01/28/2008 17:31

It does work that way right now.

I was playing the river map, and bullets/rockets went through the exact same models I did...

Or do you mean the branches of large trees? The player *would* be stopped on those, try it. You can walk on top of the bigger ones.

What you seem to want is being able to clip/noclip based on individual model *meshes*, instead of the whole model.

Or one could use a model of a tree trunk with the larger branches only, set that to clip, then add seperate models of the 'leafy' stuff at the right places set to noclip. Wala!

Now if those leafy models where animated a bit...

reply to this message

#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

   Board Index