Worms Armageddon maintainer here, AMA :)
Here is a somewhat more nicely formatted list of highlights: https://worms2d.info/Worms_Armageddon_3.8_Features
Here is a somewhat more nicely formatted list of highlights: https://worms2d.info/Worms_Armageddon_3.8_Features
Slightly offtopic: I haven't played Armageddon for a long time, but I assume the pace of Worms Armageddon is similar to Worms W.M.D. (which I'm playing on Switch), and it seems like there is a lot of waiting involved - just a few seconds here and there, but overall, it feels like the game could move at a much faster pace, especially when playing single player.
Do you know if this is a conscious decision (e.g. to keep people from burning through the available content through fast) or due to technical limitations (e.g. the AI actually has to think), or just happens to be that way?
A few seconds before the damage count shows up, a few seconds before the next enemy worm gets selected, the five-second countdown before the bot worm starts moving, a few seconds after the turn ends, a few seconds between the "machine gun destroyed" and the explosion etc. - would it be possible to add a "faster" mode? (Sorry if Armageddon has that, as I said, it's been a while.)
(For W.M.D. on the Switch, the long loading screens add to the waiting, but those sound a lot harder to avoid than the in-game delays.)
I haven't played W.M.D., but from what I've seen from the streams, pacing definitely feels different. The delays are a part of it, and they do subjectively seem less forced in Armageddon. For another thing, W.M.D. introduces crafting, giving players at least something to do between turns - in Armageddon you've nothing to do but follow the action and mock your opponents' mistakes :D
There is a spicy game mode in Armageddon called Paranoia (https://worms2d.info/Paranoia), in which these delays, plus the turn duration, are all set to zero, meaning players have exactly one frame to make their move. As you can imagine it is very hectic!
Though I imagine games are rather quick like that
That’s just how Worms was originally (eg the DOS game) because that’s how turn based games were originally paced. A large part of that will obviously be due to the capabilities of systems back in the day but it was also that a lot of games weren’t so fast paced as they are now.
You see a similar thing with beat em ups too. Take Street Fighter 2 on the SNES then look at Capcom games on every console each generation after and there is a noticeable difference in how the pace increases with each new release. Same is true for a lot of other genres too.
>Worms Armageddon now runs well under Wine or Proton on Linux.
Was wondering if there would ever be a chance of a true native linux port? I've got one of the later worms games natively on linux, but it sort of pales in comparison to worms Armageddon and while I appreciate the efforts of the proton maintainers and Devs like yourself that work hard to make their games compatible with proton, but I'd still prefer to buy a game that runs natively on the os I use.
If I'm going to be a paying customer, I'd prefer to be treated like all the rest of them.
Speaking as a full-time Linux users since 2016: I found that getting old (i.e. unmaintained) native Linux games to work again is MUCH harder than running their Windows version. E.g., I spent hours trying to get the Linux port of Unreal Gold to work with no luck, and in the end had to give up and run the Windows version under Wine. There is just so much change on the Linux desktop that old software is just not going to behave well. Not only do you usually need to reproduce the entire userspace from the time the game is released (and of the distro that it was built against), but changes in display APIs (Xinerama, XRandR, SDL versions...) often result in full-screen or resolution problems.
This is a project I wrote to work around exactly issues like this: https://github.com/CyberShadow/hax11
why would it matter?
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).
https://worms2d.info/WA_vs_WWP
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...
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."
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.
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.
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.
I found them on YouTube now that I started looking for them, but I've been missing them from my Worms game (on steam) :-)
For anyone wondering: here they are: https://m.youtube.com/watch?v=wV5AFxEnuBo
I think I first saw them in 1998 or something.
Is the game still for sale, and does it still sell enough copies to employ someone fulltime to do this kind of work?
Yes, the game is still for sale; I know it's available on Steam, GOG, and Humble Bundle. I don't know any sales numbers, sorry.
Is there something like a "roadmap", which things you want to tackle for future updates? (if there are any planed at all, since this is done in your free-time and the last patch was 2013)
Because my oldschool and nostalgic memories are about worms world party i always wondered if it could be possible to get the two games together. It's a little bit sad, that the online-community of wwp is nearly dead, and the remastered version did not get too much momentum.
I always liked the theme/ui of wwp more, because wa's UI feeld a little bit clunky to me. (e.g. the selection of worm-pots does a neat integration of this features) Do you also do/plan some work on the UI?
I think Project X (a powerful but sadly unmaintained third-party scripting mod for the game) has shown us a glimpse of what the culmination of the game's development might look like, so that's the direction that we want to go. Games with powerful modding capabilities (Garry's Mod, Skyrim) very often outlive the more static linear games, and combined with Armageddon's existing configurability and random map generation, I think it is something with a lot of potential.
In the same vein, the new schema format with Rubberworm capabilities was definitely a game changer. There's something so exciting about user-generated content officially making it into a base game. Thank you for making this possible!
But most importantly, it seems you guys have enough freedom to work on these sort of new features as much as the usual quality of life/bugfix changes.
How open is Team17 to these more intricate changes, especially towards the modding capabilities dream?
Worms 2 introduced the "Danish Pyrus" voice bank, and it might have been voiced by Jan Linnebjerg, who played Pyrus, but it isn't written down anywhere in the manual or credits.
wa.team17.com
Also curiously, when covering the release announcement, a lot of news websites referred to our unofficial website (worms2d.info) as the official one, possibly due to the same reason!
Edit: I've been told that the removal of 32-bit support in the latest OS versions makes macOS support unlikely. The game uses some old proprietary DLLs (for some file formats) that are 32-bit only. Sorry :(
IIRC you were also working on a D port of the engine. Did that make it into this release or is it planned for later / not at all?
(Thank you!!)