JK:JA Competitive Mod (Brainstorming)

[Guest x0nic]

Hello folks,

 

I guess everyone who ever tried to play JA in some more serious and competitive way somewhen became kinda fed up with the major role that cfgs, cvar- & "lag"-unlockers (etc.) can play. Obviously, the only ways of creating sufficient e-sport conditions for JKA are either to port the whole game to another engine, or to see what could finally be achieved by modifying the openJK code.

Being aware of the fact that the Q3 engine clearly ain't the most convenient solution for such a kind of game, I still think it could be possible to improve the fairness of matches by implementing some basic but appropriate multiplayer-code enhancements.

I thought about that yesterday, and do now want to present you some of my ideas. Feel free to give me feedback of any kind

 

 

What we need

1. An anticheat-workaround for avoiding runtime memory patches

2. The same fixed netsetting values for every client on the server

3. Client- AND server-sided code improvements

4. Some cfg-freaks who REALLY know what JKA cfg-tweaking is about (since my personal knowledge is rather limited)

 

 

My suggestions

 

1. The "Anti-Cheat-Engine"

I don't think that the implementation of some external memory-surveillance program like punkbuster would make people happy.

My idea was to make the client regularly create hashes of static parts in the game process memory on runtime (e.g. SHA-1/256 or MD5 - the latter being already implemented for pk3-integrity checks on pure servers) and send it to the server in a special packet every 10 to 30 seconds (chosen randomly). I doubt that his would have a serious impact on the bandwith or FPS performance. Do you?

 

However, the server then simply compares the hashes (i.e. the client-hash with the concrete hash of a trusted jamp-process) and either kicks the client directly or at least displays an according svsay message for every player if the given strings don't match.

Obviously, hash-spoofing can be an issue here, assuming the project to be open source. But let's not precipitate things for now and try to keep it simple - this is only supposed to be a basic brainstorming.

 

2. Fixed netsettings/cfg cvars

In order to keep things fair, it's necessary to force certain settings for ALL clients to be the same. This could be achieved by either adding the flag CVAR_ROM (read-only flag, combined with various if/else limiters in the client exe) or CVAR_USERINFO, therefore letting the server read + correct the values, if necessary.

Some of the lethal cmds that everyone should know are:

• rate -> fixed value: 25000 - since lowrate staff players are a bugged pain in the ass
• cl_maxpackets 63 -> the most neutral value that doesn't create unfair advantages for any of the 3 saber types. Plus, it disables lag unlockers (keep in mind that this one correlates with the clients fps rate)
• com_maxfps 125 -> kinda obvious, I guess
• pmove_fixed 1, _msec 8, _float 1
• timescale / cg_timescalefadeend/fadespeed -> This one is already fixed in openJK
• snaps -> I'm unsure if this one should be locked, since we already fixed the rate... But assuming that competitive players usually don't have ISDN, I'd suggest a value of 40
• cl_packetdup 1 -> If we locked snaps and rate, this is just like finishing the job
• cg_smoothclients 0/1 -> Depends on the way we treat timenudge...
• cl_timenudge 0/-X -> Probably the most important one. I think this should either be "globally" zero or set individually (= player-specific) by a continuous void that computes X = (cl->ping) * -1, so that the "virtual latency" of every client is around 0 (The last solution could produce rendering bugs, tho. Plus, it resembles some kind of hardcoded LU... But the main point is >equality< between the players, nothing else)

I'm sure that there are plenty of other settings which influence the gameplay and thereby create uneven conditions between the players. That's where we would need a q3/jka cfg expert.

Points 3. and 4. have already been discussed.

 

------------------------------------------------------------------------------

 

As already stated, I only want to initiate a spontaneous brainstorming. Besides some simple minor changes on the MP client (= some values locked + flagged read-only) I didn't do any actual programming work yet. And to be honest, such a project - if finished according to all the suggested functionalities I mentioned above - would clearly exceed my C/C++ capabilities. That's where YOU come into play

 

And now, just tell me what you guys think.

If a thread on the topic does already exist, please post a link - since the forum search didn't provide me with proper results. Sorry.

 

 

