I feel like, rather than having no sound at all, the ability to output a PC-speaker-like beep (i.e. turn on/off a fixed-frequency, fixed-amplitude square wave channel) might be nice. No parameters because otherwise you might get distracted trying to trick it into sounding vaguely musical ;)
I’ve also always wanted to see something like this but with emoji for the “graphics.” (Emoji are, after all, the standard graphics resource pack of our era—like DOS box-drawing characters were for the 80s.) Maybe stick them as labels on a grid of buttons, resulting in a similar look to Chip’s Challenge.
I've spent the morning knocking up a little Space Invaders clone, it's the most fun I've had programming in ages. It's at https://incoherency.co.uk/24invaders/ and the logic is mostly done, just got some graphics work to do.
I got into programming as a teenager by making shitty games, first with Blitz Basic, and then with the Allegro C library.
My favourite parts of the Allegro community were the annual "speedhack" in which people create a game over a weekend, and the informal "screenhack" in which you create a game that must fit in 80x25 characters of C code. 24a2 brings back all the joy of those challenges for me.
I just love it. I can’t wait to make a bunch of toys with this.
I do think some very primitive sounds might be a good option. Don’t even use files. Just use the AudioContext and provide an enumeration of a couple beeps and boops. And I 100% support if the answer to this is “avoiding scope creep”
Interesting that you say this. I am thinking of running a python course online, and have programmed a 200-line battleship game with TkInter, since I think it is game that is engaging even when you play against a fairly straightforward computer adversary. I had a lot of fun playing my own game, even when programming it was so simple.
This framework is based on a game loop that runs an update on each frame which is more intended for real-time controls. I think a turn-based game like battleship is a different paradigm.
You always have to update every frame -- UI, sounds, animations, etc -- the question is whether you update your game simulation every frame. But really, you don't want to link your simulation-updates to your frame updates anyways, real time or not, because then you get weird behaviors like different framerates producing different physics (I believe it was quake that famously let's you jump further if your framerate is higher).
Is importing P5 a requirement for this engine to work? I know “minimal” can mean a lot of things to different people, but I don’t think it P5 adds much that you couldn’t trivially do without it in this case, and by stripping that dependency away you’d be able to make a very strong case for this being an ultra minimal engine.
I'm sure it's easy to render a 24x24 grid of colored dots using JS without any kind of graphics engine. But I guess it's a stylistic choice - abstract out the rendering code so that it's just an engine.
I love the minimal API, but this would really be awesome if it was a hosted fantasy console style environment with zero boiler plate and shareable links. I know that sounds like a minor difference, but having to write even a little bit of boilerplate in a minimalist environment is a source of friction. Also, as said by many people in this thread, a simple sound API (PC speaker style sounds, sfxr, 10 hard-coded effects, etc) should be added.
I find that any game created with this game engine ends up being far more code-heavy and complex than it would be without using it. In my mind, this invalidates the argument of using an ultra-minimalist game engine at the first place...
Perhaps I've missed the point, but I'd always expect a "minimalist" framework of any type contain less code in itself but require more application code. That's practically the point.
You have to write more boilerplate, but at least you know what all that code is doing because the framework is so easy to understand. By contrast, a more heavyweight framework lets you wrote less boilerplate because there's a helper function for every situation, but then your application code is filled with lots of magical calls into the framework, so to understand your code you need to look at a different bit of the framework documentation for every line.
That's not to I say I think either is better or worse, just that those are the expected trade offs.
Of the two example games that come with the engine, skiing is 113 lines long and snake is 158 lines long. Both include comments and don't make any attempt at a brief style of coding, so their lengths seem reasonable to me.
What games have you seen that you feel are too code heavy, written using this engine?
"Code heavy" of course in a relative sense. You can definitely make a snake game with the same aesthetic in less that 158 line, and you won't need to carry along the engine. I would also argue that the plain javascript version will be easier to understand as you will not need to understand what the engine is doing.
It isn't forcing you to do any extra work, it just saves you from having to worry about setting up a canvas, listening for input, or running a timer. That's literally all it does. And it gives you a neat aesthetic with the grid of dots.
Exactly. The demo scene requires innovation, but the bar for entry is high. This also requires innovation, but the bar is on the floor. Great idea! I'd love to see game competitions around these sorts of arbitrary restrictions.
tl;dr A javascript framework with a canvas output of 24x24 grid of dots. These dots can adopt nine distinct colors. Default input is arrow keys or mouse click on one of the dots. Includes a short eight section tutorial and api doc for two classes (game, gameconfig) and two enumerations (color, direction). Has example games for snake and 'skiiing' (wall avoidance on a linear path).
Strong shades of https://perlenspiel.net/ (though probably convergent evolution) - something to look at if you want just slightly more (variable-sized grid, pixel borders, sounds).
I have no idea if this is any good compared to existing game engines, but the limits imposed by its simplicity certainly tickle my creativity. If nothing else, it could be a great prototyping space.
One question: have you considered making it mobile friendly somehow? Given that all of the examples require arrow keys, it's a bit hard to demo on a phone.
I meant more in terms of architecture, extensibility, etc. I noticed it uses rather procedural updates -- maybe other game engines use more functional updates? I have no idea.
24A2 sort of looks like 24^2, which is what I originally wanted to call it, and only uses alphanumeric characters. The combination of numbers and letters also reminded me of P5 and pico-8, which were both inspirations
I’ve also always wanted to see something like this but with emoji for the “graphics.” (Emoji are, after all, the standard graphics resource pack of our era—like DOS box-drawing characters were for the 80s.) Maybe stick them as labels on a grid of buttons, resulting in a similar look to Chip’s Challenge.