fostrb / robotfight Goto Github PK

Display should be entirely uncoupled from bout.

-Some classes still have their own draw methods for cairo (cairobot, projectile, etc).
-The list of scan events in Bout should independently time-out and get removed, instead of the display thread checking/removing them.
-Bout should not depend on display to run at all, and should be able to run as fast as possible to crank out a ton of sims.

On occasion, a bout's display will cease to update. The bout itself will continue, but no graphical changes occur.

I'm imagining there's a cairo draw function somewhere that's getting stuck and locking up the thread.
First step of bug hunt is gonna be tracing the display draw routines.
Maybe de-couple draw functions from classes while doing this for sake of sanity.

Robots should be able work with relative rather than absolute positional data.
Relational sensors should return and accept values relative to their position, not the bout area.
Relational weapons should operate similarly.

For example:
A robot DAVE has the heading 180. (As such, is facing left on screen).
DAVE performs a scan with a Relational ArcScanner at -90 degrees (its immediate right).
Within the scan callback, DAVE's heading is taken into account before the scan happens.
The angle of the scan is translated 180 degrees, and the the return values are also translated.
The angle of the scan is literally 90, but the exposed data will read as if 180 is 0.

It so happens that robot ROB is directly to DAVE's right, so a target angle of 270||-90 is returned. (Even though ROB is technically at angle 90).

DAVE, having acquired a target angle, begins aligning itself to fire upon the enemy.
DAVE has a front mounted, non-repositionable flak cannon, that threatens a 30 degres arc centered around the heading. (And no other weapons), So DAVE has to position itself such that the target is within that arc before it can pull the trigger.
DAVE's pursuit code might look something like:

while acquired_target_angle < 0:
self.turn(self.turn_max*-1) # negative turn value because we're turning right

#add the angle we turned to our scan angle, cause we repositioned
acquired_target_angle = self.scanner.scan(acquired_target_angle+val_turned)

self.flak.fire()

DAVE rotates right and continues tracking ROB until the flak cannon is aligned, then fires.

Mines
-Deployable projectile
-Perhaps different mines behave differently. (SC Spider Mines vs traditional landmines)

behavior brainstorming:
-Mine does not damage when triggered, but reports its position.
-Mine will detonate and damage in a small radius upon being run over.
-Mine will detonate after a specified time.
-Mine has a small threat radius and will hop out of the ground and pursue targets that enter it.
-Mine has a limited sensor array and emits a DEW blast upon enemy in threat range. Is programmable.

Polygon data currently contains no scalar data. (It should be presented in simplest form)
Polygon data should include a scale.

For instance: "here's what this thing looks like. It is X big"

The distinction between Polygon/Entity should be more clear.

Polygon is just the size and shape of a thing, without context for position or rotation.
Entity holds a Polygon, as well as a heading and position (and other data), which it uses to project its body in space.

Polygon should contain methods for collision detection, which currently reside entirely within Entity.
A Triangle, for instance, would override the default Polygon.intersects() method, providing an interface for detecting intersection with that specific shape, given that Entity supplies the projected coordinates.

An irregular twenty-six-sided-oragami-nightmare polygon, however, would likely benefit from not overloading the default intersection detection for the sake of dev sanity and cpu preservation.

-Polygon more abstract
-Make types of Polygons
-Entity cleanup.

-Polygon & Entity Unit Tests

Dataclass decorators seem particularly sweet and it'd be a fun way to dig through all the code and refresh the brain on internals - maybe catch some stuff that oughtta be implemented differently along the way.

Dig through Google Protocol Buffers.

Project should have a virtual environment.

There is an occasional exception in Bout when in attempting to remove a projectile, it is discovered that it's already been removed.

There are 3 points for potential projectile removal, which is sloppy as hell. Maybe mark projectiles as "detonated" and projectile could check if it's detonated before testing intersect. Then at the end of an update cycle, remove all detonated projectiles.

There is currently only one class of Robot and it's functional, but kinda boring.

-Different shapes
Triangle, Large battlecruiser, etc

-Module limitations
Slots for types of modules. Not like "Weapon" or "Sensor", but a size-class or something, so that a builder could decide to throw two scanners on a bot instead of a scanner and a gun, or only guns and no scanners or something dumb like that.

-Different stats and exposed vars
Maybe a battlecruiser has more hull or a shield or something, but imposes slower mobility.
A TechnoVessel could have two threads, giving them twice the CPU time each cycle.
A Turret could have zero mobility capability, but hella slots for weapons and sensors or a huge base power bank.

-Base stats
Each class ought to have base things like a default power source, a hull, etc.

Modules shall all contain a list (empty or not) of exposed methods; self.exposed.

the RMInterface will contain these methods and give the user access to the module.

Modules shall also contain the method gen_interface(self), which will generate and return a RMInterface.

RMInterface will be passed only the list of exposed methods, and within init will set them as attributes of self, like so:

for m in exposed_m:
setattr(self, m._name_, m)

--
bout callbacks need to be injected after modules applied to bot, but before modules are initialized - reactively.

bout might call a bot-builder class upon initializing bots, parsing a 'header' structure for each controller.

DEWs
-Lasers. Fast/instant propogation beam weapons.
-High energy requirements & high cooldown on fire.
-Can be modulated to change color/frequency.
-Cooldown on modulation.

