Enemy Territory + Cube 2 = wOOt?

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

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   

#33: Re: Performance

by yetanotherdemosthenescomputer on 01/22/2008 00:38, refers to #31

Just as a heads-up, ATIRULE has never been real truthful in providing data, as I can remember a running complaint he had that simply could not have been true given the data he was providing.

If you like, I'll see if I can crank out some numbers for you from my SLi rig tonight or tomorrow.

reply to this message

#34: Re; Performance

by ezombie on 01/22/2008 02:08

Yeah, the low spec machine is running old catalyst (6.5 i think), plus hasn't run any games before this - it's the wife's computer, slowest comp I could get my hands on. How do I check if the software renderer is running?

Oh, and BTW, HOLY CRAP!! Has anyone run this on FreeBSD 7.0 yet? I just booted into it (my dev platform for work) and fired it up on the mid spec machine...

120-190FPS solid at 1280x1028, everything on. Blasted my way through some SP maps, felt like superman.

reply to this message

#35: Re: Performance

by ATIRULE on 01/22/2008 10:48, refers to #33

i get 45-100+ fps on most maps with full shaders 1024x768

one thing i should have pointed out is that my 6200 is far from stock it been modded and over clocked by about 70%

I can run doom 3 at 800x600 and be pegged at 60 fps most of the time on high settings

system info
OS windows xp Pro sp3
cpu intel P4 2.88 OC 2.66 stock air cooled
768mb ddr 400 ram
NVGf 6200 caped at x4 ;(

reply to this message

#36: re:

by geartrooper2 on 01/22/2008 12:55

I guess I'll throw my hat in the ring if you need a modeler/animator. The more concept art the better, if it works out.

reply to this message

#37: ..

by makkE on 01/22/2008 21:43

Don ´t make the mistake of judging the darkplaces engine by running Nexuiz!!

Nexuiz, though certainly a nice project, has lots of internal flaws, 3000-polygon gibs anyone? Their .zym model format is a ressource hogger too... also, their bump and spec-maps are kinda cheap (ps filter slapped on older diffuse textures), so it looks worse than it could ;)

If you know what you do in terms of optimized meshes (and art assets in general) DP is a great engine...

reply to this message

#38: ..

by James007 on 01/22/2008 22:23

Nexuiz runs great on my intel mac, I just have to turn 1 or 2 of the lighting options off for the game to play smoothly on high settings. It looks fantastic too.....

A Wolfen ET game would work on Dark Places.... but some tweaking would have to take place im sure.

reply to this message

#39: Blam!

by dfhkshjkfsdconorbhjfkdshkj on 01/23/2008 02:58

Can anyone say Blam! Engine?

I will test out nexiuz...

reply to this message

#40: ..

by ezombie on 01/23/2008 03:24

Blam Engine? as in Halo Custom Edition?

reply to this message

#41: Maybe...

by jsfdlconorhjfd on 01/23/2008 05:10

Maybe...


(Good luck)

reply to this message

#42: RE: Maybe

by ezombie on 01/23/2008 23:25

Since you don't feel like making a identity on the forum, I'll assume you are the bloke that suggested the Blam! engine.

I'm not sure how to evaluate that suggestion, since Blam! is not an open source engine. Heck, you need a Halo CD just to run Halo:Community Edition. This is going to be an open source project, so commercial engines are not a viable option.

We might have the master servers ad supported (ads displayed on the server browser screen/player account website, not in game), but that would be the extent of commercial involvement in this.

reply to this message

#43: Re: Maybe

by Julius on 01/23/2008 23:44, refers to #42

[quote]We might have the master servers ad supported (ads displayed on the server browser screen/player account website, not in game), but that would be the extent of commercial involvement in this. [/quote]

That sounds like a cool idea, especially with the player account to prevent cheating (maybe by adding a karma system where other players can vote someone up or down and certain servers only allow you to join if you have a certain number of upvotes).

So what are your futher plans? Did you talk to Quin and Acord about colaborating on the Bloodfronteer engine?

reply to this message

#44: ..

by ezombie on 01/24/2008 00:31

You hit the nail on the head. Having central player and server registrations kinda makes sense for this. The abuse (player cheating/stat padding/server spoofing/exploit hosting) of it will be handled mostly by reputation. This is how it's envisioned:

