An implementation of the milestag protocol and some game mechanics intended to run on an arduino and a raspberry pi.

braidstag, updated 🕥 2022-01-22 18:20:30

== BraidsTag

An implementation of the milestag protocol and some game mechanics intended to run on an arduino and a raspberry pi.

The arduino interacts with some bespoke electronics and defers to the pi for any gameplay logic. The pi allows us to have a client-server connection over a wi-fi mesh network which should allow for some very interesting mechanincs more often associated with computer games such as voice communication, team power ups etc.

== Electronics The electronics have become significantly more complex than I first imagined but there is very little which I think could be removed without loosing a lot of functionality,

The circuit and board layout for the elctronics is included in "fritzing" files.

== Gun software This is written in C and runs on the arduino. Currently, it has to be compiled and uploaded using the arduino IDE and the reset button has to be physically pressed manually. Once connected to the Game software via a serial link, all this does is handle the hardware, letting the game software handle the higher order logic.

== Game software This is written in pythin nd runs on the pi. It is responsible for communicating with the arduino, deciding what the incoming events mean and how to respond. It also communicates with the server.

This is deployed using resin. A good quickstart is https://docs.resin.io/raspberrypi/nodejs/getting-started/ when it comes time to deploy the code, use the clone of this repo, instead of the simple-server-node sample project

Currently, I have only done this by pushing to their servers and having them do the building. However, it should be possible to build locally by enabling the cross-build-start and end lines in Dockerfile.template and using:

{{{ resin build --deviceType raspberry-pi -a BraidsTag -v }}}

it is also possible to synchronise all of the local files with a container running on your network using:

{{{ resin sync --source . --destination /usr/src/app -vp }}}

== Server software Written in python, this keeps tracks of all of the guns and allows administration of the game. It can be deployed in a docker container and exposes a rich client via vnc on port 5900.

it can be build and executed using:

{{{ docker build . -f Dockerfile.server -t braidstag-server docker run -it --rm -e SERVER=0.0.0.0 -p7079:7079 -p5900:5900 braidstag-server }}}

Issues

Bump node-fetch from 2.6.0 to 3.1.1 in /admin-webapp

opened on 2022-01-22 18:20:30 by dependabot[bot]

Bumps node-fetch from 2.6.0 to 3.1.1.

Release notes

Sourced from node-fetch's releases.

v3.1.1

Security patch release

Recommended to upgrade, to not leak sensitive cookie and authentication header information to 3th party host while a redirect occurred

What's Changed

New Contributors

Full Changelog: https://github.com/node-fetch/node-fetch/compare/v3.1.0...v3.1.1

v3.1.0

What's Changed

... (truncated)

Changelog

Sourced from node-fetch's changelog.

Changelog

All notable changes will be recorded here.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

What's Changed

New Contributors

Full Changelog: https://github.com/node-fetch/node-fetch/compare/v3.1.0...v3.1.2

3.1.0

What's Changed

... (truncated)

Commits
Maintainer changes

This version was pushed to npm by endless, a new releaser for node-fetch since your current version.


Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) - `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language - `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language - `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language - `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/braidstag/arduino-milestag/network/alerts).

Identity and status lights

opened on 2019-08-16 20:12:58 by neothermic

Should we have status LEDs that are always or periodically visible to indicate team ID or other effects such as invulnerability, quaddamage, dead, etc?

These would have an impact on power consumption, immersion, stealth etc so would probably need to be optional.

Potentially opens up possibilities of "reveal enemy" mechanics (see stompyrobots "radar hack")

Related to #38

Game Types

opened on 2019-01-23 23:58:10 by ashirley

We should support switching GameType and changing a bunch of the behavior of the game in one switch. Examples of game types are:

  • Persistent DM
  • Timed DM / TDM
  • war games
  • territory control (domination tube)
  • hunter / seeker
  • monster mode / Asymmetric.

System for changing parameters

opened on 2019-01-23 23:53:59 by ashirley

We should have a common system for setting parameters in an Admin UI or console.

Parameters might include: * Player * health * maxHealth * ammo * maxAmmo * Gun * damage * rateOfFire * brightness of torch / flash * Game * gameTime

These should have base values which are the same for everyone and should be able to be overridden by 1 or more effects. Effects might come from admins or from gameplay bonuses.

Effects could be: * Set to a value (e.g. =100) * Add/Subtract a Value (e.g. +50) * Multiply by a value (e.g. *1.50) (50% boost)

Each effect would be able to be removed once it no longer applies.

Effects can apply to the whole game, a single team or a single player (although it doesn't make sense to set the gametime for just 1 player)

TODO: Once we have a concept of a gun, we should be able to apply an effect to only a gun (for everyone, a team or a player)

Server persistence

opened on 2019-01-23 23:40:17 by ashirley

The server should keep data for players between sessions. If this could be stored frequently enough, it would be good if we could make the server able to survive a crash or even make it HA.

There will need to be GDPR considerations if we are storing data cross-sessions.

When hit, add invulnerability period and impotent period

opened on 2019-01-23 23:37:15 by ashirley

When you are shot there should be a time when you cannot shoot back (to prevent tit-for-tat) and when you cannot be shot again. The 2 times should be independent and preferably changeable by admin/console