The Supreme Cube Engine Game (temp name Slayer)

by Nixot on 07/06/2010 14:12, 50 messages, last message: 08/23/2010 02:43, 27197 views, last view: 05/19/2024 03:48

Hello everybody.
Some of you may recall a mod of Cube I posted a while back called "Newcube". This time, I have gone further. If you don't want to read all this, just skip to the demo video at the bottom.

I propose to bring together all the best bits of the Cube mods there have been to create one "super Cube", and also to make a cool SP campaign and multiplayer maps too. I've been working in secrecy on this for quite a bit now and have decided to give it a bit of public exposure.

I have already integrated fisheye rendering from Fisheye Cube and all pCube mods, plus fixed several bugs and added lots of tiny features, but I have yet to integrate Rick's Cube But mod as I have been busy creating levels to get ready to test it with people.

The theme of the game is as of yet undecided, but I've been leaning towards a sort of sci-fi thing like there was in Doom 3, but I've been playing a lot of F.E.A.R recently (I completed it in a week) so I want to add in a bit of a scare factor and lots of darkness too. Anyone who's played the original Newcube, expect to see quite a lot of metl4ish and exol2 looking maps.

I'm not expecting everyone to rush forward, but if you want to be a playtester then feel free to e-mail me (click on my name at the top and reformat the e-mail address).

And now for a demo video: http://www.youtube.com/watch?v=QrIW5VekRRk

Thanks for reading (if you did)!

   Board Index   

#41: Re: ..

by LeftClicker on 07/17/2010 23:36, refers to #38

"The problem you referenced in your last post was about cheating. If I distribute the source code the same, people will be able to change it and still be able to enter servers, thus enabling cheating. Wouldn't that defeat the object?"

Me being of the hardcore "read-everything" type, I was reading something and thus didn't have time to read his hell of a post. I thought he was talking about how Linux users would have to compile and thus be screwed for playing on normal servers. Also, having one set in the code would kind of lead to an underground server specifically FOR cheat gameplay wouldn't it? That would be kind of cool—let the cheaters get it out of their system.

reply to this message

#42: Re: .. does anyone actually read the subject?

by Whales ( Dthdealer ) on 07/18/2010 11:16

====
The problem I get with apt is usually the packages A) are outdated or B) want to remove half of the packages on your system, thus breaking everything majorly.
====
If you have used apt on Debian before, you have probably used the 'stable' release. This contains packages out of date only because the dev team is certain that even if you threw a brick at a system running software from the 'stable' tree, it will not falter.

Debian is a confusing OS in this department. It is unwise IMHO to ship the default distro as the stable release, when most people use the 'testing' release anyway ( where everything is up to date and more packages exist. Don't judge it by its name - it is stable ). Those who are hardcore go for the 'unstable' release where most packages are whacked in from svn with little testing. Complicated isn't it? That's why I'm sticking with Ubuntu.

I've never had your second problem with apt. Incompatibility rules are only in place where it is a fact that the package you want to install does not function or breaks the function of other packages when installed with another certain package. In most cases it is under-sensitive rather than over-sensitive as you describe it.

====
The problem you referenced in your last post was about cheating. If I distribute the source code the same, people will be able to change it and still be able to enter servers, thus enabling cheating. Wouldn't that defeat the object?
====

Sorry, I was talking about the issue that caused me to ask about the release rather than the contents of the post itself - my fault here.

====
Solution 2 sounds pretty cool. I could make the server process checksum the client against itself, and if the client is different the person is denied access.
====

This will work with the same effectiveness as a lock on a door. Most cheater will give up but there will be a few that know how to 'pick the lock' and supply the official binary for checksum while they themself use another. Please excuse the use of a 'singular they' just then.

If you can do it then it would help prevent cheating effectively, but a known bypass method is known so a cheater could just upload a cracked executable to the web for others to enjoy.

====
Master and auth system in sauer very useful aginst cheaters. Makeing protocol of official bins incompatible with user compiled will not save the game from cheaters anyway, think not so hard make external aimbot for example. And one more reason for example cube 1 not have official bins for FreeBSD.
====

It is harder to write software that injects into in the binary than it is to edit the binary yourself. A known way to stop cheats such as this is employed by Assaultcube where everything goes skewy ( massive lag, draw errors and crashes ) on the client when its memory footprint is changed even in the slightest by an outside program. Just try using scanmem ( linux ) or cheatengine ( Windows ) on Assaultcube while not playing online and you will see the effects.

Possibly the best option for an official release of binary is to compile a universal all-system one that is slightly larger but covers everything from Mac to BSD and then also a Windows version ( notice how Windows still requires special treatment? ). I don't know how though, sorry.

====
Remember that you should NEVER trust the client.
====

I'm a client you know!
*cry*

====
So unless you want to get into all kinds of encryption, the best thing to do would probably just be to set the network protocol magic to a known offset for the official binaries, then make sure you never disclose that offset.
====
This was employed in the official release and is what stops people like me and degrave3 playing the game with people who use the official release online.


====
Me being of the hardcore "read-everything" type, I was reading something and thus didn't have time to read his hell of a post.
====
Nice one ;) Point understood though.

