Ideas for design/game

[Frijol]

Hey this is Kelsey from the Lantern event last night! I recognize that this is obnoxious Github etiquette, but I didn't want to drop a whole slew of ideas issues, so please feel free to ask me to break out the ideas you like as their own issues.

1. For the commute overlay, I think what I was expecting to see was not just to/from, but a set of colored paths coming out of the hovered area: not just destination, but how people get there.
2. If you were to do ^, it would be useful to color the paths not just by absolute number, but by e.g. waiting time—implying an objective of reducing commuter frustration
3. And/or ^ color by transportation type, with an objective to reduce car traffic. Ofc this starts to get very handwavey since it means diverging from the existing sim model, but I think it would be not-crazy to build in an assumption that a given commuter would make a switch to whatever gets them to their destination fastest. This is probably my favorite part of playing Cities Skylines: I'm always trying to build a design that maximizes pedestrianism by building up transit. This would massively change the game—but I think per your objectives? After all, a big part of the appeal of improving transit is that it should change people's behavior; it's not going to make much difference in your sim to improve transit if nobody gives up the car commute to ride it.
4. Since it is turn-based, I'd imagine being able to see the whole day all at once in simulations like ^. Of course, you'd immediately want to change your streets and rerun to see the whole-day difference, which gets compute-intensive pretty fast, but perhaps since it's game-based there's a way to design around that, e.g. in a challenge you have X budget corresponding to X # changes? (Thinking that in games, frustration can be part of the design)
5. Just to document it here, color gradients might be more helpful if absolute, if what the player is trying to do is identify problem areas. Instead of a transparent-to-red gradient, maybe more of a blue-to-red, so it doesn't just wash out in low areas? Or since you already have various map subsections, maybe the scale sets by map
6. For survival mode, instead of playing from midnight, what about slicing the day into X-minute chunks and rearranging them in order of difficulty (# of wait times above 12 minutes across the city in the vanilla sim?) (no idea how hard it is from your end to set initial state, but seems plausible to save it at intervals?). This lends itself to levels: you survived the morning commute! (Also avoids the mini metro sour feeling of: you lose every single time)
7. In general instead of playing from midnight, maybe make the day start at 4am? This is a more human-oriented cutoff point; I'd assume that midnight to 3 is people still awake from the previous night. Would also let you get to the more interesting commute hours faster.

Might have some more ideas, will add if I think of them. Thanks for the demo, obviously you have me hooked on the concept!

[dabreegster]

Hi Kelsey, thanks for stopping by and providing these ideas!

The commuter patterns layer

For reference, this thing:

a set of colored paths coming out of the hovered area: not just destination, but how people get there.

This could indeed be a useful dataviz. Originally this layer was meant to solve the problem that just showing every single trip as a straight line or a route would be absolutely overwhelming. But if we're just considering a pair of "neighborhoods" or a single start/end, we could probably try doing this. I don't have examples handy, but I've seen visualizations where a route starts very thick near the source, then as people take different paths to different destinations, the line thickness thins out.

it would be useful to color the paths not just by absolute number, but by e.g. waiting time

We've got some layers that show delay at any particular moment in the simulation, and maybe we've tried coloring intersections/roads by the aggregate delay experienced over the whole day... but this would be even more focused. Between Ballard and the Udistrict, where are people waiting the longest? And since we measure stuff like risk exposure, we could also show the most dangerous (or at least stressful) parts of the routes.

Instead of a transparent-to-red gradient, maybe more of a blue-to-red, so it doesn't just wash out in low areas? Or since you already have various map subsections, maybe the scale sets by map

Was this just in context of the commuter patterns layer, or also stuff like instantaneous delay?

Mode shift

I think it would be not-crazy to build in an assumption that a given commuter would make a switch to whatever gets them to their destination fastest

Yes! This is the elusive mode shift. The thing stopping us from trying this so far is not being confident about calculating which people actually would switch modes, given changes to the map. One idea is to just estimate total travel time by all the modes and pick the fastest, but...

1) I think this doesn't match people's real behavior -- sense of safety/comfort and trip purpose (bringing kids to school vs going out for a coffee) probably factor in too. Defining how a utility function should combine these different factors is unclear so far. 2) Estimating those times by static pathfinding will usually mean driving comes out the winner. But maybe if we measure real times from the "previous day's" simulation before the map edits, we have more info about the time it takes to park, get past traffic signals, etc. 3) We have to figure out how to initially calibrate the travel demand model we're bringing in from Soundcast. Before any map edits, what if we run this "mode shift" process and find that the original mode that Soundcast predicted for a bunch of people doesn't match what we think? Maybe this mis-match could help us parameter tune our end.

We do have some existing controls to manually perform mode shift, but it's a blunt hammer of percentage of trips:

Gameplay

Since it is turn-based, I'd imagine being able to see the whole day all at once

There could be two types of scores that we give the player in response to map edits. 1) a mode shift prediction, which could be fast to recalculate, since it might just use pathfinding and pick the "best" mode 2) the actual per-trip travel time, delay, risk exposure, etc measurements, from the slower simulation

in a challenge you have X budget corresponding to X # changes

I think this is a great way to scale the game's challenge modes. We need more progression from easy to hard "levels", and picking much smaller maps and limiting edits is probably a way of defining those levels.

For survival mode, instead of playing from midnight, what about slicing the day into X-minute chunks and rearranging them in order of difficulty

This is brilliant! It simplifies some real-world issues -- a certain traffic signal has multiple plans through the day (morning rush, slo weekend night), but we don't support that yet. Just focusing the sim on certain time periods would dodge this. Also, some strong feedback about things like the traffic signal survivor challenge that we've gotten is that the feedback loop is way too slow -- you change a signal, then have to start the simulation over to see the full effects. We've tried to mitigate by changing the signal "instantly" without reseting to midnight. But still, the score function of "survive the whole day" is too monolithic. Chopping up into smaller pieces spreads out the reward and makes it more obtainable.

The technical challenge here... We can "savestate" the simulation and start from any time, at the expense of downloading more larger files. But the simulation state that we start from would be pre-calculated probably, and based on the unedited map, not incorporating the player's changes. In many cases, that'll just gridlock / totally break by 6am or really early. So we'd start people off with impossible traffic jams.

.... Maybe we've been overcomplicating this. We could break up the day into different time chunks, and just initially seed the simulation with trips starting from then (or a bit earlier). If one level starts at noon, we spawn all trips beginning at 11:45 and... maybe just simulate 15 minutes without any player edits, then drop them in.

In general instead of playing from midnight, maybe make the day start at 4am?

This gets at the same problem as above. I've been trying to keep things too "realistic." Our travel demand model input roughly describes a typical weekday, so how do you initially seed the simulation? If you just start all trips at 4am, what about the ones that are still ongoing by 4am? Midnight is a convenient number and usually has low traffic, so that's why we've been choosing that start point. But I think indeed we could start anytime of the day, and just seed trips from 15-30 minutes before that moment.

Thanks a ton for all of the ideas! It's massively helpful to have a fresh perspective on things.