[sillysaurusx]

That’s wonderful! Is the code open source{,able}?

I used to play an old game called Underlight. When they shut it down, the owner sent me a CD with the codebase. To my eternal shame, I lost the code. It was so neat seeing the old hacks; it even overwrote the ebp register in an inner graphics loop, because apparently in the early 90’s that sort of thing made a big difference.

Would love to get a glimpse at how worms’ ninja rope physics is implemented...

[CyberShadow]

> That’s wonderful! Is the code open source{,able}?

Unfortunately no. And, saying this as a big open source enthusiast (see profile), it would not do the game's community much good to be open-sourced right now (as the game relies almost entirely on security by obscurity to deal with multiplayer cheating). Open sourcing also would be unlikely to solve any big problems - e.g. native Linux / macOS support is not due to lack of motivation, but simply due to how much the game depends right now on Windows and other Microsoft APIs and libraries. We are however trying to move the codebase into a direction where as many of the same benefits can be achieved, such as refactoring the game logic into a portable core, and add scripting support to allow arbitrary customizations.

The question of whether the source code is open sourceable has also been raised, and unfortunately the answer is also no - my understanding is that parts of the code were written by a party under an agreement that precludes the source code being released.

[sillysaurusx]

A shame, but understandable. I wish you luck with your code foraging!

(Also, don’t underestimate the power of people wanting to play worms on MacOS — it’s the type of thing I’d rewrite out of pure joy. But that’s not in the cards.)

[cycloptic]

On the first point: If the assumption is that some community members are interested in developing cheats, would it not also make sense to assume that some community members are instead interested in hardening the netcode and developing anti-cheat systems?

On the second point: Please have the powers-that-be consider doing a partial release of the parts that are not under that agreement. Some code is better than no code at all.

[CyberShadow]

You may be right. For what it's worth, we are continuously looking for members of the community who have the skills and desire to contribute positively, and empower them to do so as much as we can. There is certainly no lacking in things to improve even outside of the game itself, such as infrastructure, network services, and third-party software such as tools or game extensions.

The situation about cheats is not that simple. Armageddon's way of modelling the game state is already immune to certain kinds of cheats. The current state essentially is a function of the previous state plus player's inputs; therefore, it is impossible to give yourself infinite ammo or noclip through walls. We've tightened that further by e.g. introducing "Schrödinger's crates", which makes the contents of crates determined when they are opened instead of on creation (thus making their contents impossible to predict). The remaining avenues for cheating can mostly be categorized in "perfect knowledge" cheats (i.e. knowing what weapons are in other players' inventories) and input cheats (creating macros or bots that produce frame-perfect input); these are not solvable generally, and can only be protected against either through "security by obscurity", or very intrusive anti-cheat software which analyse which software runs on users' PCs. We would very much like to avoid having to do the latter, as such software can only be effective if it is more invasive than the cheat software itself, not to mention requiring a lot of effort and resources to implement and maintain.

And, yes, unfortunately these concerns are not purely theoretical. Nearly every competitive season we have issues with some players thinking they can get away with using some generic cheat software, or occasionally some curious hackers making some cheats for fun for their friends which then find their way out to general availability.

[folknor]

This might sound a bit harsh and overly dramatic, but frankly you're better off not worrying about it and going the route that Super Mario speed running has taken.

They require, in the harshest of cases, (1) a full-length video of you actually playing the session, with input methods visible in frame, hosted on a publicly accessible site such as YT or Twitch, (2) game audio must be audible and undistorted, and (3) hardware input tracking software logs - I'm not sure what the application they use is called but you can easily find out. There might be other requirements I forget, you can probably google it easily.

With these things required, the community polices itself. Staying ahead of these things in code is completely wasted effort that could be spent on positive coding, which grows the community and therefore reinforces the self-policing.

These requirements might seem harsh and alienating, but I'd just say "get over it, if you want to compete, these are the rules."

[CyberShadow]

Sorry, but frankly this is unhelpful. The comparison is quite far-fetched.

For one thing, Worms Armageddon is a PC game. By design, PCs can run arbitrary software alongside the game, and the game software can be relatively trivially modified to do whatever the user wants. It is practically impossible to remotely prove that a PC is running exactly the software that the player claims it is running.

Second, competitive gameplay in a multiplayer game is very different than speed-running. Though similar variations exist (e.g. time-trial rope races, where contestants can take as many tries as they want to beat a map off-line and then submit their best replay), mostly we're talking about actual online tournaments (often with community-pooled cash prizes). Forcing every contestant to set up video recording and other proof as you describe would make competing impractical for most players.

