Game Projects

VHST Simpgrade Checklist

It makes more sense to distribute charms rather than make them random, and this in turn means that it's easier to connect multi-links and ensure things exist on every latitude. Also I'd optimally like to have 5 charms, as it just makes the whole thing much neater.

Delete charms latitude charms, they're now irrelevant.

Assign vhst_dir: NE and NW over and over repeating,

Latitude directions should go up or down by 30 degrees at a time. No actual charm needed. And making it 30 makes it make a bit easier to use.

Lat index shifts by 5 at a time, and wraps. Again, no charm needed.

Depending on the vhst dir, go NE+SW or NW+SE.

If you'd go off the latitude mapping, drop the link entirely.

Core Links

Seed the absolute value of the latitude and the longitude, with a negative of the longitude if latitude is positive. There's a 1/5 chance of there being a core link given on the district screen.

If so, transport you to the opposite longitude and opposite latitude, and make sure this works both ways.

This should get the framework of districting up to 100% -- the actual rendering would happen inside the city scale, so it's kinda irrelevant herein.

Cities Notes

Need this prior to checklisting it.



Blocks Structure

Each Block (an intersection of a horizontal road and a vertical road) contains 100 Buildings arranged in this way: 1 building on each "corner", and 12 buildings on either side of the corner on all four sections that face the block.

Your basic movement is: You can move from one building to the next. At a corner building you'd instead wrap around to the other side of it. You can also cross the road at any point. Basic movement takes a good bit of time since these buildings are huge, however street crossing isn't bad.

Transport

Transports all require activation via Wildcards, probably at something you have to navigate that's reasonably close via other transport networks -- this makes the game more metroidvania. I'm thinking there would also be speed upgrades that work similarly, requiring navigation to specific areas and costing Wildcards. Just makes the game a bit more interesting.

Taxis will pick you up at any stop around one of the 4 faces and drop you off at any stop. So they run the full 25-building route, which makes them pretty handy.

Subways run along the horizontal or vertical space, shifting in such a way that they cover half the length between a corner building and the next halfway point -- this isn't to scale because it assumes 4 buildings on either side, whereas the actual value is 12, so the gap would be 6 instead of 2, assuming my math holds up.

The "Interchange" node is always in the same spot and lets you cross between a horizontal track to a vertical track and vice-versa. You have to actually be on the right face. This doesn't cost disembarking time and you can switch to either direction. The interchange node however is only accessible from the subway system itself.

Each block has a single horizontal station, which lets you get onto either horizontal face. Same deal with the vertical track (which is missing the arrow in the diagram above). To switch faces you have to disembark at the station and switch tracks. Getting on the subway in any capacity actually requires going to the specified building.

Interaction with other systems

Each corner building has a Helipad elevator that goes to the helipad section, which is at the top of a platform on top of all four buildings and allows access to all four's top floors. However this requires unlocking the actual Helipad functionality with Wildcards. Helipad connections are therefore useful beyond their movement capabilities in that they allow bottom-to-top floor access and also connect four buildings together in a guaranteed way.

City edges and corners will lack 2 or 4 faces, crossing won't be possible and subways will turn around and become the other direction -- they'll also swap faces so using edges might be a valid trick for avoiding disembarking/re-embarking to switch faces. Helipads will obviously only go to 2 or 1 buildings.

Trains and VHST always appear at this special type of city block in the area you'd expect. For player sanity, taxis and subways probably just have an extra node in the center that allows access, or you can cross to it manually. Helipads will similarly have access to it.

City Notes 2

Forgot this one.

Helipads appear at the center nodes of a city block at the top floor of all the buildings, which are genned to have an identical amount of floors so this makes some kind of sense. They allow access to 2-adj tiles out of other helipads like this.

If you're in the center node you can also go 2-adj out at a higher range.

Lastly, if you're at the center node here you can move around a 4x4 grid of the entire city, which moves 25 city blocks at a time. This grid will also have access to the train and VHST transports.

Train / VHST Integration

Trains connect adjacent districts together, whereas VHSTs connect far-flung districts together via the charms algorithm. However, the stations are virtually identical, with one exception:

Train stations appear along edge blocks, while VHSTs appear along corner blocks.

The stations integrate in the following ways:

You can of course cross to them manually on foot.

Taxis and subways have an extra stop that allows access to them.

Helipads have a dedicated elevator that goes down to them.

The high-level helipad network will also connect to them despite them never being center nodes. They appear around the edges of the grid.

For wildcards, you can activate a Metro transport network, which links together all stations in the city. This allows you to move a larger number of districts relatively effortlessly.

Core stations are outside of town on one of the train pathways, however very close to the origin. This makes more sense from a lore perspective and also prevents the need of connecting them somehow to in-district transport networks.

Floor Plan Framework

This project creates the basis for floors, though it doesn't really define what the details/variables are that can be changed according to the building seed.

Phase 1: Generation

Some amount of hallways are generated. Maybe an average of 25, with 40 rooms apiece (with 20 per side).

Phase 2: Hallway Attachment

In the second step, each hallway is attached to another hallway in various ways. At each step it can favor either attaching to an unattached hallway or an attached hallway. It'll attach in the following single-use ways:

