Enemy Territory + Cube 2 = wOOt?

by ezombie on 01/19/2008 16:25, 258 messages, last message: 04/03/2008 21:39, 172727 views, last view: 05/05/2024 19:57

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   

#239: Re: ..

by MovingTarget on 02/19/2008 00:18, refers to #238

Doesn't [not releasing the source] kinda nullify "open-source"?

reply to this message

#240: Re: cheaters

by tentus_ on 02/19/2008 00:20, refers to #235

Interesting idea pitched to me by a 5-year-old today: we were goofing around and he innocently asked "Why not just put the cheaters in a make-believe match?"

Not a bad idea, if you think about it. Rather than kicking players out of a game entirely, just kick them into a game inhabited by bots without any external signs. This obviously requires fairly complete botcode, but it's been done before. End result is that both sides get what they want, or at least they think they do.

reply to this message

#241: ..

by ezombie on 02/19/2008 00:44

And what does not releasing the source do, exactly (but to slow down development)?

I love how people say *well, the hackers are so good they will just walk around your barriers* - then in another breath they say *if they dont have the source, it will be so hard they wont bother*

You cant have both viewpoints. They kinda contradict each other.

reply to this message

#242: Source

by hdsfkjshconordhfjks on 02/19/2008 03:30

Why not give the source away, but leave the authentication out.

Or, do what they did with Cube 1, change things in the released source than what you have in the binary.

One problem: You are going to want someone 'trusted' to compile *every* binary: Mac os x, windows, windows x64, linux, linux x64, etc.

reply to this message

#243: Re: Fried gold

by a`baby`rabbit on 02/19/2008 03:48, refers to #233

Streaming the client game control bytecode from the server is a fun idea! To that end (as a mac ppc user) does lua now support cross-platform bytecode (as opposed to native)? - this used to be an issue...

reply to this message

#244: Re: Source

by ezombie on 02/19/2008 03:54, refers to #242

This was an early suggestion. But what is to keep someone from using the proper authentication, then cheating afterwards? I hear some saying *just hash and verify the binaries*...

From a purely technical standpoint, that path is fraught with roadblocks and speedbumps. On Linux it's almost a joke (PB still has trouble doing it - after many years of dev). On Windows they had to switch to using two separate system services. I just don't see enough bang-for-the-buck when using that feature.

And then there is the point that the client game logic *has* to be published for servers admins to customize it. This is where 80% of any cheating would occur anyways.

In the end, such *drastic* measures (as I would call them) should be reserved as a last response if and when rampant cheating starts to occur. A system that inherently doesn't reward cheating is a much better early response to such concerns.

Listen to the little kid - he knows what he is talking about.

reply to this message

#245: ..

by James007 on 02/19/2008 04:01

I am not worrying about cheating, i havn't seen anything to bad in opensource games like this(or the other 6 mentioned). I am more concerned about where the game is actually headed, i just hope it doesnt end up a watered down version of W:ET(I only hope for the best outcome).

reply to this message

#246: Re: Fried gold

by ezombie on 02/19/2008 04:23, refers to #243

Good question.

Let's see, we have three platforms to support - Windows (Intel), Linux (Intel), and MacOSX (???).

Since we are using a fully embedded (staticly linked) Lua VM, this means that we don't have to worry about what version of Lua the machine might have on it (if any).

I think the issue of 32 vs 64bit is a bigger one then endianess. One could simple set the load function in the Lua code to byte swap if needed (since the endianess is stored in the header).

But if one compiled their ET:CE on a 64bit Linux installation, then the bytecode would not work without serious massaging.

Perhaps, since it is so temporal anyways, we could just LZO the source off to the client? Compiling Lua does NOT make it run faster, since it compiles it upon loading if it is not already. This only take a fraction of a sec for even BIG files.

The main benefit of pre-compiling is 1) you get to check it for errors, and 2) to hide the source by removing all names and comments.

reply to this message

#247: Re: ..

by ezombie on 02/19/2008 04:26, refers to #245

Don't worry, I'm pretty picky & passionate about my games. I even still play ET an hour or so every day.

Of course, if you don't like the game on one server, just find another running a different version ;)

reply to this message

#248: Re: Fried gold

by ezombie on 02/19/2008 04:46, refers to #246

Oops, spoke too soon.

Seems the current version of Lua has much better 64-bit support. It can run the bytecode from a 32bit machine on a 64bit machine. It also does the endian swap (if needed) as well.

So it appears that we shan't have any problems using shared bytecode for the various Sauer targets.

