Server Help :: View topic - Make a New SS client

Server Help

Trash Talk - Make a New SS client

baseball43v3r - Wed Jan 02, 2008 11:57 pm
Post subject: Make a New SS client

Quote:

What we need is a new client that is cross platform or make a different client that runs on Mac OS X and Linux. Linux doesn't have a lot of games like Continuum. Most people don't want to learn how to play with wine to get it working. With people like GeNe getting a Mac for Christmas meant no more continuum. Imagen the community if we all had a chance to play even if we had some other OS. Linux users would be all over that games because linux lacks a lot of gaming. Linux also has communities that talk about all kind of stuff. We could introduce the game to the community. I think instead of several people making their own client in their spare time, we all need to come together and get ONE client together. We need people that can work with a certain area. Like one guy who understands how the networking goes (does all the packet stuff) one for the graphics (could probably use most of the ones in the graphics folder), one for the GUI, and one for the menus/profiles and things like that.

This would at least work for the ASSS community. We could get ASSS to be more popular and have more players that play ASSS zones. More people use it. Couldn't we do what kirk did with subchat and get it to connect to a subgame zone? That post woke me up. I don't want ss to die.

Here's what we need to decide:
1. Which language to use.
2. Cross platform or several different platform specific clients.
3. Who is going to help
4. Who does what
5. If these efforts will work.

I'll do what ever I can to help.

there, now shut up and stop jacking.

Dr Brain - Thu Jan 03, 2008 12:13 am
Post subject:

Open source is a bad idea for a massively multiplayer game like SS.

Sercit - Thu Jan 03, 2008 12:28 am
Post subject:

Yep. You want it centered with a group of people releasing official copies. If you didn't then you'd need to have a different version loaded on your PC to play from server to server because every programmer will think their version is best.

baseball43v3r - Thu Jan 03, 2008 3:36 am
Post subject:

i was posting on the behalf of DB btw.

Cancer+ - Thu Jan 03, 2008 8:18 pm
Post subject:

Did they ever say that about Linux

BDwinsAlt - Thu Jan 03, 2008 9:30 pm
Post subject:

Well, thats why I said get a few people together. The top SS coders need to come together and do this. Releasing it to the community would be suicide to the game because of the cheats unless we figured out some kind of md5 sum thing.

Doc Flabby - Fri Jan 04, 2008 5:25 am
Post subject:

Acctually I've come up with an idea that will make cheating difficult, even with an open source client.

The key to how to prevent cheating lies in that realising that Subspace itself is just a simulator. The ships on the screen are only an estimation of their current position. All you need to do to prevent cheating is to ensure everyone is running the same simulation. When someone breaks out of sync with the simulation, they are either laggy or cheating. Either way they can be kicked off the server or made to spec. When subspace first came out computers didnt have the processing power to do this, but now they have more than enough power to ensure that every player is playing by the rules. All that matters is all the clients are running the same simulation, not what simulation

Maverick - Fri Jan 04, 2008 7:38 am
Post subject:

I don't see how that differs from the current client, flabby.

BDwinsAlt - Fri Jan 04, 2008 8:39 am
Post subject:

Can't we make it detect different file versions like continuum does? I know I tried to edit a dll onces, then it wouldn't let me play.

Doc Flabby - Fri Jan 04, 2008 9:23 am
Post subject:

Maverick wrote:

I don't see how that differs from the current client, flabby.

The current client assumes everything that is sent to it is correct. I propose a different approach, where it works out if the information being sent to it is valid at the current stage in the simulation. If it is not, it still actions it like the current client BUT IT ALSO reports this to the server. The server then collates these reports. Enough reports and some statistical anaylsis and you have caught your cheater/lagger. Obvious cheating can be caught pretty much instantaniously. Subtle cheating will be caught over a period of time.

BDwinsAlt wrote:

Can't we make it detect different file versions like continuum does? I know I tried to edit a dll onces, then it wouldn't let me play.

All continuum does is check its-self and its dll's for a hash, if it doesnt match, it doesnt run. This check is obsured by continuum's anti-debugging protection - it can be broken, with the source the protection is pretty much pointless.

