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...
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.
(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.)
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.
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.
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."
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...
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.
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?
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!
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. :)
This brought back waves of nostalgia I haven’t felt for like a decade.
