Search the Community

Showing results for tags 'remake'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • HTML5 Game Coding
    • News
    • Game Showcase
    • Facebook Instant Games
    • Coding and Game Design
  • Frameworks
    • Phaser 3
    • Phaser 2
    • Pixi.js
    • Babylon.js
    • Panda 2
    • melonJS
    • Haxe JS
    • Kiwi.js
  • General
    • General Talk
  • Business
    • Collaborations (un-paid)
    • Jobs (Hiring and Freelance)
    • Services Offered

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL





Found 3 results

  1. Hello! I'm here to share my new weekend project. Remake Asteroids with HTML canvas. I documented the process, if you'd like to see, check it out on github
  2. Hi Game Devs, Repeat lurking visitor, first-time poster here. I enjoy seeing the games made for both work and fun by the community on this forum, and the quality of work shown here is quite impressive. I have had a lot of fun working on browser-based games over the years, and wanted to share some of my own. With apologies for the lengthy "roll-up" post, I figured it'd be more efficient to share a few bits of work at once. I've been playing with JavaScript since the "DHTML" (Dynamic HTML) days of the mid-late 1990s, and have always believed it's possible (and heck, dare I say required) to make fun and practical applications in the browser using HTML, CSS and JavaScript. For any old-skool heads who may be around, I used to post on the "Ozone Asylum" DHTML forum many moons ago. It has been really, really great to see JavaScript take off and gain recognition as the lingua franca of the web (and more recently with node.js etc., on the backend), as the powerful language it truly is. I'm preaching to the choir here, but JS isn't just for pop-ups, you know. DHTML ARKANOID My first real experience with object-oriented JS was DHTML Arkanoid (written in 2002, when most screens were 800x600 or 1024x768 - please keep this in mind ) - I learned a lot, and my motion + collision detection code was not great then nor now, so apologies for that up front. That said, I'm glad the game continues to work in modern browsers. This was based on the PC-DOS version which also included a level editor, so I made a web-based level editor as well. To date, just over 19,000 levels have been created by users - most of them are not rude. I wanted JavaScript-driven sound effects for this game, and used an early version of what is now the SoundManager 2 library ( ) to get audio triggered by JS. The original SoundManager I made for a portfolio site some time in 2001, and it evolved to become an open-source project that I continue to maintain and develop to date. Native audio support in browsers is still a bit of a minefield ("and then there's mobile"), but things are definitely progressing on that front. SURVIVOR A few years ago, I was on a six-hour holiday flight to Hawaii with a fully-charged laptop and no wifi; poking around and finding an old Commodore 64 emulator installed on my desktop, I finally got the motivation to start on a browser-based remake of "SURVIVOR", a fun game from 1982 that I played as a kid. It's a fun space shoot 'em up (it is 1982, after all) that has an element of "tower defense" to it. Your goal is to take out the turrets on four bases, while avoiding indestructible meteors resembling slime balls and the occasional "bad guy" that shows up to chase you. The game speed and intensity increases as you destroy each base. The game made good use of sound effects also, in simple and effective ways; I remember it being quite fun to play because of that. Since it is a Commodore 64 game, it also felt appropriate that it should have a C64-themed loading screen and other touches. Fly-through: I wrote up a lengthy article on the makings-of, performance findings and such here. Additionally, the original didn't have a level editor - but once you write the engine, the rest is just data, right? I added an editor once I got the original game done, albeit with no "save" option. I hackishly stuffed the level data into the URL, and worked in a Twitter share button. When playing a custom level shared via Twitter etc., users could also choose to "remix this level", where they would be taken into the editor populated with the level they just played - I thought perhaps it would be fun to remix and share again. It was fun trying to think of ways to make editing efficient - for example, letting users cilck and then shift-click a second point to "fill" a shape of blocks, or simply click-and-drag to "paint" walls that would turn corners using the right pieces automatically. Screencast here: Also on GitHub: ARMOR ALLEY After digging through some more old games this year, I started on my own interpretation of "Armor Alley", the action/strategy PC-DOS version from 1990. I thought this one might not be practical as a side project given the types of infantry, vehicles, buildings and interactions between them etc. "SURVIVOR" took perhaps two months, and this one was about four months after all was said and done. I had a working prototype within a few days and a fairly feature-complete game after the first two months, but it was the polish, performance tuning and intricate details that took the most amount of time and effort. Hours vs. "output" definitely dropped toward the end, and while it was worthwhile, I couldn't help but think of that quote: "The first 90% of the code accounts for the first 90% of the development process. The remaining 10% of the code accounts for the other 90%." I did not implement all game features, so it is a "web prototype". The original had boot camp "training" mode, in addition to a full campaign mode. I covered level 1 plus a few additional elements like gun (turret) emplacements, and made my own version of a tutorial that guides the player through the controls, units and basic gameplay tactics. The game runs scaled to fit your browser height by default, but you can also run it in 1:1 mode, retaining the original resolution. The wider your monitor, the more of the battlefield you can see at once - but the same applies to enemy units, who can also see you. Screencast of the tutorial mode: Some of the game sprites: Notes on the development and performance findings etc. here, including examples showing Chrome's excellent DevTools in action: Also on GitHub: --- I have found that games are a great way to push your capabilities as a developer, whether new or experienced. Games demand attention to detail, and require performance as a feature to be enjoyable. I don't work on games professionally, but I always learn things while working on games or other personal browser-based side projects - and I always end up feeding new knowledge to use in my professional work. Client-side rendering and performance are particular areas of common interest, in this regard.
  3. Hi guys! I want to show you some of my work. This game i made in a 3 days. While i was having a bath, an idea came to my head. What if i could use this cool css3 transitions in game, they look pretty cool and you can code them in one line. And then the i've got it. Snake !. It was fun and quick to implement and now i can show you my work. It simple game so i don't use any 3rd party libraries besides sound, where i used soundjs from createjs project. Hope you enjoy it ! PLAY