Wifi and Drone Networks

In Factropy various types of entity can connect to Wifi -- wifi towers, arms, loaders, containers, drone ports, vehicle stops, fluid tanks, computers etc. This is similar to connecting stuff by circuit network in Factorio, with wifi packets acting like circuit signals. The lack of wires makes it less fiddly to work with, and wifi network names (SSID) keep overlapping networks separate.

The thinking is that anywhere in the game entities can form a "network" for the purposes of interaction or control, then it should be a wifi network unless there's a really good reason to do it differently.

Setup Process

• Place a Wifi Tower, choose an SSID and connect other entities
• Place another Wifi Tower to extend the network
• Local network connections between an entity and nearby towers are blue animated packet streams
• Longer tower to tower connections are yellow animated packet streams
• Connected entities show a tiny aerial :)

Drone Port Networks

Drone Ports don't form a Factorio-style "roboport network" analogue based on proximity and range, instead they can connect to a wifi network and all entities on the same network co-operate for logistics and construction regardless of physical location.

A Drone Port without a wifi network connection always does the following within a 100m area-of-operations (AO) radius:

• Repair damaged entities
  
• Construct ghosts with resources from buffer or provider containers
• Supply requester and buffer containers from providers
  
• Redistribute overflow items to other logistic containers with space

A Drone Port with a wifi connection will perform some operations outside its local AO:

• Supply networked requester and buffer containers outside its AO from local providers within its AO
• Supply requester and buffer containers within its AO from networked providers outside its AO
• Redistribute overflow resources from containers within its AO to networked containers with space outside the AO
  

By combining local AO behaviour with network configuration, it's possible to control stuff like:

• Precisely where drones can go and which resources they have access to
• Ensuring construction or logistics request are serviced by nearby drones
  
• Running multiple overlapping drone networks that operate independently
• Move resources between networks or over long distances

Network Packets

Underneath the obvious high-level game-play differences, the low-level basics of Factropy wifi networks are similar to Factorio circuit networks:

• Containers can transmit their contents as item signals with counts
• Network packets of the same item type automatically sum
• Some entities like arms and loaders can be controlled by network rules

However there are no combinators here. Instead there's currently a Computer entity which:

• Has multiple NICs to bridge wifi networks
• Has a limited number of CPU cycles per tick
• Has a limited amount of RAM addressed like a spreadsheet
• Runs as a tiny stack machine with a reduced instruction set
• Compiles external source files, so one can use a favourite editor

The Computer won't be to everyone's taste and is still quite rough around the edges! Probably a future Dev Log there.

The Problems are...

Wifi networks are rebuilt when a networkable entity is constructed. This is relatively infrequent so the network system (an ECS) has low overhead per tick. When networks must be rebuilt the following steps occur:

• Use a flood-fill algorithm to find network hubs (Wifi Towers) with overlapping AO transmission ranges
• Use a flood-fill algorithm to find network nodes (everything else) within each hub AO
• Rebuild the hierarchical tree of network links from both data sets

Obvious problems include:

• Placing a single networkable entity could cause the network rebuild code to touch every other networkable entity on the map
• Searching for network nodes is heavy on spatial index queries, which are cheap individually but quickly become expensive in aggregate
• Maintaining network state across a rebuild suffers requires extra code to handle large network splits and joins
• Moving entities are problematic because they can go in and out of range, breaking the static network tree

Obvious enhancements:

• Use a dedicated spatial index for networkable entities tuned for hub AO size
  • Complete; this is essentially a coarse grid index
    .
• When the network system ticks the simulation spatial index is in read-only mode, so it's fine go parallel with the thread pool
  • Complete; though C++, the thread pool is based on CSP (goroutines, channels) and easy to fan out quickly
    .
• Don't make moving entities (vehicle, aircraft) wifi-capable; instead make their stops and landing pads the networkable part
  • Complete; logistic vehicles take signals from their next stop or waypoint, and aircraft from their next landing pad
    .
• Initially flood-fill only from the newly placed entity to establish a smaller set of potentially-affected nodes. If they form a discrete group then it's find to only rebuild networks they touch
  • Incomplete; my largest test bases haven't stressed this bottleneck yet so it's hard to tell if it's worth the effort and extra tracking of state across rebuilds