reply to this message

#249: Re: Fried gold

by fhsdfjkhsdkconorhfjkds on 02/19/2008 05:06, refers to #246

You said Mac OS X(????)

That would be Intel (64Bit?) and PowerPC.

You can have a universal binary which runs on both Intel and PPC architectures (And in theory also ARM, which is what the iPod Touch, iPhone, and iTablet run)

reply to this message

#250: Re: Fried gold

by ezombie on 02/19/2008 06:21, refers to #249

Well, PPC is big endian IIRC - so that will be covered by byte swapping in the loader.

Arm... who knows. Not sure the iPhone could run Sauer anyways (Oooo, now there is an idea)

As to the *watered down ET* comment, that got me chatting with some others. I hope that even if we completely duplicated current stock ET, adding nothing new, it would be a great improvement:

1) Maintained code. Mods have had to step in and finish it. Many (at times serious) engine quirks/bugs have remained, since that is not the open source part. Most people with Vista cannot even run the game.

2) Easier to make maps. Granted that many good maps have been made for ET over the years. But the supply is dwindling, and many newbies out there have great ideas for maps but lack the complex radiant skills to make them work.

3) Lag-resistant netcode. This is a BIG one. Playing ET with over a 100 ping means you will die, and die often - regardless of skill. Most pro players refuse to play on servers with over 100 ping for this reason.

4) Ease of customization. Our framework gives just about anyone the ability to make their own *mod*. Only those with gobs of time and well developed coding skills can even hope to unravel the spaghetti that is the ET SDK.

I'm actually fighting adding more stuff then is found in ET. Just the stock gameplay + updated models and weapons is what I'm focusing on.

reply to this message

#251: Re: Fried gold

by ezombie on 02/19/2008 06:26, refers to #250

Forgot #5:

Performance on older hardware. I get 50-80FPS in ET. On the same machine and resolution I get 120-190FPS in Sauer. This is remarkable to me, any way you cut it.

reply to this message

#252: ..

by James007 on 02/19/2008 17:56

ah, well im hoping for a better ET what ever happens. I hope the fact that we're looking out for people with older hardware, it doesnt mean it will cripple the fun for us with good machines.

reply to this message

#253: ..

by smartalco on 02/19/2008 23:14

on the OS X thing, just having a universal binary will solve everything (intel and powerpc, as well as 32bit or 64bit, for leopard anyway, i suppose if you have 64 bit tiger your kinda screwed...)

reply to this message

#254: Re: Mac

by ezombie on 02/19/2008 23:32, refers to #253

I'm not sure you are understanding the problem. We are talking about the VM bytecode, not the executable.

But luckily the Lua VM source code is very clean and easy to understand, so customizations are a piece of cake. A couple of #ifdefs and it should work fine.

reply to this message

#255: progress update

by ezombie on 02/19/2008 23:37

Weeee!

We got OpenGL working from the VM now. Here is the beginnings of our radar:

function client:drawradar(x, y, radius, alpha)
gl.Color({1, 1, 1, alpha})
sauer.settexture("data/radar.png", false)
gl.Begin('QUADS')
gl.TexCoord({0, 0}); gl.Vertex({x - radius, y - radius})
gl.TexCoord({1, 0}); gl.Vertex({x + radius, y - radius})
gl.TexCoord({1, 1}); gl.Vertex({x + radius, y + radius})
gl.TexCoord({0, 1}); gl.Vertex({x - radius, y + radius})
gl.End()
end

Still hammering away at porting the reference fpsgame classes over to Lua - one method at a time. This last inclusion should make things go a bit faster. Once enough is in the VM, our script guys can take over much of the logic coding and I can focus on internals again (like adding triggers).

reply to this message

#256: Further Progress?

by Brianv on 04/02/2008 21:13

Is there any further progress on this? I\'ve checked out both this thread as well as the website and SF page, and things seem to be dead since late February.

Hope this is still rolling, sounds like a great idea!

reply to this message

#257: ..

by IllvilJa on 04/02/2008 22:29

That's less than two months of inactivity, so I would not worry about this project being dead. Not intended as sarcasm, I know how projects of this kind often seem to be developed in bursts of activity interleaved with more "calm" periods.

But yes, I also hope it keeps going.

reply to this message

#258: ..

by RealNitro on 04/03/2008 21:39

Check their forum: http://www.usef-et.org/forum/viewforum.php?forum_id=11 The last update was today. ;-)

reply to this message

   Board Index