Bak - Fri Jan 04, 2008 9:23 am
Post subject:

yes but nothings stopping a malicious programmer from making it send "Everything's ok" when it's really not.

Dr Brain - Fri Jan 04, 2008 6:58 pm
Post subject:

Well, assuming you can overcome the small-level speed hacking stuff (big assumption), you've still got a major issue with information hacking, where people can see cloaked ships without having x-radar.

Smong - Fri Jan 04, 2008 8:08 pm
Post subject:

baseball43v3r wrote:

i was posting on the behalf of DB btw.

You mean BDwinsAlt? http://forums.minegoboom.com/viewtopic.php?p=75545#75545

BDwinsAlt - Fri Jan 04, 2008 9:39 pm
Post subject:

At least someone has it right. Cases and all.

Hmm I just realized that I never said open source. Everyone got on a tangent about that.

baseball43v3r - Fri Jan 04, 2008 10:04 pm
Post subject:

currently the client is only known to 2 people i recall correctlly. if you do this then a bunch of people would have it, which kind of implies it to be open-source. i think thats where they got it from

BDwinsAlt - Fri Jan 04, 2008 10:11 pm
Post subject:

Only the top coders would have it. I doubt they would put their work to waste by spreading around the code to other people who, in turn, would cause them to have to stay up late coding protection. If everyone codes, which client is better? Which version should I use? Where is the game going? What does yours have that mine doesn't. That sort of thing would happen. This way only the top people have the source. They each contribute and release one version. Ubuntu releases an upgrade every 6 months. Maybe we should, too.

Samapico - Fri Jan 04, 2008 10:53 pm
Post subject:

about the open source thing: they were talking about flabby's The Continuum Project

Animate Dreams - Mon Jan 07, 2008 8:47 pm
Post subject:

Dr Brain wrote:

Do cloked ships have to have their position packets forwarded to all clients? I'd think as long as the server knew, it would be alright.

Samapico - Mon Jan 07, 2008 10:33 pm
Post subject:

Well, you must be able to turn xradar on for a fraction of a second and immediatly the cloaker... which won't be the case if your client does not receive these position packets

Bak - Mon Jan 07, 2008 10:39 pm
Post subject:

solution: change the feature (put in a delay for x-radar)

Doc Flabby - Tue Jan 08, 2008 7:55 am
Post subject:

Samapico wrote:

Well, you must be able to turn xradar on for a fraction of a second and immediatly the cloaker... which won't be the case if your client does not receive these position packets

A delay of 2 x ping IS a fraction of a second. That's all the time it would take. Server received change of status to x-radar. Server sends back position packet of ships now visible. There's no reason for the server to send packets to you that you can't see anyway. However there would be more of a problem where a player is cloaked but not stealthed...

Dr Brain - Tue Jan 08, 2008 11:33 am
Post subject:

How about position packets from stealthers that include weapons? You'd still be able to change the client to show you those.

SamHughes - Tue Jan 08, 2008 11:36 pm
Post subject:

You still need to be able to see the cloaker get hit by bullets you fire at it while cloaked.

Samapico - Wed Jan 09, 2008 8:00 pm
Post subject:

SamHughes wrote:

You still need to be able to see the cloaker get hit by bullets you fire at it while cloaked.

Yep... good point.

Cerium - Thu Jan 10, 2008 4:00 pm
Post subject:

If you're making a new client, why force yourself to stick to the old protocol? I've had this discussion several times with various people (probably Bak). We came up with the same idea for x-radar, except that you'd also have to add a few things:

- Weapon packets which create/use weapon ids
- A packet which tells a client to invalidate various weapons.

This lets you hide players by simply not sending the packet, and still null weapons that hit them as they're cloaked. The problem it creates, however, is that now the client has the ability to nullify weapons. You'd have to implement some kind of check to make sure it still has the correct number (and correct ids) active.

...and THEN you have lag issues and other nonsense to worry about with the new features -- all so you can truly hide cloaked players from a cheater.

