Enemy Territory + Cube 2 = wOOt?

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

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   

#173: Two lightmaps?

by conorkirkdjfahsd on 02/07/2008 06:30

If the destructable walls would always blow up the same way, then you could have two lightmaps, one with all the walls blown up, and one with them all intact. Then if one blew up, you could just take that section of the lightmap.

Another way could be to have the wall be "glowing" Or, casting a dynamic light that matched that area of the lightmap, then if the lightmap were mucked up, it would still look decent. :D

reply to this message

#174: Weapons

by JadeMatrix on 02/07/2008 14:44

Coilgun = railgun
Odd enough, ET had railguns, even though it was WWII. Actually, just one...

I just saw the M29 for the first time a few days ago. It is the ugliest gun I have ever seen, despite how much I like HK.

reply to this message

#175: Re: Two lightmaps?

by RealNitro on 02/07/2008 15:30, refers to #173

Having multiple lightmaps like conorkirkdjfahsd said would do for ET I think. When a well is blown up in W:ET, the hole always looks the same.

reply to this message

#176: Re: Weapons

by Julius on 02/07/2008 18:06, refers to #174

That was a railgun as in train-rails :p

But seriously folks... when did descructable walls ever improve the actual gameplay of a game?
Quite the oposite is true for the most part.

reply to this message

#177: ..

by RealNitro on 02/07/2008 19:39

Julius: In ET some of the base classes' main task is to blow stuff up... Engineers blow stuff up. (And repair other stuff.)

(I love playing engineer class, hence my nick.)

reply to this message

#178: ..

by scasd on 02/07/2008 20:04

Worms is very popular and has destructable level geometry. It is an essential gameplay part there. It just came into my mind when I heard ezombie talking about tiny cubes and rocket launcher.
The problem for my opinion is only the destroyed lightmap in other places. The level designer could adjust the light behind and before a destructable level part to have the same brightness.

Realtime shadows would be nice but you need actually three render passes instead of one. You could have a flag in the shaders menu saying \'shadow maps on/off\' but that would be a lot more work then fixing the lightmap inconsistence and using the (existing) editing code to remove some cubes somewhere.

@ JadeMatrix: I like the fancy big capacitors on some of the coilguns. Others are looking ugly for sure.

reply to this message

#179: ..

by ezombie on 02/07/2008 21:53

Well... for now 'blowing stuff up' means using an animated mapmodel. This works rather nicely for ET:CE - having destructible terrain would only be eye-candy, really. You can implement the same gameplay flow using exploding mapmodels, and it's MUCH easier for us to code (not to mention utilize in the mapeditor).

The M29 *is* a truly fugly weapon, yes. This is why I'm not letting it near ET:CE. We shall be using one of the M21/M24/M25 rifles for a sniper.

reply to this message

#180: Re: Weapons

by demosthenes on 02/07/2008 22:03, refers to #174

Coilgun != Railgun

They operate in very different manners.

But, both are fairly awesome.

reply to this message

#181: Re: ..

by SheeEttin on 02/07/2008 22:43, refers to #179

I vote M24 (in case votes mean anything).

reply to this message

#182: ..

by ezombie on 02/08/2008 00:30

Best idea I've heard in awhile. Simple to implment, yet can add a whole new dimension to the game.

"I'm working on a pipe kit for making networks of pipes using mapmodels.

http://fluffy-tiger.deviantart.com/art/valve-thingy-76659329

An idea occured to me about damage.
If the mapmodel pipe takes damage but less than needed to destroy it, perhaps a 'smoke' particle entity could be placed where the bullet 'hit' ( from the to-hit ray ) for clouds/jets of steam... Even if noone is hurt, it could make a nice bit'o'cover and let players interact with something other than other players."

Definitely going in. Going to test the idea this weekend. :D

reply to this message

#183: ..

by Julius on 02/08/2008 02:21

Not sure that would work in a mp game.

1. you would have to propage the entire "pipe got hit here" thing over the network, which would be quite a heavy burden for the relativly small effect.
2. people who (have to) turn of the particle effects for faster rendering would have an unfair advantage.

