worked on discord integration and fixed some stats issues Hopefully fixed so statistics in localstorage are synced to server and on new logins and stuff

changes to map and map proxy

Added XPBar to MP and some tiny bit things more

Worked more on getting the playing state in MP to work.
fixes POI markers.
And changed the Map component a bit to fit both SP and MP, very temp UI

Added a reverse proxy to avoid cors in rust (needs redis cache thingy) and more detailed readme for setting it up. also made the minecraft map always lowres

for the rust lovers:
I've made an image converter made in rust and now using webp instead of png
development of map logic is still ongoing

laying out the barebone map core logic

Initialized setup like config files and stuff
Made some readmes

refactor abilities and add tests and docs
resolve coflicts
fix: refactor AIController

here is a short video demo

fix: resolve conflicts
fix: return correct ENDPOINT
fix: resolve conflicts
fix: unnecessary movements on multiplayer
Add dynamic types for heroes
Code clean uo
Code clean up
Merge branch 'main' into update-multiplayer-logic
Update attacking logic
fix the number of available lives
Merge branch 'main' into update-multiplayer-logic
Update multiplayer logic
fix hero sound and some fixes
fix: able to change direction without moving
add exclude start and end coords for generate enemies
add enemies and refactoring conditions layers
fix assets paths
remove routing
add origin to server
resolve conflicts
add origin to server
add base href

Update cd.yml
Update cd.yml
add CD config
set env port
changes to deploy
return correct port
replace image for torch enemy
CI fixes

replace image for torch enemy
return correct port
changes to deploy
fix: boundaries coords
fix: resolve conflicts

Implemented collision checks during attacks, enabling accurate hit detection. Added minimum frame time to ensure consistent performance across systems. Organized resources into proper rendering layers. Removed leftover debug code and improved variable naming. Added logic for spending resources (e.g., for abilities or items) and introduced volume controls to support audio settings.

add CI
fix: remove debug; change names
add resources to layers
add levelToPlain to actions
add volume set
feat: force enemy to attack when hero is in front of him

Cleaned up some code. Introduced a minimum frame time to stabilize game speed across devices. Added resources to the appropriate rendering layers for better visual organization. Completed health bar logic.

Resolved merge conflicts. Applied several small fixes and general code cleanup for better maintainability. Also began implementing attack mechanics for future combat interactions.

today i've focused on level integration, adding a core process for changing levels. This led me to create new environments, including a sand level and adding more variety with new layer scenarios. To make the world feel more alive, I added some decoration like sheeps and a foam layer for water effects so the map would feel more populated

the core gameplay mechanics got improved so that now a player have the ability to collect resources like coins and logs, i've fixed some bugs with their positioning. i also done minor tweaks on character movement, fixing the sprite animations and dialing the character's speed.

also i worked on fixing the collision. I implemented a basic collision check and then refined it, fixing the hero's collision area specifically. done some refactoring, like moving the checkCollision method into a more appropriate class to clean up the code.

On the architectural side, I introduced observables to the stores and refactored the rendering for resources to improve performance. Sounds and a mute button have also been added. Finally, some UI elements were updated, including the main menu, the hero's resource bar, and the next-level menu.

initialized setup, added new map layers like foam, sand, and terrain to enhance the game world. The main menu and hero menu are now in place, with support for multiple game modes.

Character movement feels smoother thanks to improved collision detection and speed adjustments. I also expanded the abilities system to include attacks, animations, and tile interactions. Behind the scenes, I cleaned up the code, optimized rendering, and refactored key systems for better performance.

so apparently yesterdays devlog did not post so here it is again
ambient Occlusion
Added vertex-based ambient occlusion for voxel faces. Darkens corners and edges where faces meet by checking neighboring voxels during mesh generation. Simple but makes blocks actually feel like they have volume instead of looking flat.
Voxel Interaction & Data Packing
Rewrote voxel data packing and interaction handling. Switched from storing full voxel objects to bit-packed integers for common properties. Block placement/breaking is much snappier now and memory usage dropped by ~60% for chunk data.
Code Cleanup
Added proper comments to files and refactored messy functions around world generation and chunk management. Actually readable now.
Shader Work
Commented the shaders and cleaned up the water fragment shader - removed redundant calculations and improved logic flow. Added fog support for water rendering so distant water fades properly instead of cutting off abruptly. Uses the same depth-based calculation as terrain fog.

