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, 27132 views, last view: 05/06/2024 08:18

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   

#21: ..

by yoopers on 07/12/2010 23:43

Great discussion, but one needed feature has gone unmentioned: will there be rocket-powered ponies?

reply to this message

#22: Re: ..

by Quin on 07/13/2010 00:05, refers to #19

Red Eclipse has kicking and rocket boots already? :P

reply to this message

#23: Re: ..

by tentus_ on 07/13/2010 02:29, refers to #22

But it has lots more, obviously. I'm visualizing a game that is primarily focused on the boots, like how Portal was primarily focused on the Portal Gun.

reply to this message

#24: ..

by Pieter on 07/13/2010 02:51

"Bulletstorm"
http://www.youtube.com/watch?v=4HfCqw_8iKo

Lots of kicking action

reply to this message

#25: Re: ..

by Whales ( Dthdealer ) on 07/13/2010 12:22, refers to #13

====
Oh, and Whales (Dthdealer) (what name do you use anyway?), why on earth would you want the railgun to shoot through walls? It would be pretty hard to do, and I see no logical reason why it would happen.
====

I prefer Whales, but I also am known by the nick Dthdealer in some forums I don't participate in any more. I keep my old nickname in my current name as often as I can.

"why on earth would you want the railgun to shoot through walls? "

Why not? :) No offence intended.

Currently cube only handles bullets and rockets, that simply apply damage and/or explode when they hit something. One method to add more fun to a game is to make some weapons have more features, ie remote explosives that stick to walls and players, bouncy projectiles, gravity-affected miniguns etc.

"It would be pretty hard to do..."

Probably, but possibly the way cube is written allows you to duplicate the code that checks when/where a projectile will hit and change it a bit so projectiles are not stopped by walls. I don't know myself.

reply to this message

#26: ..

by Razgriz on 07/13/2010 12:53

can we get Buzz's hand lasers too? that fires portals using rainbow rays?

reply to this message

#27: Re: ..

by Nixot on 07/13/2010 15:57, refers to #23

Inago rage.

Whales, no offence taken, it just seems a bit counter logical.

Razgriz, I don't know what you mean, sorry. If you're talking about a portal gun like in Portal, no can do. A) it would be nigh on impossible to create and B) I don't plan to include anything like that.

Meanwhile, development on Slayer continues. I have fixed the old problem of ammo resetting when you enter a new level in Cube, and have started work on the SP campaign today!

Also, to everyone, could you make the thread a bit more on topic rather than about games that aren't Slayer? Thanks.

reply to this message

#28: ..

by degrave3 on 07/13/2010 16:48

Nixot: do no attention posts before if you don't want Blood frointer's fate ;)

reply to this message

#29: Re: ..

by LeftClicker on 07/13/2010 17:41, refers to #27

I'm pretty sure Razgriz was being sarcastic and talking about including the hand lasers of Buzz Lightyear (you know, the space ranger from Toy Story). Then he said something about portals and rainbows, and I was left in the intellectual dust.

reply to this message

#30: Great!

by freegamer on 07/13/2010 18:53

Glad to see somebody taking on a single player verison of Sauerbraten. There's so many great resources on quadropolis, so hopefully you can get quite far before running into needing new models.

I guess more monster models is the main issue. There are a few good models on http://www.opengameart.org/ though.

reply to this message

#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

   Board Index