{"author_link":"\/users\/kalgynirae","author_name":"kalgynirae","author_uid":"kalgynirae","comments":[],"epoch":1760936429,"event":"LD58","format":"md","ldjam_node_id":423229,"likes":5,"metadata":{"p_key":"197697","p_author":"kalgynirae","p_authorkey":"1003496","p_urlkey":"429629","p_title":"Using HTML, CSS, & JavaScript as a game engine","p_cat":"LDJam ","p_event":"LD58","p_time":"1760936429","p_likes":"5","p_comments":"0","p_status":"WAYBACK","us_key":"1003496","us_name":"kalgynirae","us_username":"kalgynirae","event_start":"1759449600","event_key":"112","event_name":"Ludum Dare 58"},"node":{"_collation":{"body_sanitizer":"TextUtils::SanitizeHTML via existing importer","event":"LD58","removed_author":false},"_superparent":415614,"_trust":1,"author":3496,"body":"Following the time-honored tradition of using Ludum Dare as an opportunity to try out a completely unfamiliar game engine, my team decided* to write our game using purely HTML, CSS, and JavaScript. Here's some thoughts about how that went for us.\n\n\\*technically *I* decided and they were forced to deal with the consequences\n\n## Big differences\n\nThere are some similarities between a web page and a real game engine:\n\n* The [DOM](https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/API\/Document_Object_Model) is in many ways very similar to the tree of nodes found in an engine like Godot.\n* The [Web Audio API](https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/API\/Web_Audio_API) is extremely capable and can handle mixing audio tracks, looping, and effects.\n* You can use [sprite sheets with CSS](https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/CSS\/CSS_images\/Implementing_image_sprites_in_CSS).\n* ... and so on.\n\nBut in practice, the differences far outweighed the similarities. Many tasks that are trivial in a real game engine were a huge bother in a web page, either requiring large amounts of code or deep knowledge of the quirks of web layout. For example, something as basic as positioning entities at specific coordinates in our game window required some fairly esoteric CSS understanding: the \"game window\" div has `position: relative`, and each entity has `position: absolute` and then is given coordinates using the `left` and `top` CSS properties.\n\n\n*Screenshot of the browser devtools showing *one part* of how we positioned entities using CSS*\n\n## The bad\n\nHere is an incomplete list of things that we had to do by hand (that a real game engine would have done for us):\n\n* Ensuring all assets are loaded: Our code handles this, but poorly, by making you think the game is completely broken until everything is finally loaded.\n* Resetting\/reloading levels: We had to write a lot of code to move elements back to their starting positions, hide\/unhide them, etc.\n* Editing levels: There's no easy way to place a thing in a position and *save* that. We hard-coded the starting coordinates for every object in our code and tweaked the numbers by hand as needed.\n* Sound: We got it working well, but it required more code and more troubleshooting than expected.\n\n## The good\n\nOn the other hand, there were some things that the web made *easier* for us:\n\n* Browser devtools are powerful: The console was super useful for debugging code, the inspector was great for understanding why positioning quirks were happening, etc.\n* Easy debug UI: It was trivial to throw some `` elements on the page and use them to control stuff while we were developing.\n* Animations: We just plopped animated GIFs directly onto the page. Luckily we didn't care about starting\/stopping any animations, because that would have been difficult.\n* Creative freedom: Our game is not confined to the \"game window\", and I feel like we barely scratched the surface of what could be done in this environment.\n\n\n*Screenshot of our debug UI*\n\n## Would we use it again?\n\nIt's likely! I certainly think there is a lot of untapped potential for fourth-wall-breaking gameplay which would be fun to explore.\n\n## Would *you* use it?\n\nLet us know in the comments!\n\nIf you'd like, [try our game](https:\/\/ldjam.com\/events\/ludum-dare\/58\/this-game-is-trash) (it's quite short).\n\nIf you liked the music, [both tracks](https:\/\/www.lumeh.org\/music\/#2025) are available now on my website (CC BY-SA), and they'll also be appearing on streaming services in the next few weeks.","comments":5,"comments-timestamp":"2025-10-21T22:48:49Z","created":"2025-10-20T03:44:47Z","files":[],"files-timestamp":0,"id":423229,"love":5,"love-timestamp":"2025-10-20T23:57:23Z","meta":[],"modified":"2025-10-21T22:48:49Z","name":"Using HTML, CSS, & JavaScript as a game engine","node-timestamp":"2025-10-20T05:02:18Z","parent":421626,"parents":[1,5,9,415614,421626],"path":"\/events\/ludum-dare\/58\/this-game-is-trash\/using-html-css-javascript-as-a-game-engine","published":"2025-10-20T05:00:29Z","scope":"public","slug":"using-html-css-javascript-as-a-game-engine","subsubtype":"","subtype":"","type":"post","version":1341097},"node_metadata":{"n_key":"423229","n_urlkey":"429629","n_parent":"421626","n_path":"\/events\/ludum-dare\/58\/this-game-is-trash\/using-html-css-javascript-as-a-game-engine","n_slug":"using-html-css-javascript-as-a-g","n_type":"post","n_subtype":"","n_subsubtype":"","n_author":"3496","n_created":"1760931887","n_modified":"1761086929","n_version":"1341097","n_status":"WAYBACK"},"source_url":"https:\/\/ldjam.com\/events\/ludum-dare\/58\/this-game-is-trash\/using-html-css-javascript-as-a-game-engine","text":"Following the time-honored tradition of using Ludum Dare as an opportunity to try out a completely unfamiliar game engine, my team decided* to write our game using purely HTML, CSS, and JavaScript. Here's some thoughts about how that went for us.\n\n\\*technically *I* decided and they were forced to deal with the consequences\n\n## Big differences\n\nThere are some similarities between a web page and a real game engine:\n\n* The [DOM](https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/API\/Document_Object_Model) is in many ways very similar to the tree of nodes found in an engine like Godot.\n* The [Web Audio API](https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/API\/Web_Audio_API) is extremely capable and can handle mixing audio tracks, looping, and effects.\n* You can use [sprite sheets with CSS](https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/CSS\/CSS_images\/Implementing_image_sprites_in_CSS).\n* ... and so on.\n\nBut in practice, the differences far outweighed the similarities. Many tasks that are trivial in a real game engine were a huge bother in a web page, either requiring large amounts of code or deep knowledge of the quirks of web layout. For example, something as basic as positioning entities at specific coordinates in our game window required some fairly esoteric CSS understanding: the \"game window\" div has `position: relative`, and each entity has `position: absolute` and then is given coordinates using the `left` and `top` CSS properties.\n\n\n*Screenshot of the browser devtools showing *one part* of how we positioned entities using CSS*\n\n## The bad\n\nHere is an incomplete list of things that we had to do by hand (that a real game engine would have done for us):\n\n* Ensuring all assets are loaded: Our code handles this, but poorly, by making you think the game is completely broken until everything is finally loaded.\n* Resetting\/reloading levels: We had to write a lot of code to move elements back to their starting positions, hide\/unhide them, etc.\n* Editing levels: There's no easy way to place a thing in a position and *save* that. We hard-coded the starting coordinates for every object in our code and tweaked the numbers by hand as needed.\n* Sound: We got it working well, but it required more code and more troubleshooting than expected.\n\n## The good\n\nOn the other hand, there were some things that the web made *easier* for us:\n\n* Browser devtools are powerful: The console was super useful for debugging code, the inspector was great for understanding why positioning quirks were happening, etc.\n* Easy debug UI: It was trivial to throw some `` elements on the page and use them to control stuff while we were developing.\n* Animations: We just plopped animated GIFs directly onto the page. Luckily we didn't care about starting\/stopping any animations, because that would have been difficult.\n* Creative freedom: Our game is not confined to the \"game window\", and I feel like we barely scratched the surface of what could be done in this environment.\n\n\n*Screenshot of our debug UI*\n\n## Would we use it again?\n\nIt's likely! I certainly think there is a lot of untapped potential for fourth-wall-breaking gameplay which would be fun to explore.\n\n## Would *you* use it?\n\nLet us know in the comments!\n\nIf you'd like, [try our game](https:\/\/ldjam.com\/events\/ludum-dare\/58\/this-game-is-trash) (it's quite short).\n\nIf you liked the music, [both tracks](https:\/\/www.lumeh.org\/music\/#2025) are available now on my website (CC BY-SA), and they'll also be appearing on streaming services in the next few weeks.","title":"Using HTML, CSS, & JavaScript as a game engine","wayback_source":[]}