283KB on the wire, close to four megabytes in RAM: an ASCII city's real budget
A solo developer's walkable ASCII cyberpunk city ships as a 283KB Rust WebAssembly module. The numbers underneath that headline figure are the ones worth reading.
The Engineer · Build desk
What happened
- Rhys Gronow of Grow Now! Games put ASCII City Prototype 1 online this week, a walkable browser city with interiors, elevation and multiple floors.
- The page fetches a 283KB Rust WebAssembly module that reports engine version 0.1.0 when instantiated outside the browser.
- World generation runs in Rust, which passes packed byte arrays to JavaScript for display.
- The whole visible grid reaches the GPU as one buffer upload and one drawArrays call per frame.
- Access is being offered through Ko-fi, with no monetization plan, release date or final scope disclosed.
Why it matters
- What it costs cost The saving lands on the wire, not in RAM: whoever loads the page pays multi-megabyte residency for a sub-300KB fetch, which is why the touch profile cuts the grid instead of the detail.
- What's now possible capability With glyphs generated on the client, extra city costs generation time and code rather than download, so scope can grow while the fetch stays flat.
- What it limits constraint Caching per character-and-colour combination means visual variety, not map size, is what inflates the atlas and the upload, so the cheap axis to expand is the world.
- What doesn't add up contradiction The no-shaders, no-textures framing that carried the original video does not describe the build now on offer, which changes what the achievement should be credited for.
Next story · Product · 2d ago
Reviewers find ArtCraft's PhotoCraft looks like Photoshop but stumbles on HEIC and savingConfirmed3 publishers
The download figure is the smallest number in this build, and the file listing invites you to mistake it for the size of the thing. The module reserves 1,152KB of linear memory the moment it instantiates [2], roughly four times its weight on the wire [21]. The renderer then preallocates a 2.76MB vertex buffer and doubles it when a frame overruns [16]. Before you count the JavaScript, the shader pair or the atlas canvas, resident cost is already about fourteen times the fetch [22].
Divide the buffer by the grid and the geometry becomes legible. Desktop draws 180 columns by 80 rows, 14,400 cells [6], at six vertices apiece [4], which puts the preallocation at roughly 192 bytes per cell, near 32 bytes per vertex [26]. That is eight floats: a position, an atlas coordinate and not much else. All 86,400 vertices ride in the single upload [23]. Every cell is the same quad with a different lookup and the fragment stage is one texture2D call [15], so the batching costs nothing to arrange. Perspective comes from a custom ray-caster that fires rays from the camera each frame and uses first-hit distance for depth and occlusion, according to PC Gamer [20].
What the character grid buys is the absence of an asset pipeline. Nothing ships as a model or a texture; glyphs are drawn on the client with fillText, cached per character-and-colour combination, and uploaded once [4]. Download size therefore tracks code, and the code is generation: debug paths name city.rs, world.rs, population.rs, interiors.rs and rendering.rs [14], and the data crossing into JavaScript goes down to window styles, lit flags and floor plan IDs [3]. The corollary is that atlas growth is priced in palette rather than in city. More blocks cost nothing there. More hues do.
The engine also carries a separate 160 by 112 profile [7], 17,920 cells, a quarter more than the desktop display shows [24]; Tom's Hardware's inspection does not say what the surplus serves. Touch sessions drop to 48 rows and 96 to 168 columns [7], 32 to 56 percent of the desktop cell count [25], and two fallbacks sit beneath WebGL, a Canvas 2D drawImage path and a per-cell fillText path reachable with a ?direct parameter [8].
Grow Now! Games described the original demo to PC Gamer as having "no Unity, there's no Unreal, there's no 3D models, textures, or shaders" [9]. The build now playable compiles a shader pair and uploads a texture atlas [15][4]. Runtimewire's reading is that the ASCII presentation survives regardless, since what the browser draws underneath is GPU-backed textured geometry [12]. The video version filled 120 by 56 characters [17]; the playable one fills a little over twice as many cells [27]. Behind it is an audience of more than a million video views and 9,000 comments [11], and a studio that has disclosed no outside investors or funding [13]. PC Gamer reported Gronow is weighing dialogue and a fuller game [19]. On the evidence in the binary, the world can get much larger before the wire cost moves; the visual vocabulary is the part that has a price.
What to watch
- Whether the 2.76MB vertex buffer actually doubles in the field on mid-range phones running the narrow touch profile.
- Whether the atlas moves from runtime fillText to a prebuilt asset, which would put download size back in play.
- A named price or platform for the prototype, which would say whether the Ko-fi page is a tip jar or a storefront.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence74
- Adoption20
- Hype gap+28
- Incentives34
- Confidence70
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Rhys Gronow, a South Wales hobbyist behind Grow Now! Games, put ASCII City Prototype 1 online this week, turning a video experiment into a walkable browser city with interiors, elevation and multiple floors.
- [2]
The page fetches ascii-city-engine_bg-DqjAhqbp.wasm, a 283KB module that reserves 1,152KB of linear memory at startup and reports an engine version of 0.1.0 when instantiated outside the browser.
- [3]
World generation runs in Rust, which hands JavaScript base64-packed byte arrays covering building heights, tile kinds, surfaces, hues, saturations, window styles, lit flags and floor plan IDs.
- [4]
Characters are drawn once each into an atlas canvas with fillText, cached per character-and-color combination, uploaded to the GPU with one texImage2D call, then drawn as textured quads with six vertices apiece.
- [5]
Every visible cell goes into one buffer upload, and one drawArrays call per frame.
- [6]
Desktop sessions render 180 columns by 80 rows, or 14,400 character cells, in 10px Consolas at nine pixels per row.
- [7]
Touch devices drop to 48 rows and between 96 and 168 columns, and the Rust engine uses a separate 160 by 112 profile.
- [8]
Two fallbacks sit beneath the WebGL path: a Canvas 2D drawImage path when WebGL is unavailable, and a per-cell fillText path reachable through a ?direct URL parameter.
- [9]
Grow Now! Games described the original demo to PC Gamer as having "no Unity, there's no Unreal, there's no 3D models, textures, or shaders."
- [10]
The 283KB number describes the Rust WebAssembly module rather than the complete game download or its total memory footprint; JavaScript, WebGL shaders, browser memory and generated graphics also contribute to the running build.
- [11]
The original video had passed 1 million views and reached 9,000 comments.
- [12]
The current browser build still avoids a commercial game engine and conventional 3D assets, and its ASCII appearance remains intact even though the browser ultimately renders GPU-backed textured geometry.
- [13]
The available materials disclose no outside investors, funding round or valuation, and do not establish total revenue, retention or the playable build's user count.
- [14]
Exports include initialise_native_game, step_native_game and generate_native_local_map, and debug paths left in the binary name the Rust source modules city.rs, world.rs, population.rs, interiors.rs and rendering.rs.
- [15]
The renderer requests a WebGL context and compiles a vertex and fragment shader pair, the fragment stage consisting of a single texture2D lookup.
- [16]
The vertex buffer preallocates 2.76MB and doubles when a frame overruns it.
- [17]
The original video demonstration rendered at 120 by 56 characters.
- [18]
Prototype access is being offered through Ko-fi, and the available materials do not disclose a broader monetization plan, commercial release date or final scope.
- [19]
PC Gamer reported that Gronow was considering dialogue and a fuller game as possible future additions.
- [20]
PC Gamer reported that the custom ray-casting system casts rays from the camera each frame, identifies the first hit, and uses distance to calculate perspective, depth and which surfaces occlude others.
- [21]
The 1,152KB linear memory reservation is about four times the size of the 283KB module itself.
- [22]
The linear memory reservation plus the preallocated vertex buffer come to roughly 3.9MB, about fourteen times the 283KB download, before JavaScript, shaders, the atlas canvas and browser overhead are counted.
- [23]
A full desktop frame is 86,400 vertices sent in a single buffer upload and one draw call.
- [24]
The engine's separate 160 by 112 profile is 17,920 cells, about 24 percent more than the 14,400 cells the desktop display shows.
- [25]
The touch grid runs from 4,608 to 8,064 cells, or 32 to 56 percent of the desktop cell count.
- [26]
Spread across the 14,400-cell desktop grid at six vertices per cell, the 2.76MB preallocation is roughly 192 bytes per cell, about 32 bytes per vertex.
- [27]
The video demonstration's 120 by 56 grid was 6,720 cells, so the playable build's grid holds about 2.1 times as many cells.
Sources
2 independent publishers whose own reporting we read for this story.
- runtimewire.comRhys Gronow ships a walkable ASCII city with a 283KB Rust engine
1 article · August 22, 2026
- tomshardware.comWalk through a 3D cyberpunk city built purely from ASCII characters — a text-based metropolis runs on a 283KB Rust WebAssembly engine feeding a WebGL renderer
1 article · August 22, 2026
Topics and entities
Topics
- Solo indie game development
- Rust Game Engine Internals
- ASCII and text-mode graphics
- Browser GPU rendering
- WebAssembly runtime footprint
Entities
- ASCII City Prototype 1
- Rust
- Tom's Hardware
- WebAssembly
- WebGL