Enemy Territory + Cube 2 = wOOt?

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

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   

#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

#193: ..

by ezombie on 02/09/2008 10:19

Wish I could. But the point of the proxy classes is to let the VM access the members functions of the clientcom and fpsclient classes. So they have to both be in scope.

reply to this message

#194: ..

by ezombie on 02/09/2008 17:46

Erm... but if you do this:

comclient *c;

Anywhere but inside of fpsclient{}, you get a \'comclient not found\'. If you then #include \"client.h\" anywhere but inside of fpsclient{}, you get a \'fpsclient not found\' - since fpsclient is used inside of comclient...


client.h
---------
struct comclient {
fpclient &cl;
...
};

fps.cpp
---------
struct fpsclient {
#include \"client.h\"
...
comclient cc;
...
};


See, in order for client.h to be included, fpsclient needs to be in scope. But fpsclient also needs comclient to be in scope.

This is an old C++ trick I have seen before - you use it when class A needs to have a reference to class B, which has an instance of class A inside it. True, there are cleaner ways to do this, but they take quite a bit more code.

Are you *sure* you are the guy that works with this stuff? (LOL)

reply to this message

#195: ..

by ezombie on 02/09/2008 18:51

Got the first piece of logic ported to the VM and running nicely:

-- This script provides a VM implementation
-- of some of the fpsclient methods

-- create global proxy class instances
client = clientproxy(this)
clientcom = clientcomproxy(client.getcom())
player = playerproxy(client.getplayer())

-- let's add an extension onto one of them
clientcom.text = "BOING!"

function canjump()

-- fetch a current copy of the properties
_client = client:fetch()
_player = player:fetch()

-- have some testing fun
clientcom:chat(clientcom.text)

if(!_client.intermission) _client.respawn()
return (_player.state ~= CS_DEAD) and (not _client.intermission)

end


Now this script is compiled into bytcode with luac, then saved as client.dat for now. The game 'runs' it once when it first starts, effectively caching everything into memory. When you need to jump, the game calls the 'canjump()' function in the bytecode directly.

This means it's very very fast. WAY faster then java, almost as fast as the C++ code it replaces. And you can now change the jump logic *without* a recompile.

reply to this message

#196: ..

by ezombie on 02/09/2008 18:54

Oops! the line

if(!_client.intermission) _client.respawn()

should be

if (not _client.intermission) then client:respawn() end

Hope it makes more sense now for you Lua guys out there.

reply to this message

#197: ET:CE website is up

by ezombie on 02/09/2008 21:08

http://etce.usef-et.org/

reply to this message

#198: ..

by ezombie on 02/09/2008 23:46

I tried that, but the VM binding class (template class) won't let me.

It works good this way, I got almost everything in external files now. The fpsclient and fpsserver instances in REGISTERGAME can have their own seperate VMs as well, which is a good thing(c).

I profiled that canjump() function using C++ and Lua. C++ ~ 1-4 microsends, Lua ~ 20-30 microseconds. Keep in mind that the invocation cost of calling a function in the VM is about 15 micros.

So the performance looks great, and the code is itty bitty so far (only added about 200K to the binary so far).

Onwards and upwards!

reply to this message

#199: ..

by ezombie on 02/11/2008 02:01

Just trying to get some input. What do you guys think of this HUD?

http://www.usef-et.org/forum/attachments/hud1.jpg

The blue is health, the red is stamina (or maybe the other way around). The numbers show the current ammo in the gun/your total ammo, which is above the 'weapon card' that shows your current weapon. The green bar is the 'charge' level - used to perform class-specific activities (fire heavy weapons, repair stuff, hand out ammo or health packs)

The radar has players in red or blue, depending on team. The yellow blips would be for objectives. The radar rotates so that up is where you are currently pointed.

reply to this message

#200: Re: ..

by rancor on 02/11/2008 02:12, refers to #199

Looks pretty good in general, just a couple of things:
Heath and stamina should be the other way around, as you implied. Red == health 99% of the time.
Also, you should indicate how much ammo is left in the clip, so something like
5/10
200

reply to this message

#201: ..

by ezombie on 02/11/2008 02:35

Huh?

The first number *is* the amount left in the clip. The second number is the extra ammo you are carrying.

reply to this message

#202: Re: ..

by yetanotherdemosthenescomputer on 02/11/2008 02:51, refers to #199

Looks good!

reply to this message

   Board Index