reply to this message

#184: Re: ..

by MovingTarget on 02/08/2008 02:27, refers to #183

(1) Why would it be so bad? All the client has to do is send the position to place the particles. The clients already send shot x,y,z, direction, weapon, etc.

reply to this message

#185: ..

by ezombie on 02/08/2008 02:37

LOL - well, since all the clients know about the model, and they all know about the shot - how about each client do it locally?

I see the point about the particle effects being off... ET:CE might have certain particles always on, we aren't sure yet. It depends on if any gameplay features use them. ET has always used smoke & explosion cover as part of the tactics of the game.

A middle ground would be to make the steam, well 'steamy' - as in very seethrough. This would demote it to pure eyecandy, though.

reply to this message

#186: Re: ..

by yetanotherdemosthenescomputer on 02/08/2008 11:38, refers to #185

How do you handle RL splash damaging them to the point of steam ejection? Flamethrowers burning them to that point? A shotgun hitting a mass of them to that point?

Just trying to raise questions to help refine an interesting idea. :)

reply to this message

#187: ..

by ezombie on 02/08/2008 18:57

Good questions. Don't know yet. Just going to try the simple "I got hit so I'm going to steam" first.

I have to dig through the code some more to see what kind of impact this may have on performance (think of ALL those pipes that a mapper might put in). I suspect it will actually have to be an entity that the mapper places (invisible 'hit me and I create a particle' box). Or we could add a 'pain' trigger for mapmodels. The game can then include any models with these triggers in the 'shot' and 'splash' checking...

reply to this message

#188: ..

by ezombie on 02/08/2008 22:12

After lengthly review, I believe this is how we are going to structure ET:CE ->

As part of our goal to keep the engine modifications to a minimum, we shall us the Lua VM to perform as much of the game logic as possible. This should allow client and server mods (mod of a mod?) to be written and distributed quite easily by the community. There are a few ETPro Lua coders that have contacted me, and this will let them contribute as well.

For the 'interactive mapmodel' issue, I am hoping to use triggers as much as possible here. This will keep map scripting in CubeScript where it belongs. And it focuses our development nicely, since we now have more Lua coders then C++.

Any caveats/warnings about expanding the Sauer triggers you can pass my way?

reply to this message

#189: Re: ..

by Captain_Ahab on 02/09/2008 00:18, refers to #187

thinking about it, making a 'pain' animation would look dumb unless the shot hit in the same and 'right' spot each time..unlikely to happen. Therefore the steam should be released in a position thats independant of hit location. As the pipe sections would be meant to be placed in various positions/combinations/orientations, specific hit locations might be tricky to get right.

therefore I suggest that the steam gets 'released' at joints between pipe sections as if the pipework is starting to break apart at the joints and the animation might involve cracks there or popped rivets/bolts. The death animation can then be a section of pipe blowing out abd the emitters moved via script to a logical place. Tags could be placed in the models as markers for where emitters would be placed.

reply to this message

#190: ..

by ezombie on 02/09/2008 01:48

I was just going to create the particle emitter adhoc - like how the GL/RL projectile explosion code does it.

Now for mapmodels, we might have to do that. Not sure yet. I would rather have them 'hidden' and 'unclipped' though...

reply to this message

#191: ..

by ezombie on 02/09/2008 09:05

BTW, the whole clientcom within fpsclient within clientcom thing is going to haunt my nightmares for some time to come. Never could stand circular scoping...

Now I remember why I like C so much :P

reply to this message

#192: ..

by ezombie on 02/09/2008 09:23

HAHA!

const char fpsclient::clientcomproxy::className[] = "clientcomproxy";

const Luna<fpsclient::clientcomproxy>::RegType fpsclient::clientcomproxy::Register[] = {...};

That works - I had to first stick the proxy classes inside of fpsclient, but they have static arrays so the VM can map stuff.

For anyone else who wants to someday use classes that require static members with Sauer, I will leave this little gem for you to search out and find.

<grumble>

reply to this message

   Board Index