Lengthening -- the hallway attaches one of its ends to a free hallway end.

Split -- one of its ends will attach to a hallway at some node in the middle.

Intersection -- Some area along its length intersects with some area along another hallway's length.

It can also attach to a pre-existing intersection point (and may favor this or not, depending on building properties):

Branch -- Like Lengthening but attaches to a point where two hallways are already coming together.

Split Branch -- like a branch but comes from a split rather than a Lengthening. Basically it's a hallway that suddenly has a couple of branches coming out of a single node.

Intersection Branch -- a branch coming out of an intersection.

Complex intersection -- an intersection that happens within an existing intersection. This can stack a bunch of times.

Some of these may be favored over other types randomly.

Phase 3: Complexity

At the start of this phase, all existing intersections are labeled appropriately in the engine.

Each hallway can be thought of as having an end, a medial section (that contains rooms and intersections) and another end. In this phase, ends are attached to various things (or not) depending on their properties:

Nothing -- basically just becomes a dead end.

The other end of the same hallway, if possible. Favoring this leads to some pretty interesting layouts, regardless of what else is happening.

another hallway end. Identical to lengthening.

Part of a medial section. Identical to a Split.

An existing: one of anything already covered. Needs to be itemized, assuming it's even important.

For my own sanity, medial sections can't do anything more, they're purely determined by phase 2.

Phase 4: Hubs

For each promised staircase and elevator, turn the most congested intersections into hubs.

The rest can also be hubs with varying probability (no more than 50% though).

hubs will pull some amount of rooms out of the hallways attached to them. They'll also appear differently when rendered. That's really it though.

Floor Transport networks

Given some of the complexity here (and the sheer quantity of rooms), there are a couple optional (via wildcards) transport options:

Tube transit -- automatically goes down hallways, picking branches at random (though you can constrain it or tell it to stop). You can also alter the speed. Generally faster than just moving around on foot, largely automatic as well.

Hub transport -- transports between hubs on the network, note that this only applies to those with staircases or elevators.

Cities Checklist

Cities ultimately revolve around the "block" so I'll build the engine with that in mind.

Basic Stuff

Create cities{} and rename whatever is currently occupying that space if anything.

Figure out the 100 street names, and then stick both lists in a database.

Pull them back out, shuffling randomly, and turn this data into cities.horiz[] and cities.vert[].

Make sure player starting positions are still being generated, and ideally pull that endpoint out entirely to a top-level hook.

Run cities.render_block() in the init.

Block rendering

The trick here is creating a full block api, which transport networks tie into. Then your position generates your location in this schematic so it doesn't have to be stored anywhere. This also helps with figuring out Edges and Corners -- it's okay that those buildings just don't exist since we went for procgen rather than distributive languages.

Create .faces { horiz: {}, vert {}, corners: {} }. In here, make the various faces according to the image and list out the numbers from 0-99 in the appropriate spot. They should be labeled H1, V1, C1, etc appropriately.

get_face() looks up your position according to some basic if/else logic.

Movement API

move(dir,amt) will move a certain amount of positive or negative spaces in that direction. Horizontal faces get east/west and vertical spaces get north/south. This isn't going to go above 6, so it doesn't matter beyond that.

This does what you'd expect within your current face, however edges vary:

Horizontal Logic

Face	Dir	Logic
H1	West	go one block west, become H2.
H1	East	go through C* and then V*.
H2	West	go through C* and then V*
H2	East	go one block east, become H1.
H3	West	go one block west, become H4.
H3	East	go through C* and then V*
H4	West	go through C* and then V*
H4	East	go one block east, become H3.

If H is odd and west, go one block west, H+1.

If H is even and east, go one block east, become H-1.

Else, go through C* and then V*.

Vertical Logic

Face	Dir	Logic
V1	North	go one block north, become V3.
V1	South	go through C* and then H*
V2	North	go one block north, become V4.
V2	South	go through C* and then H*
V3	North	go through C* and then H*
V3	South	go one block south, become V1.
V4	North	go through C* and then H*
V4	South	go one block south, become V2.

If V1 or V2 and North, go one block north become V+2.

If V3 or V4 and South, go one block south, become V-2.

Else, go through C* and then H*.

Crossing

Crossing is used in both the subway and walking. The logic looks like this:

Face	Logic
H1	H+2
H2	H+2
H3	H-2
H4	H-2
V1	V+1
V2	V-1
V3	V+1
V4	V-1

If H1 or H2, run H+2.

If H3 or H4, run H-2.

If V is odd, V+1.

IF V is even, V-1.

Corner	Cross Dir	Goto	Logic
C1	East	C2	C+1
C1	South	C3	C+2
C2	West	C1	C-1
C2	South	C4	C+2
C3	North	C1	C-2
C3	East	C4	C+1
C4	West	C3	C-1
C4	North	C2	C-2

If West, go C-1

If East, go C+1

If North, go C-2

If South, go C+2

Misc Logic

The horiz station goes from H4 --> H2

The vert station goes from V2 --> V1

The vert/horiz interchange goes from H3 <--> V3