Fixed a bunch of annoying stats issues that were bugging players. The default stats weren't generating properly and cookies were being weird, so I moved all the cookie handling into the base layer to keep things consistent. Also cleaned up the stats system by removing some overloaded functionality that was causing conflicts.

Added some satisfying sound effects to make the game feel more responsive when you're solving puzzles. Nothing fancy, just good audio feedback that makes successful crafts feel rewarding.

Had to migrate the database to a new schema, which was a bit of a pain but needed to happen. The old structure was getting messy and the stats system needed a fresh start to work properly.

Everything's running much more reliably now. The whole update was focused is making the game feel more polished and stable rather than adding flashy new features, but sometimes that's exactly what you need.
here is a short gameplay

World Generation
Implemented core world generation systems that handle the procedural creation of voxel terrain. This likely includes terrain height maps, biome generation, and the foundational structure for creating explorable voxel worlds.
Voxel Face Optimization
Added optimization techniques for individual voxel faces. This is crucial for performance in voxel engines, as it reduces the number of faces that need to be rendered by culling hidden or unnecessary faces between adjacent voxels.
Chunk Face Optimization
Implemented chunk-level face optimization, which works at a higher level than individual voxels. This system optimizes entire chunks of voxels together, further improving rendering performance by reducing draw calls and managing larger sections of the world more efficiently.

made it.

With a functional prototype established, development focused on refining the user experience and hardening the project's technical foundation.

Core Experience Enhancements:
Key updates were made to improve gameplay and accessibility. A high-contrast mode was implemented to enhance visual clarity , which was later refined to be more consistent with established accessibility standards. A recurring technical challenge with timezones was addressed; after several attempts , a stable fix was implemented to convert UTC dates to the player's local time, ensuring the puzzle date was always listed correctly.

Gameplay Integrity and Polish:
Subtle but significant bugs affecting game fairness were squashed.

A critical exploit was patched that allowed players to submit an empty crafting grid without penalty. The bug was caused by the game state not resetting after a valid guess , and was fixed by adding a new validity check before processing a craft.

The system for tracking and displaying the maximum guess limit was corrected for better player feedback.

The end-of-game message for a loss was updated to display the specific recipe name, not just the item name, for better clarity.

Backend and Codebase Maturation:
Significant effort was dedicated to improving the project's stability and long-term health. The database backend was made more robust by ensuring connections and cursors were explicitly closed to prevent resource leaks. Extraneous debugging code, such as

console.log statements, was systematically removed. Finally, the project's major dependencies, including Next.js, were updated to keep the technology stack modern and secure.

This log outlines the creation of Mineguessr, a Minecraft-inspired puzzle game. It highlights the key technical systems, design strategies, and architectural decisions that shaped the final product.
1. Foundation: Core Architecture and Assets

The initial phase focused on planning and establishing a stable foundation. To ensure accuracy with Minecraft mechanics, detailed to-do lists and reference documents were created.

Visual Identity:
The interface adopted Minecraftia fonts and a modified workshop template to replicate Minecraft’s visual language, enhancing player recognition and immersion.

Asset Pipeline:
A structured system was developed to manage textures and UI elements. Official Minecraft databases were used to ensure mechanical accuracy and visual consistency.
2. Interface: Crafting Grid System

Slot Interaction:
The main mechanic centers on a 3x3 crafting grid, enabling drag-and-drop item placement. Mouse events are precisely handled to mimic Minecraft’s interaction style.

State Management:
Each slot tracks its own state using UUIDs, preventing duplication and supporting consistent gameplay.

Responsive Feedback:
Hover states and slot highlights deliver immediate visual feedback, creating a smooth and intuitive user experience.
3. Gameplay Logic: Recipes and Validation

Recipe Sanitization:
A custom engine formats and filters raw recipe data, handling exceptions like shapeless recipes and alternate ingredients.

Feedback System:
Color-coded hints guide players—green for correct item and position, orange for correct item in the wrong spot—mirroring Wordle-style mechanics.

Puzzle Generation:
A random recipe selector ensures daily puzzles are solvable and appropriately challenging.
4. Enhancements: Audio and Performance

Sound Integration:
Authentic Minecraft sound effects are used for interactions, with adjustable volume and user preferences.

Mobile Adaptation:
The interface scales for touch devices and different screen sizes while maintaining visual fidelity.