Let it flow!

Cheers,

xnc

[Raz0r]

Most of your suggestions assume security facts that are not true, mostly related to crossing trust boundaries.

 

As someone with experience in gamedev + engine programming, security and competitive play, the only real options are heavily modified OpenJK (See: CompJA on GitHub), or an entirely new engine.

Trying to graft JA onto another engine will result in a game that feels terrible, especially if you don't understand the very intricate parts of iD tech 3's design and implementation (network model, frames and snapshots, rendering, input)

Trying to stick to gamecode changes won't bring the improvements needed for a successful competitive JA.

Jumping the gun with "anti-cheat" is never a good idea. I've seen countless attempts that get all core assumptions on security wrong, and are almost entirely ineffective.

 

But really, the main flaw with this is a lack of experienced coders who are available and willing to put time into it. If I ever do get time again, it'll go into CompJA again.

[Guest x0nic]

Yeah I am indeed no expert on the field Do you have any ideas on how to solve the "hax.cfg" problem without making JKA some kind of radioactive rootkit?

And if I got it straight, you do not consider the client-sided value fix/lock solution for cvars to be a good idea, don't you?

And thanks for the hint to CompJA, didn't hear of it yet!

 

@@Hugo: Yea, I already thought about a U4 porting as well. But you are right: Time and money.... I hoped to find a less complicated solution by patching the openJK code in some way. With a team of 5 to 10 experienced coders who have in-depth knowledge about id-tech3, that shouldn't be an absolutely impossible task. I guess.

[Guest x0nic]

"only focus on single saber dueling"

Actually, the raw concept of JKA's dual/staff sabers is awesome. A decent staff player needs a whole lot more movement/footwork and timing skills than the common poke/wiggle/crouch-addicted single guy. The thing is that the actual saber collision detection and netcode calculations usually suck when it comes to non-single; I guess that's what you were refering to?

 

"We were also limiting it by focusing on maybe three maps and one player model."

Why? There are tons of free community-made .bsp and .mdl (was that the correct suffix? I forgot) files out there which are quite HQ and available for free.

 

"Awful for new players" - "interactive tutorial."

Indeed, good idea. I play it since release (with several breaks), and nowadays, if one ain't able to air-kill a passively jumping staffer with a one-hit poke, you can consider him a noob. And naturally, being a noob is rather discouraging. I always feel kinda sorry for all the poor and clueless newcomers.... and then I kill them. So yeah you're right, a decent tutorial is vital.

 

"We were also aiming to make it not 'star wars' themed."

Avoiding copyright issues, clever. Simply rename the swords to plasma sabers and force powers are too imba for comp gaming anyway, EXCEPT for the high jumps. But we could simply put the arenas on planets with low gravity, explaining it that way, haha

"However, even that never got off the ground."

 

"a whole new game, so that maybe a new audience is attracted."

You got the point. JK's gameplay is absolutely cool and unique. There's a lot of potential, but it needs a proper implementation, i.e. NOT idTech3

And I would consider myself as talented, but lack knowledge & experience in this specific field. I am only an autodidact who had his biggest projects in cryptography, and thus serious game programming is rather new to me (although I wrote several unlockers for Q3 games and created some unplayable maps with radiant, lol). But I love learning new cool stuff and am quite interested gonna try my best

 

----------------------------

 

I've just read the interview with Damian Scott, who says that he already ported certain parts of Jedi Outcast to the Unreal 4 engine for his movie project. Great news, actually! Plus, he's speaking about two mysterious game projects his company is dreaming of...

Do you know more about that? Can I find the ported code parts somewhere?

 

 

EDIT: You may check this video out, if you're interested. It's my favorite JKA fragvid

Most hits of this sicko are absolutely impossible with default cfg

(yt cutted the audio....)

 

 

 

[Circa]

Topic moved to Mod Requests and Suggestions forum.

[Ping]

Most hits of this sicko are absolutely impossible with default cfg

