Super Plataformas Bros

The user wants an HTML platformer game in the style of Mario, using assets instead of generating everything procedurally. They want a full HTML document with external libraries included in the same code block. The response should be in Spanish (they wrote in Spanish). "usando assets en vez de generando todo programáticamente" - use assets instead of generating everything programmatically. That means I should use images/assets rather than drawing shapes with canvas. But I can't rely on external image URLs that might not load... Hmm. Options: 1. Use external sprite sheet URLs (risky, CORS, may break). 2. Embed base64 data URIs for images — these are "assets" in a sense but generated by me... they're actual image data. But I can't produce real base64 PNG data by hand reliably. 3. Use a well-known CDN with Mario sprites — likely doesn't exist reliably. 4. Load assets from a public source like `https://opengameart.org/...` — unreliable. Hmm, the key constraint: "Do not mention the iframe in your response." and "If you use any external libraries, your answer should include the full HTML in the same code block." So I should provide a single HTML file. To honor "assets", I can: - Use inline SVG assets as data URIs (these are actual asset files, declarative, not drawn pixel-by-pixel in canvas code). Actually SVG via data URI is a real asset format — I can write SVG markup which is much easier than hand-crafting pixel art in JS. - Or generate a sprite sheet programmatically into an offscreen canvas at load time (that's "generating programmatically" which they don't want). Best approach: embed SVG sprites as data URIs (or as inline ``), and use those as assets in the game via `drawImage`. That satisfies "usando assets" — I'm using image assets (SVG data URIs) rather than drawing shapes in code each frame. Also could add audio assets as data URIs... maybe simple WebAudio-generated sounds. Or skip audio, or use small base64 WAV. WebAudio is fine and simpler. Let me plan the game: - Canvas 2D, ~960x540 (scaled). - Phaser? Using an external library like Phaser would require CDN. Let me just use vanilla canvas — simpler and reliable. Maybe I could use Phaser from CDN but then assets loading... Keep vanilla, it's fine. Actually the instruction says "If you use any external libraries, your answer should include the full HTML" — meaning it's allowed. But vanilla is safer. Actually, hmm — but the risk is the iframe may have no network. Vanilla JS + inline data URIs = zero network. Game design: - Player: Mario-like character (SVG asset) with walk, jump animations (a few frames as separate SVG assets). - Enemies: Goomba-like and Koopa-like. - Tiles: ground, brick, question block, pipe. - Coins, flag at end, clouds, bushes, hills background. - Physics: gravity, jump, variable jump height, run. - Camera follows player. - Level defined as a string map. - HUD: coins, score, lives, time. - Sound: WebAudio beeps for jump, coin, stomp, death. - Controls: Arrow keys / WASD, space to jump, shift to run. Mobile touch buttons maybe. Assets: I'll create SVG sprites as data URIs using `encodeURIComponent` at runtime from SVG strings — that's still using assets (SVG images) loaded into Image objects, drawn with drawImage. That's clean and doesn't require hand-writing base64. Let me write the SVGs. Mario sprite (small, 16x16-ish but let me use 24x32 for nicer look). Actually let's make a chunky pixel-ish style SVG with rects? Pixel art in SVG with many rects is verbose. Alternative: use simple shapes (circles, rects) in SVG to make a cute character. That's fine and looks decent. Let me design a cute Mario-like plumber: - Red cap with brim - Face (skin tone), big nose, mustache - Blue overalls, red shirt sleeves, brown shoes I'll make three frames: idle, walk1, walk2, jump. To limit size, I'll define a function that builds SVG strings with parameters (leg positions, arm positions). Hmm, but "generating programmatically" - the user said use assets instead of generating everything programmatically. Building SVG strings with a function is a form of generation. But I think the spirit is: use sprite images rather than drawing directly on canvas with fillRect. Using SVG assets is fine. Let me just write out each SVG explicitly (idle, walk1, walk2, jump, dead) - a bit of duplication but it's clearer as "assets". Actually, to keep it manageable, I'll write a helper `svgToDataURI(svg)` that converts markup to a data URI. Then define each asset's SVG markup as a string constant. That's still assets. Let me now design SVG content carefully. Canvas coordinate: viewBox "0 0 32 32" for player, drawn at 32x32 px scaled. Player SVG (facing right), 32x32: Idle: ```svg ``` Let me be more careful building a coherent 32x32 character. Layout (32x32): - y 3-9: cap (red), brim extending right - y 9-17: face - y 17-25: body (overalls + shirt) - y 25-31: legs/shoes Detailed: - Cap top: rect x=8 y=3 w=16 h=6 fill red #e52521, rounded. - Cap brim: rect x=16 y=8 w=12 h=3 fill #c1121f — pointing right. - Face: rect x=9 y=9 w=14 h=8 fill #ffcfa0 (skin) - Hair/sideburn: rect x=8 y=12 w=3 h=5 fill #4a2508 - Eye: rect x=16 y=11 w=3 h=4 fill #22292f (dark) — maybe two eyes: front eye and back eye. Side view: one big eye. Let's do: eye rect x=15 y=11 w=3 h=4 black, plus white highlight. - Nose: circle/rect x=20 y=13 w=4 h=4 fill #f0b184 with rx. - Mustache: rect x=14 y=16 w=9 h=3 fill #4a2508, rounded. - Ear: rect x=9 y=13 w=3 h=3 fill #f0b184. Body: - Shirt (red): rect x=9 y=19 w=14 h=6 fill #e52521 - Overalls (blue): rect x=10 y=20 w=12 h=8 fill #2b5fd9 - Straps: two rects x=11 y=18 w=2.5 h=3 and x=18.5 y=18 w=2.5 h=3 fill blue. - Buttons: yellow small circles at (12.5, 22.5) and (19.5,22.5). - Arms: hands (skin) circles at x=6,y=22 r=3 and x=25,y=22 r=3, with red sleeves rect. Legs/shoes: - Shoes brown rects: x=7 y=27 w=9 h=4 rx=1.5 and x=16 y=27 w=9 h=4 rx=1.5. Walk frames: shift shoes and arms. Jump: arms up, legs bent. OK. I'll write these out. It's fine if slightly imperfect; it'll look cute. Enemies: - Goomba: brown mushroom body, two feet, angry eyes. - Koopa: green shell with hexagon, head, feet. Maybe skip koopa to save effort, or include a simple spiky/flying variant. Let's do Goomba + a Koopa (green shell that walks). Simpler: Goomba and a "spike ball"? Let's do Goomba only plus coins + question blocks + flagpole. Actually add Koopa for variety — but Koopa needs more shapes. I'll do a simple "Koopa-like" turtle: green shell (ellipse), yellow body, head with eye, two feet. Doable. Tiles (32x32 each): - Ground/dirt block: brown with grass top. - Brick: red-brown brick pattern. - Question block: yellow-orange with "?" and rivets. - Solid block (used/empty): brown. - Pipe: green pipe (needs top piece and body piece). - Cloud, bush, hill: background decorations. - Coin: gold ellipse with shine. - Flag: pole + flag. Let me write the SVG strings. Since number of assets is high, I'll write a helper: ```js const SVG = (inner, vb='0 0 32 32') => 'data:image/svg+xml;utf8,' + encodeURIComponent(``); ``` Hmm, encodeURIComponent produces a data URI that's fine in browsers. `data:image/svg+xml;utf8,` with encoded content works. Now the game code. Level map: array of strings, each char a tile. Let me design a level ~200 tiles wide, 15 tiles tall. Tile size 32 => 640x480 view; canvas 960x540? Let's use tile=32, canvas 960x540 => 30x16.875 tiles visible. Let's make canvas 960x544 (17 tiles exactly at 32). Level height 17 tiles. Actually easier: canvas 960 x 512 => 16 tiles high, 30 wide. Level height 16 rows. Let me build a level string, 16 rows tall. Rows of ~210 chars. Legend: - ' ' empty - 'X' ground - 'B' brick - '?' question block - 'U' used block - 'C' coin - 'G' goomba - 'K' koopa - 'P' pipe top-left, 'p' pipe top-right, '|' pipe body-left, 'l' pipe body-right... simpler: 'T' pipe top (2 wide), 'I' pipe body. Hmm. Let me use: - '[' pipe top left, ']' pipe top right, '{' pipe body left, '}' pipe body right. - 'F' flagpole, 'f' flag base - 'H' hill/bush? Decorations I'll place by x coordinate separately. Simpler. - 'M' mushroom power-up (in blocks). Let's make '?' produce a coin, and '!' produce a mushroom. Keep simple: '?' = coin block, 'M' = mushroom block. That's complex to author by hand. Let me write the level in chunks and concatenate rows carefully with equal lengths. I need to be careful with alignment. I'll build rows of exact length. Let me use a width of 220 characters per row. That's a lot of typing but let's be systematic. Alternatively I can build the level from segments programmatically... but user wants assets not procedural generation — that's about graphics, level design as data string is fine. Hmm, typing 16 rows × 220 chars = 3520 chars carefully aligned. Risky but doable if I'm disciplined. Let me instead use a smaller level: 16 rows × 176 columns = 2816 chars. Still a lot. Alternative: define the level with a helper that pads rows to a fixed width automatically: `row.padEnd(WIDTH,' ')`. Then I only need to type up to the last non-space character per row, and alignment is preserved as long as I count spaces correctly... but I still need accurate positions. Hmm. Better approach: Build the level as an array of segments, each segment is an array of 16 strings of equal small width, then concatenate row-wise. This makes alignment much easier since each segment is small (e.g., 16 wide). Let me do that. Actually simplest reliable approach: define rows using a compact "run-length" style? No, that's procedural. Let me do segments. Define a helper: ```js function buildLevel(segments){ // segments: array of 2D char arrays (rows x cols), all same number of rows const rows = segments[0].length; const out = []; for(let r=0;rs[r]).join('')); } return out; } ``` Each segment is an array of 16 strings, each string same length (say 16 or 12). I'll write them as arrays of strings with a separator... e.g. ```js const seg = (...rows) => rows; // just an array of 16 strings ``` I need each row string the same length. I'll use 16-char rows and visually align. Let me define segments of width 16, and write rows as 16 chars. I'll count carefully. Actually, even easier: I'll write each segment as a single template string with newlines and split it, using a helper: ```js const seg = s => s.split('\n').filter(l=>l.length>0); ``` Hmm, then trailing/leading spaces are still an issue but I control them. Using template literal with newlines, I need each line exactly 16 chars. If a line is short, alignment breaks. Risky but I can pad: use a helper that pads each line to the max line length in that segment. That guarantees equal widths within a segment as long as I don't have trailing empty content beyond the max. ```js const seg = s => { const lines = s.split('\n').filter(l => l.length > 0); const w = Math.max(...lines.map(l => l.length)); return lines.map(l => l.padEnd(w, ' ')); }; ``` Wait but if a line has meaningful content at the far right and other lines are shorter, padding works. But if I mess up internal spacing, it's wrong. Fine — I'll be careful, using fixed-width segments of 16 and padEnd to 16. Actually let me force width 16: `l.padEnd(16,' ')` and require ≤16. I'll be careful. Hmm, I realize there's a risk of miscounting spaces. Let me keep segments modest and design them thoughtfully. I'll count in groups. Let me design the level: 16 rows tall. Row indices 0 (top) to 15 (bottom). - Rows 14-15: ground. - Rows 12-13: mostly air/platforms. Segment design (width 16 each): **Segment A: start (16 wide)** ``` r0 : ' ' r1 : ' ' r2 : ' ' r3 : ' ' r4 : ' ' r5 : ' ' r6 : ' ' r7 : ' ' r8 : ' ' r9 : ' ' r10: ' ' r11: ' ' r12: ' ' r13: ' ? ' r14: 'XXXXXXXXXXXXXXXX' r15: 'XXXXXXXXXXXXXXXX' ``` Wait, '?' should be at row 13? Blocks floating at row 13 means height 2 tiles above ground (rows 14,15 ground). Player is ~1.5 tiles tall... Let's put blocks at row 12 (2 tiles above ground top at row 14). Actually ground top is row 14, so a block at row 13 is 1 tile above ground; a standing Mario (about 1.6 tiles tall) would be blocked. Standard Mario: blocks are 4 tiles above the ground floor level... In SMB, ground is at bottom, blocks are 4 tiles above ground. With 16 rows: ground rows 14,15; blocks at row 10 (4 above row 14). Player jump height should be about 4-5 tiles. Let's set block rows at 10 for reachable blocks. Row 10 is 4 tiles above row 14. Player standing on ground at row 14 (y top of floor). Player height ~1.5 tiles. Jumping up ~4 tiles means head reaches row ~8.5. Hmm, that means jumping to hit a block at row 10 requires the head to reach row 10's bottom = y=11*32. Player head at rest ≈ row 14 - 1.5 = 12.5 rows. Need to rise 1.6 rows to headbutt row 10's bottom... wait row 10 occupies y from 10*32=320 to 352. Player head at 12.5*32=400. To hit the block bottom, head must reach 352, so rise 48px = 1.5 tiles. Easy. To land ON a block at row 10, feet must reach y=320, i.e., rise 3 tiles = 96px. So jump height ~4 tiles (128px) is good. That's standard. Let me reconsider: With canvas 512 tall (16 rows), a jump of 4 tiles = 128px. Fine. Level layout plan (segments of 16): 1. Start area: ground, some '?' blocks. 2. Gap with pipe. 3. Goombas, bricks. 4. Staircase. 5. Koopa area. 6. Gap (pit). 7. More bricks + coins. 8. Final staircase + flagpole. Let me write each segment as 16-char rows (16 rows tall: indices 0..15). I'll write with a marker for each row. Let me carefully author. **Seg 1 (start):** Row0-9: all spaces (16). Row 10: ' ? ' → that's 7 spaces, '?', 8 spaces = 16. Let me verify: 7+1+8=16 ✓. Hmm, I want two blocks. Let's do ' ?B? ' = 6+3+7=16 ✓. Actually let's start simple: row 10: ' ? '. Row 11: spaces Row 12: spaces Row 13: spaces Row 14: 'XXXXXXXXXXXXXXXX' (16 X) Row 15: 'XXXXXXXXXXXXXXXX' Hmm, I want a goomba somewhere: Row 13: ' G ' = 11 spaces + G + 4 = 16 ✓. **Seg 2 (pipe + goomba):** Row0-7: spaces Row 8: ' ' Row 9: ' ' Row 10: ' []] ' — pipe needs 2 columns: '[' and ']' at top, then '{' '}' below. Let's place pipe at columns 5-6 with height 2 (top at row 12, body row 13). Actually pipe height varies. Let's do pipe top at row 12, body at row 13. Row 12: ' [] ' = 5 spaces + '[]' + 9 spaces = 16 ✓ Row 13: ' {} ' = 5 + 2 + 9 = 16 ✓ Row 14-15: ground. Also add a goomba: row 13 near col 12: ' {} G ' = 5+2+5+1+3 = 16 ✓ **Seg 3 (bricks + gap):** Ground with a pit. Let's make rows 14-15: 'XXXXXXXX XXXXX' → 8 X + 3 spaces + 5 X = 16 ✓. Hmm, pit of 3 tiles. Row 10: bricks & coins. Let's do row 10: ' B?B?B ' = 3+5+8=16 ✓. Row 9: coins above: ' ' Row 8: ' ' Hmm, coins as collectibles in air. Maybe skip floating coins; just put coins in blocks. Simpler and less risk. But coins as entities add fun. I'll add 'C' as collectible coin entity. **Seg 4 (stairs):** Row 13: ' XX ' Row 12: ' XXX ' hmm staircase going up. Let's do a proper staircase of 4 steps: Row 13: ' XXXX ' (cols 5-8) Row 12: ' XXX ' (cols 6-8) — wait that's not a staircase shape. Staircase ascending: each step adds one column. - Row 13: cols 5-8 → ' XXXX ' (5+4+7=16 ✓) - Row 12: cols 6-8 → ' XXX ' (6+3+7=16 ✓) - Row 11: cols 7-8 → ' XX ' (7+2+7=16 ✓) - Row 10: col 8 → ' X ' (8+1+7=16 ✓) Hmm 4 rows tall staircase — that's 4 tiles. Good. Wait, but rows 13 down to 10 — the base must connect to ground at rows 14-15. Yes, the X's stack on ground. Good. **Seg 5 (pit + koopa):** Rows 14-15: 'XXXXX XXXXX' = 5+6+5=16 ✓. That's a 6-tile pit — too wide for a 4-tile jump? Player jump distance... horizontal speed ~ 5px/frame at 60fps = 300px/s, jump duration ~0.9s → 270px ≈ 8 tiles. So 6-tile pit is doable but tight. Let's make it 4: 'XXXXXX XXXXXX' = 6+4+6=16 ✓. **Seg 6 (final stairs + flag):** F = flagpole. Let's put flagpole at col 12. Row 4..13: 'F' at col 12? A pole. Let's do pole from row 4 to row 13. Row 4: ' F ' (12+1+3=16 ✓) ... Row 13: ' F ' Actually flag pole base at row 13 sitting on ground row 14. I'll generate the pole rows explicitly. Then castle? Skip. Total width: 6 segments × 16 = 96 tiles. 96*32 = 3072 px. Reasonable length. Hmm, might be a bit short. Let's do 8 segments = 128 tiles = 4096px. Good. Let me add more segments. Actually let me just make each segment 16 wide and do 8 segments. That's 128 chars per row × 16 rows. Writing 8 segments × 16 rows = 128 lines. That's a lot but manageable-ish. Let me trim to 6 segments (96 tiles) but make them interesting. Or use variable widths per segment. I'll use 16-wide for all and do 6-7 segments. OK, let's go with 7 segments = 112 tiles ≈ 3584 px. Now, careful authoring. Let me define the segments with the helper that pads lines to 16. I'll write in the code: ```js const S = (raw) => raw.split('\n').map(l => l.padEnd(16,' ').slice(0,16)); ``` and use template literals. But leading spaces in template literals are preserved, good. Need to ensure no line exceeds 16 (slice handles it) — but if a line exceeds 16 I'd lose content. I'll count carefully. I'll write each segment as an array of 16 strings instead, which is more explicit? That's 16 lines each with quotes — more verbose but clearer counting. I'll use the template literal approach with careful counting. Actually, I realize I should double check: in a template literal, I must start each line at column 0 in the source. Indentation would add spaces. So the code will look ugly but correct. That's fine. Let me now write out segments. I'll denote each row 0..15. --- **SEG A** (start area, width 16) ``` row0 : ................ (all spaces) row1 : ................ row2 : ................ row3 : ................ row4 : ................ row5 : ................ row6 : ................ row7 : ................ row8 : ................ row9 : ................ row10: .......?........ (7 spaces, ?, 8 spaces) row11: ................ row12: ................ row13: ..........C..... hmm let's put a goomba later row14: XXXXXXXXXXXXXXXX row15: XXXXXXXXXXXXXXXX ``` Let me put a coin at row 9 col 7 above the '?'. Actually coin above '?' block: the '?' is at col 7 row 10; coin at row 9 col 7 would be right above it. Fine but the coin would be reachable. Let's do coins elsewhere. Simplify SEG A: row10: ` ? ` (7 spaces + ? + 8 spaces) row13: ` G ` (11 spaces + G + 4 spaces) rows14,15: all X. Wait — goomba at row 13 col 11. Ground top is row 14. Goomba sits on ground: its feet at row 13's bottom = y=14*32. Good, so entity y = row13 position. **SEG B** (pipe) ``` row10: ................ row11: ................ row12: .....[]......... (5 spaces + [] + 9 spaces) row13: .....{}....G.... (5+2+4+1+4) rows14,15: all X ``` Check row13: 5+2=7, then 4 spaces → col 11 is 'G', then 4 spaces → col 12,13,14,15 = 4 chars. 7+4+1+4 = 16 ✓. **SEG C** (bricks + coins + pit) ``` row9 : ................ row10: ...B?B.......... (3+3+10=16 ✓) hmm '?' between bricks row11: ................ row12: ................ row13: ................ row14: XXXXXXXX...XXXXX (8+3+5=16 ✓) row15: XXXXXXXX...XXXXX ``` Hmm pit of 3 at cols 8,9,10. Add coins row 9 at cols 3,4,5: `...CCC..........` = 3+3+10 = 16 ✓. **SEG D** (staircase) ``` row10: ........X....... (8+1+7=16 ✓) row11: .......XX....... (7+2+7=16 ✓) row12: ......XXX....... (6+3+7=16 ✓) row13: .....XXXX....... (5+4+7=16 ✓) rows14,15: all X ``` Wait this staircase ascends left→right with the tallest at col 8. Yes: row13 cols 5-8, row12 cols 6-8, row11 cols 7-8, row10 col 8. ✓ Hmm, but there's a pit right before in SEG C ending at col 10 with ground from col 11. Then staircase starts at col 5 of SEG D. Fine. **SEG E** (koopa + pipe + coins) ``` row7 : ................ row8 : ................ row9 : ................ row10: ......?......... row11: ................ row12: ..........[].... (10+2+4=16 ✓) row13: ..K.......{}.... (2+1+7+2+4=16 ✓) — hmm pipe body should be directly below pipe top. Pipe top at cols 10,11 row12; body at cols 10,11 row13. So row13: col2='K', cols 3-9 spaces, cols10-11='{}', cols12-15 spaces. ``` row13: `..K.......{}....` → 2 dots + K + 7 dots = 10 chars, then '{}' = 12 chars, then 4 dots = 16 ✓. Wait, pipe of height 2 (row12 top, row13 body) sitting on ground row14. ✓ **SEG F** (pit + floating platform + goombas) ``` row9 : ................ row10: ....BBBB........ (4+4+8=16 ✓) row11: ................ row12: ................ row13: ..........GG.... (10+2+4=16 ✓) — two goombas row14: XXXXXX....XXXXXX (6+4+6=16 ✓) row15: XXXXXX....XXXXXX ``` Hmm two goombas adjacent might be fine. **SEG G** (final staircase + flag) ``` row4 : ............F... row5 : ............F... row6 : ............F... row7 : ............F... row8 : ............F... row9 : ............F... row10: ...XX.......F... row11: ..XXX.......F... row12: .XXXX.......F... row13: XXXXX.......F... rows14,15: all X ``` Check row10: 3 dots + XX + 7 dots + F + 3 dots = 3+2+7+1+3 = 16 ✓ row11: 2+3+7+1+3 = 16 ✓ row12: 1+4+7+1+3 = 16 ✓ row13: 0+5+7+1+3 = 16 ✓ And the flag pole 'F' at col 12 for rows 4-13. Hmm wait, row13 has 'F' at col 12 but also X's at cols 0-4. ✓ Flag base: at row 13 col 12 the pole stands on ground row 14. Good. Now total: 7 segments × 16 = 112 tiles wide. Also need to handle: the 'F' tile is the flagpole — I'll treat it as a solid? No, it should be non-solid, decorative; touching it triggers level complete. I'll draw the pole and a flag at the top. Now let's also add background decorations: clouds, bushes, hills — draw them as repeating background based on camera with assets. Now the engine. **Physics constants** (px, seconds): - TILE = 32 - gravity = 1800 px/s² - moveSpeed = 160 (walk), 260 (run) - jumpVelocity = -560 (gives height = 560²/(2*1800) = 313600/3600 = 87px ≈ 2.7 tiles). Too low. Need ~128px+. Let's use jumpVelocity = -680 → 680²/3600 = 462400/3600 = 128px = 4 tiles. But with variable jump (holding jump), apply reduced gravity while holding: gravity 900 while ascending and holding. Then height = 680²/(2*900) = 462400/1800 = 256px = 8 tiles. Too much. Let's do: jumpVel = -560, gravity up-hold = 1300, gravity normal = 2200. Height while holding = 560²/(2*1300) = 313600/2600 = 120px. Then with normal gravity 2200 falling. That's good: max jump ≈ 3.75 tiles. Let's bump to jumpVel = -600, gUp = 1300: 360000/2600 = 138px ≈ 4.3 tiles ✓. And if you tap (release early), gravity becomes 2200 → shorter hop. Also add: horizontal speed 170 walk / 280 run. And air control. Jump distance at 280 px/s for ~1.2s airtime (up 0.46s + down 0.5s... total ~0.95s) = 266px = 8 tiles. Plenty for 4-tile pits. **Collision**: AABB vs tile grid, resolve axis-separately. Standard. **Entities**: - Player: x,y,w,h (w=22,h=30 for hitbox inside 32x32 sprite... let's use w=20,h=28). - Goomba: w=26,h=26, walks at 60px/s, turns at walls/edges? Classic goombas walk off edges. Let them walk and turn on wall collision. - Koopa: w=26,h=30, walks at 50px/s, turns at walls. - Coin: 24x24, static, animated spin (rotate/scale). - Mushroom: spawns from '?'... let's implement 'M' block? I'll keep '?' → coin popup; add one '!' block giving a mushroom that makes Mario big. Big Mario = taller sprite (needs another asset). Hmm, extra work but adds a lot. Let's do it: small → big (mushroom), and big → small on damage (invulnerable briefly). I'll create 2 sprite sets: small and big. That doubles SVG work... Let me instead keep it simpler: Mario is always "small" and any hit = death (with lives). Hmm, lives system with 3 lives and respawn. That's simpler and still fun. Actually, let me include the mushroom power-up for the classic feel, and just scale the player sprite when big (scale 1.0 vs 0.75?) Hmm, hitbox change with same sprite... Decision: Keep it simple and polished — no power-ups. Player has 3 lives, dies on enemy contact (or falling), respawns at start or last checkpoint. Coins give score. That's a complete fun game. Hmm, but "platformer de Mario" implies the mushroom. I'll compromise: add mushrooms that give +1 life / extra points (like a 1-UP mushroom). That's easy: an item entity that gives points/life. Good, adds the classic item without hitbox complexity. So '?' blocks give coins, 'M' blocks give a mushroom item. I'll put an 'M' block in the level. **Rendering with assets**: - Load all SVG data URIs into `Image` objects, await all, then start. - Draw tiles via drawImage(tileImg[type], x, y, 32, 32). - Animate coins via rotation. **Camera**: follows player, clamped to level bounds. **HUD**: draw with canvas text (or DOM overlay). Use canvas text with a pixel-ish font (monospace, bold). **Audio**: WebAudio oscillator beeps. jump, coin, stomp, bump, death, level complete. Mario-like approximations. Keep them short. **Game states**: title/ready, playing, dying, gameover, levelcomplete. **Input**: keyboard + touch (on-screen buttons for mobile). Let me now write the code. ```html Super Plataformas Bros