Optimization:
Efficient cursor tracking and event handling prevent lag during extended sessions.
5. User Systems: Progress and Sharing

Statistics Tracking:
Local stats monitor win rates, average attempts, and streaks, giving players insight into their progress.

Social Sharing:
Emoji-based results allow players to share outcomes without revealing solutions, inspired by Wordle’s viral format.

Popups and Modals:
Result screens, stats, and help content appear in themed modals that match the game’s visual identity.

today i've done changes to the game's structure to support a much more robust multiplayer experience.

4-Player Support: The game now supports up to 4 players.

    Added graphics assets for Player 3 and Player 4.

    The server now manages an array of players instead of fixed player1, player2 slots.

    Added spawn points for all four players.

    The in-game UI now displays the status for all connected players.

Nickname Feature:

    Players are now required to enter a nickname before they can create or join a game.

    Nicknames are displayed in the lobby and in-game.

Game Lobby System:

    The player who creates a game is now the "host".

    A new lobby screen shows all connected players and their nicknames.

    The host has a "Start Game" button, which is disabled until at least two players are in the lobby.

    Other players see a "Waiting for host..." message.

    Once the game starts, the room is locked, and no new players can join.

Click-to-Copy Game Code:

    In the lobby, a "Copy" button has been added next to the game code, allowing the host to easily share it.

Rematch System:

    At the end of a game, a "Play Again" button appears for all players.

    Players have 30 seconds to vote for a rematch. The UI shows the current vote count.

    If all players in the room vote "Play Again" within the time limit, the game immediately restarts in the same room with the same players.

    If the timer runs out and not everyone has voted, the room is closed.

Backend Refactoring:

    The server.js code was significantly refactored. The games object now holds a more complex state, including a list of clients, player data, game status (waiting, active, finished), and rematch information.

    Client identification is now handled with a unique ID (clientId) assigned on connection.

    Broadcasting messages to all players in a specific game room is now more streamlined.

    Improved handling for player disconnections in both the lobby and active game states.

Feature Change: Bomb Placement Mechanics

Removed Per-Player Bomb Limit: The previous limitation where each player could only have a specific number of bombs active on the map at one time (i.e., bombsMax) has been removed.

Implemented "One Bomb Per Square": Players can now place as many bombs as they wish, with the only restriction being that each bomb must be on an empty square. The existing game logic already prevents placing a bomb on a tile occupied by a wall, a crate, or another bomb, so this change was made by simply removing the old bombsMax check in server.js.

This change encourages a more dynamic and potentially chaotic style of play, where players can create long chains of explosions or strategically block off larger areas of the map.

Mobile Landscape Layout with Side Color Pickers
HTML Changes:
The original #color-pickers div was renamed to #color-pickers-desktop.
Two new divs, #p1-color-picker-mobile and #p2-color-picker-mobile, were added to the main #game-container.

A new wrapper, #game-board-container, was introduced to surround the #game-board. This helps manage the flexbox layout in landscape mode.

CSS Changes:
A @media query was created to target landscape orientations on devices with a max-height of 500px (a common breakpoint for phones).
Inside the media query:

game-container was changed to flex-direction: row.

The #color-pickers-desktop is hidden with display: none;.

p1-color-picker-mobile and #p2-color-picker-mobile are made visible using display: flex; and styled to be vertical columns on either side of the game board.

The color buttons (.color-btn) within the mobile pickers were made slightly smaller to fit the vertical layout.

JavaScript Changes:

The createColorPickers function was updated to populate all three picker containers (desktop, P1 mobile, P2 mobile) with color buttons. This ensures the correct pickers are ready, regardless of the orientation.
2. Grayed-Out Inactive Player's Picker
Goal: When it's one player's turn, the opponent's color picker on mobile should be visually disabled (grayed out).

Todays Devlog is on Game.js

Core Architecture
ImageGame Class
Single class handling all game logic with these key properties:

attempts: Remaining guesses (default: 6)
history: Previous attempts with similarity scores
imageProcessor: Handles image comparison logic
targetImage: The album cover to guess

Key Features
1. Theme System

Auto-detects system dark/light mode preference
Persists user choice in localStorage
Toggle button for manual switching

1. Game Flow

Initialize: Fetches target image from api/images.php
Search: Debounced album search (1s delay) via api/search.php
Compare: Uses ImageProcessor to calculate similarity percentage
Update: Tracks attempts, history, and reveals more of target image
End Game: Modal with full reveal and Spotify embed

