See what i mean? If you put the three of us in a room we would try kill each other

java vs linux vs .net

last man standing gets to pick the platform... lol...

Let's all write our own and see whose is better.

Surely any of the options would be sufficient for the game now. We aren't talking 100k users here..

As long as someone was very clever with the main client-server code that makes the game "fair" and bug free, then I can't see it mattering what platform.

Computers have got a touch quicker since 1982 or when ever this game started

I spend my programming time between cloud based business databases and integration of automation systems. So it's really outside my area of expertise on which solution is best.

I'd chip in and help on any platform however, just wouldn't claim to be the lead person.

Even Java as I was involved in the infamously named J-Twat

anything you did like that would change the game...and it would NOT be trade wars anymore. I think we are stuck with JP and he is stuck with us. just wish he would be around more..

sk

Well, that's the whole point. It would be something new that TradeWars players would hopefully enjoy. We would base it on something older, say Chris Shamrock's TW II, and we would have Cabal instead of Ferengi, different planet and ship names, and limitless possibilities. Let's call it "Space Invaders" so we can get sued by Atari and Midway instead of EIS. Are either of those companies in business anymore?

I would actually be willing to collaborate, as long as it is on .net

Just kidding. I actually think Linux is the best choice for a project like this. We are talking about a service on a server, not a client application. I would be more comfortable with MONO than python, but I would assume Python has less overhead. I don't know python, but it would be interesting to learn. I have been playing a bit with Linux on my Raspberry Pi. I loaded the latest release of Debian “jessie” on it, with RetroPie console emulator and over 100K games. lol

A dedicated client might be a good idea too though, so we could include something like nProtect or PunkBuster to make it harder to cheat.

You kids today with your ruby, python, etc. Back in my day, we wrote K&R C and liked it. None of this object oriented, interpreted language nonsense.

Anyway, I would actually agree with Mongoose that Java is probably the best choice if one were to rewrite the server. Java provides the right balance of performance and ease of use; and it's very easy to extend with new classes, plus it's easy to make a modular code base that multiple people can contribute to.

Regarding Star Killer's point, there's a difference between porting the game and writing a new one. Porting would mean implementing the same functions and behavior in a new language, versus creating something perhaps derivative but new. I suspect people would be resistant to the latter.

Ack. I would never, in a million years, implement any sort of security in the client. If the security model isn't implemented in and enforced by the server, it may as well not exist. I am almost certainly not the best programmer here, but security is what I do.

Actually, I started with Assembler on a Radio Shack COCO (Color Computer), and later on 8086 IBM compatible Tandy 1000. I was shocked the first time I compiled a C "Hello World" application and it was around 32,000 bytes (32 KB), because that is about 120 bytes of Assembler and 100 of that is the DOS file header... and yes I am talking single bytes... no KB or MB or GB or TB just plain old bytes (B)... lol

Porting the game would require obtaining the rights from JP, and players would hate it if you didn't exactly copy everything, including every single bug and timing constraint. That would be impossible!

I thought you wanted LAMP?

I know I am gonna get slammed for this, but any form of third party software, including any form of scripting or automation is considered cheating by most, if not all, MMORPGs. I am the ultimate hypocrite. I love scripting, but I don't want to play against your scripts

The server can't prevent automation on the client side. I have automated many MMOs with a program called Auto HotKey (https://autohotkey.com/). One MMO allowed the tab key to target the nearest enemy, so my script was hit tab, then click the attack button several times, repeat... Come back the next morning and have all the resources I needed... I scripted World of Warcraft with two accounts... Hitting a single key would attack the current target, then switch to the second account and cast a heal spell, and continue switching windows (alt-tab) and attaching till the target was dead... It's a bit harder to select targets in WOW, but that could be automated too.

You can easily script ANY web browser game, because these programs aren't allowed to directly access your computer and prevent you from running "Auto Hotkey", "Cheat Engine", or other hack tools. I have never used cheat engine, but my son has, and it can modify your client program that is running in memory. Some games have such poor security that you can give yourself extra lives, weapons, money, or other resources. There is a hack for Call of Duty that gives you a head shot, guaranteed, every time. That's why I don't play FPSs any more.

I know implementation is a problem, that's why I would recommend buying a package that has already been battle tested. Even then, you can still beat them. One MMO had protecton, so I ran it in a VM, and the protection couldn't see my scripts running on the host machine.

None of us have the time, but if we collaborated, then we could possibly achieve something.

I'm a pragmatist. What I want and what's realistic aren't always the same thing.

A suggestion would be to get in touch with Jeff Moriarty and buy the source for his last release of the HVS MBBS TW 2002.

The late 90s HVS was very buggy which was partly why (I think) JP created TWGS. Post TWGS, HVS brought out a new, less buggy MBBS Game. Cruncher and I played it a few bangs half a dozen years ago on Stoneslinger's BBS. The only bug I can remember that we found was the port rollover bug, mebbe she remembers others.

One major downside for some, perhaps upside for others - much of the TWX internal database will not function under HVS. Most of the reactive attack scripts would not work. Telix, Qmodem, ZOC, Procomm - all fine, just TWX. The reason is very simple and a rewrite of TWX source would fix the problem. Outside my competence.

EDIT- Rewriting the scripts would not fix the problem, the database itself is the problem.


Possible problems:
How to contact Jeff or Stoneslinger (who knew Jeff)
Might be legal ownership issues JP/Jeff Moriarty, I don't know if Jeff Moriarty has the right to continue to work with the HVS version.

You definitely don't want to play against my scripts I haven't had time to write too many yet, fortunately for everyone out there. Lol. I mostly just make the ones that already exist better.



Right. #1 lesson in secure software design: security through obscurity *never* works. The only way to protect it would be to encode a crypto key in the client and have the server only recognize encrypted transmissions, but if the key's in the client, someone will figure out where it is using a binary analyzer and extract it, and then built their own client. If the protocol is not encrypted, then all you have to do is run a sniffer for a while, figure out what it's doing and write your own in perl. (well, that's probably what I'd use.) Security through obscurity simply creates smarter attackers; it weeds out the ones who can't code and presents are more interesting challenge to those who can.

The MBBS version of Tradewars 2002 by HVS was licensed from Martech. I believe those rights have reverted to JP now. I also believe the rights to Tradewars Rising have expired and returned to JP. They have re-branded the game as "Merchants of War", but they are heavily violating EIS intellectual property rights. There were other companies that had rights, but I think all of them have expired now.

The Swamp BBS went down in May of 2012. I often wonder what happened to Stoneslinger.

Exactly... So you have to prevent people from modifying your code... There are packages that can encrypt your executable, but I don't know how effective they are... In any case, your code is vulnerable after it is in memory, so you need to monitor all other processes for anything attacking your program, and run check-sums against your program in memory... I'm no expert, so I would have to rely on some kind of third party package...

Bottom line is that your client is going to get hacked, so you are right, most of the protection needs to be on the server side where you have control. The client should only be a window that can see what's happening on the server, but you still need something on the client side to prevent automation (i.e. automated head shots).

Consistently releasing updates can also make it harder for hackers to keep up as long as your code changes significantly enough that existing cheat tools fail to work and hackers have to release new tools, and the end players have to update there hack tools.

you could also make your game so unpopular that no one bothers to hack it