# Squanets

Squanets are planets of squares. We assume that we have levels of of either 192x192 or 256x256 units.

The intention of a squanet is to make planets more interesting by splitting their undifferentiated boring area into smaller, more focused spaces, and providing transitions between them. Squanets also reduce the space complexity per playable area, making full simulation less costly.

A squanet consists of one level partitioned into square subvolumes. Each square may either serve a system purpose or host a point of interest. The default assumption is simple:

At 192, a squanet provides:
- 1 hero volume at 128x128, or 126x playable
- 4 standard volumes at 64x64, 62x
- 4 small volumes at 32x32, 30x


And at 256, a squanet provides:
- 2 hero volumes at 128x128, or 126x playable
- 6 standard volumes at 64x64, 62x
- 8 small volumes at 32x32, 30x

(\* also see limitations)

It might not look like much of a difference, but a 192 only has 56% of the usable space. Still, it might be a necessary size concession to account for scaling up non-squanet spaces to match 256 on a side, since they are ~220? currently.

In order for volumes to work without excessive dedication of turfs to simple vision borders we should abandon that concept. It would be a waste to make volumes loop anyway.

Instead, volumes have a single impassable turf border. This catches movements into the edges that should cause transitions and eases use of existing projectiles, air, etc. Volumes are distinct from one another visually, using different plane groups (or renderers) to provide separation. They will also need work to be separated in most other interaction terms.

Hero volumes are large, at 8.5 screens across. They could host a major structure, starship crash, or small village.

Standard volumes are 4.25 screens across and can easily be used for notable things like pods and small structures.

Small volumes are ~2 screens across and should be reserved for utility - the planet map, landing points, and dynamic encounters.

## The planet map

The planet map is an overmap for the planet. Player mobs exiting the edge of a volume are held in hammer space while their view follows an entity on the planet map. They can move that around, enter volumes, and intercept other entities on the planet map as dynamic encounters. The planet map also has potential to contain roving encounters - hostile (or even neutral!) entities that will chase (or be chased by) players.

## Dynamic encounters

Dynamic encounters are small real spaces created when a planet map entity engages another planet map entity. That can be player/player, player/ai, or ai/player. A dynamic encounter can only be created when there is a free small volume. The terrain of the volume is generated on demand (that is freshly generated every time) and stuff, including involved players, is placed into it. There should probably be a timeout before people can escape them to avoid thrashing.

## Landing points

Landing points take up a free small volume, contain a shuttle, and are added to the planet map as joinable entities (ie, an ongoing dynamic encounter). They are removed when the shuttle and all players leave.

## Limitations

Even for a 256, that's not actually all that many volumes for dynamic encounters! 7 might sound like a bunch, but it becomes 5 or 4 if there are a few shuttles, and then if players split up ... - We could probably poach one more Standard to make it 12 smalls and 5 standards. This gets much worse for a 192, obviously, where we only have 56% as much space and *probably* want 3 standards and 7 smalls.

It's technically complex! Vision, speech, *sound*, and a bunch of other interactions need to be sandboxed in a way that isn't simply gated by level anymore. We have to build a bunch of infrastructure that is squanet-aware. Squeindly, if you will.