The user wants an HTML with Super Mario World (SNES) embedded game, as faithful as possible, with at least the first 10 levels + boss, fully functional and faithful to the real game. Obviously, I cannot embed the actual ROM (copyright), and emulating requires an emulator + ROM. But I can build a faithful HTML5/JS recreation — a Mario platformer engine with SMW-style mechanics: run, jump, spin jump, power-ups (mushroom, flower, star, cape), coins, blocks, pipes, enemies (goomba, koopa, piranha plant, chargin' chuck, bowser), world map progression, 10+ levels, boss battle with Bowser (fireballs, ball throwing, bridge crumbling). Let me write a substantial, self-contained HTML game. I'll use canvas 2D, tile-based level design, SMW-style physics, and procedurally generated-but-designed levels. I'll make it reasonably complete but manageable in code size — I should write a solid, working game. Key features to implement: - Canvas rendering, tile-based levels (2D array) - Player: small/big/fire/cape states, running, jumping, spin jump, ground pound? (SMW has spin jump), crouch, climb? maybe skip climbing - Physics: SMW-style variable jump height, running speed, skidding - Blocks: question blocks, bricks, breakable bricks, coin blocks, used blocks - Power-ups: Super Mushroom, Fire Flower, Cape Feather, 1-Up, Starman (temporary invincibility) - Enemies: Goomba (Spiny?), Koopa Troopa (green/red), Piranha Plant, Chargin' Chuck, Bullet Bill, Bob-omb, Monty Mole?, Boo?, Fish (Cheep Cheep), Bowser (boss) - Fireballs from fire Mario- Cape: spin attack (kills enemies), cape spin, super cape flight- P-Switch, key blocks? maybe skip - Pipes, coin blocks - HUD: score, coins, lives, time, world display - Level selection / world map: SMW world map with nodes- Goal: flagpole (SMW uses a goal gate with a switch), then a "castle" for boss levels - Bowser fight: throwing fireballs, stomping bowser to make him fall? In SMW you defeat Bowser by dropping him off the platform (he falls on lava) — you hit the switch under him. I'll implement: Bowser throws balls/fireballs, you need to make him fall (stomp head) — actually in SMW you hit the button/switch on the floor to drop the bridge... Actually in SMW final boss you must hit Bowser (stomp him) to make him fall off, and there's a switch at the end that ends the level if you touch it... Hmm, in the final Bowser battle, Bowser jumps on you and throws fireballs; you can stomp him and he will fall to the lava and be defeated; there's also a switch at the end that ends the level if you touch it. I'll implement: Bowser spawns, throws fireballs and spawns Bowser bombs; you must stomp his head 5 times to drop him into the lava, then touch the switch/goal to end. That's faithful enough. Given the complexity, I'll write a well-structured engine. Let me plan the code. Structure: - HTML: canvas, overlay screens (title, world map, game over, level clear, ending), controls help- CSS: pixelated rendering, retro font (Press Start 2P via Google Fonts — external link ok, but "if you use external libraries include full HTML" — fine, but maybe safer to use system monospace font to avoid network dependency). I'll use a Google font link for retro feel but fallback monospace. Let me design the engine: ```js const TILE = 16; ``` Levels: I'll create a level builder using string maps or a procedural generator with hand-designed sections. Writing 10+ full hand-crafted levels as ASCII maps is a lot of text but doable — each level maybe 150-200 tiles wide. That's a lot of typing but it's fine... Actually 12 levels × 180 columns × 14 rows = huge. Better: procedural generation with hand-tuned parameters per level, plus hand-placed features (pipes, stairs, platforms, enemies). That gives variety and faithfulness without absurd text length. I'll do a hybrid: a level generator with seeded RNG, deterministic per level, with themes (overworld, underground, athletic/athletic, castle, bonus, ghost house) and hand-designed "set pieces" generated algorithmically (staircases, pipes, gaps, enemy formations, coin arcs). Let me define tile types: - 0 empty - 1 ground (solid) - 2 brick (breakable when big) - 3 question block (coin or mushroom) - 4 used block - 5 solid block / stone - 6 pipe parts (top-left, top-right, body-left, body-right) — treat solid- 7 coin (collectible, non-solid) - 8 lava / water (hazard) - 9 spike - 10 flagpole- 11 goal switch / gate - 12 bridge (collapsing) - 13 spike / saw- 14 semi-solid platform (SMW-style — only solid from above) - 15 message block - 16 coin block / brick with coin Tile rendering: procedural vector art (rects) drawn to offscreen canvas for tiles — pixel-art style via drawing simple shapes with colors. To keep it manageable, I'll draw tiles with simple colored rects/pixel patterns. Character sprites: draw with rects (pixel art drawn via small pixel arrays). That's a nice touch: define sprites as arrays of strings with color palette keys, then draw at 16x16 or 16x24 (big Mario 16x32). That's authentic-ish and not too long. Let me do pixel-art sprite arrays for: small mario (idle, walk frames, jump, skid), big mario (same), fire mario, cape mario — that's a lot of arrays. I can define a base shape and recolor with palette mapping: define "small" sprite templates in grayscale-ish and map colors by state (red overalls/yellow shirt vs blue overalls/red shirt for fire... In SMW: small = red cap/shirt... Actually SMW small Mario: red cap, red shirt... no: small Mario has red hat and red shirt? In SMW small Mario: red cap, red shirt, blue overalls... hmm, actually SMW small Mario: red cap, red shirt... Let me recall: In Super Mario World, small Mario wears a red cap and red shirt with blue overalls? Actually small Mario sprite: red cap, red shirt, blue... I believe small Mario has a red cap and red shirt and blue... no wait, in SMW small Mario's shirt is red? The sprite shows red cap and red... I'll go: small: red cap, red shirt... Hmm. Let me settle: classic small Mario (SMW): red cap, red shirt, blue overalls, brown shoes. Fire Mario: white cap, white shirt, red overalls. Cape: yellow cape, red... Cape Mario wears red overalls + yellow cape, green? In SMW cape Mario has red cap/shirt... Cape Mario: red cap, red shirt... hmm, cape Mario sprite: red cap, yellow cape, red overalls? I'll go with red cap + yellow cape + red overalls + white gloves. For big Mario in SMW: green cap? No — Super Mario: red cap, red shirt... Actually in SMW big Mario: red cap, red shirt... hmm, SMW Super Mario has a green cap? No! That's Super Mario Bros. where Super Mario has red cap and red shirt with blue overalls (actually SMB1 Super Mario: red cap, red shirt... no, SMB1 Super Mario: red cap, red... The "super" sprite in SMB1 is red shirt/overalls... ugh. I'll just go with: small/big/fire all use palette variants: - normal: cap #e52521, shirt #e52521, overalls #2038ec, shoes #6b3e1f, skin #ffb28a - fire: cap #ffffff, shirt #ffffff, overalls #e52521 - cape: cap #e52521, shirt #e52521... cape is #fbd000 - star: cycling rainbow That's fine and recognizable. Enemy sprites: goomba (brown), koopa (green shell), red koopa, piranha plant, bullet bill, chargin' chuck, bowser (bigger pixel art — I'll draw with shapes), boo, cheep cheep, spinies? I'll draw these procedurally with rects/circles for simplicity but with SMW colors. Given size limits, procedural drawing for enemies is more compact than pixel arrays. I'll do pixel arrays only for Mario (small 16x16 and big 16x32 approximations), and shape-drawing for enemies. Hmm, actually maybe shape-drawing for Mario too, but pixel arrays look much better. Let me write compact pixel arrays. Small Mario sprite (16 wide, 16 tall) — I'll write approximate pixel art: Let me use characters: `.` transparent, `R` red, `S` skin, `B` blue, `Y` yellow(brown shoes), `W` white(eye), `K` black(outline/dark), `C` brown/hair. I'll write a 16x16 small mario idle: Row layout (approximate SMB3/SMW small Mario): ``` ................ .....RRRRR...... ....RRRRRRRR.... ....CCCSCSS..... ...CCCSSSCS..... ...CCSCSSSSS.... ....SSSSSSSS.... ...RRBRRRB...... ..RRRRBRRRRB.... .RRRRRBBBBRR.... .SSRBYBBYBRSS... .SSSBBYBBBSSS... ..SSBBBBBBBSS... ...BBB...BBB.... ..BBB.....BBB... ................ ``` Hmm this is fiddly but fine — it will look like Mario at16px scaled. Let me instead do a cleaner, more carefully designed 16x16. Honestly, given the effort, I'll write a decent approximation and rely on the engine. Let me craft it. Actually, I'll design sprites at 16x16 for small and 16x24 for big (SMW big Mario is 16x24-ish, hitbox smaller). Let me write them thoughtfully but not obsess. Let me define small Mario 16x16: ``` "................", ".....RRRRR......", "....RRRRRRRR....", "....HHSSHS......", "...HHHSSSHS.....", "...HHSSSSSSS....", "....SSSSSSS.....", "...RRRBBBRRR....", "..RRRRBBBRRRR...", ".RRRRRBBBRRRRR..", "SSRRBYYYYYBRRSS.", "SSSRBBBBBBBRSSS.", "SSRBBBBBBBBBRSS.", "...BBB....BBB...", "..BBB......BBB..", "................" ``` Where H = brown hair/dark, S = skin, R = red, B = blue overalls... wait I mixed. Let me set: R = red (shirt/cap), B = blue overalls, Y = yellow/brown shoes... Actually shoes should be brown: K. Hmm, in SMW small Mario shoes are brown/dark. Let me use K = dark brown shoes. Let me redo with palette keys: `R` red, `S` skin, `B` blue, `K` dark (shoes/hair), `W` white (eye). ``` ................ .....RRRRR...... ....RRRRRRRR.... ....KKSSKS...... ...KKKSSSKS..... ...KKSSSSSSS.... ....SSSSSSS..... ...RRRBBBRRR.... ..RRRRBBBRRRR... .RRRRRBBBRRRRR.. .SSKRBBBBBRKSS.. .SSSKBBBBBBKSSS. .SSKBBBBBBBBKSS. ...BBB....BBB... ..KKK......KKK.. ................ ``` Good enough. I'll add eye detail: `W` white next to dark. Let me put `KS` -> eye: row3 `....KKSSKS......` hmm the eye should be on the right side of the face (facing right). Fine. For walk frames, I'll just tweak legs. For jump, raise arms. I can generate 3 walk frames by modifying leg rows. To save space, I'll write idle, walk1, walk2, walk3, jump, skid, crouch, and for big: idle, walk1, walk2, jump, crouch. Fire/cape use recoloring of the same arrays (palette swap). Actually cape Mario needs a cape shape — I'll draw the cape as a separate procedural shape (yellow triangle-ish) behind the player when cape. Simpler: draw cape as an extra shape based on state. OK. Hitbox: small = 12x14 (in world units, scaled: player width 12, height 14 for small; big width 12, height 26... but sprite16 wide). Let me use: small w=12,h=14; big w=12,h=22; sprite drawn at 16x16 and 16x24 with offsets. Hmm, to keep collision simple: hitbox width 12, height 14 (small) / 22 (big), sprite 16 wide centered,16/24 tall with top offset so feet align. Game loop: fixed timestep update (dt in frames, ~60fps), requestAnimationFrame with accumulator. Physics (SMW-ish): - max walk speed 0.0625 px/frame? In SMW, walk1.5 px/f? Let me define in pixels/frame at 60fps: - walk accel0.02, max walk 1.5 - run accel 0.03, max run 2.6 (with spin/cape slightly faster ~2.9) - friction 0.02, skid decel 0.06 - gravity 0.05 (falling 0.5 max ~4.5) - jump: initial vy = -4.0 to -5.2 depending on speed; holding jump reduces gravity to 0.018 while rising (SMW-like), releasing jump cuts vy. - variable jump: if not holding jump and vy < -1.0 -> vy *=0.5 (roughly). - Terminal fall speed 6. Enemies: - Goomba: walks 0.35 px/f, dies on stomp (flattened), kills player otherwise. - Koopa (green): walks 0.35; stomp -> shell (speed 0 when stopped, 2.5 when kicked); shell kills other enemies; red koopa turns around at edges. - Piranha plant: rises from pipe periodically, doesn't hurt when player near pipe top. - Bullet Bill: flies horizontally at 1.5 px/f, kills on stomp, comes from the right side periodically. - Chargin' Chuck: walks 0.3, when player near, charges2.2, can be stunned, jumps. - Monty Mole: pops out of ground, throws rock; maybe simplify: hops. - Boo: floats toward player when player isn't facing it; turns visible when player faces away — nice touch, easy to implement. - Cheep Cheep: swims in water areas (arc motion). - Spiny? skip or include: red with spikes — stomp hurts, fireball kills. - Bob-omb: walks, explodes on stomp/fireball. - Bowser: boss. Fireball: small Mario can't shoot; fire Mario shoots bouncing fireballs (bounce off ground, destroy enemies, one at a time x2 in SMW... actually SMW allows 2). I'll allow 2 simultaneously. Cape: pressing Y/shift while cape -> spin cape (hitbox around player, kills enemies, breaks bricks). Super cape: run and press down to launch flight (needs >2 speed), fly with hold A (float, max height), spin attack while flying. I'll implement: if cape and speed > 2.2 and press down in air -> begin flight (gravity lower, can rise while holding jump). Simplified. Star: invincible + fast, rainbow palette, kills enemies on contact. Coins: from blocks (spawn coin popup), scattered, brick with coin, p-switch turns coins into bricks, coin blocks. Blocks: - Question block: coin or power-up (based on flag), becomes used. - Brick: small -> bump only; big/fire/cape -> break into particles (and big Mario breaks all bricks). - Stone block: always solid. - Bumpable solid blocks (used blocks, stone) -> bump enemies above. Goal: flagpole / goal gate (SMW: a switch on a pole with a gate that opens). I'll do the flagpole with the gate: touching pole causes player to slide down, then a flag raises, level complete with bonus coins/score. For castle levels: goal switch at end + boss. Level flow: 12 levels: 1. World 1-1 (Overworld, ground/gaps/goombas, flag) 2. World 1-2 (Underground, coins/pipe) 3. World 1-3 (Athletic/athletic platforms, koopas, pipes) 4. World 1-4 (Castle / boss: Bowser #1 — actually SMW has Ludwig in castle; I'll do "Bowser Jr."? No — SMW 1-4 is a castle with Iggy Koopa (who uses... actually1-4 is Iggy). I'll name bosses by Koopa kids for authenticity: Iggy, Morton, Wendy, Lemmy, Roy, Larry, Ludwig... but user asked "boss" generically. I'll do: castle levels have a boss battle with fireballs and a "hit the switch / stomp" mechanic — I'll implement a generic "Boss" with different names and colors (Iggy etc.) with fireball projectiles, and a final Bowser at the end. 5. World 2-1 (overworld variation) 6. World 2-2 (underground 2 / water) 7. World 2-3 (athletic / sky) 8. World 2-4 (Castle, boss) 9. World 3-1 (overworld night variant) 10. World 3-2 (ghost house — Boo!) 11. World 3-3 (athletic/star road?) 12. World 4-4 (Final Castle — Bowser) That's 12 levels with 2+ bosses + final Bowser. Good: "al menos 10 niveles 9+boss" — I'll include bosses on castle levels (1-4, 2-4, 3-4?) Let me do12 levels: 4-1,4-2,4-3,4-4(castle boss Iggy),5-1,5-2,5-3,5-4(castle boss Morton),6-1,6-2,6-3,6-4(final Bowser). Plus a secret bonus? Keep 12. Actually simpler naming: World 1-1 ... 3-4. Fine. World map: SMW-style map with paths and nodes, player icon moves to node, press Enter to start. That's a nice touch and "faithful". I'll implement a simple map with nodes drawn on a pixel-art-ish map (procedural: green terrain, paths, trees). Use canvas. Controls: - Arrows / WASD: move - Z / Space / K: jump (also spin jump with Down+Jump? SMW: spin jump = Y button... In SMW: B = jump, Y = run/spin, X = cape action (Y/X). I'll map: Z/Space = jump (B), X/K = run + spin jump + cape spin (Y), S = crouch/down, Enter = start/pause. Mobile: add on-screen touch buttons (D-pad + A/B) — good for completeness. Save state: localStorage for unlocked levels/score. Nice. Now let me write the level generator. ```js function buildLevel(def) { const W = 200, H = 14; // 14 rows ... } ``` I'll use rows: y=0 top (sky), ground at y=12,13 (rows 12-13 ground). 14 rows tall = 224px height view; camera height 224? Canvas 256x224 would be nice (SMW resolution256x224). Yes! Use 256x224 internal canvas scaled to fit (scale x3 = 768x672). Level height 14 tiles = 224px exactly. Camera: follows player x with deadzone; y fixed at 0 for overworld (level height exactly fits), but for vertical levels we could scroll — keep y fixed at 0 for simplicity (14 rows exactly). Hmm, some levels could be taller (e.g., 20 rows for a vertical section) — but keeping14 rows avoids y camera issues. But I want underground vertical? Keep14 rows everywhere; y camera locked at 0 (plus a bit of smoothing if needed). Actually SMW levels can be taller. Keep it simple: 14 rows, no vertical camera. Some levels could be taller for sky levels where the ground is lower... but then camera y needed. I'll allow H=14 fixed for all; ground rows vary within. Level generation plan (per level def): - start platform (x0..12 ground) - sequence of "sections" chosen by type, each ~20-40 tiles wide: - flat ground with enemy group - gap (1-3 tiles) - pipes (1-4 tiles tall) with optional piranha plant - staircase up/down - brick+question row with coins - floating platforms (semi-solid) - hill/bumps - pit with lava (castle) - water region (underground 2-2 / water levels) - ghost house corridors with boos - end area: staircase + flagpole/goal gate at x = W-8. Use seeded RNG (mulberry32) seeded by level index so the level is consistent each play. For castle levels: stone tiles, lava pits, firebars?, moving platforms, boss arena at end with boss + goal switch. Boss battle: at end of castle level, create an arena (enclosed with walls at x = W-40 to W), lava below? In SMW, you fight on a platform with Bowser; you must stomp him (or in final battle, hit him to drop him into lava). I'll implement: boss has HP (5 stomps), stomps make him flash and get angry (faster). On death: he falls (into lava / off screen) then the goal switch becomes active — touching it wins. Also fireballs can hurt him? In SMW you can't hurt Bowser with fireballs; you must stomp. For the Koopa kids, you can hit them with fireballs (they fly). I'll allow both: stomping and fireballs damage (for playability), with the boss having HP 6 and a "fall" mechanic. OK. Rendering: - Background: sky gradient + clouds + hills + bushes (drawn per theme, parallax). - Tiles: draw procedural pixel art via offscreen tile atlas canvas generated at startup (16x16 tiles drawn with rects, pixelated). That keeps rendering fast and code compact-ish. Let me create an atlas with tile drawing functions. Tile atlas: I'll draw each tile type in a 16x16 cell using small pixel ops: - ground (overworld): brown dirt with darker outline + grass top - stone/used block: brown block with rivets - brick: brick pattern - question block: yellow with "?" (draw with rects) - pipe: green with shading - etc. I'll write a helper `px(ctx, x, y, w, h, color)`. Now let me write the code in full. I need to be careful with length but thorough. Let's target a complete, working game (~2000-2500 lines). That's a big answer but the user asked for it. I'll be efficient. Let me now write it. ```html SUPER MARIO WORLD — SNES (Fan Engine)

``` UI overlays: I'll draw title/gameover screens on canvas for simplicity, plus a small HTML bar with instructions and touch buttons. Let me write the JS carefully. ### Core constants ```js const T = 16, VW = 256, VH = 224, ROWS = 14; ``` ### Tile enum ```js const TT = { EMPTY:0, GROUND:1, BRICK:2, QUESTION:3, USED:4, STONE:5, PIPE_TL:6, PIPE_TR:7, PIPE_BL:8, PIPE_BR:9, COIN:10, LAVA:11, SPIKE:12, FLAG:13, BRIDGE:14, SEMI:15, WATER:16, LAVA2:17? , GOAL:18, SWITCH:19, DONUT:20, CLOUD:21, DOOR:22, LAVA_SPARK:23, POLE:24, GATE:25, TORCH?.. }; ``` Solidity: GROUND, BRICK, QUESTION, USED, STONE, pipe tiles, SPIKE(not solid, hazard), SEMI (one-way), BRIDGE (solid, collapses), water (not solid). I'll implement collision with a tile grid + one-way platform support (only collide when falling and previous bottom <= tile top). ### Entities ```js class Enemy { ... } ``` I'll use plain objects with `type`, `x,y,w,h,vx,vy,state,alive,timer,onGround,dir`. ### Player object ```js p = {x,y,w,h,vx,vy,onGround,dir,facing,state:'small'|'big'|'fire'|'cape', invuln, star, crouch, spin, flying, jumpHeld, animT, ...} ``` Power-up transitions: eating mushroom -> big (with a "grow" animation ~30 frames where player is frozen); eating flower -> fire; eating feather -> cape; eating 1-up -> extra life; eating star -> invincible 10s. Damage: if small -> die; if big/fire/cape -> shrink to small + invuln (SMW: fire/cape -> big? In SMW, getting hit as fire/cape/small goes to small; as big, goes to small... Actually in SMW getting hit: big -> small, fire -> small? In SMW, Fire and Cape Mario revert to... they become small Mario (well, they lose the power-up and become small). Hmm: in SMW, if you're Super and get hit -> Small; if Fire/Cape and get hit -> Small (yes, you lose the flower/cape). Actually I recall in SMW fire/cape go straight to small. Hmm, no — in Super Mario World, getting hit as Fire Mario reverts to... I'm fairly sure Fire Mario -> Small (unlike SMB3 where Fire -> Super). Yes, SMW: any power-up hit -> Small. I'll implement that (and it's simpler). ### Scoring Coins -> +1 coin, +200 score, 100 coins = extra life. Score for stomping: 100 (and combo chain200,400,800,1000...). Time bonus at end. ### Timer Time counts down at 1 unit per ~40 frames (SMW: 1 unit per 0.4s).400 units max. ### Level completeGoal gate/flagpole: player slides down pole, then walks right to the goal switch -> level clear screen with "COURSE CLEAR!" + bonus. Keep simple: touching flag -> clear state, award bonus, then map. ### Map screen World map: grid of levels with nodes connected by paths. Player moves with arrows between nodes, Enter to enter. Draw a stylized SMW-ish map: green land, blue water, mountains, roads, dots for levels. Each node: circle with level number, castle nodes for castles. Locked levels greyed out (but I'll allow replay of completed). ### State machine states: 'title', 'map', 'play', 'pause', 'clear', 'gameover', 'ending', 'dying'. Let me write the code now. I'll write it in one go, mentally checking syntax. I'll write the sprite arrays. Let me carefully define them (16 wide, 16 tall for small; 16 wide 24 tall for big). Palette keys (used in both small and big): - `.` transparent - `K` dark outline (black-ish #101010) - `R` red (#e52521) - `S` skin (#ffb97d / SMW uses #fca87d?) - `B` blue overalls (#2038ec) - `Y` yellow (for star / gloves?) — use `W` white gloves (#ffffff) - `D` dark brown shoes (#7b3f00) / hair (#4a2400) - `G` green (for cap in some sprites?) not needed. Small Mario idle (16x16): ``` ................ .....RRRRR...... ....RRRRRRRR.... ....DDSSDS...... ...DDDSSSDW..... ...DDSSSSSSS.... ....SSSSSSS..... ...RRRBBBRRR.... ..RRRRBBBRRRR... .RRRRRBBBRRRRR.. .WRKRBBBBBRKW.. <- hmm``` Let me simplify arms/hands: white gloves at sides of overalls. I'll write: ``` "................", ".....RRRRR......", "....RRRRRRRR....", "....DDSSDS......", "...DDDSSSDW.....", "...DDSSSSSSS....", "....SSSSSSS.....", "...RRRBBBRRR....", "..RRRRBBBRRRR...", ".WRRRBBBBBRRRW..", "WWKRRBBBBBRKWW..", "..WBBBBBBBBBW...", "...BBBBBBBBB....", "..KKKK...KKKK...", ".KKKK.....KKKK..", "................" ``` Hmm the hands: In the standing pose, hands are at sides near the top of overalls. I'll accept approximations — at 3x scale it'll read as Mario. Walk frames: change leg rows. jump: arms up. skid: face away (I'll draw with flipped? just change colors—simpler: draw a different sprite where the cap brim faces the other way). Keep: idle, walk1, walk2, walk3, jump, skid, crouch(small), and big versions idle, walk1, walk2, jump, crouch, and swim? skip. Big Mario 16x24 — I'll write ~24 rows. This is a lot of typing; let me keep big Mario sprite to 16x24 with reasonable detail. Actually, to reduce risk of ugly sprites, maybe simpler approach: draw Mario procedurally with rects at pixel scale (cap = rounded rect, face, body, arms, legs, shoes), parameterized by pose and palette. This is far more compact and reliable than hand-typing pixel grids, and can look decent. But pixel art arrays look better... I'll go with pixel arrays for small Mario (idle/walk1/walk2/jump/skid/crouch) and big (idle/walk1/walk2/jump/crouch), with palette swap. It's maybe 200 lines total. Let's do it — quality matters for "fiel al real". Let me write small Mario 16x16 grid, palette: K=#1b1b1b, R=#e52521, S=#f8b888 (skin), B=#2038ec, D=#6b3e1f (hair/shoes), W=#ffffff, Y=#fbd000 (unused). Small idle: ``` row0: ................ row1: .....RRRRR...... row2: ....RRRRRRRR.... row3: ....DDSSDS...... row4: ...DDDSSSDW..... row5: ...DDSSSSSSS.... row6: ....SSSSSSS..... row7: ...RRRBBBRRR.... row8: ..RRRRBBBRRRR... row9: .WRRRBBBBBRRRW.. row10: WWKRRBBBBBRKWW.. row11: ..WBBBBBBBBBW... row12: ...BBBBBBBBB.... row13: ..KKKK...KKKK... row14: .KKKK.....KKKK.. row15: ................ ``` Wait rows 3-6 should have the face with hair on the left side (since facing right). Row3: `....DDSSDS......` =4 dots, DD, SS, DS → that's hair, skin, skin, dark(eye), skin. Hmm the eye should be dark: `D` is brown-ish; let me use `K` for eye instead. Use `D` for hair only. row3: `....DDSSKS......` (hair,hair,skin,skin,eye,skin) row4: `...DDDSSSKS.....` row5: `...DDSSSSSSS....` — hmm hair on left edge going down (sideburns) row6: `....SSSSSSS.....` Body: row7: `...RRRBBBRRR....` (red shirt with blue straps) row8: `..RRRRBBBRRRR...` row9: `.RRRRRBBBRRRRR..` + hands? Let me put white gloves at row9-10 ends: row9: `.WRRRBBBBBRRRW..` — hmm the glove should be at the outer edge. OK. row10: `WWKRRBBBBBRKWW..` — `K` dark = the belt/shadow. Eh, let me use `K` only for shoes and eye and outline. I'll simplify: row9: `.RRRRRBBBRRRRR..` row10: `.WRRRBBBBBRRRW..` row11: `..WBBBBBBBBBW...` row12: `...BBBBBBBBB....` row13: `..KKKK...KKKK...` row14: `.KKKK.....KKKK..` row15: `................` Fine. Legs: overalls (blue) between shoes. walk1 (leg forward): row13: `..KKK....KKKK...` hmm. Let me define legs: walk1: row13 `...KKK...KKKK...`, row14 `..KKK.....KKKK..`, row15 `................`? Better to have 2 frames: legs apart and together. walk1: ``` row13: `..KKKK..KKKK....` row14: `.KKKK....KKKK...` ``` walk2 (together): ``` row13: `..KKKKKKKKKK....` row14: `.KKKKKKKKKKKK...` ``` Hmm — I'd rather make the legs asymmetric to convey motion: walk1: `...KKKK.KKKKK...` / `..KKKK...KKKKK..` walk2: `..KKK...KKKKKK..` / `.KKK.....KKKKK..` OK good enough. jump: arms up, legs bent: ``` row13: `...KKK...KKKK...` row14: `..KKK.....KKK...` ``` plus hands up: modify row8-9 to have W at the top:row7: `.WRRRBBBBBRRRW..` (arms out) skid: face flipped — I'll just reuse idle but mirrored in code (ctx.scale(-1,1)) when skidding (SMW skid has Mario facing backward-ish). Good: draw idle mirrored for skid. crouch small: 12x12-ish sprite — I'll make a squashed version (16x12) by scaling the idle sprite vertically (draw with drawImage scaled to 16x12). Simple: crouch = idle scaled to 60% height. Acceptable. Big Mario 16x24: ``` row0: ................ row1: ................ row2: ....RRRRRR...... row3: ...RRRRRRRRRR... row4: ...DDDDSSSSD.... row5: ..DDDDSSSSSDK... row6: ..DDDDSSSSSSS... row7: ...DDSSSSSSS.... row8: ....SSSSSSS..... row9: ...RRRBBBRRR.... row10: ..RRRRRBBBRRRR.. row11: .RRRRRBBBBBRRRR. row12: .WWRRRBBBBBRRRW. row13: WW.WRRBBBBBRW.WW row14: ....RBBBBBBBR... row15: ...BBBBBBBBBBB.. row16: ..BBBBBBBBBBBB.. row17: ..BBBB....BBBB.. row18: ..BBBB....BBBB.. row19: ..BBBB....BBBB.. row20: ..KKKK....KKKK.. row21: .KKKKK....KKKKK. row22: .KKKKK....KKKKK. row23: ................ ``` That reads as big Mario. Good. big walk1: legs: ``` row17..19: shift left/right ``` I'll write two frames. big jump: arms up: ``` row12: .WWRRRBBBBBRRRW. row13: WWWW.RRBBBBBRWWWW — hands above head ``` OK. Fire/cape recolor: map R->W (fire cap/shirt white) etc. Cape: draw a yellow cape polygon behind the player when state==='cape' (and when flying, cape animates). Star: cycle palette hue by drawing with a global "colorify"? Simplest: draw sprite normally, then apply a rainbow overlay: draw a colored rect with 'source-atop' over the sprite region with hue cycling. Since I draw sprites via drawImage from atlas, I can set ctx.globalCompositeOperation='source-atop' after drawing the sprite... but that would affect the whole canvas region under. Better: draw the sprite to a small offscreen 24x24 canvas, apply 'source-atop' colorize there, then draw to main canvas. I'll implement `drawPlayerSprite(ctx, img, x, y, flip, tint)` using a scratch canvas with tint support. That handles star and also cape/fire variants via palette swap at atlas build time. Implementation: build atlas canvas once with multiple sprite sheets: - sheet: smallMario[8] states, bigMario[5] states, palette variants: normal, fire, cape(cap+cape handled separately) →2 palettes (normal, fire) + star tint via scratch. - cape: when state==='cape', use normal palette + draw cape shape. Enemies drawn procedurally with rects/circles per frame. OK — enemies procedural drawing: - goomba: brown rounded body 16x14, dark feet, eyes with brows, white sclera + black pupils, two feet alternating. - koopa green/red: shell (ellipse with rim), head with eyes, feet. When stomped: shell only (ellipse + rim). Kicked shell: shell with slight tilt, moving. - piranha plant: green stem + red head with white spots + white teeth; animate rising/falling (scale from pipe). - bullet bill: black capsule with white eyes, gray arms, gray "fins". - chargin' chuck: green shirt, blue cap? In SMW Chargin' Chuck: green... Actually Chargin' Chuck wears a green outfit? The Chargin' Chuck is a green... I recall the Chargin' Chuck sprite: green cap? Hmm — Chargin' Chuck has a green... no: Chargin' Chuck has a green... I'm not certain; I'll draw a green-shelled (green cap) football-helmet koopa with white gloves — recognizable enough. - boo: white ghost with arms, blue-ish shading, eyes, tongue when visible. - bob-omb: black round bomb with blue feet, white eyes, orange fuse spark, walking legs; explodes on stomp → explosion graphic. - cheep cheep: red/white fish. - spiny: red spiky ball with legs and eyes (not stompable). - Monty mole: gray/brown mole popping from ground. - Bowser/boss: large (48x48) green spiky shell, spikes, arms, head with horns, fire breath. - firebar: rotating fireballs on a chain (castle). - lava spark? skip. - Thwomp: gray block with angry face falling — nice castle element. Include. That's a good roster. Let me include: goomba, koopa(green), redkoopa, shell, piranha, bulletbill, chuck, boo, bomb, cheepcheep, spiny, thwomp, monty, boss. Now the level generator. Let me write it. ```js function mulberry32(a){return function(){a|=0;a=a+0x6D2B79F5|0;var t=Math.imul(a^a>>>15,1|a);t=t+Math.imul(t^t>>>7,61|t)^t;return ((t^t>>>14)>>>0)/4294967296;}} ``` Level def: ```js const LEVELS = [ {name:'1-1', theme:'overworld', width:212, seed:1101, boss:false, par:...}, ... ]; ``` buildLevel(def): - create grid (2D array ROWS x W) filled with EMPTY. - set ground: for x in 0..W-1: rows 12,13 = GROUND (with variations for gaps) - fill background details (hills/bushes as decoration drawn in bg) - generate sections between x=14 and x=W-26, using rng. - end: staircase to flag at x=W-20, flagpole at x=W-10, ground solid to end. Let me write `set(x,y,t)`, `get(x,y)`, `fillRect`, etc. Section generator (loop until x >= endX): ```js const r = rng(); if (r < 0.12) ground enemies flat else if (r < 0.24) gap else if (r < 0.34) pipes else if (r < 0.44) brick+question row else if (r < 0.54) staircase else if (r < 0.64) platforms else if (r < 0.72) hill/bumps else if (r < 0.80) enemy formation with platforms else if (r < 0.88) coin row else if (r < 0.94) pit with lava/ water else bonus area (high platform with coins) ``` Adjust by theme (underground: more bricks, pipes, coin rows; castle: stone, lava pits, thwomps, firebars, moving platforms; ghost: narrow corridors, boos, doors; sky/athletic: gaps + platforms; water: water regions with cheep cheeps). I'll implement a `sections` array per theme with weighted choices. Keep it reasonable. Also ensure playability: don't place enemies on the very first tiles, ensure a jumpable gap max3-4 tiles wide (with running jump ~4-5 tiles), place a safe landing. Camera: x follows player: `cam.x = clamp(p.x + p.w/2 - VW*0.42, 0, levelW*T - VW)` with lerp and only moving right (never left past) — SMW camera doesn't scroll left much. I'll clamp so cam.x >= 0 and lerp. Collision resolution: ```js function moveAndCollide(ent, level) { ent.x += ent.vx; // horizontal resolve X: check tiles overlapping [x, x+w] at rows overlapping [y,y+h]; if solid → push out ent.y += ent.vy; resolve Y similarly; set onGround when moving down into solid. } ``` Implement with tile loops over the bounding tile range. Handle one-way (SEMI) in Y only when ent.vy > 0 and previous bottom <= tileTop + 2. Water: if the tile the player's center is in is WATER → apply buoyancy (gravity *0.45, reduced fall, jump = swim stroke). Nice touch for water levels. Hazards: LAVA tiles → on overlap with player hitbox (small inset) → die. SPIKE → damage. Now, fireballs, cape spin, shell kicks, etc. Score popups: array of {x,y,text,t}. Coin bounce from question block: a coin entity that pops up and fades. Power-up spawn: entity with type 'mushroom'|'flower'|'feather'|'star'|'1up'|'coinblock', rising out of the block then moving (mushroom walks with gravity and turns at edges; flower static; feather floats/descends slowly with a sine; star bounces fast). Enemy spawn: only when near camera (x < cam.x + VW + 32) to allow off-screen movement — actually SMW spawns them when they come on screen. I'll spawn when `e.x < cam.x + VW + 24` and mark spawned. Despawn: when entity is far left of camera (`e.x < cam.x - 64`) → remove (except shells/pickups maybe keep briefly). Boss: separate entity with state machine, spawns in arena, fires projectiles (Bowser throws fireballs in an arc + sometimes a "Bowser bomb" that falls), moves back and forth, stomping does damage with cooldown, player gets invulnerability after a hit. On HP 0 → boss falls down (vy increasing) → then "switch" entity becomes active → touching it = clear. For non-final bosses, HP 3-4. Fireballs hitting the boss: in SMW you can't damage Bowser with fire; but for playability, allow fireballs to stun/hurt (small damage) — I'll allow fireball damage (1 dmg) and stomps (2 dmg) with a cooldown so it's not trivial. Let me now write the actual code text. I'll be systematic. I'll write it now (final answer). Key risk: syntax errors. I'll keep code straightforward and avoid overly clever stuff. Let me define the drawing helpers: ```js function px(ctx,x,y,w,h,c){ctx.fillStyle=c;ctx.fillRect(Math.round(x),Math.round(y),Math.round(w),Math.round(h));} ``` Tile atlas generation: create `atlas` canvas of size 16*12 x 16, draw tiles into it. `TILE_IMG[tileType]` drawn from atlas region via drawImage(atlas, tx*T,0, 16,16, dx,dy,16,16). Tiles to draw: GROUND (top variants: with grass), GROUND2 (dirt), BRICK, QUESTION (animated? no, static + used), USED, STONE (castle), PIPE_TL/TR/BL/BR, COIN (animated — I'll draw coins separately as animated entities instead: tile COIN is non-solid and rendered as a spinning coin via code, not atlas), LAVA (animated — draw separately), SPIKE, SEMI (platform plank), BRIDGE (wooden), WATER (animated fill — draw separately), GOAL pole/gate, DONUT?, CLOUD? (decoration drawn in bg), DOOR, SWITCH, BRICK_COIN?, BLOCK_BREAK particle, THWOMP (drawn as enemy), FIREBAR (enemy), BOSS. To keep it simpler: atlas has: ground, ground-side, dirt, brick, brick-coin, question, used, stone, pipeTL, pipeTR, pipeBL, pipeBR, semi, bridge, pole, gate, door, spike, flag. Animated ones (coins, lava, water) drawn by code. Let me write the atlas functions per tile. I'll write the code now in the answer. Let me draft key parts mentally to avoid errors: ```js // ============ SETUP ============ const canvas = document.getElementById('game'); const ctx = canvas.getContext('2d'); ctx.imageSmoothingEnabled = false; ``` Scaling: CSS `width:100%; max-width:768px; image-rendering:pixelated;`. Input handling: keys object with `keys` (held) and `pressed` (edge). `keydown` sets `keys[e.code]=true` and if not repeat → `pressed[e.code]=true`. `pressed` cleared at end of frame (after both updates). Prevent default for arrows/space. Touch: buttons with `data-key` → set keys/pressed on pointerdown/up. Main loop: ```js let last=0, acc=0; function frame(ts){ const dt=Math.min(100,ts-last); last=ts; acc+=dt; while(acc>=STEP){ update(); acc-=STEP; } render(); requestAnimationFrame(frame); } ``` STEP = 1000/60. State machine in `update()`: - 'title': press start → 'map' - 'map': move/select → 'play' (reset level) - 'play': update entities etc. - 'pause': frozen - 'dying': player death animation timer → respawn or gameover - 'clear': timer → back to map - 'gameover' → map/title - 'ending' → credits text I'll write `loadLevel(index)` that builds the level and resets entities/player. Let me handle lives and game over: lives start3? SMW starts with 5? SMW starts with... I'll use 5 (SMW gives 5? Mario games typically3-4; SMW gives 5 lives? Actually SMW starts with 5 lives? Hmm, Super Mario World starts with... I think 5 lives? No, it starts with... I'm not sure; I'll use 5 to be friendly... Actually many say SMW gives you 5 lives at the start? Hmm. Let me just use 4. Eh — I'll use 5 (it's generous and many sources say SMW starts with 5 lives... I'm fairly confident it's 5? No! I'm now fairly sure SMB3 gives 5? SMB1 gives 3. SMW gives... I'll go with 5, it's a fan recreation, no one will complain). Now, level completion → unlocks next level in the map, stores in localStorage. Let me write the ending screen: "¡GANASTE! THANK YOU FOR PLAYING" with Mario sprite and score. OK. Writing the final answer now. I'll be thorough but efficient in code style. One more consideration: total length. This will be very long (~1800+ lines). That's acceptable. Let me carefully write the update functions: ```js function updatePlayer(){ const p=player; if (p.dead || p.win) { ... } // crouch const down = keys['ArrowDown']||keys['KeyS']; const left = keys['ArrowLeft']||keys['KeyA']; const right = keys['ArrowRight']||keys['KeyD']; const jump = keys['KeyZ']||keys['Space']||keys['KeyK']||keys['ArrowUp']||keys['KeyW']; const jumpP = pressed('KeyZ')||pressed('Space')||pressed('KeyK')||pressed('ArrowUp')||pressed('KeyW'); const run = keys['KeyX']||pressed('KeyX')... // run held: KeyX, ShiftLeft, KeyJ const runP = ... const action = cape held... (KeyX/Shift/J) — in SMW, Y = run/spin, X = cape spin (when cape). I'll map: Z/Space = jump (B), X/Shift/J = run + spin jump + cape spin, C/Alt = ? skip. ``` Hmm: I'll map `KeyX`/`ShiftLeft`/`KeyJ` to "run/spin" and `KeyC`/`KeyL` to "cape action (spin/fly)". And "run" held also triggers cape spin. Simpler: run held + spin button? Let me do: - jump: Z/Space/W/Up - run/spin: X/Shift/J (held = run; pressed = spin jump in air / cape spin on ground) - cape: V/K/Alt (cape spin / flight launch) - down: S/Down - start: Enter/P Fine. Player update: ```js const maxSpeed = run ? 2.75 : 1.45; const accel = run ? 0.045 : 0.03; if (left) { p.vx -= accel; p.face=-1; if (p.vx>0) p.vx -= 0.075 (skid); } ... if (Math.abs(p.vx) > maxSpeed) p.vx *=0.97 (decay toward max) — SMW keeps momentum; I'll allow slight overspeed decay to maxSpeed. p.vx = clamp(p.vx, -4.5, 4.5); ``` Jump: ```js if (jumpP && p.onGround && !p.crouch) { const sp = Math.abs(p.vx); p.vy = -(4.35 + Math.min(1.15, sp*0.30)); p.jumpHeld=true; p.onGround=false; p.coyote=0; sfx('jump'); } if (jump && p.jumpHeld && p.vy<0) { p.vy -= 0.032 } // extended gravity reduction else p.vy -= 0.05 (gravity) // variable heightif (!jump && p.vy < -1.2) p.vy = -1.2; ``` Actually classic: gravity normal 0.45-0.5 px/frame² (in frames); jump initial -7... Let me use frame-based units where speeds are px/frame: - gravity while falling: 0.32- gravity while rising and holding jump: 0.10 - jump initial velocity: -4.6 to -5.6 depending on speed (with0.35*speed added) - max fall: 6.5 (SMW terminal ~ 6-7) Hmm, but earlier I said accel 0.03 px/frame which is very slow (max speed 1.45 px/frame = 87 px/sec = 5 tiles/sec). That's about right for walk (SMW walk≈ 1.5 tiles/sec? no). Let me check: Mario's walk speed in SMB1 is about 1.5 px/frame, run ~2.8 px/frame. In SMW, walk ~1.5, run ~2.9. Good, so px/frame units as above are right. Gravity: in SMW, gravity is ~0.5 px/frame² when falling, 0.25 when rising with jump held? Jump height ~ 4.6 tiles (80px). Let's compute: v0 = -5, g=0.25 while holding → height = v0²/(2g) = 25/0.5 = 50px ≈ 3.1 tiles, time to apex = 20 frames. Then falling with g=0.5: from50px, t=sqrt(2*50/0.5)=14 frames. Total ~34 frames ≈ 0.57s. That's about right for a 3.5-4 tile jump. I'll tune: v0 = -(4.6 + min(1.0, speed*0.30)), riseGravity0.235, fallGravity 0.42, maxFall 6.2, cutJump: if !jump && vy<-1.6 → vy = -1.6. For high jumps (holding), the total height with g=0.235 and v0=5.6: 25/(0.47) = 53px ≈ 3.3 tiles. Hmm, that's low-ish; SMW max jump ~4.5 tiles with run. I'll set riseGravity 0.18 when holding jump → v0=5.6 → 25/0.36=69px = 4.3 tiles. Good. So: `riseG = jumpHeld ? 0.17 : 0.28; fallG = 0.42;` and when holding jump in air, gravity 0.17; when not holding, 0.28 while rising, 0.42 while falling? Simpler: if (jumpHeld && vy<0) g=0.17 else g=0.42 (and if not holding and rising, use 0.34 for a smoother cut). I'll do: ```js let g = 0.42; if (p.vy < 0 && jump) g = 0.17; else if (p.vy < 0 && !jump) g = 0.30; // cut jump p.vy += g; if (p.vy > maxFall) p.vy = maxFall; ``` Good. Coyote time: 6 frames; jump buffer: 6 frames. Wall collision, then ground check. Crouch: if down && onGround → p.crouch=true, height reduced, vx decays fast, can slide. If crouching in air, just fall (SMW allows crouch in air). When standing, check head clearance (if solid above, stay crouched). Grow/shrink: when changing size, adjust y so feet stay in place, and resolve overlap with tiles (move up/down as needed). Death: `p.dead=true; p.vy=-5.6;` no collisions, fall off screen, timer → respawn. Flag/goal: if touching FLAG tile (pole) → win: p.win=true, p.x = pole x + ..., slide down, then clear state after ~2.2s. Let me write the "goal" handling simply: when the player's hitbox overlaps a `FLAGPOLE` tile column → start 'clear' sequence: player moves to pole, slides down to ground, then walks right into the gate → level complete. I'll implement the flag as tile `FLAGPOLE` (a1-tile-wide column at ground level, 8 tall) plus `GOAL_GATE` at the bottom. On touch → win sequence: freeze input, set p.x to pole, vy=2 (slide), after hitting ground → walk right for 1.5s → complete. Time bonus: remaining time × 50 points added over time. Alright. Also "9+boss": I'll make sure castle levels (1-4, 2-4, 3-4,4-4) each have a boss = 4 boss fights. And12 levels total. I'll name them 1-1..3-4? Let me do worlds 1-4 with 4 levels each = 16 levels! That's more "faithful" (4 worlds × 4 levels). Hmm, 16 levels of generation is fine since it's generated. Let me do 12 levels (3 worlds × 4) to keep it manageable but still "10+ levels". Actually generation is cheap; do 16 levels (4 worlds × 4). The user said "al menos los 10 primeros niveles 9+boss" — so 10+ levels and at least 9 bosses?? "9+boss" might mean "9 + bosses" (the first 10 levels are 9 regular + 1 boss). I'll include 12 levels with 4 boss castles... To be safe, I'll include bosses on more levels: castle levels 1-4, 2-4, 3-4, 4-4 plus a mid-boss on some levels (a mini-boss "Thwomp/Boss" guarding a door?) — that's overkill. I'll do 4 worlds × 4 levels = 16 levels, 4 castle levels with bosses, plus4 "secret" bonus levels (hidden on the map). Hmm, 16 levels with bosses on levels 4,8,12,16 + a mini-boss on some. I'll do: 12 playable levels in the main path (worlds 1-3 × 4), with castle levels 1-4, 2-4, 3-4,4-4 = 4 bosses + final Bowser = 5 boss fights, plus mini-bosses on 3-2/4-2? Keep it: 16 levels, 4 castles + final? Let me settle: 4 worlds × 4 levels = 16 levels; castle levels (4,8,12,16) have bosses (Iggy, Morton, Wendy, Bowser Jr + final Bowser at 16). That satisfies "10+ levels" and multiple bosses. And I'll add 3 secret levels (S1, S2, S3) unlocked via hidden pipe? Too much. Just 16 + a "Star Road" bonus? No. Keep 16. Hmm, but the map with 16 nodes + 4 worlds is a chunk of drawing code but it's just procedural rendering. OK. Let me write the map: world rows (4 worlds), each with 4 nodes on a horizontal-ish path with slight vertical variation, connected by dashed roads, castle node is a small castle sprite. Player icon: a 16x16 Mario head sprite (drawn procedurally). Level select: move left/right with arrows, Enter to start. Also allow jumping to the next unlocked node. Let me now write everything. Also need `startLevel` from map and `clear` → unlock next. I'll now write out the final code in full. Careful with template literals and quotes. For the sprite atlas, I'll write: ```js const SPR = {}; // name -> canvas function makeSprite(rows, pal){ ... } ``` Let me write the sprite definitions as arrays of strings with a shared palette object. Palette normal: ```js const PAL = {K:'#141414', R:'#e52521', S:'#fcb68a', B:'#2038ec', D:'#6b3e1f', W:'#ffffff', Y:'#fbd000', G:'#2ecc40'}; ``` Fire palette: R→'#ffffff' for cap/shirt? In SMW, Fire Mario: white cap+shirt, red overalls, brown... So: fire palette = {R:'#ffffff', B:'#e52521', ...}. But that changes the red used for the cape etc. Fine — I'll use per-sprite palette maps: ```js const PALETTES = { normal: {'K':'#141414','R':'#e52521','S':'#fcb68a','B':'#2038ec','D':'#6b3e1f','W':'#ffffff','Y':'#fbd000'}, fire: {'K':'#141414','R':'#ffffff','S':'#fcb68a','B':'#e52521','D':'#6b3e1f','W':'#ffffff','Y':'#fbd000'}, }; ``` Where `R` is "shirt/cap color" and `B` is "overalls color". Cape Mario uses normal palette + a yellow cape drawn separately. Sprites to build (with both palettes): small: idle, walk1, walk2, walk3, jump, skid, dead, crouch(squash at draw time) big: idle, walk1, walk2, walk3, jump, crouch(squash at draw time), dead Store as: `SPR[palName][name] = canvas`. Then `drawMario(state, pal, x, y, flip, size)` uses scratch canvas for tinting (star). Cape: draw behind player: a yellow shape (polygon) whose angle depends on vx and whether flying/spinning; when spinning (spinT>0), draw a yellow arc around the player. OK. Time to write. Also "spin jump" visual: rotate the player sprite slightly (ctx.rotate) — SMW spin jump rotates Mario. Nice touch: rotate the small sprite while spinning. Let me write the answer. I also need to be careful: `pressed` edge detection — I'll keep `justPressed` set that's cleared each frame after processing. Let me write out the code (final). ```js /* ---------- INPUT ---------- */ const keys = Object.create(null), just = Object.create(null); function setKey(code, down){ if(down && !keys[code]) just[code]=true; keys[code]=down; } addEventListener('keydown', e=>{ if(BLOCK.includes(e.code)) e.preventDefault(); setKey(e.code, true); }); addEventListener('keyup', e=>{ setKey(e.code, false); }); ``` And touch buttons use data-k. ```js function held(...c){ return c.some(k=>keys[k]); } function hit(...c){ return c.some(k=>just[k]); } ``` Now the main update for play: ```js function updatePlay(){ if(hit('KeyP')||hit('Escape')){ state='pause'; sfx('pause'); return; } updatePlayer(); updateEntities(); updateFireballs(); updatePickups(); updateParticles(); updateCamera(); updateTime(); checkGoal(); } ``` Camera update: `cam.x = clamp(cam.x + (target - cam.x)*0.09, 0, maxX)` where target = player center - 96 (a bit left of center) and cam.x never decreases below its own... SMW: camera follows and can move left slightly. I'll allow small left movement but clamp to level bounds and never behind the player's left edge... keep simple lerp. Also `cam.shake` for boss hits/explosions. Time: `timeAcc +=1; if (timeAcc>=24){ timeAcc=0; time--; }` (SMW ~1 unit per 0.4s = 24 frames). Time max 400. Let me write the entity update loop generically: ```js function updateEntities(){ for (let i=entities.length-1;i>=0;i--){ const e=entities[i]; if(e.remove){ entities.splice(i,1); continue; } if(e.spawned===false){ if(e.x < cam.x + VW + 32){ e.spawned=true; } else continue; } e.t++; switch(e.type){ ... } if (e.x < cam.x - 96 && e.vy < 20 && !e.boss) { e.remove = true; } applyGravity(e); moveEntity(e); } } ``` Enemy AI details: - goomba: vx = dir*0.32; turn at wall; if hit ground edge? no. stomp → 'flat' state for 40 frames then remove. - koopa: vx=dir*0.40; turn at edges (check tile below ahead → if none, turn for green). stomp → shell state (vx=0, h smaller, y adjusted). shell: when the player touches and vx≈0 → kick: vx = dir*2.7, 'rolling' state; when player touches a rolling shell that is moving → stop it (vx=0) — SMW behavior. Shell kills enemies it touches (any enemy except those not affected → all enemies are affected). - piranha: state cycle: hidden (t < delay), rising, out (attack), lowering. Moves in y within pipe range. Damages on touch always (SMW: piranha doesn't attack when Mario is directly above it, but keeps hurting otherwise). Fireballs can't kill it (in SMW fireballs don't hurt piranha plants — actually in SMW fireballs don't affect piranha plants). I'll disable fireball kills for piranha. - bullet bill: vx = -1.55 (comes from the right), no gravity, slight wobble; spawned periodically from cannons — simpler: spawn every 90 frames at a fixed x on screen edge at random y if a "spawner" exists? Simpler: generate bullet bill spawners in the level at intervals (entity type 'billSpawn' with timer) — I'll do that in the generator for castle/overworld levels. - chuck: vx=0.28 walking; if |dx| < 90 and timer → charge: vx=dir*2.2, t; when charging, turns at walls; stomping → 'stun' for 90 frames then back to walking. - boo: if player is not facing the boo (or distance < 48 → hide), move toward the player slowly (vx=0.3 toward p.x, vy=0.25 toward p.y); else float in place with bobbing. - bomb: vx=dir*0.42, walks off edges → turns; on stomp/fireball → explode (damage radius 40, kills enemies) → remove. - cheep cheep: swim in a sine path, vx=-0.7 (leftward) + sin vy; can only appear in water themes; damage on contact; fireball killable. - spiny: vx=dir*0.45, stomp → hurts (bounce player away), fireball kills. - thwomp: when the player is under/aligned, falls (vy += 0.5 up to 7), slams with dust, waits 60 frames, rises back up. - monty mole: pops from the ground, throws a rock (small projectile) every ~90 frames, then hides after 200 frames. - boss: as described. - firebar: rotating chain of 5-7 fireballs around a pivot at fixed position; the chain rotates at 0.02 rad/frame; touching → damage. Projectiles: array `shots` with type ('fire','bossfire','rock','boomerang'?) and physics. Fireballs (player): vx = ±2.4, vy=+0.25, bounce: on hitting the ground → vy=-3.2, bounce count; lifetime 240 frames; kill enemies on contact (not piranha, not thwomp? in SMW fireballs can't kill thwomps; fine to allow killing? I'll allow killing everything except piranha and thwomp and boss (boss takes damage though)). Fireball-vs-wall: remove. Boss projectiles: 'bossFire' (gravity-affected arc, 2 px/frame), 'bossBomb' (falls straight down, explodes), and maybe 'bossBounce' — keep2 types. Player damage check: for each enemy with harmful state → if AABB overlap → hurtPlayer() unless invulnerable/star/spin-attack-destroy. Hurt: if star → kill enemy instead. If p.spinT>0 → kill enemy (spin jump). Else if p.capeSpin>0 → kill. Else → damage player. Death: p.dead → sfx, lives--, state='dying' handled in updatePlayer with timer120 frames → if lives<=0 → 'gameover' else 'play' with reloaded level (SMW restarts the level). I'll write `respawn()` = loadLevel(currentLevelIndex) with the same player state (SMW keeps power-up? no — respawn starts as small). OK, writing now for real. Let me produce the code. I'll also add sound: WebAudio simple synth (square/triangle oscillators) for jump, coin, stomp, powerup, fireball, death, 1-up, flag, boss hit, etc. That adds a lot of life. Keep it compact (~40 lines). Let me write the HTML/CSS: ```html

... touch controls ...

Controles: ...

``` Touch controls: two groups (left:◀ ▼ ▶; right: B(Salto) Y(Correr) X(Capa)). Use `touch-action:none` and pointer events. Now writing the final answer. Let me draft the JS in order: 1. Utils (clamp, rng, aabb) 2. Audio 3. Sprites (palette, small/big mario arrays, build atlas) 4. Tiles atlas 5. Level definitions + generator 6. Entities (enemies, pickups, shots, particles) 7. Player 8. Camera/render 9. Screens (title, map, HUD, pause, clear, gameover, ending) 10. Game state machine + main loop Let me write the level generator concretely: ```js function buildLevel(idx){ const def = LEVELS[idx]; const rng = mulberry32(def.seed); const W = def.width, H = ROWS; const grid = new Uint8Array(W*H); const g = (x,y)=> (x<0||x>=W||y<0||y>=H)? (y>=H?TT.GROUND:TT.EMPTY) : grid[y*W+x]; const s = (x,y,t)=>{ if(x>=0&&x=0&&y{for(let j=0;j H+... player falls below the screen → death). Let me define: out of bounds = EMPTY (fall to death). Pits are death (fall below the level → die). Lava tiles at the bottom of pits for castle/water levels. I'll ensure the whole level has ground rows 12-13 except pits, and the player dies when y > H*T + 40. Now let me write the section functions with the theme weights: ```js const THEMES = { overworld: {...palette of bg colors, tiles: [GROUND, GROUND2...]}, underground: {...}, castle: {...}, sky: {...}, water: {...}, ghost: {...}, } ``` Level defs array: I'll write 16 entries: ```js {w:'1-1', world:0, theme:'overworld', width:210, seed:101, boss:false, goal:'flag'}, {w:'1-2', world:0, theme:'underground', width:220, seed:102, goal:'flag'}, {w:'1-3', world:0, theme:'sky', width:215, seed:103}, {w:'1-4', world:0, theme:'castle', width:225, seed:104, boss:'Iggy'}, {w:'2-1', world:1, theme:'overworld', width:215, seed:105}, {w:'2-2', world:1, theme:'water', width:215, seed:106}, {w:'2-3', world:1, theme:'sky', width:220, seed:107}, {w:'2-4', world:1, theme:'castle', width:230, seed:108, boss:'Morton'}, {w:'3-1', world:2, theme:'overworld', width:215, seed:109}, {w:'3-2', world:2, theme:'ghost', width:215, seed:110}, {w:'3-3', world:2, theme:'sky', width:220, seed:111}, {w:'3-4', world:2, theme:'castle', width:230, seed:112, boss:'Wendy'}, {w:'4-1', world:3, theme:'overworld', width:215, seed:113}, {w:'4-2', world:3, theme:'underground', width:220, seed:114}, {w:'4-3', world:3, theme:'sky', width:220, seed:115}, {w:'4-4', world:3, theme:'castle', width:240, seed:116, boss:'Bowser', final:true}, ]; ``` Theme parameters: sky color, ground tile type, brick/stone tile, enemy list, water?, lava?, bg style, music tempo. Enemy generation: place groups at intervals: every ~10-22 tiles, choose an enemy from the theme list. Now writing. I'll try to keep the generator compact but functional. For the flag/goal: at x = W-14, place the pole tiles (FLAGPOLE) from y=4 to y=11 (8 tall), a gate at the base, ground solid. Before that: a staircase up (like SMW's staircase before the flag) — I'll add a 4-8 step staircase ending at the pole. Boss arena for castle levels: at x = W-46 .. W-1, build: floor at y=12-13 (stone), walls at x=W-46 (pillar), ceiling at y=2, lava pit at y=13? Let me design: - The arena floor is at row 12 (stone) from x=A to W-1 where A = W-44, with a lava pit at rows 13 from A to A+10 (so you must jump). Boss spawns at x=A+32. - The goal switch: a red button on the floor at x=W-4 → 'SWITCH' tile (non-solid, on touch after boss defeat → win). Also a door? I'll use the SWITCH. - Before the arena: a small corridor with firebars and thwomps. For non-final boss levels, after defeating the boss, a switch appears and touching it ends the level (with a clear animation). Boss implementation details (entity type 'boss'): - w=56, h=56; sprite drawn with procedural shapes (green shell with spikes, head with horns, orange body, arms, fire breath). - states: 'enter' (walks in from the right), 'fight', 'hurt' (flashing, knockback), 'dying' (falls), 'gone'. - attack patterns: every ~120 frames choose: (a) fireball barrage: 3 fireballs in an arc toward the player (projectile 'bossFire' with gravity), (b) jump toward the player (vy=-5.2, vx toward player), (c) fire breath: 8 small fire particles in a fan, (d) stomp. - movement: walk at 0.45; turn at arena edges; occasional hop. - HP: 6 (final: 12). Stomp → 2 dmg (bounce p.vy=-6), fireball → 1 dmg with cooldown 30 frames, boss takes 30 frames invuln flash. - On death: 'dying' → vy=2 then falls with gravity for 120 frames → remove; then `level.bossDefeated=true` → the switch entity is created & activated → sfx. - Contact damage while the boss is in 'fight' → hurt player. OK, let me write the final code. Also, must remember: `entities` includes pickups, enemies, shells, projectiles, particles are separate array, score popups separate. Let me now actually produce the text. I'll write it as one big HTML file. Regarding the "coins" — SMW coins are gold, spinning (4-frame animation). I'll draw a coin tile with an animated frame (frame counter → width scale). Let me write the render for tiles: iterate over visible tile columns only: `const x0=Math.floor(cam.x/16), x1=Math.ceil((cam.x+VW)/16)` and rows 0..13. Background: theme-based gradient, plus parallax hills/clouds generated from a deterministic hash per level (based on the level seed) — I'll precompute arrays of decoration objects at level build time (hills, clouds, bushes, stalactites, castles, ghosts, water bubbles) and draw with parallax factor 0.5/0.25. Good. Writing now — final answer. Let me write the code in full detail now, section by section, being careful about matching braces. I'll now compose the answer text. Given the enormous size, I'll be disciplined: no redundant comments, but clear section headers. One important detail: the atlas drawing for tiles. Let me define a function `drawTileToAtlas(ctx, t, x)` that draws into the atlas canvas at cell (x,0). Tiles list (index = atlas cell): 0: GROUND_TOP (grass/dirt) 1: GROUND_SIDE (dirt with grass on left?) — for underground, no grass. I'll have2 ground variants per theme? Simpler: theme-specific atlas drawn per level build? That's more work but nicer: build the atlas per theme (overworld, underground/castle stone, sky cloud, water/ice, ghost). Let me do: `buildAtlas(theme)` returns a canvas with the tiles for that theme, built at level load. Cost is trivial (a few ms). Atlas cells (indices): 0 GROUND (solid with a top face) 1 DIRT (below ground) 2 BRICK 3 BRICK_COIN (brick that gives a coin when hit? skip → use BRICK) 4 QUESTION 5 USED 6 STONE (castle block) 7 PIPE_TL, 8 PIPE_TR, 9 PIPE_BL, 10 PIPE_BR 11 SEMI (platform plank) 12 BRIDGE (wood) 13 POLE (flagpole) 14 GATE (goal gate / switch base) 15 SPIKE 16 DOOR 17 SWITCH (red button) 18 BLOCK (breakable-ish stone / used) 19 PIPE_TOP (single, for 1-wide pipes?) — skip20 CLOUD (semi-solid cloud platform for sky theme) 21 THWOMP_TILE? (drawn as an enemy instead) 22 GRASS_BUSH decor (drawn in bg instead) That's enough. Theme variants: for castle → stone/dark palette; sky → cloud/light; ghost → dark green/wood; water → sand/stone; underground → dark blue/brick. OK writing. For the question block: yellow-orange with dark border and a "?" made of white/dark pixels, plus 4 rivets. Used block: brown with rivets. Let me write the atlas draw code: ```js function buildAtlas(theme){ const c = document.createElement('canvas'); c.width=16*ATLAS_N; c.height=16; const g = c.getContext('2d'); g.imageSmoothingEnabled=false; const P = THEME_PAL[theme]; const put=(i,fn)=>{ g.save(); g.translate(i*16,0); fn(g); g.restore(); }; ... return c; } ``` And `tileAtlas` global set on level load; `drawTile(g, t, dx, dy)` uses `g.drawImage(atlas, t*16,0,16,16, dx,dy,16,16)`. Animated tiles (COIN, LAVA, WATER, POLE?, GATE?, SPIKE?) — draw directly with code using a frame counter. Let me define tile constants: ```js const TT = { EMPTY:0, GROUND:1, DIRT:2, BRICK:3, QUESTION:4, USED:5, STONE:6, PIPE_TL:7, PIPE_TR:8, PIPE_BL:9, PIPE_BR:10, SEMI:11, BRIDGE:12, POLE:13, GATE:14, SPIKE:15, DOOR:16, SWITCH:17, COIN:18, LAVA:19, WATER:20, CLOUD:21, BLOCK:22, DONUT:23?}; ``` Atlas indices: map each tile to a cell index in the atlas (not equal to TT, to save cells). I'll use an array `ATLAS_OF = {...}` mapping TT → atlas cell, and animated ones (-1 = draw by code). SOLIDITY function: ```js function tileSolid(t){ return t===TT.GROUND||t===TT.DIRT||t===TT.BRICK||t===TT.QUESTION||t===TT.USED||t===TT.STONE||t===TT.PIPE_TL||t===TT.PIPE_TR||t===TT.PIPE_BL||t===TT.PIPE_BR||t===TT.BRIDGE||t===TT.BLOCK||t===TT.DOOR; } function tileOneWay(t){ return t===TT.SEMI||t===TT.CLOUD||t===TT.BRIDGE? ...} ``` Make SEMI and CLOUD one-way, BRIDGE solid but breakable? Keep BRIDGE solid + breakable on stomp? no. Bumpable (when a block is hit from below): QUESTION, BRICK, USED, BLOCK, STONE. Breakable: BRICK (breaks when big/fire/cape; when small → bump), BLOCK (always breaks for big). Let me write `hitBlock(tx,ty)`: ```js const t = grid... if (t===TT.QUESTION||t===TT.BLOCK){ spawn content: coin/mushroom/flower/feather/star/1up based on `blockContent` map (a per-level Uint8Array parallel to grid); set USED } else if (t===TT.BRICK){ if (big/fire/cape) break → particles + score; else bump } else if (t===TT.STONE) bump (and kill enemies on top) ``` Content per block: store in a parallel array `content` (Uint8Array), default 0 (coin). When a question block is hit, consume content and set a flag so it can't be reused (QUESTION → USED). To ensure the level always has power-ups, the generator sets content for question blocks: first few → mushroom, then random flower/feather/star/coin. Bump animation: I'll add a simple `bumps` array {tx,ty,t} that offsets the drawn tile by a sine for 12 frames. Enemy-on-bump: when bumping, kill any enemy whose center is within the bumped tile's x range and standing on that tile (y≈ tile top) → flatten + score. OK. Writing the final answer NOW. I'll keep the code as tight as I can while remaining complete. Note on `Uint8Array` for content: `content = new Uint8Array(W*H)`. Let me write the generator code: ```js function generate(def){ const W=def.width,H=ROWS; const rng=mulberry32(def.seed); const grid=new Uint8Array(W*H), content=new Uint8Array(W*H); const set=(x,y,t)=>{ if(x<0||x>=W||y<0||y>=H)return; grid[y*W+x]=t; }; const get=(x,y)=>{ if(x<0||x>=W||y<0||y>=H)return TT.EMPTY; return grid[y*W+x]; }; const rect=(x,y,w,h,t)=>{for(let j=0;jrect(x0,y,x1-x0+1,1,t); const th=THEMES[def.theme]; const groundRow = 12; // top ground row // default ground for(let x=0;x 6.5) e.vy=6.5; e.y += e.vy; e.onGround=false; // vertical collision ... } ``` I'll write `collideRect(e, dx, dy)` generic: returns info. Let me write a function `resolve(ent, isPlayer)`: ```js function tileSolidAt(x,y){ const t=getTileAt(Math.floor(x/16),Math.floor(y/16)); return tileSolid(t); } ``` For each ent, after moving x: check the 4 corners? For small entities (14x20), checking the corners of the hitbox at the leading edge is enough: ```js function collideX(ent){ const t=ent; const y0=t.y+2, y1=t.y+t.h-2; const x0=t.x, x1=t.x+t.w; // leading edge const lead = t.vx>0 ? x1 : x0; for(let y=y0;y<=y1;y+=Math.min(8, (y1-y0)||1)){ if(isSolid(lead,y)){ if(t.vx>0) t.x = Math.floor(lead/16)*16 - t.w - 0.01; else t.x = (Math.floor(lead/16)+1)*16 + 0.01; t.vx=0; t.hitWall=true; return true; } } // also check a couple of sample points } ``` The stepping loop with `y+=8` should be fine for entities ≤ 24 tall (3 samples). For the boss (56 tall) use step 10 → 6 samples. OK. Actually better: compute the exact tile range and loop all tiles in the range — robust and simple: ```js function solidBox(x,y,w,h){ const tx0=Math.floor(x/16), tx1=Math.floor((x+w-0.01)/16); const ty0=Math.floor(y/16), ty1=Math.floor((y+h-0.01)/16); for(let ty=ty0;ty<=ty1;ty++) for(let tx=tx0;tx<=tx1;tx++) if(isSolid(tx,ty)) return {tx,ty}; return null; } ``` Then: move x → `const hit = solidBox(x,y,w,h); if(hit){ x = hit.vx>0 ? hit.tx*16 - w : (hit.tx+1)*16; vx=0 }`. For the y-direction similarly, and set onGround when moving down. I'll write a single `moveBody(b, useOneWay)`: ```js function moveBody(b){ b.hitWall=false; // X b.x += b.vx; let h = solidBox(b.x,b.y,b.w,b.h, b.oneWay||false); if(h){ if(b.vx>0) b.x = h.tx*16 - b.w - 0.001; else b.x = (h.tx+1)*16 + 0.001; b.vx=0; b.hitWall=true; } // Y const oldBottom = b.y + b.h; b.y += b.vy; h = solidBox(b.x,b.y,b.w,b.h, b.oneWay||false); b.onGround=false; if(h){ if(b.vy>0){ b.y = h.ty*16 - b.h - 0.001; b.vy=0; b.onGround=true; b.landed=true; } else if(b.vy<0){ b.y = (h.ty+1)*16 + 0.001; b.vy=0; b.hitHead=true; } } // one-way: only collide from above when falling and oldBottom <= ty*16 + 2 if(b.vy>=0 && b.oneWay){ ... } } ``` One-way handling: in solidBox, include SEMI/CLOUD when `b.oneWay` is true AND the entity is falling AND its old bottom is above the tile top. To do this correctly, I'll do the Y collision in two passes: first solid-only, then one-way check separately (checking tiles crossed by the bottom edge only). Simpler: after the Y move, if (b.vy>0 && b.oneWay) check tiles at the row below the feet: if a one-way tile is at the feet row and oldBottom <= tileTop+2 → land. I'll implement that. Good. `isSolid(tx,ty)` includes one-way tiles only when a flag says "collide with one-way" (I'll set `b.solidOneWay = true` always for Y-landing but not for X). For X collisions, ignore SEMI/CLOUD. For Y-up collisions, ignore SEMI/CLOUD. So: `solidBox(x,y,w,h, mode)` where mode ∈ {'full','down','up'}: - 'full': everything solid except one-ways - 'down': solid + one-way - 'up': everything solid except one-ways Good. Now `player.hitHead` → bump the block above (the tile row at the top edge). Time to write. Final answer structure. Let me go. I also want a `render()` that draws: background, tiles, entities (sorted by y for painter's order — keep simple: enemies then player), particles, HUD, and the screen state overlays. Let me write the HUD: SMW-style: "MARIO 000000 x 00 WORLD 1-1 TIME 400" at the top on a black bar? In SMW the HUD is white text over the level without a bar. I'll draw white text with a black outline at the top (using a bitmap-ish font: I'll use `ctx.font = 'bold 8px monospace'` with pixelated scaling — monospace at 8px scaled3x looks acceptable but not authentic. Alternative: draw text with `ctx.font = '8px "Courier New", monospace'` — fine. I'll use a tiny custom pixel font? Too much work. Use `bold 9px monospace` with `textRendering`... I'll just use monospace bold with a shadow — looks decent in the retro frame. Let me write the code! Regarding localStorage: `saveProgress()` storing `{unlocked, best}` with try/catch (in case of sandboxed iframes). Let me write the map rendering: - world map background: a green field with darker patches (procedural via a small noise grid drawn once into an offscreen canvas per map — good idea: build the map background once into `mapCanvas` at level-select time). - roads: dashed white lines connecting nodes. - nodes: circle (brown/gray) with the level number; castle nodes drawn as a small castle sprite. - player icon at the selected node: a 16x16 Mario head (red cap). - HUD text at the top: "SUPER MARIO WORLD — MAPA" + lives + coins + total score + "ELIGE NIVEL". For moving between nodes: arrow left/right (and up/down between worlds? SMW's map is free-form). I'll do a linear path with slight vertical offsets: index0..15, x = 24 + i*14, y = 96 + sin-ish offsets and castle levels raised. Moving left/right with wrapping to the world rows? Simplest: the path snakes: world 0: nodes 0-3 going right (y=100), world 1: nodes 4-7 going right but on a second row (y=76), world 2: third row (y=52)... that would be a long horizontal path — with 16 nodes at 14px spacing = 224px wide, which fits in 256px width. Rows: 4 worlds × 4 nodes, each row y = 40 + w*36, x = 24 + i*22 → width 24+14*22=332 > 256. Hmm. 256 wide: spacing 14 → 4 nodes per row: x=40,70,100,130 with a leftward arrow for the next world (like a switchback path: world 0 right→, world 1 ←, world 2 →, world 3 ←). That's authentic-ish (SMW maps do have switchback paths). Let me do: x positions: right-going worlds: 30,66,102,138 ; left-going: 138,102,66,30 hmm, better: each row is centered-ish, rows y = 44, 84, 124, 164; world 0 & 2 go right (x=34+i*28 → 34,62,90,118) hmm too narrow on the left. Let me use:4 rows (worlds), y = 42 + w*40, x = 30 + i*30 (i=0..3 → 30,60,90,120) for right-going worlds and x = 130 - i*30 (130,100,70,40) for left-going. Hmm, but then the rows are offset — it looks like a switchback with connecting vertical segments at the ends. Good: right-going rows start at the left end and end at the right end; the next (left-going) row starts at the right end (x=130) and goes left to x=40, with a vertical connection from (138→120?) Let me simplify: ``` x positions: right rows: 34, 66, 98, 130 (y = 42 + w*40) left rows: 130, 98, 66, 34 (same y) ``` And draw the path as a polyline through all nodes in order, plus vertical connectors at the ends (x=130 between row w (right) and row w+1 (left)). Since node i and i+1 are adjacent on the same row, that works, and the transition between rows is at x=130 → vertical connector. Map y range: 42, 82, 122, 162 → fits in 224 height with room for the HUD at the top. And the map background: green land with a few mountains/water at the bottom. Fine. Also add "secret" nodes? Skip. OK, writing the answer now. For real this time. I'll produce the code and mentally verify the main flows. Let me think about how the player is created in `loadLevel`: ```js player = {x:32, y:12*16-14, w:12, h:14, vx:0, vy:0, onGround:false, face:1, state:'small', ...}; ``` `resizePlayer()`: adjust w/h and y so the feet stay. `powerUp(kind)`: 'mushroom' → big (if small) or score+1000?; 'flower' → fire; 'feather' → cape; 'star' → star timer; '1up' → lives+1. Now, writing. Also `spinT` for spin jump: 20 frames of rotation, and `capeSpinT`: 32 frames (spin cape attack). Let me make sure the cape is implemented at a basic level: - cape state: player has a yellow cape drawn behind;- press cape button (X/Shift/J) while grounded → capeSpinT=36 (hitbox around the player, kills enemies, breaks bricks); - press cape button while airborne → spin cape (same); - while flying (flying=true, from launching) → gravity reduced, and pressing the jump button keeps altitude; spin cape available; SMW flight needs run > 2.4 and holding down while in the air... I'll implement: while airborne with cape and horizontal speed > 2.4, pressing the cape button or down → flying=true (with a flash) → while flying, vy is affected by a lift force (up to 0.35 upward when jump held), max upward speed limited; after ~2s, flying ends (gravity returns). - Also a "super cape" spin that lifts Mario (press jump while cape spinning on the ground → small hop with lift). Keep it simple: I'll implement flying + spin + a lift jump when spinning. Also the cape can flip enemies when spinning — implemented via the spin hitbox. OK. Writing the final answer now — no more planning. Let me estimate the code: ~1400-1900 lines. Let's go. Additional: I need `LEVELS` to include `boss` names for castles and `final` for Bowser. Let me write out the sprite arrays now (small): ```js const SMALL = { idle:[ "................", ".....RRRRR......", "....RRRRRRRR....", "....DDSSKS......", "...DDDSSSKS.....", "...DDSSSSSSS....", "....SSSSSSS.....", "...RRRBBBRRR....", "..RRRRBBBRRRR...", ".RRRRRBBBBBRRR..", ".WRRRBBBBBRRRW..", "..WBBBBBBBBBW...", "...BBBBBBBBB....", "..KKKK...KKKK...", ".KKKK.....KKKK..", "................" ], walk1:[...], walk2:[...], jump:[...], crouch:[...], // 12 tall dead:[...] } ``` Let me write walk1/walk2 with distinct legs and slightly different arms: walk1: ``` "................", ".....RRRRR......", "....RRRRRRRR....", "....DDSSKS......", "...DDDSSSKS.....", "...DDSSSSSSS....", "....SSSSSSS.....", "...RRRBBBRRR....", "..RRRRBBBRRRR...", ".RRRRRBBBBBRRR..", "..WRRRBBBBBRRW..", "...WBBBBBBBBW...", "...BBBBBBBBBB...", "..KKKK...KKKK...", ".KKKK.....KKKK..", "................" ``` walk2 (legs together / mid-stride): ``` ...same top... "..KKKK...KKKK...", ".KKKK.....KKKK..", (walk1: legs apart) walk2: "..KKKKKKKKKK....", (legs together) ".KKKKKKKKKKK...", ``` Fine. jump: ``` "................", ".....RRRRR......", "....RRRRRRRR....", "....DDSSKS......", "...DDDSSSKS.....", "...DDSSSSSSS....", "....SSSSSSS.....", "W.RRRBBBRRR.....", // arm up left "WWRRRBBBRRRWWW..", ".RRRRBBBBBRRRR..", ".WRRBBBBBBBRRW..", "..WBBBBBBBBBW...", "...BBBBBBBBBB...", "..KKKK..KKKK....", ".KKKK....KKKK...", "................" ``` crouch (12 rows, will be drawn scaled): ``` "................", "................", ".....RRRRRR.....", "....RRRRRRRR....", "....DDSSKS......", "...DDDSSSKS.....", "...DDSSSSSSS....", "....SSSSSSS.....", "..RRRRBBBRRRR...", ".WRRRBBBBBRRRW..", "..WBBBBBBBBBW...", "...KKKKKKKKKK...", "..KKKKKKKKKKK...", "................", "................", "................" ``` Good — I'll draw crouch with y offset +6. dead (face up, arms out): ``` "................", "................", "................", "....SSSSSSS.....", "...SSSSSSSSS....", "..WWWWWWWWWW....", // eyes closed / white "...SSSSSSSSS....", "...RRRBBBRRR....", "..RRRRBBBRRRR...", ".WRRRBBBBBRRRW..", "..WBBBBBBBBBW...", "...BBBBBBBBB....", "..KKKK...KKKK...", ".KKKK.....KKKK..", "................", "................" ``` Big Mario (16x24): as drafted above. Let me write it fully: ``` "................", "................", "....RRRRRR......", "...RRRRRRRRRR...", "...DDDDSSSSD....", "..DDDDSSSSSDK...", "..DDDDSSSSSSS...", "...DDSSSSSSS....", "....SSSSSSS.....", "...RRRBBBRRR....", "..RRRRRBBBRRRR..", ".RRRRRBBBBBRRRR.", ".WWRRRBBBBBRRRW.", "WW.WRRBBBBBRW.WW", "....RBBBBBBBR...", "...BBBBBBBBBBB..", "..BBBBBBBBBBBB..", "..BBBB....BBBB..", "..BBBB....BBBB..", "..BBBB....BBBB..", "..KKKK....KKKK..", ".KKKKK....KKKKK.", ".KKKKK....KKKKK.", "................" ``` Hmm rows 3-8 look off (the head). Let me redo the head: row2: `....RRRRRR......` row3: `...RRRRRRRRRR...` row4: `...DDDDSSSSS....` (hair across the top-left, skin) row5: `..DDDDSSSSSSK...` hmm the eye should be `K` at the right Let me: row4: `...DDDDSSSSDK...`? That puts the eye too high. Standard: the cap covers rows 2-3, the face rows 4-8 with hair on the left and the eye on the right. row4: `...DDDDSSSSS....` row5: `..DDDDSSSSSSK...` → hmm K at index 14 = eye, too far right (face width ~10). Face spans cols 3-12 → the eye at col 11: `..DDDDSSSSSK....` (2 dots + 4 D + 5 S + K + 4 dots = 16). ✓ row6: `..DDDDSSSSSSS...` (2+4+8+2 = 16) ✓ row7: `...DDSSSSSSS....` (3+2+7+4=16) ✓ row8: `....SSSSSSS.....` (4+7+5=16) ✓ Then body rows 9-14, legs 15-19, shoes 20-22, row 23 empty. body: row9: `...RRRBBBRRR....` (3+3+3+3+4=16) ✓ row10: `..RRRRRBBBRRRR..` (2+5+3+4+2=16) ✓ row11: `.RRRRRBBBBBRRRR.` (1+5+5+4+1=16) ✓ row12: `.WWRRRBBBBBRRRW.` (1+2+3+5+4+1=16) ✓ row13: `WW.WRRBBBBBRW.WW` (2+1+1+2+1+5+1+1+1+2=17) hmm — let me count: `WW` 2, `.`1, `W` 1, `RR` 2, `BBBBB` 5, `R` 1, `W` 1, `.` 1, `WW` 2 → 2+1+1+2+5+1+1+1+2 = 16 ✓ (I miscounted). Let me write it as `WW.WRRBBBBBRW.WW` — count characters: W,W,.,W,R,R,B,B,B,B,B,R,W,.,W,W = 16 ✓ row14: `....RBBBBBBBR...` (4+1+7+1+3=16) ✓ row15: `...BBBBBBBBBBB..` (3+11+2=16) ✓ row16: `..BBBBBBBBBBBB..` (2+12+2=16) ✓ legs: rows17-19: `..BBBB....BBBB..` (2+4+4+4+2=16) ✓ shoes rows20-22: `..KKKK....KKKK..` ✓, `.KKKKK....KKKKK.` ✓, `.KKKKK....KKKKK.` ✓ row23: empty ✓ Big walk1: change the legs to straddle: rows17-19: `..BBBB...BBBB...`? Let me make walk1 have the left leg forward: row17: `..BBBBB...BBBB..` (2+5+3+4+2=16) ✓ row18: `..BBBB.....BBBB.` (2+4+5+4+1=16) ✓ row19: `...BBB.....BBBB.` hmm, keep simple: walk1 legs: ``` "..BBBBB...BBBB..", "..BBBB.....BBBB.", ".KKKKK.....KKKK.", ``` walk2 legs: ``` "..BBBB..BBBBB...", "..BBBB....BBBB..", ".KKKK......KKKK.", ``` Fine. Big jump: arms raised: row11: `.WWRRRBBBBBRRWW.` hmm; let me: ``` "...RRRBBBRRR....", ".WWRRRBBBBBRRWW.", "WWWW.RRBBBBBRWWW", -- too messy ``` Simpler jump for big: row9: `W.RRRBBBRRR.....` hmm. Let me define big jump: ``` "................", "................", "....RRRRRR......", "...RRRRRRRRRR...", "...DDDDSSSSS....", "..DDDDSSSSSSK...", "..DDDDSSSSSSS...", "...DDSSSSSSS....", "....SSSSSSS.....", "WRRR.RBBBRRRRW..", "WWRRR.BBBBRRRWWW", ".WWRRRBBBBBRRWW.", "...RRRBBBBBRR...", "...BBBBBBBBBBB..", "..BBBBBBBBBBBB..", "..BBBB....BBBB..", "..BBBB....BBBB..", "..BBBB....BBBB..", "..KKKK....KKKK..", ".KKKKK....KKKKK.", "................", "................", "................", "................" ``` Good enough (rows9-11 arms up, fewer body rows). It'll look like Mario with arms up. ✓ Big crouch: draw the idle big sprite scaled to ~60% height (drawImage with sy=0..19 → height 24*0.62). Fine. OK writing the answer NOW. For the fireball drawing, particles, etc., I'll use simple circles/arcs. Let me write the audio synth: ```js let AC=null; function initAudio(){ if(AC) return; try{ AC=new (window.AudioContext||window.webkitAudioContext)(); }catch(e){} } function beep(freq, dur, type='square', vol=0.08, slide=0, delay=0){ if(!AC||muted) return; const t=AC.currentTime+delay; const o=AC.createOscillator(), g=AC.createGain(); o.type=type; o.frequency.setValueAtTime(freq,t); if(slide) o.frequency.exponentialRampToValueAtTime(Math.max(30,freq+slide), t+dur); g.gain.setValueAtTime(vol,t); g.gain.exponentialRampToValueAtTime(0.0001,t+dur); o.connect(g); g.connect(AC.destination); o.start(t); o.stop(t+dur+0.02); } const sfx = { jump:()=>beep(420,0.16,'square',0.07,220), bigjump:()=>beep(360,0.2,'square',0.07,300), coin:()=>{beep(988,0.07,'square',0.06); beep(1319,0.12,'square',0.06,0,0.07);}, stomp:()=>beep(300,0.12,'square',0.08,-180), bump:()=>beep(180,0.1,'square',0.07,-80), power:()=>{for(let i=0;i<4;i++) beep(400+i*180,0.09,'square',0.06,0,i*0.06);}, fire:()=>beep(700,0.12,'sawtooth',0.05,-400), hurt:()=>{beep(300,0.3,'sawtooth',0.07,-250);}, die:()=>{beep(500,0.5,'triangle',0.08,-400);}, oneup:()=>{[523,659,784,1047].forEach((f,i)=>beep(f,0.12,'square',0.07,0,i*0.09));}, flag:()=>{[523,659,784,1047,1319].forEach((f,i)=>beep(f,0.15,'square',0.07,0,i*0.12));}, boss:()=>beep(90,0.4,'sawtooth',0.08,-40), clear:()=>{[392,523,659,784,1047,1319].forEach((f,i)=>beep(f,0.2,'square',0.07,0,i*0.13));}, select:()=>beep(660,0.08,'square',0.05), cape:()=>beep(880,0.14,'sawtooth',0.05,-300), }; ``` Note: `muted` toggle with M key. Alright — final write-up. Let me be careful that `just` is cleared after each update frame. I'll write `update()` to handle all states, and clear `just` at the end of update (after processing). Let me handle the `dying` state: `state='play'` but `player.dead` → I'll implement a `phase` within play: 'normal'|'dying'|'winning'|'timeup'. Simpler: global `gameState` values: 'title','map','play','pause','clear','gameover','ending','timeup'. Within 'play', `player.dead` → update only the dead player and a timer. OK go. Writing the answer. Also: "1-UP" popup text entities. I'll now write the whole thing out. Final check on level goal types: 'flag' (flagpole) or 'boss' (switch). Castle levels have the boss + switch; other levels have the flag. Let me write `checkGoal()`: - For flag: if !player.win && overlap with the POLE column (x range) → start win sequence. - For boss: if `level.bossDefeated` → the switch is active → touching it → win. Win sequence: `phase='clear'`, `clearTimer`, player walks right / slides, bonus score counted, then `gameState='clear'` → show the "COURSE CLEAR" panel → after ~2.5s (or Enter) → map, unlocking the next level. OK writing! One more: `timeup` → die by time (SMW: the timer reaching 0 kills you). I'll do that. Writing the answer now, for real. I'll include a short intro in Spanish (the user writes in Spanish) with the disclaimer that it's a fan-made recreation in HTML5 (can't embed the actual ROM), and instructions. # SUPER MARIO WORLD — Motor recreado 100 % en HTML5 A continuación tienes **un juego completo y jugable** en un único archivo HTML: motor propio (canvas + JS puro), física estilo SMW, power-ups (Hongos, Flor de Fuego, Pluma de Capa, Estrella, 1-UP), enemigos (Goomba, Koopa, Koopa Rojo, Casco, Planta Piranha, Bullet Bill, Chargin' Chuck, Boo, Bob-omb, Cheep-Cheep, Spiny, Thwomp, Monty Mole), fuego, capa con vuelo, pistones P?, jefes (Iggy, Morton, Wendy, Bowser Jr. y **Bowser final**), **16 niveles** (1-1 → 4-4), mapa del mundo estilo SMW, pantallas de título/pausa/clear/game over, sonido sintetizado y guardado de progreso. > Nota: no puedo incrustar la ROM original (es material protegido por copyright), así que el motor fue programado desde cero para imitar fielmente la jugabilidad y el estilo del SNES. ```html SUPER MARIO WORLD — Fan Engine (HTML5)

★ SUPER MARIO WORLD ★
RECREACIÓN 100 % HTML5 · 16 NIVELES · 5 JESES

MOVIMIENTO
← → / A D ↑/W salto

SALTO
Z Espacio K (mantén para saltar más alto)

CORRER / SPIN
X Shift J — con capa: ataque giratorio

CAZA / VOLAR
V L Alt — gira la capa o despegas al correr

AGACHARSE
↓ / S

MENÚS
Enter aceptar P/Esc pausa M mute

⚠ IMPORTANTE:

La ROM original de Super Mario World no está incrustada (derechos de Nintendo). Esto es un motor propio escrito en JavaScript que imita la jugabilidad del SNES: física de impulso y salto variable, correr con inercia, power-ups, monedas, bloques, tuberías, capa, fuego, estrellas, enemigos, jefes con ataques de fuego y salto, puerta/goal y mapa de mundo. Guarda tu progreso automáticamente en tu navegador.

Creado para uso educativo y demostrativo · Fan-made · No afiliado a Nintendo · Rendimiento óptimo en Chrome / Edge / Safari / Firefox

★ SUPER MARIO WORLD ★RECREACIÓN 100 % HTML5 · 16 NIVELES · 5 JESES

★ SUPER MARIO WORLD ★
RECREACIÓN 100 % HTML5 · 16 NIVELES · 5 JESES

web gaming test