Third, cheating massively hurts the game even for non-competitive play. In situations such as what I described above, when an easy-to-use cheat program becomes easily available and before we patch it out, many groups of players will download and will use the program. It is very demoralizing when players run into one cheater after another when they're just trying to enjoy a casual but fair game. You can find plentiful evidence of this in other games, which were bombarded by complaints and negative ratings after the developers' lenience to take action against cheaters in multiplayer games.

[Haegin]

That seems fairly reasonable for speed running - most speed runners are doing countless practice runs and the time spent running is dwarfed by the relatively small amount of time I imagine is required to start a keylogger and hit record on a camera. Additionally if the speedrunner sets a new record there are probably a good number of people happy to check the video and if no record is set then it's not really relevant.

With a multiplayer game that lots of people are playing online in multiple rounds that's a lot less feasible. Would you ever want to watch a bunch of videos of people playing a turn based strategy game to make sure they're not cheating? Even if you did put these requirements in place, if you suspect someone you're playing against is cheating and ask for the video proof that they're not what motive do they have to hand anything over? For the hypothetical speed runner they need to prove their record so they can lay claim to something which takes a lot of time and effort to pull off. For the Worms player they get to confirm that they didn't cheat when playing some stranger on the internet? Then they have to do this again next game in 10 minutes time? It's just not practical.

[folknor]

While I agree that opensourcing would be unlikely to solve any big problems, you frankly can't know. Someone might come along, especially when we're talking in timespans of decades. Probably not. But maybe.

The argument you're using here about the game depending on MS APIs and such is simply not an argument against releasing, and you know that perfectly. It is in fact an argument for releasing it open source. There's no point at which it's ideal to release the code - it can always be cleaner, more optimized, saner, and so forth.

Here[1] is an example of someone using that argument and delaying the release by first a decade, and then saying it probably won't happen at all. It's just complete nonsense - if they were afraid to release their code because it was "ugly" or "not modern", again, that's not an argument.

But obviously I have little to say about your last paragraph, except to reiterate what someone else said and asking if the code could be released without those parts :-)

1: https://www.phoronix.com/scan.php?page=news_item&px=Lightwor...

[CyberShadow]

> While I agree that opensourcing would be unlikely to solve any big problems, you frankly can't know. Someone might come along, especially when we're talking in timespans of decades. Probably not. But maybe.

For as long as the game has an active community and a competitive multiplayer scene, this is not a risk worth taking.

> The argument you're using here about the game depending on MS APIs and such is simply not an argument against releasing, and you know that perfectly.

That is not what I said.

Since this is getting into strawman territory, I will need to stop this discussion here. I recognize that you have very strong ideals about open-source, which I respect, but my priority is the interests of the game's community, so we will just have to agree to disagree.

[malern]

Thanks for your efforts! It's great to see someone keeping the classic Worms going.

Out of general curiosity, is there anything you can tell us about the source code? What languages are used? How many LOC? Did they use any sort of version control? Whats the build process like?

Were you surprised by any of the ways they were doing things when you first got to see the code?

[CyberShadow]

Yes, I'll gladly answer those questions!

Worms Armageddon is written in C++, with some bits of x86 assembler. Though, we are phasing out the assembler code (for portability), and it isn't as necessary due to advancements in compiler optimizers. 300KLOC at the moment. No version control software was used back in 1999, to the best of our knowledge. The build process changed over the years, due to inheriting Worms 2's frontend/game split; these days it's just one Visual Studio project, though I'm trying to move to CMake/Clang.

The game engine was written by Karl Morton, and it definitely felt special. Information is propagated using a message queue system. Other parts of the code were in a completely different style, having been written by other people. Fun things like jokes left around in comments, and also "fun" things like UI code tangled with network code and other nightmares that we're untangling to this day. It's humbling being able to maintain this legacy!

[akdor1154]

There was a project to get some D code into the engine, did this get anywhere?

[gus_massa]

Is this the code https://www.reddit.com/r/MMORPG/comments/981nmi/underlight_a... ?

[sillysaurusx]

I just hopped into their Discord server and recognized so many people from those days: BuzZz, Drizzt, Ironman, Off Kilter, Star Scream, Windsong, Erasmus, Kelos, Nostradaemon, PAMSWEETS, Tember, Stormy, RavenXR.

All those people helped to profoundly shape my childhood, of which ~7 years was spent playing this game.

I really am grateful you posted this link. Thank you again. :)

[sillysaurusx]

Yes! Wow! Thank you so much!!

This brought back waves of nostalgia I haven’t felt for like a decade.