ABA Games

In the first game pictured, timber test [0], you can spam cut repeatedly to get some pretty high scores. I love finding little strategies like this. This is only possible in games with a tiny feedback loop, which I think makes them fun to play on a whole new level. [0] https://abagames.github.io/crisp-game-lib-11-games/?timbertest

> Gamedev has got to be the most rewarding type of software coding there is. It is... under certain circumstances. At a AAA studio it's an utter slog, unless you're the designer or one of the top coders working closely with the designer. Then you get to build prototypes, bounce ideas around, etc. until you come up with something you can hand down to the C++ slaves in the salt mines. If you don't want to be in the salt mines yourself, the best route to take is the indie route. Become the designer/lead programmer, write the game on your own schedule, and either do your own art/sounds/music or hire people to make those assets for you as necessary and use placeholders while you refine the game design. You also get your choice of language. Want to write a game in Lisp or Haskell? Go nuts! Do yourself a favor and start with a data-oriented model for your game world like ECS, instead of an inheritance-based object-oriented model. Your inheritance tree is going to whack you like a Whomping Willow the minute you try to build a game object with traits from different classes across the tree. With a data-oriented approach, your game objects are just pieces of state -- rows in a spreadsheet -- and you can change them with whatever tools are most handy: objects, plain functions, whatever. Choosing an ECS has saved me much hassle in adding new enemies and behaviors to the game I'm working on, and that shortens the time and effort from "I need to add this thing" to "WOW! It works!" Oh,…

May not be obvious from the article, yet all of the authors games are available for play [1] [1] http://www.asahi-net.or.jp/~cs8k-cyu/ And there's also a breakdown of games by their included game mechanics at [2], which from my own perspective is perhaps more fascinating. [2] https://abagames.github.io/action-mini-game-mechanic-tags/index.html

The source code for the page doesn't have any reference to a game-specific source code, so it must have been loaded dynamically and can be found from devtools [1]. You can then read the actual code and find that every state is in the global scope, so they are directly accessible without any trick. It hasn't been minimized so all variable names make sense and you can even guess their purposes without actually checking. [1] https://abagames.github.io/crisp-game-lib-11-games/pakupaku/main.js

Looks like a custom-built game library they designed atop Pixijs https://abagames.github.io/joys-of-small-game-development-en/tools/for… [edit] It seems that Pixi is one rendering method, and the graphics themselves are abstracted via a "terminal" and "view" class, so the engine focuses on positioning art rather than handling sprite draws directly. It's a nice set of opinionated choices. In particular, implementing collisions for 2D sprites. I built a game engine like that with particles and collisions (and particle collisions!) in AS3 on top of Starling at one point... sadly, I can't make games with it anymore.

I like cywall by Kenta Cho. The one-button approach is refreshing to explore as a gamedev who tries to cram everything in. https://abagames.github.io/crisp-game-lib-games/?cywall He wrote a lot of words on small game development: https://abagames.github.io/joys-of-small-game-development-en/ (PS I liked cywall so much, I'm made a clone: https://opyate.itch.io/paddles (audio not working yet, sorry)) And hopefully this doesn't suffer from HN hug 'o death, but here's some more of his games, implemented with all sorts (HaXe, Flash, JS, etc): http://www.asahi-net.or.jp/~cs8k-cyu/

I reverse-engineered it. This whole exercise took me about 30 minutes while half coding and half watching a TV show. Since the JS code was neither minified nor obfuscated, it was easy. Here are my exact steps: In Chrome, right-click on the page -> View Source. Go to the "Sources" tab. When you open the tree on the left you find a file, that was dynamically loaded (so you wouldn't have found it by just looking at the HTML source of the main page), https://abagames.github.io/crisp-game-lib-11-games/pakupaku/main.js that seems to contain the game's code. And indeed it's less than 200 lines and implements the core game logic. There is a main function, update(), containing a conditional "if (!ticks)" that seems to do initialization. "ticks" is probably zero at the start of the game. The code initializes multiple variables, including "player" and "enemy": if (!ticks) { player = { x: 40, vx: 1 }; enemy = { x: 100, eyeVx: 0 }; multiplier = 0; addDots(); powerTicks = animTicks = 0; } Then with a bunch of console.log() statements added to the update() function (just edit the code and type Ctrl-S to save it, Chrome allows this sort of in-place code editing), I got a sense that player.x and enemy.x was the x position, with the scale going from 0 (left edge) to 100 (right edge). Then with more console.log() statements I found enemy.eyeVx was normally 0 when the enemy is a ghost or 1 or -1 if the ghost has been eaten and its eyes are flying…

I don’t know if anyone else noticed, and I’m not sure whether this is intentional, or maybe the dev found it too hard to do well in browser-based games, but it seems like most of his games don’t sync the sound with actions happening in the game. For example, in Pac Man, the dots chomping sound seems like it’s just a repeating sound that is toggled on and off, vs. actually syncing with the timing of chomping the dots. Also, if you check out his other web-based games [1], you’ll notice the same thing — the actions (by tapping) cause a sound that is just repeated at a pre-set rhythm that doesn’t sync with when you tap. It’s subtle, but can actually have an adverse affect on the performance of the game. I often use sound feedback as a way of timing, and when this doesn’t match what I’m doing, it can definitely throw me off my rhythm. The Timber Test game [2] is a perfect example of this, particularly on the later levels where you need to cut the log into equal fractions, but the sound timing is always the same, making beeps in unequal intervals. [1] https://www.asahi-net.or.jp/~cs8k-cyu/browser.html [2] https://abagames.github.io/crisp-game-lib-11-games/?timbertest