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, 27128 views, last view: 05/05/2024 10:38

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   

#31: Re: Great!

by Quin on 07/13/2010 19:16, refers to #30

If I'm viewing the OP correctly, this is Cube, not Sauerbraten.

reply to this message

#32: Punching Fun

by Whales ( Dthdealer ) on 07/14/2010 03:59

A suggestion to aid melee punching/kicking

in weapon.cpp

{ *SOUND*, *DELAY*, *DAMAGE*, *SPEED*, *PART*, -100, "*WEAPONNAME*" },

Keeps you following your enemy when you punch them, useful if they are running away.

A negative integer ( signed? I don't know ) is accepted here and it works in-game, where the kickback sends the player forward instead of backward. No other modification is necessary.

Keep up the good work :) Can't wait to see those sparkly emitters in a release.

reply to this message

#33: Re: Punching Fun

by LeftClicker on 07/14/2010 06:24, refers to #32

Negative integers are signed: http://en.wikipedia.org/wiki/Integer_(computer_science)#Value_and_representation . And I doubt these will be integrated into a release unless Nixot and eihrul /both/ want them there, which IMHO seems somewhat unlikely.

reply to this message

#34: ..

by Nixot on 07/16/2010 23:25

Bots have been fully implemented! Also, players are now split into two teams (red and blue), like in Assault Cube, so now your teammates are displayed the right colour, even if you're on the red team. :P

Also I'd like to say a big thank you to RaZoR, Zethus and Bombadealar for playtesting with me and verifying that CTF and other modes work. Thanks guys.

reply to this message

#35: Re: ..

by Whales ( Dthdealer ) on 07/17/2010 04:08, refers to #34

*drewl*

Will you employ the anti-cheat of the official cube where the binaries have a slightly different netcode to the source? Is so, I please ask you distribute a 64-bit executable as well :)

reply to this message

#36: ..

by Nixot on 07/17/2010 11:15

Most likely so, but you'll have to tell me which bits to slightly change because I don't know how to reverse engineer the Cube executable into source code. Would it just be a simple matter of changing the net protocol number?

And I wouldn't know about the x64 release. If you could compile a binary for me for a release I would be most pleased, since you compiled it on Linux, which is far more challenging than compiling stuff on Windows (or not, I may just be a tremendous noob).

reply to this message

#37: Re: ..

by Whales ( Dthdealer ) on 07/17/2010 15:38, refers to #36

= = = =
Most likely so, but you'll have to tell me which bits to slightly change because I don't know how to reverse engineer the Cube executable into source code. Would it just be a simple matter of changing the net protocol number?
= = = =

I don't personally know. The networking from the source version works, but AFAIK cannot be played online with/against players with the official binaries and visa-versa.

Here is an excerpt from the readme which came with the source.

= = = =

CHEATING
========
If you want to use cube as a base for a game where the multiplayer aspect is
important and used by a large community, you need to be aware that cube's
thick client - thin server architecture is extremely cheat sensitive. If you
release a cube based game with source code equivalent to the binaries, some
minor changes can give anyone an aimbot or other cheats in online games.
There are several ways to make this less easy, some of which are:

1. only distribute binaries (the ZLIB license allows this). Executables can still
be hacked, but unless you have a really large online community, noone will
probably bother.
2. write a network proxy, such as qizmo used with QuakeWorld (whose sources are
also open source). The proxy is a small closed source program that checksums
the executable, and maybe also some game media. You can then make servers
or game admins request this information and ban cheaters.
3. release the sources with an incompatible network protocol or other changes
compared to the binaries you release.
4. build serious cheat detection into the game. Since all clients are their own
"servers", you can make them all keep track of stats for the other players,
such as health etc. you can make all sorts of consistency checks on shots,
movement speed and items. If the discrepancy for a certain client becomes
too big, all clients but the cheater can send their "vote" to the server
for having him banned. Even better, you can add server side stat checking.

For the cube's own game I chose option 3, i.e. you can only play the official
cube game using the binaries supplied by me, and you can't compile your own clients
for multiplayer use (you can still make custom clients that work with matching
custom servers, or play cube single player maps compatible with the real thing).
This situation is not ideal, but there is no easy way around it.

This scheme is probably very easy to defeat if you are capable of using disassemblers
and packet sniffers, but please contrain yourself and don't ruin the fun of the
cube multiplayer community. Thanks.
= = = =


Back to your post


= = = =
And I wouldn't know about the x64 release. If you could compile a binary for me for a release I would be most pleased, since you compiled it on Linux, which is far more challenging than compiling stuff on Windows (or not, I may just be a tremendous noob).
= = = =