====
I thought he was talking about how Linux users would have to compile and thus be screwed for playing on normal servers. Also, having one set in the code would kind of lead to an underground server specifically FOR cheat gameplay wouldn't it? That would be kind of cool—let the cheaters get it out of their system.
====

Most Linux users would not have to compile, it is just I have a 64-bit processor in my computer and so use the 64 bit version of my operating system to exploit its full potential. 32 bit operating systems cannot address ( use ) more than 4gb of ram and cannot handle as big numbers as 64 bit systems can ( eg my computer can (sic) hold the life of the universe in seconds in one integer ).

Most 32-bit programs don't care if they are run in a 64-bit environment, but games tend to. They only accept libraries that they know are the right thing for stability, and consequentiality anti-cheat purposes. As far as the 32 bit version of cube is concerned, my libraries are corrupt, so I had to compile it for my 64-bit system. Compiling the 32-bit version from source would be just as hard in many ways.

On the second point you raised, I don't think anyone would host a master server for the non-official releases unless they are major mods, in which case the same annoying technique would apply again to stop cheaters among other legitimate users.

The guaranteed way to stop cheats is to employ a thick server thick client ( or thick server thin client such as the Onlive service if you have the bandwidth and money ) model rather than cube's current thin server thick client model. Perhaps even a thin server extra-thick client or p2p system would be better, but that is taking the cheat-protection into the hand of the clients which would require a big rewrite.

Currently, the client works out where that client's player should be and when he fires etc. The server just bounces all of the information to the other clients and keeps track of map, score and time amongst some other simple chores. Here a cheater's packets that show him moving along the map at warp speed are accepted by the server and sent to the clients who also accept them ( although their users' won't! )

If the server also ran simultaneously a version of the game that is slightly modified so it runs the physics as the client would between receiving the packets ( take a sentence breath here ) and logs data that tells how far away the packets are from what is physically possible on a legit game then another easily written piece of software would then check to see if these margins of error have been burst and tells the server that the player could not ( for example ) have moved 8 metres in one second when he should have only been able to move 5 metres in that time, give another metre of error making that 6. Boom! Kicked. A repeat offence would automatically ban him/her. Even if he/she is not running cheats and some strange glitch is speeding him/her up, we can't have him/her playing with such an advantage until it is fixed.

There are two reasons you would take the client code to do this rather than running it inside the server:
1) Re-writing the code in the server would introduce errors where you may forget certain parts of cube physics and lets say ban the users when they jump rapidly in water to gain height quickly.
2) The server thread may run at a different cycle rate, and putting the client in a different thread would allow hardware optimisations such as running it on a different core.

The extra-thick client model would have clients doing the cheat detection and if they don't like another player the rest of the players in the server simply ignore ( drop ) information/packets concerning that player and not compute them. If many clients do this the player will have no effect on anything but his own score. Here just a little bit of code in the clients that tells the server when they are ignoring the player can tell the server to kick the cheater when a dozen or more clients simultaneously tell the server the cheater is cheating. Here however the issue arises of exploitation of clients where the players run a modified binary that allows them to manually send the signal to the server and the players all gang up on someone they don't like.

