The WorldForge Project Celebrates Three Years!

cyanide writes "Well it has been three years since The WorldForge Project was first announced on Slashdot as an effort to develop open source Massively Multiplayer Online Roleplaying Games (MMORG ^? ). Back then we were calling ourselves 'Altima', but since then we've released our first game, Acorn, and are now working on our next release, Mason. The project really is thriving now, and I'd love to see some new blood join us. "

Re:cheating

[geekster]

Eric S. Raymond wrote an essay about this... here [tuxedo.org].

not really

[Anonymous Coward]

There's very little room for cheating in an RPG- or strategy-style game, if the protocol is designed properly. As was mentioned before, rule #1 of game protocol design is don't trust the client AT ALL!!!

Where cheating becomes a problem is where the computer-skill is better than human-skill. An example of this was Quake and its auto-aimers (once the source was opened). But with these types of games, the game basically comes down to intelligence, and human intelligence will win out over computer intelligence more often than not, so cheating isn't desirable. There are exceptions: e.g. in a strategy game where you have to balance resources, you may want to hack the client to do cost-benefit analyses for you. But for RPG's especially, the computer won't help you out much.

The other area where cheating could be a problem is where the server gives you information that you shouldn't have, e.g. the location of enemies. This is actually pretty hard to get around unless you put a lot of intelligence in the server, which would slow it down a lot. But for these types of games it probably won't be TOO bad.

Worldforge's Philosophy on Cheating

[scrytch]

I'm nominally a member of worldforge ... more like I hang around them all the time on irc, while my hobby projects that do directly involve them get pushed down on my project stack. There's plenty of disagreement on how to best prevent cheating, but much of it boils down to this: closed source hasn't prevented cheating in other MOG's (I like how we're boiling down the acronym from the unwieldy MMORPG to MOG -- don't really need the "massively" anymore, that's implied). Given the inevitability of failure here, the prospect of cheating needs to be treated more as a policy approach than anything else.

One approach is to make the client dumb -- basically just a display for its inputs, the server only sends you what you need to see. Cheating is still possible here, but it'd be an impressive hack.

Another approach is that a protocol codec might be made closed source, and with a few clever techniques, you can send "booby trap" packets that flag cheaters if they are ever responded to by a client (also requiring a closed protocol codec at the other end). This isn't foolproof, and might indeed turn out to be a useless measure. But hey, we can always lock 'em up for circumventing, right? ;) Finally, if the folks who wrote the protocol code are among the GPL zealots of WF, then it might be politically infeasable to go with a "closed one-off" approach.

Bottom line, cheaters exist for open and closed source games, and WF will be no exception. WF can provide means to catch a large chunk of cheaters, not all of them, and ultimately it's going to be up to the policy of the server admin as to what to do with them. We just make the tools, you use 'em.

Re:development pace

[__aaedhn419]

>not to be rude or anything, but WF makes Mozilla look like linux - development is just plain glacial.

I don't fully understand your analogy - a 3 year project (WF) makes another 3 year project (Mozilla) look like a 9 year project (linux) - but I believe WF has done well for a distributed volunteer effort. Unlike mozilla, none of us are employed by WorldForge, and unlike linux, we don't have a heritage of bad and good OS design to learn from. MOGs are the bleeding edge, which is a good place to be. :)

Also, I believe some careful examination of WorldForge will reveal that we only have 2 different game servers, Cyphesis and STAGE, and that our goals are clearer than many open projects. Witness the rapidly growing Mason documentation at http://moria.mit.edu:8080/wf/dev/systems/in_develo pment/mason and the almost completely defined acorn rules at http://www.worldforge.org/website/rules/acorn/rule s . I believe that WorldForge seeming slow would only be because we need more help, not that we're unfocused. ;)

Interesting

[Rykard]

But I don't quite see what an re-invented and extended VRML has to do with WF ;)
Unfortunately, a dedicated 3d protocol doesn't do us all that much good, as our clients all use the same protocol, and vary from text clients to isometric 2d clients and fully-3d clients, which means our protocol has to be 'generic' as possible. I can see the use if we were making a game that was dedicated to 3d only clients, but unfortunately, this is not the case.
That being said... one of us will probably pick it apart to see if there is anything we can use :)

Re:The thing I don't understand is...

[An Onerous Coward]

Easy. You simply program them both in, and let the Stormtroopers blow the elves back to Kingdom Come.

Seriously, though. The main point of WF is to create the infrastructure that someone can build any game they want on top of. The games that WF puts out are, as I understand it, meant to be proofs of concept and testbeds for testing and improving the underlying architecture.

Once the foundation is up and running, it can be used for the basis of an MMORPG western, feudal Japan, dystopian future, or "run around with a mallet bopping other players on the head" game. A cool game coming out of this will simply be icing on the cake.