I've made a couple of comments like this on HN before, but whenever you make a homepage for a project, whether it's a game, game engine, software library, command line tool or anything--please start by describing what the thing is in one or two sentences.
Here's what I thought when I clicked this link:
> BZFlag? Does this have something to do with zipping files? Meh, I'll click and see what it is.
> A picture of some 3D rendered stuff, and download links for a bunch of platforms... Is this a game engine? A physics simulator? Maybe if I scroll down I'll find out
> Hmm, the project news doesn't tell me much... "A Flying tank", "Tanks with Superpowers"... I guess this is a game where you drive tanks? I'll take a look at the comments.
> Ohhhhhh, I see.
This could've been fixed by just having an h2 and a paragraph at the top saying "BZFlag" and "An open source tank-based warfare game with online multiplayer, going strong since 2008!" (or whenever the project started)
You don't necessarily need to have a tagline like that on every release page or documentation page, but if I end up on your site and delete everything from the URL except "projectname.org", I should be 2 seconds away from a simple description of what your project is.
With all that said, people seem to like this game, I may check it out later!
Edit: Looks like they added a tagline to the page. It’s clear, it’s obvious, it makes sense. Thanks!
It's a FPS with jumping tanks. Grab flags on the ground and get special abilities.
The main gameplay element is that when a tank is in the air it keeps its rotational momentum and you have no way to correct the trajectory mid air. Sometimes you have to jump and aim on the right or even backwards and this all gets down to injecting the exact quantity of movement prior to the jump with the mouse (a nice addition beyond the classical pointing mechanics of FPS).
Tanks can't tilt, but hopefully they can jump, so another saillent part of the gameplay are mid-air duels, when two tanks facing each other start firing, jump to avoid the slow-moving orbs, and carry the fight into the air.
It looks like a caricature, but it has great mechanics that could make a good basis for an e-sport. If e-sports are introduced into the Olympic Games and they decide to look for an open-source game, BZFlag would be a good contender.
Web pages? Those'll never catch on if you ask me. The package info seems clear enough:
$ dnf info bzflag | sed 's/^/ /'
Last metadata expiration check: 0:00:29 ago on Thu 31 Oct 2019 22:24:31 GMT.
Available Packages
Name : bzflag
Version : 2.4.18
Release : 3.fc30
Architecture : x86_64
Size : 11 M
Source : bzflag-2.4.18-3.fc30.src.rpm
Repository : fedora
Summary : 3D multi-player tank battle game
URL : http://bzflag.org
License : LGPLv2
Description : BZFlag is a 3D multi-player tank battle game that allows users
: to play against each other in a networked environment. There are
: five teams: red, green, blue, purple and rogue (rogue tanks are
: black). Destroying a player on another team scores a win, while
: being destroyed or destroying a teammate scores a loss. Rogues
: have no teammates (not even other rogues), so they cannot shoot
: teammates and they do not have a team score. There are two main
: styles of play: capture-the-flag and free-for-all.
> going strong since 2008!" (or whenever the project started)
It's not immediately clear from the site, but it might surprise people to learn BZFlag was first released in 1993. (And is based on an arcade game from 1980.)
> "An open source tank-based warfare game with online multiplayer, going strong since 2008!" (or whenever the project started)
1992, FYI. Same year as Wolfenstein 3D. Not sure what the original graphics looked like, but I know it was first person. It probably had line polygons like Battlezone, the arcade game that inspired it.
Not correcting you just to seem smart, I genuinely think it's interesting that the game is that old and still active.
Oh wow, I played this game a lot about 15 years ago. I was in my teens and this game is the reason I learned linux system administration so I could run my own server. I built a computer with junk parts from my friend's dad's old parts bin and installed ubuntu on it.
I struggled with linux then but learned a lot. Some say I am still struggling with linux to this day.
This game, Tux Racer, Chromium B.S.U. If you could get your graphics drivers to work, these were your reward. Learning linux was so fun back in the day! And the fact that you could just apt/rpm install them was mind blowing.
I love that this game is still going on. I had a similar experience; logging onto random servers was an absolute madhouse of learning new rules on the fly.
One of my favorite variants of this is the rabbit hunt. One tank is white (a rabbit) and everyone is supposed to hunt it. Whoever kills the rabbit becomes the new rabbit, right then and there. Only ever saw 1 or 2 servers running a game this way.
That might just be it too. People wind up doing most computing on their phones. A game I used to play as a teen now has most of their users on their mobile apps while old players use their desktops.
I am one the developers of the game. Improving the anti-cheat capabilities is certainly one of our long time goals. The game server currently lacks a complete simulation of the game, so most of the important logic is handled only in the clients.
The first big step would be isolating the simulation logic into its own library. Then both the client and server can share that library. We would be able to move some of the decisions to the server, or at the very least verify if the client's decision make sense.
The server shouldn't trust the clients. The clients should just send inputs or actions, and the server will do validation and decide what the result will be.
Autoaim cannot be solved absolutely by technical solutions.
Even if the executable is fully electric fenced and verified matching a checksum, aimbots can just read the video buffer from a different process.
In practice, you can statistically analyze player hit metrics and then monitor people who appear to be too good.
However, this requires basic customer service which is less likely to come from a free server for a noncommercial game.
I don't expect it would be that hard to make an aimbot look human by throwing in some random variation. It would probably then be difficult (even for a human auditor) to reliably differentiate genuinely good players from "too good" players.
It may send the position the player is aiming at at certain periods, if the player is way to accurate and linear moving to the target you can ban him. Some false positives and stuff should be considered too
That's a good first step but it doesn't really stop hackers. Specifically the two cheats that the parent mentions don't require the server to trust the client. There's mitigation that can be done to prevent wallhacks, but aimbot can be really difficult to detect without sophisticated tools, and even then fundamentally the cheat can operate as an intermediary between mouse input and the game receiving that mouse input which makes it impossible to directly detect without memory inspection. Essentially you're left with heuristic analysis of mouse movements, or more likely a "Overwatch" (CS:GO) type system where moderators/janitors are tasked with evaluating players to determine if they're cheating or not.
Cube2, another oldie but goodie FOSS games relies heavily on admins too. They are supported with stats (a server plugin, IIRC) and a observer mode which is actually available to all spectators (the game is more focused on fun than competition).
Cube1 solved the problem by keeping the communication stack closed source so you couldn't build a aerver-compatible client. The OSS version of Cube1 used a different communication stack.
We don't really have the technology to do that completely. Because it's really hard and expensive to stream pre-rendered video at a low enough latency, most action games still transmit player positions and trust the client to accurately render the corresponding video client-side.
Although, even in scenario with a completely untrusted client receiving only final video output, there's no guarantee that the actions being input are human.
Back when I was a youngster playing nettrek, the same thing happened. Basically, those smart enough to hack the code could create their own cheats. The wikipedia page says that game mechanics were changed so that borgs no longer had a specific advantage, but I don't know what those game mechanics were. Though it was pretty obvious if you were playing against a borg or not at least in the early days. In play chat also alerted people to those that were playing borgs.
Back in the day, you would shoot at a borg, and if your shell was aimed perfectly, it would side-step one tank width while the shell was in flight. You couldn't kill one unless you were right on top of it (or had guided missile or laser).
>it would be impossible if the server would not send locations of opponents behind walls
Wouldn't that require the server to do some amount of 3D logic every netcode tick for every player? And then you'd get into real latency problems, since either you do rollbacks to account for when people are allowed to see each other or you let the fastest connection win.
Depending on the complexity of the geometry this is within the realm of reason. Fairness might not be a huge issue as long as you make sure visibility is a two way street. People will probably complain about high latency players popping into existence after they're already most of the way around a corner though.
The server already has to do a full 3D simulation for each client. The server just doesn't send updates for players that are not visible to another player. So yes the server has to do a bit more work, on the other hand it reduces server bandwidth.
You can't stop cheating even on a closed source software with an anti-cheat running with kernel privileges. The same idea applies to open-source, especially as any anti-cheat feature is open sourced too.
No matter how powerful your anti-cheat protection is, it can be bypassed (There were ROP-based cheats recently on HN if you want to take a look: https://news.ycombinator.com/item?id=21355058).
At the very least, you won't be able to protect info like the position of entities and players (You need them even before you see the players to avoid problems, meaning anyone can create a wallhack or an aimbot).
If one could create a trusted environment, that would be a different story. I do think this is possible with cloud gaming. If you can't interact with the game memory, the game files or the underlying operating system, the best you can do should be macro or AI based on what's displayed on the screen.
You can't necessarily detect the cheat software, but you can detect the behaviour of cheat software. Writing an algorithm that can play a first-person shooter at a superhuman level is pretty trivial, but writing an algorithm that plays like a really skilled human is vastly more difficult. This behavioural approach to anti-cheat is now highly practical thanks to deep learning.
As long as the network and its weights are open-source, you can create adversarial examples automatically. So the idea is to run the auto-aim bot, but then run the network on your inputs backwards to morph your inputs to look more "human-looking".
Raw Autoaim Bot -> Neural Net (since its open source) -> tweak inputs until its considered a human -> send the tweaked autoaimed command.
The weights don't really have to be open-source though. After they are trained, they should be subjected to the same policies as database passwords to counter your attack, or to at least force the cheater to train the counter-network via the game.
Are you suggesting that BzFlag sysadmins are going to be custom-training their own neural nets?
Based on my experience with LeelaZero, its far more likely for people to share weights with each other. And participate in community-training. Not everyone has the skill to spin up TensorFlow, carefully partition off training data, and monitor neural nets through training.
But almost anybody can download the "latest weight file" as a Cronjob and update their bzflag server every day or week.
The server would need to provide the binary, or at least a large precompiled core library. Even then, with all of it open source it seems like one could hack it.
I believe this was my first time learning to compile a C++ project. This was 13 years ago; I was 14 years old. Great memories playing with others, chatting, building maps.
I think one reason for this is that the base variant is easy to understand and there's no 'map' to learn making it a great fit for casual, pick-up play. BZFlag is the OG Q3DM17.
In my first full-time programming job (only back in 2008!), we used to play BZFlag at lunch. It was the only fun thing you could install through the CentOS package manager. A year or two later, we had Quake 3, with Lego mods.
Here's what I thought when I clicked this link:
> BZFlag? Does this have something to do with zipping files? Meh, I'll click and see what it is.
> A picture of some 3D rendered stuff, and download links for a bunch of platforms... Is this a game engine? A physics simulator? Maybe if I scroll down I'll find out
> Hmm, the project news doesn't tell me much... "A Flying tank", "Tanks with Superpowers"... I guess this is a game where you drive tanks? I'll take a look at the comments.
> Ohhhhhh, I see.
This could've been fixed by just having an h2 and a paragraph at the top saying "BZFlag" and "An open source tank-based warfare game with online multiplayer, going strong since 2008!" (or whenever the project started)
You don't necessarily need to have a tagline like that on every release page or documentation page, but if I end up on your site and delete everything from the URL except "projectname.org", I should be 2 seconds away from a simple description of what your project is.
With all that said, people seem to like this game, I may check it out later!
Edit: Looks like they added a tagline to the page. It’s clear, it’s obvious, it makes sense. Thanks!