I bought the game when it was first released and I loved it. May I ask how come you are still working on the game? Out of sheer love for it? Did you work on the "original" codebase before becoming a maintainer?
> May I ask how come you are still working on the game? Out of sheer love for it?
Yes, for the game and its community. After so many years of playing the game and being part of the community, it is now an inextricable part of ourselves.
> Did you work on the "original" codebase before becoming a maintainer?
No; I started playing Worms World Party maybe around 2004. In 2006 I started writing third-party add-ons for the game, and I had been given a copy of the source code so I could continue maintaining it alongside Deadcode (David Ellsworth, the first maintainer).
Worms World Party is the last game of its generation to use the same engine. The reason why the updates are for Armageddon and not World Party is mostly arbitrary - it was the game that the original maintainer had and was playing. A bit more info here:
There is also Worms W.M.D., which we understand is based on Armageddon's source code, but that came out much later, and is still very different in terms of gameplay and style.
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...
> 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.
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.)
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.
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.
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."
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 :-)
> 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.
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?
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!
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. :)
Yes, for the game and its community. After so many years of playing the game and being part of the community, it is now an inextricable part of ourselves.
> Did you work on the "original" codebase before becoming a maintainer?
No; I started playing Worms World Party maybe around 2004. In 2006 I started writing third-party add-ons for the game, and I had been given a copy of the source code so I could continue maintaining it alongside Deadcode (David Ellsworth, the first maintainer).