Dr Brain - Thu Jan 10, 2008 4:34 pm
Post subject:

By mirroring the physics and damage simulation to all other clients, you're forcing a lack of randomness onto the simulation. You can't have random damages or energy costs, otherwise someone could implement their own random number generator that always spit out the best possible result. Distributing a random seed for all operations isn't practical in an asynchronous system.

What about movement? Someone could give themselves an acceleration boost, and other simulators might not pick up on that, because acceleration is hard to accurately track with discrete samples and a large sampling time.

You're also putting harder constraints on the networking system, because no packets can be lost. That means higher average latency, in general.

There are so many problems in this vein. Lots of people have said "yeah, open source is good for operating systems, so it must be good for massively multiplayer games", but I've yet to see anyone come up with a decent plan for implementing cheating protection.

Sercit - Thu Jan 10, 2008 5:45 pm
Post subject:

All this talk of client design has me curious. How much would it take for any one individual or group to help build a new game all together?

tcsoccerman - Thu Jan 10, 2008 6:31 pm
Post subject:

I would say a year of hard work?

Dr Brain - Thu Jan 10, 2008 8:11 pm
Post subject:

More like 2 to 3 years, unless they were doing it as a full time job and already had all the programming skills.

Mine GO BOOM - Thu Jan 10, 2008 8:14 pm
Post subject:

Assume they don't need graphics/sounds, I'd give it 6-12 months for a usable client. Then tack on another 1-2 years to fix bugs and implement all the ideas that the coder originally wanted or others suggested to him.

A team of 2-3 can probably get a reliable beta out in 6 months. All this assuming at least 20 hours a week is actually spent designing, coding, and testing the client.

Doc Flabby - Fri Jan 11, 2008 7:32 am
Post subject:

Sercit wrote:

All this talk of client design has me curious. How much would it take for any one individual or group to help build a new game all together?

By then end of 2008 will will find out. http://www.ssforum.net/index.php?showforum=335 http://www.ssforum.net/index.php?showforum=398

TCP can currently connect to a zone, download a map, render it in a 3D enviroment and stay connected. Not sure how much time i've, or any of the team spent on it, but i basically just dip into it when i feel the interest, or have an idea.

This is for the legacy aspect of the game.

The current situation I am trying to figure out, is how to use ASSS in such a way that doesn't break from the ASSS trunk, such that i can modifiy it, but keep up with all the updates. Bak had this problem with the 1.4.4 release of asss. basically his code was designed for 1.4.3 and it took some work to get it working again.

Anonymous - Mon Jan 14, 2008 10:43 am
Post subject:

Dr Brain wrote:

There are so many problems in this vein. Lots of people have said "yeah, open source is good for operating systems, so it must be good for massively multiplayer games", but I've yet to see anyone come up with a decent plan for implementing cheating protection.

Well, Continuum .39 was hackable for years. It was pretty widely known for a while, too. We all saw that. .40 is still hackable, but far less people know how to do it. Either way, my point is the same... we dealt with it. Cheating wasn't a common thing - at least on the SSC biller - the threat of a netban was enough to stop most people. I'm not worried about speed hacking and things of that sort at all because it's obvious when they do it. The only stuff I'd really be worried about is things like cloaked ships. Maybe there's no way to have cloaked ships and hide the cloaker from a cheating player. If that's true, it'd be hard to detect. Worst case scenario, you just have to take cloaking out of your zone altogether. To me, that's still better than not having a new client.

The previous closed-source client projects have all failed, as far as I'm concerned, since we don't have a new client. Even if no one actually used an open-source client, it'd be a great thing to have around, for all future closed-source clients. And all this is worst-case scenario stuff, too. I think it's entirely possible that an open-source client would be able to work. And when a hacking/cheating problem DID come up, there would be people who were able to fix it, unlike our current situation. I'm sure that, once both the server and client were both open source, it would be much easier to write cheating detection programs.

Cheese - Tue Jan 15, 2008 3:11 pm
Post subject:

that sounds like skywize... :S