Server admins register their server and get a key to stick in the config. Players create accounts, register nicknames and are internally assigned a GUID that is handed out directly to the servers when they join one. You would log into the game when it starts, and select from a list of nicks. All this is of course free, but not scriptable (captchas and email verification). Someone could easily create an account just to cheat, but then there stats would be wiped out if enough admins ban them. And servers that get enough player complaints could be dropped from the browser and flushed from the stats.

The current state is one where we are merely collecting & organizing information. Listening to what people want, creating a starter TODO list, getting a forum setup, registering at SF , that kinda stuff.

We do not know if we will use BF stuff yet. This is going to be a standalone, but everyone is free to snarf and new code from it for inclusion into Sauer and BF. The ET specific (non Sauer) code is likely to be license under WTFPL: http://sam.zoy.org/wtfpl/, with the assets being whatever the artist feels like. My employer likes it when I work on stuff using this license, since they can also snarf whatever they like. They might even let me do some of it on company time.

reply to this message

#45: Re: ..

by yoopers on 01/24/2008 00:45, refers to #44

Random thought: rather than creating a new authentication system, why not use OpenID? Seems like that might lower the barrier to entry for new players, allowing them to use their email address as the account name. Also, clans could setup their own OpenID providers and truly maintain a clan identity across multiple servers.

Having said that, OpenID lives in HTTP Land, and putting a full-blown browser inside the game would be silly. Maybe some stripped-down variant could be created, where only certain HTML tags could be used. I'm imagining that each server potentially becomes an OpenID provider, and all of them speak a limited dialect of OpenID.

Feel free to shoot the idea down, I've been buried in JavaScript bugs today and my neurons are only firing intermittently. ;]

reply to this message

#46: ..

by ezombie on 01/24/2008 02:29

Yeah, but the WTFPL is much sexier, and it's publicly recognized by the FSF :P

I'll take a look at OpenID. Just hope it's not overkill. No need for a full blown browser, I got lots'o'HTTP C++ code floating around here.

reply to this message

#47: Re: ..

by SheeEttin on 01/24/2008 05:48, refers to #46

I'd think any use of HTTP in a game like this'd be overkill...

Of course, if you'd prefer it to writing your own authentication system, it's your game. (I know I'd prefer it, I'm no coder. :P)

reply to this message

#48: BLAM!

by fdhjkhsdkjconorhfjkdshjk on 01/24/2008 05:51

I was making a sick, sick joke about the Blam! engine.

reply to this message

#49: ..

by ezombie on 01/24/2008 06:48

Yes, it was indeed sick. Missed the joke part though <oops>

I took a gander, and OpenID seems very much like overkill. I've written a few online authentication systems (for XML payment processing gateways) - this will be cake.

So, you login to the game with your account details (username and password which can be saved). While retrieving the server list, the master server gives you a 'session key'. When logging into a server, the client passes the session key. The server queries the master server with the player's session key, which returns the player's GUID and other info. Any stats/kicks/bans would be reported back to the master server using the server key + the player session key + the player GUID.

This way there is no farming for player data by lowlifes, or messing with people's accounts. Simple, eh?

reply to this message

#50: Re: ..

by a`baby`rabbit on 01/24/2008 07:35, refers to #49

Very centralised... "The server queries the master server with the player's session key.." - better check that the master server owners are okay about storing that info and providing the necessary bandwidth.

Meanwhile I thought that the cheating was at a low at the moment... did I miss something?

reply to this message

#51: Master Server

by dfhkshjkfsdconorbhjfkdshkj on 01/24/2008 15:35

If you need a master server for this, I will gladly run it.
Great connection, 20megs down, 3 up.

reply to this message

#52: ..

by ezombie on 01/24/2008 16:59

Thanks, but we got a dedicated server in a datacenter in Seattle. I have had it waiting for when I picked my crusade. Even ran some ET:QW servers on it. I have contributed to various BSD projects before, and now I'm in a point of my life (kid is graduating this spring) where I want to do a big hobby project.

I checked out the CVS last night and starting to sculpt a base set of projects in Eclipse (my torture instrument of choice). I see there is some md5 goodies lying around. I also noticed how thick the client really was. Not a bad thing, as I do want to keep as much on the client as possible.

I wasn't planning on encrypting anything, unless we have to. The players password will be SHA hashed. And using the 'triangle' setup means that encryption shouldn't have to be used.

reply to this message

   Board Index