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!
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.
$ dnf info bzflag | sed 's/^/ /'
Last metadata expiration check: 0:00:29 ago on Thu 31 Oct 2019 22:24:31 GMT.
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.
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.)
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.
I struggled with linux then but learned a lot. Some say I am still struggling with linux to this day.
It's fairly new and made with Godot Engine 3.0.
What would be really cool, is a reboot form that worked for mobile.
The patches to wallhack and autoaim are literally a 2 min google search away, and the compile process is well documented and easy.
I wonder what kind of measures can be put into place without utilizing what essentially boils down to DRM?
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.
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.
I imagine it would be a fairly trivial application of computer vision to make an aimbot for first person shooters that works most of the time.
Although my daughter used to always pick up that damn laser and then shut out the rest of us
For aimbot: let server slightly autoaim, but require more shots and slower rotation so it's a bit more about strategy than about aiming speed?
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.
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.
Raw Autoaim Bot -> Neural Net (since its open source) -> tweak inputs until its considered a human -> send the tweaked autoaimed command.
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.
2) Linux distributions compile BZFlag themselves, they don't just distribute upstream's binaries.