Which is a real shame, given that the game has a lot of potential to be quite excellent. To be fair, we had a great run throughout the decade, with or without the introduction of lagunlockers, cfg exploits and whatnot, so yeah. Who knows, indie devs are quite active on the PC side of things, but I fear that with the quite recent tendency of indie games not being aimed exclusively at a PC audience and seeing frequent console releases as well, we might have a really difficult time finding someone willing to bring us a successor to JKA. Blade Symphony turned out to be somewhat of a letdown unfortunately.

[eezstreet]

I think you're kidding yourself if you think a GPL opensourced game can have reliable cheat protection. That is all.

[z3filus]

not this again:  " the game is old, lets improve it " nobody ever gets anything published so why bother

[Raz0r]

"We were also limiting it by focusing on maybe three maps and one player model."

Why? There are tons of free community-made .bsp and .md3 files out there which are quite HQ and available for free.

Consistency and ease of development.

 

"We were also aiming to make it not 'star wars' themed."

Avoiding copyright issues, clever. [...] and force powers are too imba for comp gaming anyway

But are vital to competitive CTF.

 

I think you're kidding yourself if you think a GPL opensourced game can have reliable cheat protection. That is all.

Hi there. The assumption that only closed-source programs can effectively implement security is "security through obscurity", widely known to be wrong.

The less people auditing your code, the less reputable it is.

 

But again, as I said, jumping the gun WRT anti-cheat is not the way to go. You can't properly identify your threat model with an incomplete product. You can guess at it, but it will be constantly changing and any implementation of "anti-cheat" or "security" (extremely varying terms) will be invalidated. Security is something I'm passionate about and it's often done so incredibly fucking wrong because of simple assumptions/lack of knowledge.

[eezstreet]

The method your link describes is a glorified whitelist of program signatures. SAC was doing this years ago and you're implicitly talking shit about it. Not to mention that this method is easily hacked. Patch the agent program to always pass along a correct GUID. If you're going to act like an arrogant dick, then a) post your own suggestion, not somebody else's and b) post one which I won't be able to crack in 2s

[Raz0r]

I'm not talking shit about SAC :<

jdolan's method relies on hand-shaking with cryptographically-secure public/private key exchange paired with a cryptographically-secure one time pad (misnomer to call it a GUID)

If that part is implemented correctly, it is not feasible to hack or bypass. The "one time" requirement means that message does not persist, you can not use it again.

Because you can't forge that one time pad, you must be running the secure agent and generate the correct tokens.

 

Once the connection is trusted (i.e. a trust boundary is established) then further checks can be performed reliably.

 

This doesn't cover the threat model, though. This only ensures a trusted client on a small set of data (i.e. verify a certain piece of code is running, not verify a certain piece of code is NOT running)

In other words, it's only step 1 of a particular "anti-cheat" method.

There are still many more steps to take to prevent any actions you consider "cheating" as part of your threat model. Most people identify these wrongly, and this is one way false positives can be introduced.

 

If you're going to act like an arrogant dick, then a) post your own suggestion, not somebody else's

That's not a requirement, and I wasn't acting like an arrogant dick @_@

 

The more complex methods used in an anti-cheat system, the less it makes sense to hide the source code. Not providing source does not improve security, which was your claim. You already know about disassembly and the weaknesses of packers, which means you already know hiding the source does not hide the code that executes.

The best method is of course to assume the environment is not secure, and design around that. That's information theory 101.

[eezstreet]

I'm not talking shit about SAC :<

jdolan's method relies on hand-shaking with cryptographically-secure public/private key exchange paired with a cryptographically-secure one time pad (misnomer to call it a GUID)

If that part is implemented correctly, it is not feasible to hack or bypass. The "one time" requirement means that message does not persist, you can not use it again.

Because you can't forge that one time pad, you must be running the secure agent and generate the correct tokens.

 

...

The best method is of course to assume the environment is not secure, and design around that. That's information theory 101.

Yet this model relies almost entirely on a secure environment. It assumes that nobody has tampered with the agent - it doesn't need to scan the signature at all in fact if you just hardcode what is supposed to be a correct program signature into your forged agent program.