The p2p method requires no server, where players send data directly to each other. The method of above can be applied here. Two methods of doing this exist, both with major drawbacks

1) All clients send each other all data

In a normal client>server relationship, you are sending and receiving one lot of information both ways. If you have 6 players and are using this method, you are transferring six times that amount of information! Lag and burst internet caps ahoy.

2) Clients chain information together

Here two problems occur. One is that for information to be sent from one end of the chain to the other, the time between each client will add up. If on average we have 200 milliseconds between 6 clients, it will take 1.2 seconds for information from one end to travel to the other. This can be countered by each player sending information to a couple of others, but this builds up depending on how many players there are and applies the problems of P2P option 1.

The second issue is that information may be poisoned before it reaches the other end. This ranges from accidental corruption and packet drop to lack of synchronisation to evil players trying to ruin the game. What happens if a player crashes? A whole wave of packets is lost until the broken chain is re-linked.

Sorry if I have any grammatical mistakes here, I can't be bothered to read all of this again right this minute and there is not edit option in these forums.

reply to this message

#43: ..

by Quin on 07/18/2010 22:50

2 x TLDR

reply to this message

#44: Re: ..

by LeftClicker on 07/19/2010 02:31, refers to #43

On a scale of one to Whales, I'd put Quin closer to one. And while you have your awesome "<code link> Yeah, we did this a few years ago. READ." posts, some of yours are quite long. But this guy...

reply to this message

#45: Re: ..

by Whales ( Dthdealer ) on 07/19/2010 03:31, refers to #44

Sorry guys, I go off on tangents. I'll keep things down from now on.

====
And while you have your awesome "<code link> Yeah, we did this a few years ago. READ."
====

?

reply to this message

#46: Re: ..

by LeftClicker on 07/19/2010 05:17, refers to #45

That's something Quin does. He'll respond to a post with a link and some text saying "Yeah, implemented in Blood Frontier/Red Eclipse/Platinum Arts/AssaultCube." I guess I might be acting like a complete stalker, but I tend to remember stuff pretty well.

reply to this message

#47: ..

by Nixot on 07/19/2010 09:17

Sorry whales, but your posts are indeed quite long. I read through them all, and I really appreciate your input, but you must remember that this is an internet forum and posts are meant to be short.

And also, I don't care if red eclipse has all Tue features I want to add in already! The gameplay and physics is completely different than my game! Just give me a chance to add it please.

reply to this message

#48: Work continues

by Nixot on 08/13/2010 23:03

Hello everyone.

Just thought I ought to update this thread since I've made some significant progress on the project. I've added a spectator mode, fixed jump pads and bots, added team skins and fullbright player models, as well as several new editing features and bug fixes.
It's at a point now where I'll start asking for help to playtest some new features and also have a few games. Because of the way the bots are programmed, playing with players is a completely different experience code-wise than playing with bots, and I want to make sure that both points of gameplay work perfectly.

So, if anyone is interested in playtesting Slayer with me, deathmatching, CTF-playing or coop editing, don't hesitate to e-mail me (you can click on my name to e-mail me, but don't forget to replace -AT- with @).

I'm also looking for someone who can map in Cube 1 and wouldn't mind making a few maps for me. Currently, there are four maps.

I know I haven't shown anything to the public since that aging demo video, but remember that if you do playtest with me you will have the game in its entirety, ten weapons and all, which should be enough for anybody. All I will ask is don't distribute it to anyone. Thanks.

Thanks for reading (if you did).

reply to this message

#49: Re: Work continues

by Whales ( Dthdealer ) on 08/15/2010 13:08, refers to #48

Keep it up :)

reply to this message

#50: Re: ..

by LeftClickersPhone on 08/23/2010 02:43, refers to #47

I understand that RedEclipse's features are not very relevant to Slayer's, and I don't know much about game design beyond theory, but wouldn't it be helpful to se how someone else had achieved your goal? (I say this as a general question.)

reply to this message

   Board Index