Compiling on Windows is of equivalent difficulty if the code is written well to be cross platform ( using SDL, openGL etc such as Cube uses ). The difficulty only comes when a piece of software is written for only one platform. As long as you don't use any windows specific ( hooks? ) resources ( ie directX, referencing files using the C:\folder\file structure rather than $root/folder/file ) everything will be fine, but I doubt you will even do this by accident with what you are doing here.

As long as the source code you release is the same as the source you used to compile the .exe s you released the problem I referenced in my last post will not exist. Most linuxers that play games seriously on the platform know how to compile games ( to get the latest release earlier normally ) out of curiosity, not necessity.

If you have never used a Linux system before, have a look at Ubuntu, (www.ubuntu.com) which you can download and burn onto a disk. It can be run right off the disc without the need to install ( but extremely slowly in this state ). Just go and idly look at http://www.getgnulinux.org/ for a while.

The advantages cube has ( being written in a cross-platform manner ) also include using the best technology. It is a proven fact that openGL, no matter how much Microhard advertises their latest directX release, gives higher framerates at the same or better quality. Benchmarks are available on the Nvidia site somewhere to prove this. Features such as tessellation as you get closer to objects that Microsoft markets DX11 with have been an openGL extension for years. The only reasons game manufacturers use DirectX is that Microsoft commonly sponsors them and because it is a glitchier and a closed-source API, it is harder to reverse engineer and make cheats for ( than openGL ).

Compiling was once easy for cube under Linux, it is just now the technology is moving on and most of the cube code is outdated. Using an environment like you would use on Windows ( eg Visual Studio ) would fix the problem ( eg Codeblocks:: on Linux ) but most of us prefer to do this:

$ cd DIRECTORYWHERESOURCEIS
$ ./configure # Tells you whether or not you have everything needed installed to compile and sets a few things up to make the process faster
$ make # Compiles the game/software
$ make install # Moves the binaries to the right location and sets everything else that does not need to be compiled up

Modern Linux distributions ( such as Ubuntu ) simply give you a program that gets a list containing tens of thousands of free programs from a repository, and allows you to tick and install them easily. Think of it as a site full of safe free .exe s ranging from document processing suites ( eg OpenOffice ) to 3d modelling software ( eg Blender ) to web browsers ( eg Firefox ) to toy programs to MMORPGs to first person shooters ( eg Cube2 ) etc. Except rather than browsing the website you just have a list in a program you launch from a menu with tens of thousands of free programs in it sorted into categories and maintained so that none of the contain malware.


http://danlynch.org/blog/wp-content/uploads/2009/10/karmic13.png

Here is a good picture displaying such a program, however it is only showing a few dozen in the list on-screen as it is currently being told to display only the installed packages. My system contains many more ( 100+ ) including full fledged first person shooters such as Nexuix, Sauerbraten and Tremulous as well as a whole office suite, the operating system and graphics editing programs similiar to the adobe suite, but due to the modular ( rather than monolithic ) operation of Linux systems I have only used 7.7gb not including personal documents. Gotta love that. Did I mention I don't need antivirus?

Back on topic, I'm not a reliable person to ask to compile the source from. The article I posted on how to do it is a quick hack that piggy-backs the official release and does not provide full functionality. If I can work out how to solve these issues everything will be fine.

The major issue is the inclusion of the enet system to be statically compiled, meaning it is put inside the main executable. This is neccesary to have the Windows port working but causes havoc years down the road when the included version is heavily outdated. My earlier ravings on the nicety of the cube source do not cover the netcode and lack of commenting ( grrr in some places ) regularly.

Regards, Whales.

On an unrelated note, I've discovered a nickname clash with Whales in the Tremulous community. There I am known as Harpoon.

reply to this message

#38: Re: ..

by Nixot on 07/17/2010 16:20, refers to #37

Thanks for your really long introduction to Linux, but I have used several Linux systems (Debian, Ubuntu, Eee PC Linux, Puppy, Slax, Mandriva) and also apt. 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.

"As long as the source code you release is the same as the source you used to compile the .exe s you released the problem I referenced in my last post will not exist."

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?

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.

reply to this message

#39: ..

by degrave3 on 07/17/2010 17:34

Master and auth system in sauer very usefull 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.

reply to this message

#40: Re: ..

by SheeEttin on 07/17/2010 22:01, refers to #38

Remember that you should NEVER trust the client.

Even if you ask for a checksum, the user could replace your program with their own that just gives the correct checksum every time.

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.

Completely preventing cheating is a pipe dream, so don't waste your time. Anyone who really wants to cheat will find a way.

reply to this message

#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