1. Search System

Real-time search with 1-second debounce
Shows up to 6 results with cover, album name, and artist
Click to select for comparison

1. Image Comparison

Compares selected album with target using ImageProcessor
Calculates similarity percentage
Progressively reveals target image based on previous guesses
Win condition: ≥99.9% similarity

1. Visual Feedback

History Panel: Shows previous attempts with similarity scores
Progressive Reveal: showMatchingAreas() reveals more of target
End Game Modal: Full image reveal + Spotify player

Technical Details

Uses proxy for external images (proxy.php)
Async/await for API calls
Error handling throughout
Canvas-based image processing
Responsive UI with search results and history

todays deploys attempt been pretty unsuccessful and i am in shambles

How the Image Processor Works

The imageProcessor.js file is the core of the visual mechanics in the Guess the Album game. Its main job is to handle everything related to the images: loading them, comparing them, and displaying the results on the HTML5 canvas. Here’s a breakdown of its key functionalities.
1. Initialization and Canvas Setup

When a new ImageProcessor is created, it takes the canvas element as an argument. The constructor gets the 2D rendering context (ctx) of the canvas, which is the object used to draw on it.

The setupCanvas method is called immediately. It ensures the canvas resolution matches its display size. This is a crucial step to prevent distorted or blurry drawings. It measures the size of the canvas's parent container and sets the canvas's width and height attributes to match.
2. Loading Images
today's devlog is about the image processor:

The loadImage method is an asynchronous function responsible for loading an image from a given URL. A Promise is used to handle the asynchronous nature of image loading.

A key feature here is the use of a proxy (./proxy.php?url=...). Web browsers have a security feature called Cross-Origin Resource Sharing (CORS) that prevents a web page from making requests to a different domain than the one that served the page. Since album covers are hosted on Spotify's servers (a different domain), a direct request from the browser would be blocked. The proxy acts as a middleman: the browser requests the image from our own server via the proxy, which then fetches the image from the external URL and sends it back to the browser.

Once the image is loaded, it's scaled down to fit within the canvas dimensions while maintaining its aspect ratio. This is done by drawing the loaded image onto a temporary, off-screen canvas at the new, smaller size. This scaled canvas is what gets used for comparisons, ensuring that we are always comparing images of the same dimensions.
3. Comparing Images and Calculating Similarity

The compareImages method is where the core game logic happens. It takes the URLs of the target image and the user's selected image. It loads both images using the loadImage method.

After loading, it draws each image onto the canvas and gets the raw pixel data for each one using ctx.getImageData(). This function returns an object containing an array of color values for every pixel in the specified area of the canvas.

The calculateSimilarity method then iterates through the pixel data of both images. For each pixel, it compares the red, green, and blue (RGB) color values. If the difference between the color channels for a pixel in the target image and the corresponding pixel in the selected image is within a certain similarityThreshold (defined in data.js), the pixels are considered a match.

The final similarity score is the percentage of matching pixels out of the total number of pixels.
4. Revealing Matching Areas

The showMatchingAreas method is responsible for the visual feedback after each guess. It shows the player which parts of their guessed album cover match the target.