Energy Shield:
-Resists Directed Energy Weapons
-Can be modulated, changing its color/frequency.
-If color/frequency is in phase with the laser, no resistance is applied.
-Cooldown on modulation.

Note:
-Good Sensors should be able to pick up the frequency of a shield/DEW.

Vector class needs to be more complete or I'm gonna continue to shoot myself in the foot during dev.

Unit tests are a must.

Look into cross-platform solutions

Currently, graphics are reliant upon gtk & cairo, largely limiting the system to run on (graphically) *nix exclusively.

A cross-platform implementation of a Cairo Surface would be sweet, or a different display module could be written, as the main runtime is largely unhooked from the display.

Make a 'what is this' (LaTeX) doc.
Update the ReadMe to summarize the project.

The Arc
ArcScanner overlays an arc of length L and radians T.
(Technically T is held as degrees in the data, but it's easier to write out with radians).

A scanner should be able to grow and shrink either of these values while maintaining at most area A.
A = (0.5*L^2)T

So a robot like mosquito could pull its radar in a tight 180 arc to ensure detection of closeby objects, and then upon detection, pull away while shrinking the arc and lengthening the beam to keep it on target.

ArcScanner should expose methods to set either arc or length, automatically adjusting the other if necessary.

Return Values
Current version of ArcScanner returns each bot position that its arc connects with.
Data that could also be useful:
-target heading
-target velocity
-target modules
-non-bot targets (mines and stuff like that)

It might be useful to be able to return the angle & distance of the target, but writing fast-as-hell, hacky trig is half the fun of these dumb things to me. Maybe implement a less-than-optimal angle return and leave serious users to write their own using positional returns as args.

Concept:
There are different physical modules that can hook into a Robot. Different types of sensors, weapons, power sources, shield generators, etc. They should each be of the same basetype, consume/produce power, and provide interfaces to control them to the bot once hooked up.

Example(s):
-ATCannon is a Robot Module of subtype Weapon that fires ballistic projectiles that deal damage and are destroyed on contact. ATCannon requires 10 Energy to power. When connected to a Robot (via specifying so in the controller code [or a future robot building utility]) the Robot is given access to ATCannon's fire() method, allowing the bot to use the weapon to fire projectiles.

-lesser_power_source (not a real name) is a Robot Module of subtype PowerSource that provides a Robot with 30 Energy.

-ArcScanner is a Robot Module of subtype Sensor. It requires 10 Energy and provides the Robot with its scan() method, allowing the Robot to periodically detect objects within an arc.

The Robot rob is outfitted with a lesser_power_source, an ArcScanner and an ATCannon.
rob's energy requirements are 20, and the lesser_power_source provides 10 more than that. This Robot could hook up another module without penalty, if they wanted to. (Unless there's going to be a benefit to having more energy generation than you can use, module weights, etc).

instead of real-time measurements for core code (non-display code) a bout heartbeat should be used.

Module cooldowns would be an integer equal to a number of update cycles they should take to come back online.

Mass parallelization and leaning on the GIL doesn't seem like the cleanest solution to ensure equal runtime per entity.

However, without hooking the interpreter it seems difficult to circumvent user cheesing without threading or sloppy time delta techniques.

Scenarios to avoid:
-Bots are stateful and each "step" allows them to change their state; change rotation angle, change thrust value, scan, etc. This means there's a function in each bot contoller that evaluates the current state, sensor data, etc, and decides an appropriate reaction. If allowed to run until completion, this opens the door for a user to implement impractically complex and long-running evaluative methods, providing zero reward for efficient code.

-There is a thread for each bot controller. Efficient coding is rewarded, but relativity problems are introduced to the timeline. As the number of bots scales, each bot's full cycles per second decreases linearly, as the runtime stays constant. However, utilities like collision detection, while of linear complexity, scale exponentially relative to the bots. This creates possibility for noticeable inaccuracies at higher scale, and discrepancies across the board. It's possible that each entity could handle their own collision detection and other evaluative events, perhaps with callbacks or something - but that feels a lot like a patch that will complicate my life and haunt my dreams forever.

When running a bot controller, it's currently the case for smooth operation that regular small sleeps be present in the bot logic for purposes of quick and dirty GIL release. This isn't necessary, but removing the sleeps causes the display/update loop to stutter.

Running theory is that without a GIL-releasing trigger (like a sleep), the interpreter is strained, having to release the lock reactively.

Explore better methods of synchronization.
Maybe the display/update loop acquiring the GIL every update and releasing during its sleep.
A slicker method could be to iterate through each bot, giving them the GIL manually, and letting them each run for X time each cycle, before handing the lock to the display.

-clean up init files and module structure.
-remove unecessary imports (like importing Sensor when only ArcScanner(Sensor) is needed)

Solidify a structure for robot controller code.

Ideally, this will require minimal boilerplate code.
Perhaps a single import because sweet sweet IDE functionality.

Controller should be a class held by Robot.
Within Controller, robot components (sensors, weapons, etc) are defined, as well as robot Name, color, (if not desired to be random) and other customization things.

Paramount:
-Ensure that data such as Rob.position and Rob.hull has limited access so users can't set their hull to forty billion, weapon cooldowns to 0, and spin around in a circle, firing 1kdmg projectiles at mach 3.

For fun:
-Hooks on bot loaded, killed another, died, etc.