...

``` Since it's rendered in an iframe, I'll make it responsive: scale the canvas with CSS to fit. Let me write the CSS: ```css *{margin:0;padding:0;box-sizing:border-box} html,body{height:100%;background:#0b1020;overflow:hidden;font-family:...} #wrap{position:relative;width:100%;height:100%;display:flex;align-items:center;justify-content:center} canvas{image-rendering:pixelated; background:#6ec0ff; max-width:100%; max-height:100%; width:auto; height:auto; box-shadow:...; border-radius:6px} ``` Hmm, for scaling, use `object-fit`-like: set canvas style width/height via JS on resize to maintain aspect ratio 960:512. Let me do: `canvas{display:block}` and JS resizes: ```js function resize(){ const s = Math.min(window.innerWidth/960, window.innerHeight/512); cv.style.width = (960*s)+'px'; cv.style.height = (512*s)+'px'; } ``` For mobile with touch controls, leave some space at bottom. Fine. Now assets. Let me write the SVG asset definitions. ```js const svgURI = (inner, w=32, h=32) => 'data:image/svg+xml;charset=utf-8,' + encodeURIComponent( `` ); ``` **Mario (small) 32x32** — variants. Let me write the base parts: Cap: `` — hmm let's keep it simpler with rects and rounded corners. I'll define: - capTop: `` - capBrim: `` — brim pointing right. Hmm, brim should be at y 8-11. Face: `` Hair sideburn: `` Eye: `` plus highlight `` Wait, side view facing right: eye near the right/front of the face. Face spans x 9-24. Eye at x=17-20. Let's do eye ``. Nose: `` — hmm nose should protrude past face at x=24. `` plus outline. Mustache: `` — a shape under the nose. Let's simplify: ``. Torso: - Shirt: `` - Overalls: `` - Straps: two rects - Buttons: two circles gold - Arms: right arm forward. Legs/shoes: - `` - `` — hmm shoes should be under the body (x 10-23). Let's do left shoe x=8 w=8, right shoe x=17 w=9. OK, honestly, the exact look will be approximate. Let me write clean, simple, cute characters. I'll aim for a "chibi plumber" that reads well at 32px. Let me define the small Mario asset as a function of pose params? The user said avoid generating everything programmatically, but using a small builder for legs is fine... Actually no — let me just write 4 explicit SVG strings. Duplication of ~10 lines each is acceptable and clearer as "assets". Hmm, that's a lot of text. Alternative: define the SVG with CSS-like parts and just change the leg/arm rects. I'll write them explicitly but compactly. Let me reduce: poses = idle, walk1, walk2, jump, dead. I'll write each fully. To keep the response manageable, I'll write reasonably compact SVGs. Let me draft small Mario: ```js const MARIO_SMALL = { idle: `... ``` I'll write a base string with placeholders for legs and arms: Actually, let me structure it as: `marioSVG({legsL, legsR, armY, ...})`. Hmm. The user's request is about not drawing everything with canvas primitives. Using SVG assets parameterized slightly is still asset-based. But to be safe and clean, I'll write explicit strings. Let me just do it. I'll write each pose as a template with unique arm/leg rects. Pose: idle ```svg ``` Hmm the shadow ellipse at cy=30 might be unnecessary. Skip it. Wait — I should double check the y-extents: shoes at y 27-31.5, within 32. Cap from y=3. Good. Walk1: legs shifted — left shoe forward, right shoe back. Also body slightly lower. ``` (front foot forward) ``` and arms different. Walk2: mirror-ish. Jump: arms up, legs tucked. Dead: rotated/lying down — I'll just draw a different sprite (X eyes, lying). Fine. Let me write them. Now tiles: **Ground** (32x32): grass top + dirt. ```svg hmm maybe not ``` Good. **Dirt** (underground, same as ground without grass) — for rows below the top? I'll use the same tile everywhere for simplicity, but rows 14 and 15 both ground → the grass appears twice. Better: use 'X' for ground-top and 'D' for dirt below? Simpler: draw all ground tiles as dirt, and the top row of ground with grass. Since I know which tiles have empty above, I can render grass only where the tile above is empty. That's a neat trick: one dirt asset + one grass asset overlaid. Let's just have two tile images: `ground` (with grass) used when the tile above is empty, and `dirt` otherwise. **Brick**: ```svg brick lines: horizontal lines at y=10.6, 21.3; vertical offsets ``` Let me do: base fill #c1691f; pattern: rows of bricks 8px tall? Standard Mario brick: 4 rows. ``` ... ``` Simpler: draw mortar lines. ```svg hmm ``` Let me define brick pattern properly: two rows of bricks, each 16 tall, offset by 16. Row1 (y 0-16): vertical mortar at x=16. Row2 (y 16-32): vertical mortar at x=0 and x=32? For a brick of half width, that gives offset. Actually offset bricks: row1 has verticals at 0, 32 (edges) and 16 (middle). Row2 has verticals at 0, 32 only plus 0... no, an offset row would have verticals at 8 and 24. Let me do that: - Row1 (y0-16): vertical at x=16. - Row2 (y16-32): vertical at x=8 and x=24? For 4-brick-wide look. Hmm 32 wide → bricks of 16 wide in row 1 → vertical at 16 and edges. Row 2 offset by 8: bricks of 16 wide starting at -8 → verticals at 8 and 24. Yes! That's the classic look (bricks 16 wide, 8 tall? no 16 tall). Classic Mario bricks are 16x8 px in a 16x16 tile → 2 rows of bricks each 8 tall. Let me do 4 rows of 8-tall bricks with offsets 8. So: - y=8, 16, 24 horizontal lines. - Row1 (0-8): verticals at 16 - Row2 (8-16): verticals at 8, 24 - Row3 (16-24): verticals at 16 - Row4 (24-32): verticals at 8, 24 Good. **Question block**: ```svg rivets: 4 small squares at corners ? -- text rendering in SVG data URI may vary; safer to draw '?' with paths or rects. ``` A '?' glyph: I'll draw with paths: a curve. Use ``. Good enough. **Used block**: brown with border. **Pipe**: I'll make two assets: pipeTop (covering 2 tiles wide) and pipeBody. Since tiles are 32x32 and pipe is 2 tiles wide, I'll draw pipeTop as a 64x32 image placed at the left tile position, and pipeBody as 64x32. Actually for the map I use '[' ']' '{' '}' — I can just render '[' as the left half of the pipe top and ']' as the right half. Two assets: pipeTopLeft, pipeTopRight, pipeBodyLeft, pipeBodyRight. With gradient shading, left half darker on the left, right half darker on the right. That works and is simpler for rendering. Pipe top left (32x32): ```svg ``` Hmm the lip is wider than the body. Let's do: - Lip: rect x=0 y=0 w=32 h=12, fill green, with darker left edge. - Body: rect x=4 y=12 w=28 h=20. Pipe top right: - Lip: rect x=0 y=0 w=32 h=12 - Body: rect x=0 y=12 w=28 h=20. And the lip's right edge highlight. Colors: main #2eb84f, dark #1e7a34, light #6ee07e. Pipe body left: rect x=4 y=0 w=28 h=32 fill #2eb84f with highlight stripe at x=8. Pipe body right: rect x=0 y=0 w=28 h=32. Good. **Coin**: gold ellipse with inner ring and shine. ```svg ``` Plus animation by scaling x. **Goomba**: ```svg head ` — a semicircle dome from y=7 to y=20. - Face lighter: `` - Eyes: two white ovals with black pupils and angry brows. - Feet: two dark ellipses at y=22-28. Let me write: ```svg ``` Wait feet at y=25 with ry 3.5 → extends to 28.5. Good. And the dome bottom at y=21. Hmm the feet should be below the dome. Dome from y=8 to 21. Feet 21.5-28.5, and the whole sprite is 32 tall. Then the hitbox: 26x26 with feet at bottom. Let's just set goomba hitbox w=26,h=24 with y offset. I'll tune: draw the goomba occupying y 4-28 in the 32 sprite. Let me adjust: dome path from y=6 to y=20: `M3 20 a13 14 0 0 1 26 0 z`. Feet ellipses cy=23, ry=3.5 → 19.5-26.5. Hmm overlap. Let's set feet cy=24. Actually it'll look fine. I'll go with: - dome: `M3 21 a13 15 0 0 1 26 0 z` (top at y=6, bottom at 21) - feet: ellipses at cy=24.5, ry=3.5 → 21-28. - eyes: around cy=14. - face patch: ellipse cx=16 cy=16.5 rx=10 ry=7. OK. **Koopa**: - Shell: `` with darker rim and hexagon pattern. - Body/head: yellow head at right: `` with eye. - Feet: two orange ellipses at bottom. - Shell rim: `` Good enough. **Flag**: pole asset (8x TILE?) — I'll draw the pole as a thin rect in code? No, use asset. I'll create a `flag` asset 32x32 that is a pole segment (thin grey rod in the middle) and a `flagTop` asset with the ball. And a `flagBanner` asset for the flag itself. Hmm, simpler: draw the flagpole as one tall image? Variable height... The pole is 10 tiles tall = 320px. I can make a single asset of 32x320 with the pole. But the pole is at a specific column; using a 32x320 asset at that column is fine! Let's do that: `flagpole` asset 32x320 with the banner at the top. Actually, easier: make the flagpole a 32x320 SVG asset that includes the ball, pole, and the flag banner. Nice. But wait: the pole asset needs to align with the tile grid. Rows 4-13 = 10 tiles = 320px. ✓ And a flag base block? Not needed. **Clouds / bushes / hills** for background — nice-to-have. I'll add a cloud asset and a bush asset, drawn at fixed positions at the start of the level (parallax). Keep simple: draw them in world space with 0.5 parallax. OK, let's be careful about the total code size. It'll be long but manageable. Let me reduce decorations slightly. Assets list: 1. mario_idle, mario_walk1, mario_walk2, mario_jump, mario_dead (5) 2. goomba, koopa (2) 3. coin, mushroom (2) 4. ground, dirt, brick, question, used, pipeTL, pipeTR, pipeBL, pipeBR (9) 5. flagpole (1) 6. cloud, bush (2) Total 21 assets. OK. Now the code. ```js const ASSETS = {...}; const IMG = {}; function load(){ const keys = Object.keys(ASSETS); return Promise.all(keys.map(k => new Promise((res, rej)=>{ const im = new Image(); im.onload = ()=>{ IMG[k]=im; res(); }; im.onerror = rej; im.src = 'data:image/svg+xml;charset=utf-8,' + encodeURIComponent(ASSETS[k]); }))); } ``` Wait, I'll store raw SVG strings in ASSETS and convert at load. Better: `const ASSETS = { mario_idle: svg(`...`), ... }` where svg() returns the data URI directly. Then load just sets img.src = ASSETS[k]. OK. Now the level: ```js const LEVEL_SEGMENTS = [ ... ]; ``` Build: ```js const SEGW = 16; function seg(raw){ return raw.split('\n').filter(l=>l.trim().length||l.length).map(l=>l.padEnd(SEGW,' ')); } ``` Hmm, `.filter(l=>l.trim().length||l.length)` — for an all-spaces line, `l.length` is 16 → truthy. Good. But blank lines (from the template's edges) — I'll start the template right after the backtick with a newline; `split('\n')` gives a first empty string. Filter by `l.length > 0` removes it. But all-space lines have length 16 so they're kept. Fine. Careful: a line of exactly 16 spaces ` ` — I need to type exactly 16 spaces. Risky to count by eye. Hmm. To avoid counting spaces, I could use '.' as empty and convert. That's much safer! Use '.' for empty in the level strings and convert to ' ' when building. Then all lines are visible and countable. Yes! Use '.' for empty. But then '.' is visible in the source making it easy to count. Let me redo the segments with '.' as empty (I already did above). So: ```js function seg(raw){ return raw.split('\n').filter(l=>l.trim().length>0).map(l => l.padEnd(SEGW,'.').slice(0,SEGW).replace(/\./g,' ')); } ``` Hmm, but I want to check for errors. Let's not slice; just padEnd. If a line is longer than 16, it breaks alignment — but I'll be careful. Actually, let me add a validation that logs an error if any line length != 16. Good for me but silent for user. Eh, let's keep it simple. Now the level rows: 16 rows. Let me finalize each segment (16 wide): I'll write them now carefully. Each row: exactly 16 chars. **SEG A** ``` ................ (16) ................ ................ ................ ................ ................ ................ ................ ................ ................ .......?........ (7 . + ? + 8 .) ................ ................ ...........G.... (11 . + G + 4 .) XXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXX ``` Count row10: 7 dots: "......." then "?" then "........" (8) = 16 ✓ Row13: 11 dots "..........." then "G" then 4 dots "...." = 16 ✓ **SEG B** ``` ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ .....[]......... .....{}....G.... XXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXX ``` Row12: 5 dots "....." + "[]" + 9 dots "........." = 16 ✓ Row13: 5 + "{}" + 4 dots "...." + "G" + 4 dots "...." = 5+2+4+1+4 = 16 ✓ **SEG C** ``` ................ ................ ................ ................ ................ ................ ................ ................ ................ ...CCC.......... ...B?B.......... ................ ................ ................ XXXXXXXX...XXXXX XXXXXXXX...XXXXX ``` Row9: 3 dots + CCC + 10 dots = 16 ✓ Row10: 3 dots + B?B + 10 dots = 16 ✓ Row14/15: 8 X + 3 dots + 5 X = 16 ✓ **SEG D** ``` ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ........X....... .......XX....... ......XXX....... .....XXXX....... XXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXX ``` Row10: 8 dots + X + 7 dots = 16 ✓ Row11: 7 + XX + 7 = 16 ✓ Row12: 6 + XXX + 7 = 16 ✓ Row13: 5 + XXXX + 7 = 16 ✓ **SEG E** ``` ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ......M......... ................ ..........[].... ..K.......{}.... XXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXX ``` Row10: 6 dots + M + 9 dots = 16 ✓ Row12: 10 dots + [] + 4 dots = 16 ✓ Row13: 2 dots + K + 7 dots + {} + 4 dots = 2+1+7+2+4 = 16 ✓ **SEG F** ``` ................ ................ ................ ................ ................ ................ ................ ................ ................ ................ ....BBBB........ ................ ................ ..........GG.... XXXXXX....XXXXXX XXXXXX....XXXXXX ``` Row10: 4 dots + BBBB + 8 dots = 16 ✓ Row13: 10 dots + GG + 4 dots = 16 ✓ Row14/15: 6 X + 4 dots + 6 X = 16 ✓ **SEG G** ``` ................ ................ ................ ................ ............F... ............F... ............F... ............F... ............F... ............F... ...XX.......F... ..XXX.......F... .XXXX.......F... XXXXX.......F... XXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXX ``` Row4: 12 dots + F + 3 dots = 16 ✓ Row10: 3 dots + XX + 7 dots + F + 3 dots = 3+2+7+1+3 = 16 ✓ Row11: 2+3+7+1+3=16 ✓ Row12: 1+4+7+1+3=16 ✓ Row13: 0+5+7+1+3=16 ✓ Total width = 7*16 = 112 tiles = 3584 px. Hmm, SEG G: the staircase at cols 0-4 rises to row 10, then the flag at col 12. There's a gap between the staircase and the flag where the player must get down. Fine. Wait, in SEG G the staircase column 4 is the top at row 10, and the flag pole at col 12 rows 4-13. But rows 4-13 for the pole: 10 tiles. The pole bottom at row 13 resting on ground row 14 ✓. Also, in SEG G the player could just run into the flag. Good. Now, the "1-1" style: player starts at left. Let's also handle: falling into pits = death. Total level: 112 x 16 tiles. Now the code structure: ```js const TILE=32, VW=960, VH=512; ``` Canvas 960x512. Game loop with fixed timestep or delta-time. I'll use delta-time capped at 1/30. **Player object**: ```js player = { x, y, w:20, h:28, vx:0, vy:0, onGround:false, facing:1, anim:0, dead:false, big:false } ``` Sprite drawn at x + w/2 (centered), y + h - 32 (bottom aligned), size 32x32. Actually the sprite is 32x32 and the hitbox 20x28 → draw at (x - 6, y - 4) so the sprite is centered on the hitbox. Let's compute: hitbox center x = x + w/2 = x+10; sprite center = drawX + 16 → drawX = x + 10 - 16 = x - 6. Vertically: hitbox bottom = y + h = y+28; sprite bottom = drawY+32 → drawY = y + 28 - 32 = y - 4. ✓ **Tile collision**: ```js function tileAt(col,row){ if(row<0||row>=ROWS) return ' '; if(col<0||col>=COLS) return 'X'; return grid[row][col]; } function isSolid(ch){ return 'X B ? U [ ] { }'.includes(ch); } ``` Careful with the string: `'XB?U[]{}'`. Use a Set or indexOf. **Move & collide**: ```js function moveEntity(e, dt){ e.x += e.vx*dt; resolveX(e); e.y += e.vy*dt; resolveY(e); } ``` Standard implementation scanning tiles overlapping the AABB. ```js function solidAt(px,py){ return isSolid(tileAt(Math.floor(px/TILE), Math.floor(py/TILE))); } ``` resolveX: ```js const cols = [Math.floor(e.x/TILE), Math.floor((e.x+e.w-1)/TILE)]; const rows = [Math.floor(e.y/TILE), Math.floor((e.y+e.h-1)/TILE)]; ``` Check based on direction of movement. Let me write a generic: ```js function collideX(e){ const top = Math.floor(e.y/TILE), bot = Math.floor((e.y+e.h-1)/TILE); if(e.vx > 0){ const col = Math.floor((e.x+e.w-1)/TILE); for(let r=top;r<=bot;r++) if(isSolid(tileAt(col,r))){ e.x = col*TILE - e.w; e.vx = 0; e.hitWall = 1; break; } } else if(e.vx < 0){ const col = Math.floor(e.x/TILE); for(let r=top;r<=bot;r++) if(isSolid(tileAt(col,r))){ e.x = (col+1)*TILE; e.vx=0; e.hitWall=-1; break; } } } ``` Note: after setting e.x, the loop continues but that's fine since we break. collideY: ```js function collideY(e){ const left = Math.floor(e.x/TILE), right = Math.floor((e.x+e.w-1)/TILE); if(e.vy > 0){ const row = Math.floor((e.y+e.h-1)/TILE); for(let c=left;c<=right;c++) if(isSolid(tileAt(c,row))){ e.y = row*TILE - e.h; e.vy=0; e.onGround=true; break; } } else if(e.vy < 0){ const row = Math.floor(e.y/TILE); for(let c=left;c<=right;c++) if(isSolid(tileAt(c,row))){ e.y = (row+1)*TILE; e.vy=0; e.headBump={c,row}; break; } } } ``` For head bumps, I need to detect which block was hit to trigger the '?' pop. I'll use the first solid column hit. **Block bump handling**: when the player head-bumps a '?' or 'M' block, turn it into 'U' and spawn a coin/mushroom. **Coins**: entity list with type 'coin'; collect on overlap, remove, +score, +coins, sound. **Mushroom item**: spawns from block, moves right at 60px/s, falls, gives +1 life... Actually let's make it give 1000 points and extra life. Fine — call it "vida extra" (champiñón 1-UP). **Enemies**: goomba/koopa. Update: move, gravity, collide; if hitWall → flip direction. Also flip at pit edges? Classic goombas don't. Let them fall into pits — but if they fall off the world, remove them. **Stomp detection**: if player.vy > 0 and player bottom is above enemy center → stomp: enemy dies (squashed for 0.4s then removed), player vy = -420 bounce. Else → player takes damage (lose a life, respawn). **Death**: player.dead = true, vy = -600, no collision, fall off screen, then after ~2s: lives--, if lives>0 restart level (keeping score), else game over. **Level complete**: touching the flag (x within pole column range) → play music, player slides down, then flag banner lowers, then a "¡NIVEL COMPLETADO!" overlay and option to restart. Simplify: on touching the flag, set state 'win', player walks right automatically, show overlay with score and "Pulsa R para reiniciar". **Camera**: ```js cam.x = clamp(player.x + player.w/2 - VW/2, 0, COLS*TILE - VW); ``` Smooth it with lerp. **HUD**: draw text over the canvas: PUNTOS, MONEDAS, MUNDO 1-1, TIEMPO, VIDAS. **Timer**: 300 units, decrement ~1 per 0.4s. If 0 → death. Let me write the drawing code. **Background**: sky gradient, parallax clouds and hills. I'll draw hills as simple arcs? That's programmatic. Use a "hill" asset instead? I have cloud and bush. Let me create a "hill" asset too (32x32 tileable?) — actually a hill is bigger. Let me create a 128x64 hill asset. That's fine. Let me include: cloud (64x32), bush (64x32), hill (128x64). Drawn at a parallax factor of 0.6 for hills, 0.4 for clouds. Positions determined from index: e.g., hills every 480px, clouds every 320px, bushes every 400px in world space. That's procedural placement but with assets — fine. Hmm, "en vez de generando todo programáticamente" — I interpret as: use image assets instead of drawing graphics with code. Placement is fine. OK. Let me write the final code. One more thing: audio. WebAudio with oscillators: ```js let AC = null; function actx(){ if(!AC) AC = new (window.AudioContext||window.webkitAudioContext)(); return AC; } function beep(freq, dur, type='square', vol=0.08, slideTo=null){ const c = actx(); const o = c.createOscillator(); const g = c.createGain(); o.type=type; o.frequency.setValueAtTime(freq, c.currentTime); if(slideTo) o.frequency.exponentialRampToValueAtTime(slideTo, c.currentTime+dur); g.gain.setValueAtTime(vol, c.currentTime); g.gain.exponentialRampToValueAtTime(0.0001, c.currentTime+dur); o.connect(g); g.connect(c.destination); o.start(); o.stop(c.currentTime+dur); } ``` Sounds: - jump: beep(420, 0.18, 'square', 0.07, 700) - coin: two quick beeps: beep(988,0.07); setTimeout(()=>beep(1319,0.15),70) - stomp: beep(200,0.12,'square',0.09,80) - bump: beep(120,0.08,'square',0.08) - death: descending - powerup: ascending arpeggio Good. Also a simple background music? Could be annoying. Skip, or add a mute toggle. I'll add a small "♪" toggle. Actually keep it simple — no music, just SFX, and a mute button maybe. Let's skip the mute button. Now let's write everything out. Touch controls: I'll add on-screen buttons for left/right/jump/run shown only on touch devices. Use `ontouchstart` detection. Keep it simple with pointer events on divs. Let me write the HTML. ```html

``` Hmm, positioning the pad over the canvas requires the stage to be sized to the canvas. Let me size #stage to the canvas display size and position the pad absolutely inside. Let me do: ```css #stage{position:relative;line-height:0} canvas{display:block;background:#7ec8ff;border-radius:8px;box-shadow:0 20px 60px rgba(0,0,0,.6);image-rendering:pixelated} #pad{position:absolute;inset:0;pointer-events:none;display:none} #pad.on{display:block} #pad .pbtn{position:absolute;pointer-events:auto;width:64px;height:64px;border-radius:50%;background:rgba(255,255,255,.25);border:2px solid rgba(255,255,255,.5);color:#fff;font:700 22px/64px system-ui;text-align:center;user-select:none;touch-action:none} #pad .pbtn:active{background:rgba(255,255,255,.5)} .pbtn[data-k=left]{left:16px;bottom:16px} .pbtn[data-k=right]{left:96px;bottom:16px} .pbtn[data-k=run]{right:104px;bottom:24px} .pbtn[data-k=jump]{right:20px;bottom:16px} ``` OK. Now, main game code. Let me write it carefully. ```js (() => { 'use strict'; /* ---------- ASSETS (SVG) ---------- */ const svg = (inner, w=32, h=32) => 'data:image/svg+xml;charset=utf-8,' + encodeURIComponent( ``); ``` Hmm — using `width`/`height` on the SVG root ensures the Image loads at that intrinsic size; we draw with drawImage(img, x,y,w,h) anyway. Let me write the assets. ```js const A = {}; /* --- Mario: cuerpo base reutilizado --- */ const marioBody = (extra) => `...`; ``` OK I decided to write them explicitly. Let me write each. Mario idle: ```js A.mario_idle = svg(` `); ``` Hmm, arms as circles at x=6.6 and 25.4 — those are outside the body (body spans 9-24). Arms sticking out at the sides. OK, plausible. For walk1/walk2, I'll change the leg rects and shift the arms: walk1: front leg forward (shoe at x=19 w=10), back leg back (shoe at x=4 w=9), arms swinging. walk2: shoes closer together. jump: arms up: circles at (6,17) and (26,17); legs bent: shoes at y=26 x=6 and x=17 with rotation... can't rotate easily with rects. Use two shoes at slightly different y. dead: mario lying with X eyes. I'll make a sprite: rotate everything? Use a `` around the body and put X eyes. That's a nice trick. Let me do: `A.mario_dead = svg('' + BODY_IDLE_INNER + '')` — but then the eyes are normal. Fine, or I'll just use the rotated idle body. Actually simpler: reuse the idle body with a rotation. But I said no reuse... reuse of the SVG asset source is fine (it's still an asset). Hmm, but the user said "usando assets en vez de generando todo programáticamente". Reusing an SVG string for a rotation is fine. Let me define: ```js const MARIO_BASE = `...`; // string A.mario_idle = svg(MARIO_BASE); A.mario_dead = svg(`${MARIO_BASE}`); ``` Good, saves space. Similarly, walk poses: I'll define the base without legs and arms, then compose: ```js const M_HEAD = `...`; // cap, face, mustache const M_TORSO = `...`; // shirt+overalls+buttons const M_ARM = (x,y) => ``; const M_LEG = (x,y,w) => ``; ``` Hmm, that IS building programmatically. But it's about composing assets, which I think is acceptable. Still, to honor the request most directly, let me write the full sprite strings for each pose. It's just 4 poses × ~18 lines. It's verbose but clearest. Let me do it. Hmm, response length. Each Mario sprite ~18 lines × 5 = 90 lines. Plus other assets ~150 lines. Plus game logic ~400 lines. Total ~650 lines. That's a big response but acceptable. Let me trim by making sprites more compact (fewer shapes). Actually, let me use a middle ground: write the four Mario poses explicitly but compactly (6-8 lines each using grouped paths). Hmm. Let me just be pragmatic: I'll write explicit full strings for each pose. Compact-ish formatting (a few shapes per line). Let me now write the whole thing. Also note: `shape-rendering` — since we scale, and these are vector shapes, it'll look smooth. Good. Let me write out the final code now. ```js /* ============ ASSETS ============ */ const svg = (inner, w = 32, h = 32) => 'data:image/svg+xml;charset=utf-8,' + encodeURIComponent( ``); const A = {}; /* ---- Mario ---- */ const MARIO_BASE = ` `; const legs = (a, b) => ``; ``` Hmm, I'm using a helper again. Let me just inline the two rects in each pose string. Fine. A.mario_idle: ```js A.mario_idle = svg(MARIO_BASE + ` `); ``` A.mario_walk1 (front foot forward, back foot back): ```js A.mario_walk1 = svg(MARIO_BASE + ` `); ``` Hmm both shoes should be near the bottom. Actually for a walking pose, one foot forward at ground level and one back slightly raised. Let's do: ```js ``` Walk2 (legs together, slight bounce): ```js ``` Jump (arms up, legs apart): ```js A.mario_jump = svg(` ... cap ... face ``` OK. I'll write MARIO_BASE with arms included and just override the arms in jump... conflicting. Let me define MARIO_BASE without arms and legs, and add arms/legs per pose. Arms for idle = circles at (6.6,22) and (25.4,22). Let me restructure: - MARIO_HEAD_TORSO: cap, brim, face, hair, eye, nose, mustache, shirt, straps, overalls, buttons. (no arms, no legs) - per-pose: arms + legs. That's clean and still "asset" composition. Now let me write the final code. I'll be careful. Also for the dead pose: rotate the whole idle. Let me write out all assets now, final. ```js const A = {}; /* ---------- MARIO ---------- */ const TORSO = ` `; const HANDS = (ly, ry) => ``; const FEET = (a,b) => ``; A.mario_idle = svg(TORSO + HANDS(22,22) + FEET([7,28,9],[16,28,9])); A.mario_walk1 = svg(TORSO + HANDS(20,24) + FEET([3,28,10],[18,26.5,9])); A.mario_walk2 = svg(TORSO + HANDS(24,20) + FEET([8,28,9],[17,28,9])); A.mario_jump = svg(TORSO + HANDS(15,15) + FEET([4,27,10,4.5],[18,27,10,4.5])); A.mario_dead = svg(`${TORSO + HANDS(22,22) + FEET([7,28,9],[16,28,9])}`); ``` Hmm, using template functions means generating... it's fine, the sprites are still fixed assets. Hmm, honestly for the jump pose the feet should be rotated. I'll add transforms: `` — I'll handle it by wrapping FEET in groups. Let me not over-engineer. OK now enemies. ```js A.goomba = svg(` `); ``` Hmm wait, the feet are dark brown and the body is brown — might not read. Let me make the feet #4a2c12 and outline. OK. Actually, the dome `M3 21 a13 15 0 0 1 26 0 z` — the arc from (3,21) to (29,21) with radius 13,15, sweep-flag 1 means it goes... For an arc with rx=13, ry=15 between points 26 apart horizontally (which equals 2*rx), the arc is a half-ellipse. sweep-flag=1 means clockwise from (3,21) to (29,21), which in SVG (y down) goes upward. Yes, forms a dome above. ✓ A.goomba_squashed: a flat version. ```js A.goomba_flat = svg(` `); ``` Eh, simpler: draw the goomba scaled vertically in code when squashed (`ctx.scale`). Actually simplest: in code, draw the goomba with a reduced height when squashed. Yes! `drawImage(img, x, y+h*0.4, w, h*0.6)`. No extra asset needed. Koopa: ```js A.koopa = svg(` `); ``` Hmm, the head should be attached to the body. Body ellipse cx=14, cy=21, rx=11 → spans x 3..25, y 12..30. Head at cx=24, cy=11, r 6.4 → x 17.6..30.4, y 5..17. Overlaps the shell top-right. OK, decent. Feet at cy=27 under the shell. OK. Coin: ```js A.coin = svg(` `); ``` Mushroom: ```js A.mushroom = svg(` -- hmm this would be on the stem ... ``` Simplify: ```js A.mushroom = svg(` -- optional `); ``` Tiles: ground: ```js A.ground = svg(` `); ``` dirt: ```js A.dirt = svg(` `); ``` brick: ```js A.brick = svg(` `); ``` Wait, the verticals should be within each 8px band: band1 y0-8: vertical at x=16 → `M16 0v8`. band2 y8-16: verticals at 8 and 24 → `M8 8v8M24 8v8`. band3 y16-24: vertical at 16 → `M16 16v8`. band4 y24-32: verticals at 8, 24 → `M8 24v8M24 24v8`. ✓ And the left/right edges: I'll add `M1 0v32M31 0v32` for borders. Let's include the outer border with a separate rect stroke. question block: ```js A.question = svg(` `); ``` used: ```js A.used = svg(` `); ``` Pipes: 4 pieces. ```js A.pipe_tl = svg(` `); ``` Hmm, this is getting fiddly. Let me simplify: left half of the pipe: - lip: rect x=0 y=2 w=32 h=12, fill green - body: rect x=4 y=14 w=28 h=18 - shading: dark strip at left x=0..7 for the lip and x=4..11 for the body. - highlight: light strip. Right half: - lip: rect 0,2,32,12 - body: rect 0,14,28,18 - dark strip on the right edge. OK. Also I should add a black outline for definition. Let's add stroke. Flagpole (32 x 320): ```js A.flagpole = svg(` -- hmm the banner points left from the pole ``` Actually the flag banner: a triangle from the pole pointing left. `` — but negative x is out of the viewBox. Let me make the viewBox wider: `0 -? ...`. Alternatively, start the pole in the middle and put the banner to the left within bounds. With only 32px width, the banner would be small. Alternative: draw the flag banner separately in code (a triangle) — no, that's programmatic drawing. Better: make the flagpole asset wider, e.g., 64x320, with the pole at x=40 and the banner extending left from x=40 to x=4. Then place it so that the pole aligns with the tile column. But then the asset overlaps neighboring tiles — that's fine, it's just a drawing. Let me do: flagpole asset 64x320, pole center at x=42 (so the pole column tile: place at col*32 - 26). And place the flag banner at the top. Actually, simpler: I'll place the banner separately as a second asset drawn at the top of the pole. Hmm. Let's just do the 64-wide asset: ```js A.flagpole = svg(` `, 64, 320); ``` And in the render, for the tile 'F' at (col,row), the pole tile column is `col`, and the pole should be at the bottom of the pole. Rows 4..13 → top of the pole = row4*32, bottom = row13*32+32 = row14*32. So the asset (320 tall) is drawn at (col*32 - 26, row4*32). 320 = 10 rows * 32 ✓. The asset x offset: pole center at x=42 in a 64-wide asset. We want the pole center at col*32+16. So drawX = col*32 + 16 - 42 = col*32 - 26. ✓ I'll store the flag position when parsing the level (find the 'F' tile with the minimum row). Now, the decorations: cloud, bush, hill. ```js A.cloud = svg(` `, 80, 32); ``` Hmm the viewBox is 0 0 80 32, and the shapes go from x=4 to x=78, y=1 to 28. Good. ```js A.bush = svg(` `, 80, 32); ``` Hmm the path: starts at (4,30), arc to (14,20), arc to (36,16)... the coordinates need care. Let me just use overlapping circles: ```js A.bush = svg(` `, 72, 32); ``` That works: circles + a base rect. Bottom at y=32. ✓ Hill: ```js A.hill = svg(` `, 120, 64); ``` Hmm, the path: M0 64, then C ... to (60,4), then s ... to (120,64), then z closes back to (0,64). Let me write: `M0 64 C 6 26 30 4 60 4 S 114 26 120 64 Z`. Good. OK. Now the game code. Let me write it out. ```js /* ---------- NIVEL ---------- */ const SEG = 16; const seg = raw => raw.split('\n').map(l => l.padEnd(SEG, '.')).filter(l => l.trim().length).map(l => l.replace(/\./g, ' ')); ``` Hmm, order: filter first then pad. Careful: lines that are all dots have length 16 → `l.trim().length` is 0 → filtered out! Bad. So filter before replacing dots. Let me filter by `l.length > 0`: ```js const seg = raw => raw.split('\n').filter(l => l.length > 0).map(l => l.padEnd(SEG, '.').slice(0, SEG).replace(/\./g, ' ')); ``` But lines with only dots have length 16 > 0 ✓. And I must ensure I don't have an empty line. Since every line has 16 chars (all dots at minimum), fine. But the template literal starts with `\n` right after the backtick, giving an empty first element. If I write: ```js const A1 = seg(` ................ ...`); ``` The split gives ['', '................', ...]. The empty string is filtered ✓. But careful: if a line has trailing whitespace in my source... no. Also, if a line is longer than 16 (my mistake), slice would silently truncate. I'll accept it. Now build the grid: ```js const LEVEL = [A1,A2,A3,A4,A5,A6,A7]; const ROWS = 16, COLS = SEG * LEVEL.length; const grid = []; for(let r=0;r flagCol*TILE + 12 → win. On win: set state 'win', P.vx = 0, slide down the pole... Let's simplify: the player touches the flag → the flag banner animates down the pole, the player walks right off-screen, then show "¡NIVEL COMPLETADO!". Simplify further: on touch, state='win', the player stops and does a little victory animation (jump up and down), and the overlay appears after 1s with the final score. And "Pulsa ESPACIO para volver a jugar". OK. Let me now handle the win: I'll make the player continue walking right automatically at 100px/s, and after 2s show the overlay. Simple. Now let me write the render of the HUD. ```js ctx.font = 'bold 20px "Courier New", monospace'; ctx.fillStyle = '#fff'; ctx.fillText('PUNTOS ' + String(G.score).padStart(6,'0'), 24, 34); ``` With a text shadow. Also lives: draw small mario heads? Use `IMG.mario_idle` scaled to 20x20. Nice touch. OK. Let me now write the full code, carefully. One concern: `ctx.drawImage` with SVG images — after loading a data URI SVG into an Image, drawImage works but the image has intrinsic dimensions from the SVG width/height attributes. Since I always pass explicit w/h, fine. CORS: data URIs don't taint the canvas... actually, data: URIs for SVG loaded into an Image — drawing them doesn't taint the canvas in modern browsers? SVG images always taint the canvas in some browsers if they contain external references; ours don't. We don't use getImageData anyway. Fine. Let me write it. Also for the title screen: show "SUPER PLATAFORMAS" with a start prompt. Let me write it all out now. ```js /* ====== CARGA DE ASSETS ====== */ const IMG = {}; function loadAssets(){ const keys = Object.keys(A); return Promise.all(keys.map(k => new Promise(res => { const im = new Image(); im.onload = () => { IMG[k] = im; res(); }; im.onerror = () => { console.warn('asset', k); res(); }; im.src = A[k]; }))); } ``` Main: ```js loadAssets().then(() => { requestAnimationFrame(frame); }); ``` Now let me carefully write updateEnemies. ```js const enemies = []; function spawnEnemies(){ enemies.length = 0; for(const s of spawns){ if(s.type==='goomba') enemies.push({type:'goomba', x:s.x, y:s.y, w:26, h:26, vx:-55, vy:0, dead:0, onGround:false, anim:0}); if(s.type==='koopa') enemies.push({type:'koopa', x:s.x, y:s.y, w:26, h:30, vx:-45, vy:0, dead:0, onGround:false, anim:0}); } } ``` Koopa h=30, w=26 → x = c*32+3, y = (r+1)*32 - 30. For enemies, I'll also implement gravity and collisions. Koopa's walk speed 45. Goomba 55. Enemy anim: waddle (mirror the sprite / bob). Stomp detection: ```js if(overlap(P, e) && !e.dead && !P.dead){ const stomping = P.vy > 0 && (P.y + P.h) - e.y < 18; if(stomping){ e.dead = 0.5; P.vy = -420; score += 100; sfx('stomp'); } else { killPlayer(); } } ``` Actually better: check the previous bottom position. `P.prevBottom <= e.y + 8`. Let's use: `P.vy > 0 && P.y + P.h - P.vy*dt <= e.y + 6`. Simpler: `P.vy > 0 && (P.y + P.h) < e.y + 20`. Good enough. Dead enemies: after 0.5s remove. Also, dead enemies shouldn't collide. Now, the coin pop particle: ```js particles.push({type:'coinpop', x, y, vy:-380, t:0, life:0.55}); ``` and score popups: `{type:'text', text:'+200', x, y, t, life:0.9}`. Let's implement particles as a generic list. OK, writing the final code now. I'll be thorough but concise. For the mushroom item: ```js items.push({type:'mushroom', x, y, w:26,h:26, vx:60, vy:-120, emerge:0.6}); ``` Emerging: rise out of the block over 0.6s while non-collidable, then start moving. Simplify: mushroom spawns at the block, rises 32px over 0.5s, then becomes active and walks right. Item collection: overlap → +1 life, +1000 score, sfx('power'). Let me write the code. Also, handling the level complete: I need `flagCol` and `flagTopRow`. Let me now write everything. Final check on the drawing of the player sprite: ```js function marioSprite(){ if(P.dead) return IMG.mario_dead; if(!P.onGround) return IMG.mario_jump; if(Math.abs(P.vx) > 12) return (Math.floor(P.anim*10)%2===0) ? IMG.mario_walk1 : IMG.mario_walk2; return IMG.mario_idle; } ``` And flip with ctx.scale when facing left. Draw: ```js ctx.save(); ctx.translate(Math.round(P.x + P.w/2 - cam), Math.round(P.y + P.h)); // bottom center if(P.facing<0) ctx.scale(-1,1); ctx.drawImage(spr, -16, -32, 32, 32); ctx.restore(); ``` Good. For enemies: ```js ctx.save(); ctx.translate(x + w/2 - cam, y + h); if(e.vx>0) ctx.scale(-1,1); // sprites face left by default? ``` My goomba is symmetric. The koopa's head faces right. If it moves left, flip it. So `if(e.vx < 0) ctx.scale(-1,1)`. Then draw at (-16,-32,32,32). Wait for koopa the sprite's feet are around y=30 in a 32 sprite, so drawing at (-16,-32,32,32) puts the bottom at y+h. Slight mismatch but fine. Actually let me pass the enemy's h and draw with the sprite bottom aligned: `ctx.drawImage(img, -16, -32, 32, 32)` where the translate origin is (x + w/2, y + h). The sprite's bottom = origin. Since the sprite content ends around y=30/32, there'd be a 2px gap. Acceptable. Alright. Also the squashed goomba: `ctx.drawImage(img, -16, -14, 32, 14)` when squashed. Let me finalize and write. One more: the level's `F` tile should not be solid. isSolid excludes 'F'. ✓ And 'C' entities are removed from the grid (set to ' ') so they're not solid. ✓ Let me write the code for parsing: ```js const spawns = []; const grid = []; for(let r=0;r -200 && sx < VW+200) ctx.drawImage(IMG.hill, sx, VH-64-32, 120, 64); } ``` Hmm, VH-64 means the hill bottom sits at the bottom of the screen. And the ground occupies the bottom 2 tiles (rows 14,15 = y 448..512). So the hill should sit at y = 448-64 = 384. Yes: `VH - 128`. Since the ground top is at 448 and VH=512, VH-128 = 384. ✓ Clouds at y 40..140, parallax 0.3. Bushes: place in world at ground level (y = 448-32 = 416), parallax 1 (world locked). But bushes should only appear where there's ground. It's decorative, so overlap with pits would look odd. I'll place bushes only at segment boundaries where I know there's ground... simpler: place them at fixed positions and accept minor overlap. Or place them at ground-level y but choose x positions away from pits. Pits: SEG C cols 8-10 → world cols 32+8=40 to 42 → x 1280..1376. SEG F cols 6-9 → global cols 80+6=86 to 89 → x 2752..2880. I'll place bushes at x = 200, 700, 1100, 1700, 2300, 3100. None in the pit ranges... 1280-1376 has none of these ✓; 2752-2880 has none ✓. Let me write the final code now. Time to produce. Also the `sfx` function and mute. Let me write everything. One more consideration for performance: drawing per tile is fine (30x16 = 480 drawImage calls max). Writing now. For the HUD I'll use a shadow for readability. Final code: I'll write it as one script. Let me be careful with escaping backticks inside template literals — I use template literals for SVG. Inside them, I use `${}` for interpolation in some places (HANDS, FEET). Careful not to accidentally use `${` elsewhere. Let me write. Also: `String.padStart` is fine. Let me write the final answer now. I'll include a brief intro in Spanish and then the code block. Actually wait — the user said "Do not mention the iframe in your response." So I just describe the game normally. Let me write the code. ```js /* ===== sonidos ===== */ let AC = null; function sfx(kind){ try{ if(!AC) AC = new (window.AudioContext||window.webkitAudioContext)(); if(AC.state === 'suspended') AC.resume(); }catch(e){ return; } const t = AC.currentTime; const tone = (f1, f2, dur, type, vol, delay=0) => { const o = AC.createOscillator(), g = AC.createGain(); o.type = type; o.frequency.setValueAtTime(f1, t+delay); if(f2) o.frequency.exponentialRampToValueAtTime(Math.max(1,f2), t+delay+dur); g.gain.setValueAtTime(0.0001, t+delay); g.gain.exponentialRampToValueAtTime(vol, t+delay+0.01); g.gain.exponentialRampToValueAtTime(0.0001, t+delay+dur); o.connect(g); g.connect(AC.destination); o.start(t+delay); o.stop(t+delay+dur+0.02); }; switch(kind){ case 'jump': tone(380, 760, 0.16, 'square', .07); break; case 'coin': tone(988, 988, 0.06, 'square', .07); tone(1319,1319,0.16,'square',.07,0.06); break; case 'stomp': tone(300, 90, 0.14, 'square', .09); break; case 'bump': tone(160, 100, 0.09, 'square', .08); break; case 'power': [523,659,784,1047].forEach((f,i)=>tone(f,f,0.12,'square',.07,i*0.09)); break; case 'die': tone(500,120,0.5,'square',.09); tone(300,80,0.7,'triangle',.08,0.15); break; case 'win': [523,659,784,1047,1319].forEach((f,i)=>tone(f,f,0.18,'square',.08,i*0.13)); break; } } ``` Careful: `g.gain.exponentialRampToValueAtTime` requires > 0. Using 0.0001 is fine. OK, final write-up. Let me now produce the complete file. I also need `clamp`. Writing the final response. Aquí tienes un plataformero estilo Mario completo en un solo archivo HTML, usando sprites SVG embebidos como assets reales (nada de dibujar personajes con rectángulos en el canvas). ```html Super Plataformas Bros

◀

▶

``` ### Jugabilidad, controles y diseño visual El juego combina una estética de plataformas clásica con una implementación moderna basada en sprites SVG. - **Controles:** usa las flechas o A/D para moverte, Espacio/↑/W para saltar (con salto variable según cuánto mantengas) y Shift para correr. En dispositivos táctiles aparecen botones en pantalla. - **Assets:** todos los gráficos —Mario, Goombas, Koopas, monedas, bloques, tuberías, nubes y colinas— son imágenes SVG embebidas como data-URI, lo que evita dibujar formas a mano y permite animaciones suaves. - **Mecánicas:** el nivel está formado por 7 segmentos de 16 columnas; puedes romper bloques `?`, recoger monedas, obtener un champiñón 1-UP, pisar enemigos y llegar a la bandera para completar el nivel. - **Progresión:** tienes 3 vidas, temporizador, puntuación y un sistema de muerte que reinicia el nivel conservando la puntuación. --- **Optimización:** Los sprites SVG están escritos directamente en el código; si quieres cambiar la apariencia de Mario o de los enemigos, edita las constantes `TORSO`, `HANDS`, `FEET` o los assets `A.goomba`, `A.koopa`, etc. Para modificar el nivel, ajusta las cadenas de `S1` a `S7`.