It keeps track of all correctly guessed pixels in a Set called matchingPixels. For each guess, it compares the selected image with the target image. If a pixel matches (and hasn't been matched before), its color data is copied from the target image to a new ImageData object, and its index is added to the matchingPixels set.

For subsequent guesses, it first draws all the previously matched pixels. Then, it processes the new guess, adding any new matches. The final result is an image composed of all the correctly guessed parts from all previous attempts, with the rest of the canvas remaining transparent. This creates the effect of the target image being gradually revealed with each correct guess.
5. Resetting the Canvas

The reset method is a utility function to clear the canvas and reset the matchingPixels set. This is used when starting a new game to ensure no data from the previous game is carried over.

Refined User Interface: The start modal was updated to be more dynamic. Instead of having the code input sandwiched between the 'start game' and 'join game' buttons, the start modal now displays only 'start game' and 'join game' button, with the code input shown after 'join game' button being selected, this provides a neater ui to the players at the start of the match.

This log details the switch to a client-server model for online play and the definitive fix for the player stuck on bomb bug.

1. The Client-Server Architecture

The game now operates on a true online model, essential for multiplayer gameplay.

The Server (Authoritative): A Node.js application now acts as the single source of truth. It is "authoritative" because it alone has the power to decide the state of the game. It handles:

    Game State Management: Tracking the positions of all players, bombs, and explosions. It also holds the master copy of the game map.

    Physics and Logic: The server runs the main gameLoop. It calculates all movement, bomb timers, explosion paths, and collision detection.

    Player Input: It receives simple "key pressed" or "bomb placed" messages from clients but doesn't trust them to move themselves. It uses these inputs to update the player's state in the next server tick.

The Client (Dumb Renderer): Your browser is now a "dumb" client. Its only jobs are:

    Sending Input: Capturing your keyboard presses (WASD, Spacebar, etc.) and immediately sending them to the server.

    Receiving State: Getting a complete snapshot of the game state from the server multiple times per second.

    Rendering: Drawing the players, bombs, and map exactly as the server describes in the latest snapshot. It performs no game logic of its own.

This model prevents cheating (a client can't tell the server I'm invincible!) and ensures all players have a perfectly synchronized view of the game.
2. The Stuck on Bomb Bug: Solved

The previous attempts to fix this were on the client, but the real solution lies in refining the server's authoritative logic.

The Problem: When a player placed a bomb, the tile they were on was immediately marked as a bomb (a solid object). If the player tried to move before the next game update, the collision check would see the bomb they were standing on and prevent them from moving off it.

The Definitive Fix (Server-Side): The checkCollision function on the server was rewritten with a key exception:

When checking if a player's intended move is valid, the function checks the tiles at the corners of the player's future position.

If a corner lands on a tile marked as a bomb (tile === 3), a new, crucial check is performed.

It compares the bomb's tile coordinates (bomb.col, bomb.row) with the player's current tile coordinates (playerGridPos.col, playerGridPos.row).

If these coordinates match, it means the bomb being detected is the one the player is currently standing on. The collision check ignores this specific bomb, allowing the player to move freely off the tile.

If the coordinates don't match, it means the player is trying to walk onto a different bomb, which is correctly blocked.

This logic ensures a player is only ever blocked by bombs they aren't currently occupying, making movement fluid and intuitive after placing a bomb.
3. UI/UX Polish: The Lobby

The initial modals for creating and joining games have been restyled to match the aesthetic of a retro arcade game, using the same pixel font and a darker, more immersive color scheme. This creates a more cohesive and polished experience from the moment the user opens the game.

migrated from a local-only html/js game to a websocket-based client-server architecture

added server.js (express + ws)

    serves index.html

    handles game state: grid, turns, scores, connections

    supports createGame, joinGame, makeMove messages

    broadcasts sanitized game state using getSanitizedGameState()

    tracks players via ws instances

    cleans up games on disconnect

modified index.html

    removed all local game logic (score keeping, move validation, etc)

    added websocket client

    emits structured messages (createGame, joinGame, makeMove)

    handles incoming gameCreated, gameUpdate, opponentDisconnected, error

    updated modal UI for multiplayer flow (game id entry, restart logic)

moved core logic (checkNewBoxes, updateScores, game over detection) to server

    server now authoritative on rules and state

added basic game id system

    5-char alphanumeric

    prevents collisions, used to identify lobbies

disconnection handling: opponent wins if one player leaves mid-game

tested across multiple browser instances over localhost ws connections on port 8080

1. The Game Board: A Grid System

The game world is structured as a 2D grid—similar to a chessboard. It uses a 2D array in JavaScript (e.g., map[row][col]) to represent this grid. Each cell contains a value indicating what occupies that location:

0: An empty, walkable tile
1: A soft obstacle, such as a crate or bush. These can be destroyed by bomb blasts
2: A hard obstacle, like a solid wall. These are indestructible and block both players and explosions
3: A bomb

By relying on a grid-based system, the game simplifies movement, collisions, and object interactions.

1. The Player

The game represents the player as an object with several key attributes:

Position: x and y pixel coordinates on the canvas
Grid Position: row and col values representing the player’s location on the grid
Direction: A numeric value (e.g., 0 = North, 1 = South, 2 = East, 3 = West) indicating the player’s facing direction
State: Properties such as isAlive, bombCount, and bombPower

Player movement is grid-aligned. When a direction key is pressed, the game checks if the next cell is walkable. If it is, the player smoothly transitions to that cell. This prevents the player from stopping between tiles and keeps motion consistent.

1. Placing Bombs

When the player places a bomb (e.g., by pressing the spacebar), the game performs the following:

It creates a Bomb object at the player’s current grid location
It updates the corresponding cell in the grid to indicate the presence of a bomb (value 3), which blocks movement through it
It sets a timer on the Bomb object (typically 3 seconds)

1. The Explosion

This is the most complex mechanic in the game. When a bomb’s timer expires:

Chain Reaction: The game checks if the bomb is already within an explosion radius. If it is, it detonates immediately
Creating the Blast: The bomb is removed and an explosion is triggered, consisting of multiple blast coordinates

Spreading the Fire:
The explosion starts at the bomb’s origin point
It spreads in four directions (North, East, South, West) for a set distance based on the bomb’s power
It stops if it hits a hard wall, a soft obstacle, or reaches its max range
Soft obstacles are destroyed when hit; hard walls block the blast before contact

Rendering the Blast: The game uses different sprites for the explosion center, directional segments, and end caps (North, South, East, West)

Collision & Damage: It checks if any player occupies a cell affected by the blast. If so, that player is eliminated

Cleanup: Explosions remain for a short duration (e.g., 0.5 seconds) before being removed from the grid

1. Game Loop

The core of the game is a continuous loop managed by requestAnimationFrame. Each frame, the game performs two main tasks:

Update:
It processes input, updates player movement, counts down bomb timers, triggers explosions, and removes expired blasts

Draw:
It renders the background, draws walls and obstacles, displays active bombs and explosions, and updates player positions

This update-draw cycle ensures real-time gameplay and smooth animations.

made the barebarebarebone of the css of the board

today i've made it run on a local server:
Architecture: made it run on a local Node.js server

Real-Time Communication: Implemented a WebSocket (ws) server to handle instant, two-way communication between the two game clients (browser tabs).

Local Matchmaking: player 2 can join a playroom with a 5-character room code generated by p1 created playroom

Fixed a game-breaking bug where Player 2 could not take the first turn after joining a game. The server now correctly assigns the turn to Player 2 as soon as the game status becomes 'active'.
BUG FIX (Server Stability): Resolved a server-crashing error (TypeError: Converting circular structure to JSON) by creating a sanitized game state object for network transmission. This ensures only safe, plain data is sent to clients, preventing circular reference issues.

Features:

Complete Ludo Rules: Including three sixes skip rule and token capture
Terminal Style: Dark background (#111) with retro monospace fonts
Smart Gameplay: Auto-dice rolling, intelligent token selection
Smooth Animations: Pulsing movable tokens, fluid movement transitions
Responsive Design: 15x15 CSS Grid, viewport-based sizing

Technical Highlights:

Path System: Main circuit (1-52) + home paths (101-105, 201-205, etc.)
State Management: Tracks token states (yard, active, home)
Animation Pipeline: Cell-to-cell movement with capture effects
Game Logic: Turn progression, path validation, win detection

Start Modal: When you open the page, a modal appears. It explains the rules and has a password-style input for Player 1 to secretly enter their word.

Game Interface:

A status bar at the top shows the number of guesses remaining and whose turn it is. The current player's turn indicator has a blinking cursor effect.

The main area works like a chat log, showing questions from Player 2 on the left and answers from Player 1 on the right.

The input area at the bottom changes based on whose turn it is. Player 2 gets a text box to type questions, and Player 1 gets buttons for Yes, No, Maybe, and You Guessed It!.

Gameplay Flow: The game logic handles switching turns, counting down guesses, and disabling/enabling the correct controls for each player.

End Game: When the game ends (either by a correct guess or by running out of turns), a final modal appears announcing the winner and revealing the secret word. It also has a button to play again.

Styling: I've adapted the sleek, modern, terminal-like style of the previous projects for this game too.

Penguin Textures: implementing a penguin icon as visual textures for player pucks, replacing generic circles.

Texture Loading Fixes: Addressing issues with image loading and rendering to ensure textures display correctly at game start and on restart.today i am currently working on:

Core Game Logic
Turn-Based System: Implemented a robust turn-based system for two players (Player 1 and Player 2).
Box Capture Mechanic: Players can capture a box by drawing its fourth and final wall. The captured box is then filled with the player's color.
Extra Turn Rule: Adhering to the classic rules, a player who successfully captures a box is granted an immediate extra turn to draw another line.

Interactive Game Board:
Dynamic Grid Generation: The game is rendered on an HTML Canvas, with a grid of dots that is dynamically generated based on user-selected density.
Line Drawing: Players can draw lines by clicking in the space between two adjacent dots.
Visual Feedback: A highlighted ghost line appears as the player hovers over a valid move, providing clear visual feedback before a decision is made.

User Interface & Experience:
ame Setup Modal: An initial modal allows players to set up the game, featuring a slider to control the grid density (from 3x3 up to 10x10) for varying levels of complexity.
Real-Time Status Bar: A persistent status bar at the top of the screen displays the current scores for both players and clearly indicates whose turn it is with a blinking cursor effect.
Game Over Screen: Upon completion of all boxes, a Game Over modal appears, declaring the winner (or a draw) and showing the final scores.
Responsive Design: The game board and UI elements are designed to be fully responsive, adapting to the size of the browser window to ensure a consistent experience.

New Aiming Indicator: The aiming preview has been changed from a series of dots to a single vector arrow, showing both the direction and power of your shot more clearly.

UI Overhaul:

The entire user interface has been redesigned with a minimalist, terminal-like aesthetic.

The colorful top scoreboards have been replaced with a single, sleek #status-bar at the top.

The current player's turn is now indicated by a blinking cursor next to their score and a central text message.

Layout and Theme:

The game now uses a dark theme, which makes the colorful penguins pop on the dark blue "ice" canvas.

The font has been changed to a monospaced font (Menlo, Monaco) to complete the retro-tech feel.

The end-of-game message box has also been restyled to match the new theme.

Code Refinements:

The JavaScript for drawing the aim indicator and updating the UI has been completely rewritten to support the new design.

The game now resizes more cleanly within the new layout when the browser window changes.

Layout Reworked to Table Format: The entire display for guesses was converted from a list-based system (divs) to a . This ensures all stats and headers are perfectly aligned for a cleaner, more readable experience.

Duplicate Guesses Blocked: The game now tracks your previous guesses. If you try to enter the same Pokémon twice, you'll get an alert, and it won't count as a try.

Thematic Header Implemented: The Image header was replaced with a more thematic Pokémon header, featuring a static image of Oddish to fit the game's aesthetic. The extra text beneath it was removed for a cleaner look.

Name Column Removed: The column that indicated if the name was correct or not was removed to streamline the UI. The Pokémon's name and image now turn green on a correct guess, making the separate column redundant.

Game-End Modal Implemented: The Show Previous Day button was removed. Instead, a modal now appears at the end of the game (either on a correct guess or after running out of tries) to reveal the day's Pokémon, providing a clear and focused conclusion to the game.

Dark Mode UI Corrected: Fixed a visual bug where the table background in dark mode was gray and did not match the page's dark background. All UI elements are now consistent with the selected theme.

Type-Matching Logic Confirmed: Ensured the logic for checking Pokémon types works as intended:

Green: Perfect match (e.g., guessing Bulbasaur for Bulbasaur - Grass/Poison).

Orange: Partial match (e.g., guessing Ivysaur for Venusaur - both are Grass/Poison, but if the target were just Grass, guessing a Grass/Poison type would still be a partial match).Red: No types in common.

Over the cours of the day i made the following functionalities:

Two-Player Gameplay
Turn-Based System: Players take turns to choose a color.

Dynamic UI

Interactive Color Picker

Game Over State: When the board is full, a modal appears declaring the winner and showing the final scores.

and the pop-up explains the rules before the first game begins.

done a lot today, here are the added functionality,
Pixelated UI using retro fonts and colors.
User can switch between themes.
Fixes cramping issues on smaller screens.
Sprites shown in guess list.
Type(s) shown clearly next to each guess.
Each stat displays its name alongside value.
A static row shows attribute labels.
Players only get 15 tries per day.
Remaining guesses shown live.
Click button to see past Pokémon.

made the ui

made the basic script for the interaction with pokeapi

added friction physics

i want to improve the cpu logic

got most of it doneee!

Finished!

i've finished it, i remade the binding of the dial nmber with the respective backgoround, made sure the spin animation ended up on the winning number, correction can be searched in the comments

i basically finsished it, i need just to retouch the wheel itself

issues still persisting

I remade the whole ui, and rn im working on the architecture of it switching to a linux daemon with a webui

right now working on the making of the popup for the browser

made the index page and bigger tweaks needed