Making small games, which is fun in itself

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/?timberte...

> hence imo in the beginning, it's best to recreate existing games with atmost a small twist

...if your goal is to do game development.

If your goal is to do game design, though, then the place to start is making paper prototypes of your game mechanics.

Almost anything turn-based can be prototyped on a tabletop with stuff you have lying around the house, and some rules about how you and your friends should move things.

(For something like an RPG, you may want to write a few little calculator scripts for calculations the game would hide from the players, to run on a laptop at the table, just so everyone doesn't get dragged down doing hours of math that wouldn't actually be part of a player's experience of the game. But "a calculator script" is still a far cry simpler than a game engine!)

Reflex-based video games are harder to prototype, but can often be tested "by analogy" to physical-movement games. Think: testing a design for a new FPS, by designing the mechanics as a set of LARP-y mods over paintball/airsoft/lasertag.

For a reflex-based video game where the player avatar is expected to be superhuman (e.g. most platformers/adventure games), you might not be able to test the mechanics directly, but you can at least create paper rubrics — e.g. threat-radius circles for attacks. You can then do level design by building physical dioramas out of blocks (Lego — esp. Technics, to have parts of the diorama move — is great for this!) and then "testing" using your paper rubrics to ensure each course is at least possible. This isn't so great an idea — unlike the previous prototyping strategies, this one won't really indicate whether your game idea is fun to play — but it's at least something you can do to iterate on an existing game concept without constantly having to program in each new marginal idea.

The only kind of game that's near-impossible to prototype without actually programming anything, is an "artsy" game where the mechanics play with lighting / mirrors / illusions / etc. in a way that doesn't line up with things that are physically possible in the real world. So... don't try to design one of those as your first game. :)

haha, nice mine are basically what I wrote as demos for Yaksha https://yakshalang.github.io/demos/

I learned a lot about Rust by making games with Bevy and writing down everything I learned: https://taintedcoders.com/

The smaller the game the more likely you are to finish. I usually started with making the movement fun and then developed some game like concepts around it.

I also highly recommend starting by making simulations instead of games as when you're alone they are still a blast to see come alive. Building boids is a fantastic exercise I do in any new engine.

Having tried to get on board with and use paper prototypes for digital games I’d largely disagree with this. Unless the mechanics are complementary to a board game then you’re largely not going to learn anything useful working this way. I’ve found that even in the case of digital games that do have good parity you learn a lot more as soon as you ditch paper and start working in the native format. With the reflex case this just gets worse, as the prototype medium gets ever further from any congruence to what you want to make.

There’s just too much missing in what it feels like to play the game. From the affordances digital games have, to the feedback and automated book keeping.