316dcd7d06
* cargo fmt * rename ButtonStyle to ButtonTheme to avoid ambiguity widgetry::styles::button:ButtonStyle -> ButtonTheme is a collection of colors vs. widgetry::widgets::button::ButtonStyle which is a per-state styling (hover vs. disabled etc.) * Collapse button styles to be theme specified (no visible changes). Button colors are now determined by the color scheme, but for now all schemes are hardcoded to use the same "night" button colors. Read on for rationale... Previously, which button colors to use (dark/light) was specified inline while building the UI. Eventually we want to live in a world where color scheme determines: - panel colors - button colors - text colors The theme could already choose panel colors easily enough, but because the buttons and text were not determined by theme, choosing anything other than a black or dark grey panel color makes the buttons and text unreadable. This PR tackled the themeable "button colors" portion, but all themes continue to use the "night" colors for now, because using the actual "day" colors would still make the text unreadable. next up: themeable text! The one intentional regression is within the pregame tutorial, which has always been styled differently from the rest of the app. An expeditious hack has caused the prev/next/continue buttons to lose their visible hover state. I'll restore this upon completing the day theme work. * rethink rename... keep Style.ButtonStyle, rename button::ButtonStyle->ButtonStateStyle * btn_solid_panel is the same as btn_solid |
||
|---|---|---|
| .github/workflows | ||
| abstio | ||
| abstutil | ||
| collisions | ||
| convert_osm | ||
| data | ||
| fifteen_min | ||
| game | ||
| geom | ||
| headless | ||
| importer | ||
| kml | ||
| map_editor | ||
| map_gui | ||
| map_model | ||
| osm_viewer | ||
| parking_mapper | ||
| popdat | ||
| release | ||
| santa | ||
| sim | ||
| sumo | ||
| tests | ||
| traffic_seitan | ||
| traffic_signal_data | ||
| updater | ||
| videos | ||
| widgetry | ||
| widgetry_demo | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| clippy.sh | ||
| import.sh | ||
| LICENSE | ||
| README.md | ||
| rgrep.sh | ||
| rustfmt.toml | ||
A/B Street
Ever been stuck in traffic on a bus, wondering why is there legal street parking instead of a dedicated bus lane? A/B Street is a game exploring how small changes to a city affect the movement of drivers, cyclists, transit users, and pedestrians. It works anywhere in the world, thanks to OpenStreetMap.
- Play on Windows, Mac, Linux, FreeBSD, your web browser, or read all instructions (new releases every Sunday)
- build from source (new changes daily)
- Try the Dec 2020 surprise: 15-minute Santa
Show, don't tell
Find a problem:
Make some changes:
Measure the effects:
Documentation
- How A/B Street works
- Technical
- Presentations
- April 2020 Rust meetup: recording, slides
- Feb 2020 traffic sim
- Oct 2019 Traffic sim and current challenges
- Oct 2019 Map construction
- Project
Roadmap and contributing
See the roadmap for current work, including ways to help. If you want to bring this to your city or if you're skilled in design, traffic simulation, data visualization, or civic/government outreach, please contact Dustin Carlino at dabreegster@gmail.com. Follow r/abstreet for weekly updates or @CarlinoDustin for occasional videos of recent progress.
Project mission
If you fix some traffic problem while playing A/B Street, my ultimate goal is for your changes to become a real proposal for adjusting Seattle's infrastructure. A/B Street is of course a game, using a simplified approach to traffic modeling, so city governments still have to evaluate proposals using their existing methods. A/B Street is intended as a conversation starter and tool to communicate ideas with interactive visualizations.
Why not leave city planning to professionals? People are local experts on the small slice of the city they interact with daily -- the one left turn lane that always backs up or a certain set of poorly timed walk signals. Laura Adler writes:
"Only with simple, accessible simulation programs can citizens become active generators of their own urban visions, not just passive recipients of options laid out by government officials."
Existing urban planning software is either proprietary or hard to use. A/B Street strives to be highly accessible, by being a fun, engaging game. See here for more guiding principles.
Credits
Core team:
- Dustin Carlino (dabreegster@gmail.com)
- Yuwen Li (UX)
- Michael Kirk
Others:
- All contributors
- Logo by Ryan Pierson
- Graphic design advice from Starcat Games, Daniel Huffman, Brian Prince
- Character art by Holly Hansel
- Lightning-fast pathfinding thanks to fast_paths by Andreas Barth (easbar.mail@posteo.net)
- Hackathon drop-ins from Democracy Lab events
- CUGOS and Julian Michael have been great sounding boards for ideas since the beginning
- In-game character faces adapted from Anokhee Jandhyala
- Pandemic modeling by Orestis Malaspinas (orestis.malaspinas@hesge.ch)
- Game design advice from Christopher Klein
- OSM expertise courtesy Mateusz Konieczny
- Lots of helpful PRs from Javed Nissar
- Lots of help with rendering SVG and fonts from RazrFalcon and nical
- Lots of traffic signal and uber-turn work from Bruce
Data:
- Special thanks to all OpenStreetMap contributors!
- King County GIS
- Seattle Open Data
- Puget Sound Regional Council
- IPUMS NHGIS, University of Minnesota