return to table of content

Making small games, which is fun in itself

prakhar897
32 replies
1d

I've learnt that Game Designing and Game Development are two very different things. You need a creative mind to know what mechanics will be tight and grab the audience. Development on the other hand requires ruthless execution.

hence imo in the beginning, it's best to recreate existing games with atmost a small twist. This makes sure i'm learning one craft adeptly before moving to the next.

Here's a freeboard of a game I worked on recently: https://li-quoridor.vercel.app/ [Still a work in progress]

derefr
10 replies
23h30m

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. :)

meheleventyone
9 replies
23h3m

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.

crq-yml
8 replies
22h9m

I concur.

Digital game design lends itself to working "UI down" instead of "data model up" because most of the feel of the game derives from the interface. This is even true if you look at something like Civilization. The first release of that game was primarily built off the feel of the city management - the stats of everything were given very basic tuning. It switched from real time to turn based relatively late in development.

So paper can be used, but mostly in a storyboard kind of way where you're presenting some interactions to testers without coding them up. You don't have to have a full game loop at that stage - the loop is just a hook to stay engaged with those interactions.

The reason why the spreadsheets are relevant now mostly comes down to games having more and more content that needs stat balancing. This was immediately true of Wizardry and derived RPGs, but it's never been necessary for simple arcade games, and it's obviously wrong if your aim is something like a Sokoban puzzle.

derefr
5 replies
20h48m

Digital game design lends itself to working "UI down" instead of "data model up" because most of the feel of the game derives from the interface.

You're talking about a later stage of the ideation process than I am, I think.

You seem to be talking about building a game in an established genre, where you know what kind of medium you'll use, and even what game engine you probably need, and so you can sit down and start iterating on game design through development — with mechanics being either just retreads of other games' mechanics, or being things that naturally arise during development.

If you work for a game studio that makes games in one particular medium and genre, then this approach makes sense, I suppose.

But I was speaking more of ideating novel game mechanics: what you're calling an "interaction", but a bit more — basically any element of a game's concept that can be extracted out to be modelled separately as its own abstract rules state-machine, its own "micro game."

And I was speaking of these mechanics in isolation of any particular game engine, or even any particular medium — of any particular game genre.

When designing such an isolated mechanic, you can use paper-prototyping to wrap the mechanic into a Minimal Viable Game — because your goal is testing whether the mechanic is fun, rather than whether the game is fun.

Example: coming up with "a sequence of random-chance events to either buy or trade for unclaimed properties, or to be taxed by the current owner of the property" as a mechanic. Wrap it in a board game: it's an MVP version of Monopoly. But you could just as well wrap it in an async MMO game — then you've got something more like Elite or Dope Wars or EVE Online.

Monopoly and EVE Online are two very different games in two very different genres, with two very different playstyles — but before you design either game, you can determine whether the core mechanic between both of them is fun even in concept. If it isn't, don't bother putting it in a game at all.

(For another 300 examples: https://www.squidi.net/three/)

Games designed mechanics-first, are usually also designed mechanics out — which is similar to, but not the same as, "data model up." Mechanics constrain possible UX and possible data models, but don't fully determine either. And mechanics — or the particular combination of mechanics — determines a game's genre. (Often, adding one more mechanic to an existing genre makes people start calling games like that a new subgenre. Add "keys that fit multiple nonobvious earlier locks, incentivizing exploratory backtracking, with each key being qualitatively different in use" to a platformer, and you've got a metroidvania.)

So the goal of a game-designer who is designing mechanics-first, is almost always to create a game with a set of unique, innovative mechanics — i.e. to create a game that is the first entry in a new game genre.

What mechanics-first design often doesn't constrain, is medium. The same set of action-resolution and narrative-tension mechanics might work equally well in a CRPG or a TTRPG! The same set of competitive zero-sum character moveset concepts might translate equally well to a fighting game (https://www.sirlin.net/articles/balancing-puzzle-fighter) or a deckbuilding card game (https://www.sirlin.net/articles/designing-puzzle-strike)!

Which is why paper prototyping often does work well for mechanics-first design: many mechanics can be evaluated for "can it be fun even in concept"-ness through a very turn-based, abstract, talk-y form of interaction with the mechanic. A collaborative hallucination of the mechanic.

This lets you decide what random mechanic ideas you have stewing, you should bother to take the time to "translate" from their abstract-concept form, to something programmed. It also often allows you to find mechanics that "fit" together, even while they're still abstract. An entire game-genre of interlocking mechanics might just "click" and come together on paper, before any real examples of it exist. Now you just have to design an actual game that has those mechanics / is in that novel genre.

---

Bonus potential hot take: I hypothesize that Shigeru Miyamoto — not Nintendo as a whole, just Miyamoto — does mechanics-first design. It's why no project he heads, or even greenlights, is ever just effectively a DLC/content-pack for a previous game. Which is in turn why Nintendo continually leads the industry in their games being the first entries in new game genres; but it's also why the newer Paper Mario games suck. And it's why there's never going to be a sequel to many people's favorite Nintendo games: there's just no clear thing to change about or add to the mechanics, that a whole new game's worth of content could be derived from, without that game having so little to do with the original that it wouldn't appeal to fans of the original.

(Re: that last part, see also: why no Half-Life 3 or Portal 3. Those series are clearly founded on mechanics-driven design as well.)

crq-yml
1 replies
18h2m

Ask what a "game mechanic" is and you'll get three different answers. Not even the authors of the "MDA" paper, which got everyone using that term, were consistent in their definition. I sometimes find myself using it, but it's a widget.

The way I actually do design now is by Venn diagram. At the core of the diagram lies themes, principles, beliefs, or the so-called "design pillars". The "hook" of all games that reach an audience lies in offering a coherent belief structure: "I believe I'm doing this thing because it coheres with what I think the thing is about." And it doesn't have to be "about" anything very weighty; a ball sport amounts to an excuse to play with a ball in a certain way. And it doesn't have to be a popular belief, either. But it is a hard requirement that the game has this quality, because the alternative is that the player says "I don't know what this is about and why isn't it more like this other game". Game players still say that about successful games, but it's because their belief structure doesn't allow engagement with the core.

What fills out the rest of the diagram, and the design, is the supporting expression of that belief. If you believe the game is about throwing and catching a ball, you need to introduce some equipment and rules. But the reason why the game remains compelling as a whole is down to whether or not those things are facilitating the intended kind of play, and the reason to have genres of game derives from the mode of expression shaping that engagement: some games have a lot of legible rules and stats, others hide everything behind audiovisual expression. It's books vs movies, not action vs romance.

Miyamoto's training was in industrial design. That is, he brings "toy" qualities to video games. The way in which he designs follows from that: rather than exploring a core that is literary, like "hubris" or "rebirth", Mario's play value is in the experience of running and jumping. Therefore, Mario's world follows from providing elements that engage further with running and jumping - motives to progress, obstacles to face, abilities that change his relationship to those obstacles. And the direction of Nintendo as a whole, since he started working there, has been to make products tightly focused around toy concepts, with hardware platforms that allowed more experiments to take place.

Aerroon
0 replies
15h49m

This is a very interesting way of looking at game design or design of anything that is entertaining. It nails so much stuff that's cool.

Pacific rim? Giant robots and giant monsters are cool! How can we tell a cool story about giant robots and monsters?

adamrezich
1 replies
19h16m

to the best of my understanding—but please correct me if I'm mistaken—Miyamoto is not, and never really has been, what we would traditionally call a "game designer"—from what I can tell from reading numerous interviews, both with him and others who worked with him over the years, he's more like a Steve Jobs-type figure. he comes up with a broad interesting idea or set of ideas or even just general vibe, and then it's up to the programmers (and probably game designers nowadays) to figure out how to turn those ideas into an actual game. then he sees what they've come up with and gives feedback; rinse and repeat until the game ships.

with regards to paper prototyping though, while I believe it can be a useful tool in certain situations, I pretty strongly believe that its usefulness is being vastly oversold to aspiring video game designers, these days. the best use for paper prototyping is when the game you're setting out to make strongly resembles an analog game—like a roguelite deckbuilder, or Fortune Street. but if you're looking to create a design for a video game that truly embraces what's unique about the medium—instead of just making a computer-adjudicated board game—then there really isn't a better way to do it than just biting the bullet and prototyping the gameplay with code. in my opinion, the best-designed video games are not ones where the design was thought through to completion ahead of time before implementation began, but rather, ones where someone had an idea or two and sat down and started programming its implementation—prototype or otherwise—and the eventual design of the end product was discovered through playing around with the combinatoric outcomes of interesting rules and mechanics that interact in nontrivial and often unforeseeable ways, seeing what works and what doesn't, seeing what's interesting and what isn't, and gradually arriving at something special and unique.

many people disagree with my assessment here, because they want to believe that it's possible to create a design for a video game that is unique and interesting and special, whole-cloth, without ever writing a single line of code. but how can that even be possible? the main things that separate video game design from analog game design are 1.) the computer adjudicating the rules, and 2.) the much faster feedback loop between action taken action and observed outcome, from the perspective of the player. these are qualities inherent to the medium. you can choose to ignore them and design a more or less perfectly paper-prototypable game... but, if that's the case, perhaps you'd be better off designing a board game instead. just like how many AAA linear-narrative-focused games' narratives really would just work a lot better as a movie or TV series. now this isn't always strictly true of course—roguelite deckbuilders are fun as hell, even though they're generally very straightforward to paper-prototype. but again, of course these kinds of games lend themselves to paper prototyping, because they're really just essentially digital board games. and if that's all you ever want to make, then sure, go on ahead.

but if you want to make something that embraces the qualities of the medium that make it stand apart from its contemporaries, then really, making a digital prototype is the only way to go. as a hackneyed example, consider Braid: its initial prototype had a functioning "infinite rewind" system, and its designer/programmer implemented more or less every idea he had (including World 1, the final level)... but much of the rest of the mechanics (such as World 4's "current point in time for all other entities in the level = the player character's x-position") only came about—were arguably discoveredthrough the act of implementation, as opposed being done in advance of implementation. if whether or not Braid was made hinged upon the perceived success or failure of preliminary paper prototyping, then it's quite likely it would never have been made.

moreover, it is entirely possible to design a game through paper prototyping, and be reasonably satisfied with the design... only for you to then implement it and actually play it in the form of an actual video game, and find it to be underwhelming, unengaging, or otherwise completely unlike how you envisioned it with your abstracted paper prototype. for example, that page of 300 video game design ideas are likely mostly or entirely interesting at face value—but without being tested, are basically entirely meaningless. I just clicked on a random one: https://www.squidi.net/three/entry.php?id=224 this is a cute idea, but without even testing it out myself at all I doubt it's actually very good at all. but hey, maybe I'm wrong, maybe it's the next Angry Birds, or something! I'm not faulting the author for posting it on their personal website, but really, it's nothing more than just a wholly untested, spontaneous idea jotted down in a notebook. until said idea is put into practice in the form of a playable video game prototype, there's no way of knowing whether it would actually be fun at all, or worthwhile to pursue developing further.

but, to my point above: perhaps in building and testing a prototypical two-button FPS game, the designer might realize that their idea was utter garbage... except for some small aspect that they did not and could not foresee. perhaps it's entirely incidental to the "two-button FPS" game idea. maybe it's even just something as trivial as a bugged shader that produces undesired yet unexpectedly visually interesting output, or improperly-implemented movement mechanics that inspire a completely different, first-person-shooting-less idea for a game.

conversely: if Vampire Survivors never existed, and you came to me with an idea for a single-stick no-button roguelite top-down shooter with barely-animated 2D sprites that look like they should be in a side-scroller instead, I would've thought your idea was mediocre at best, and not worth pursuing. but as it turns out, it's a great idea for a game, one that ended up spawning a whole subgenre—and anyone can see the appeal for themselves, just by playing it for only a few short minutes!

paper prototypes can be useful for designing certain parts of certain types of games, but I completely and vehemently disagree that they're a useful tool for determining whether or not a broad, abstract video game design idea is worth pursuing further.

greggman7
0 replies
14h19m

I agree with you.

I watched some students prototype a simple diplomacy type game on paper first, targeted at phones. On paper people got it, talked to each other, negotiated. On the phone, people just stared at their screens, made choices entirely in isolation, no "diplomacy" what-so-ever.

chii
0 replies
5h54m

I would say that paper and table top is far too removed a medium from an interactive video game to be a proper prototyping form. Paper only cares about the rules and consequences of those rules, but no "feedback".

For example, you would not imagine that portal could've been designed from using paper and tabletop. The feel of looking thru a portal, the orientation (or disorientation) of the player, etc are all crucial to making portal good.

You would also not be able to prototype a game such as Q.W.O.P. (and their incarnations such as "Getting Over It") on paper - it's impossible to imagine it, without first getting the smallest prototype that's interactable on the medium it's ultimately delivered.

I suspect that using paper and tabletop to design a game mechanic will surely bias you to produce discrete interactions in your game, even if the ultimate medium is in the computer and played interactively.

panzagl
1 replies
21h43m

The first release of Civilization was a board game.

meheleventyone
0 replies
21h17m

I don’t think the board game and the videogame are related other than sharing the name and the former acting as inspiration.

tarruda
8 replies
23h49m

I want to begin game development as a hobby, but I'm unsure where to start. I did follow through https://learnopengl.com/ a few years ago, and while it was a very interesting experience, I imagine I would need to use an existing engine to be productive.

Do you recommend any books and tutorials aimed at experienced programmers with 0 knowledge of game development/design?

krapp
5 replies
23h43m

Just start with a framework like Godot. There are plenty of tutorials online.

If you really want to go low level with it, though, my personal sweet spot is C, Lua/LuaJIT and SDL2. Although practically speaking C++ is probably better.

tarruda
2 replies
23h37m

I will keep that in mind, thanks.

My initial research suggest that Godot games are written in C#. Since you use C/SDL2, do you code directly your own OpenGL engine?

krapp
0 replies
23h28m

I don't use OpenGL. I probably should, and this year I'm planning on getting into Blender and 3D (but through Godot) but everything I do in SDL is 2d and sprite based, and SDL handles pushing the triangles/quads on its own.

Also, Godot games are also written in its native scripting language (GDScript) and it supports other languages, although I don't know how well, or how up to date anything is.

PsylentKnight
0 replies
22h9m

My initial research suggest that Godot games are written in C#

There are a few supported languages (including a custom Python-like language called GDScript). C# is just just one of them.

alectroem
1 replies
23h39m

I would highly recommend starting with a fantasy console such as Pico-8 or TIC-80. They remove the temptation to start by building a game engine from scratch, and instead help you focus on actually creating games! Plus they have great communities, complete docs, and simple apis.

krapp
0 replies
23h16m

Yeah, one of the traps I find myself falling into a lot is that the act of writing code itself can be satisfying enough, and fear (of finishing, complexity and failure) can lead to just spinning your wheels for a long time.

hypertele-Xii
0 replies
13h25m

I can consult you on that subject if you want to chat.

GuB-42
0 replies
21h14m

OpenGL is probably not the best way to start game dev. It is a bit too low level for that. I mean, OpenGL is awesome, and a great way to learn graphics programming, but if you intend to make a game that is fun to play, it is easy to get lost in technicalities.

When I started with Blitz Basic, not only my productivity skyrocketed, but I also made better games, because I actually thought about gameplay, not about getting the maths right. Blitz Basic is a game-oriented variant of the Basic programming language, very simple and straightforward. You can try it if you want, but it is two decades old, so I don't know how well it aged. But the important part is to have something simple that can free you from technical details and boilerplate, it can be an engine.

That's unless you want to practice with the technical details, but doing that, the output will probably be more demo than game. And by the way, if you are into that you should check the demoscene, it is awesome.

felipemnoa
4 replies
1d

>Game Designing and Game Development are two very different things

Right on. Took me a while to realize this. Game Design is the blue printing process of a game. Game Development is the actual building of the game. And Game Design is way harder than what I expected.

hesdeadjim
2 replies
21h45m

So hard. As a programmer it’s so much easier to get deep in the tech and push off the ambiguous, frustrating, yet rewarding craft of designing content.

I built half the content of a VR game I released a long while back with a friend, and the only thing that got me through it was listening to talks by John Cleese on the topic of creativity. My process could be summed up as: beat my head against a wall, make something okay-ish, get frustrated, try again and again, sleep on it, and eventually repeating that enough times results in awesome stuff.

But I have a hard time calling it “fun” even with the luxury of 7 years of hindsight.

hypertele-Xii
0 replies
13h28m

I'm polar opposite - ideas coming out the wazoo, like on average 1 idea per day, after decades of research into game design, but I dread moving into production and programming. Not for lack of experience, as chief of infotech I brought business-grade software projects from whiteboard to screen, but talking to a computer is just tedious. So much plumbing.

greggman7
0 replies
14h16m

This is super true. It's why programmers like writing game engines. It's relatively well defined all the parts needed so it feels like you're making lots of progress when in reality you're just re-inventing the wheel and not doing the truly hard part, the actual design and content creation. I'm super guilty of it myself.

3737hdhd7372
0 replies
22h53m

Yeah a lot of people think of game design as just being about brainstorming cool ideas

But in reality it’s actually a pretty technical job from what I’ve seen

Can involve a lot of staring at spreadsheets and dealing with stats

bcrosby95
2 replies
22h56m

In professional game creation (trying to avoid the two "D" words you used here) the two are intertwined. You need to iterate on design, and to do that you need to develop. Basically no professional game comes out as it was originally envisioned, and oftentimes a nearly complete version is tossed out because it just sucks too much.

ugh123
1 replies
17h39m

In a more "traditional" software team or even medium sized studio, I think the two are a bit more specialized with individuals focusing on each, still with some influence on the other i'm sure.

meheleventyone
0 replies
11h15m

They are but you’re still working together to make the same thing so the process is intertwined. This is also why you have several specializations for example gameplay engineer or technical designer on larger teams that bridge the gap.

grantismo
1 replies
20h14m

Small twists are great. It's interesting how dramatically different strategies and playstyles emerge from such twists. I made a wordle spinoff which has attracted far more users than I ever would have imagined https://www.polygonle.com

Aerroon
0 replies
15h37m

I'm curious: how did people find out about the game in the first place? Ie how did you attract the first players?

adamrezich
0 replies
20h37m

there's both pros and cons to both punching above and below one's weight, in terms of programming ability. I learned a great deal from working on overly-ambitious projects—both what to do, and, more importantly, what not to do—but it wasn't until much later that I learned the value of making something that seemed, to me, to be "well below my skill level". these days, I can't advocate strongly enough for programmers, especially aspiring game developers, to first set out to do as you say and recreate a simple, already existing game first, then play around with modifying its rules, making its presentation more spiffy, and so on.

people often get enamored with success stories like, "well, [indie game you've heard of] was the first game project [creator] ever worked on, and he spent years working on it and nothing else, and now it's popular and successful and everyone you know has heard of it, so why shouldn't I just go about things the same way?" well sure, you can try to go about things the same way, but there's very, very little guarantee of success in doing things that way—not just in terms of sales or popularity, but in terms of even just actually finishing making what you set out to make. it's often surprising just how much work it takes to implement everything necessary—even for a seemingly very simple, minimal game—and going through the process of figuring out what is needed to make it, and then making it, is an absolutely invaluable learning tool.

this is especially true if you've never done any sort of game design before. some people like to make video games by "paper prototyping" first, and while this is certainly an option, I find that the best, most interesting games are made by a programmer or team of programmers who have an idea, start formalizing said idea into code, and then sort of "discover" the rest of the game's design by exploring the possibility space that the formalized initial design idea provides, by playtesting and writing more code.

but all of this is a lot easier once you have a few finished small game projects under your belt, and learned some of the basic game development insights along the way.

SushiHippie
0 replies
18h40m

FYI the layout is completely mangled on firefox on android :(

https://ibb.co/pJGYF9S

jessecoleman
4 replies
23h38m

Like others in the comments, I also used my pandemic free time to build a game. building a prototype took me a long weekend, but the long tail of adding state management, mobile responsiveness and animations etc has dwarfed the initial development time.

It quickly went from a fun playground for experimenting with mechanics to a long term project. It's been a great learning experience, and still a lot of fun to work on. But the pure creative joy of concepting and building has been supplanted with the tedium of maintenance and bug fixing.

My game for those interested: https://gramjam.app

josh-sematic
3 replies
21h53m

Fun premise! I will note that the dictionary is not as complete as I might hope—it didn’t recognize “tasers,” and there was one other word it rejected that I thought it would get (forgot what it was though). Still, a fun game!

jessecoleman
2 replies
21h35m

https://www.anagrammer.com/scrabble/tasers

You'll find a lot of variation between dictionaries. I was surprised to discover that curating the dictionary is one of the hardest aspects of building a word game. People have a lot of opinions on what should or should not be included, I've spent a lot of time manually filtering out profane and questionable words. Another interesting constraint of this particular game is that unlike Scrabble there's a lot of accidental word discovery, which can create a poor user experience if a bunch of obscure words clear and ruin a player's intended word.

P.S. I will probably add tasers after you flagged it

maaarghk
0 replies
3h44m

I played this for hours last night, I'm going to need to block it :) Set myself a target of 2048 for nostalgic reasons, turns out it takes a long time (for me anyway).

You're right about the dictionary, actually the whole time I kept wondering about how annoying it must have been to choose a dictionary for this game. Even though not accidentally making non-obscure words without noticing is part of the challenge, accidentally making obscure words is annoying!

Maybe I just don't know enough words - but looking through my game log, I was annoyed by "cony", "smit", "huic", "yipe", "nome", "torii", "agon", "mairs", "imido" and "sial", some of which don't display a definition when you click them, but all of which appear in all the scrabble dictionaries referenced on the website you just linked. Meanwhile I was sad to discover vape is so far only in one scrabble dictionary :) And annoyed to discover "oxalic", which is also in all the dictionaries on that site, was not accepted.

I guess there's a spectrum between "advanced scrabble player level vocabulary" and "fun word game", because I imagine (and suspect you have probably had feedback along these lines) _not_ allowing a word which is obscure but still unambiguously used in the modern era would be worse UX overall - the sort that's more likely to make you rage-quit.

I can see why you'd try to get a bit of wordle-esque shareability out of the daily mode even though I like the classic mode more myself. But I think the tutorial popup isn't as comprehensive as it needs to be for someone's first game to be fun. The first time I clicked the link I did an abysmal job at the daily challenge, I think it wasn't obvious that swaps didn't need to be neighbouring like the given example. Something that might be better is to make an interactive tutorial for first-time visitors - come up with a 5x5 board that is quickly solved and demonstrates several strategies and then walk the player through clearing it. I also think the help popup being one click away would be useful.

I would also have liked the help popup to let me know that progress is saved if you close the page, I ended up checking in an incognito window because I had no time to keep playing but wanted to come back and try to reach the target I'd set myself another time!

Anyway - criticism and suggestions aside - well done, it is a fun game and concept!

josh-sematic
0 replies
5h24m

Interesting points for word games in general and this one in particular!

8organicbits
4 replies
1d1h

The quick-to-build game model is quite fun. At the start of the pandemic I created a few games, probably about 30min each. My toddlers got to feel part of the process (which unicode emojis should I use?) and they played the games for much longer than I took to build them.

These are by no means at the quality of the submission, but they were how my kids learned to use a mouse and keyboard.

I definitely encourage others to try making their own. It is fun.

https://alexsci.com/games/ (only works on certain screen sizes, some need a keyboard, no instructions, etc)

netghost
0 replies
22h26m

I had a similar experience! My son is 8 now, and he still occasionally asks me to load up the "game" where you choose an emoji and type a number and it show that many of them on the screen.

It's not "fun", but dad made it and he had a say in how it worked, which is huge for kids.

memalign
0 replies
23h51m

Your toddler game ideas are thought-provoking. Thank you for sharing!

klyrs
0 replies
23h46m

Hahaha, life hack, if my youngster wants more screentime he can spend it playtesting :evil laughter:

dash2
0 replies
20h22m

I really enjoyed Find The Pig!

alexpls
2 replies
14h3m

I've been playing around with the Playdate SDK (https://sdk.play.date) over the holidays and it's awesome for small games like the author describes.

Working with a tiny 1-bit screen and ~150MHz CPU puts some serious constraints on what you can do, which I've found to be pretty freeing (less analysis paralysis, more doing...)

j0hnyl
1 replies
13h44m

first i'm hearing about this platform. how poppular is it? seems so obscure.

sp332
0 replies
12h47m

They sold over 50,000 of them in the first year (by May 2023). Maybe we'll get another sales update this year.

redbell
1 replies
19h30m

Another interesting article by the same author is "Joy of small game development" discussed here https://news.ycombinator.com/item?id=37799387

Yesterday, a game made by this author, called 1D pacman, was trending with more than 1,700 points, available here https://news.ycombinator.com/item?id=38845510

For me, this proves that this guy really knows what he is talking about. Kudos!

j0hnyl
0 replies
13h43m

The pacman game is definitely sticky, it makes me want to try making a "small game"

mteam88
1 replies
23h37m

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...

croniev
0 replies
22h30m

I played and enjoyed the game, getting the hang of it quickly. What confused me though was that the tapping sounds were not always that consistent with the cutting and mainly that from the beat it sometimes felt like a rhythm game that makes sense, but sometimes was just completely off. Or maybe thats just a skill issue.

yrandom
0 replies
23h59m

I think this is a fun and productive way to learn how to code which I why I built https://xcadia.app/ which has lots of examples of simple retro games that you can edit and learn coding from.

sharat87
0 replies
9h54m

My little daughter, and my mother, love playing a little game I made. That made making the game oh so much more rewarding and fun!

It's at https://play.sharats.me.

nxobject
0 replies
10h13m

It’s also worth thinking about other small things to program that are fun in and of themselves - for example, take a vintage photo platform. What fun toys can you create for them? What would it be like to add alt-tab to them, or Exposé?

mortallywounded
0 replies
20h54m

I'm in love with the idea of making games-- it got me into programming. It's an absolute blast to do.

There's nothing quite like grabbing SDL2 and going HAM for a few days. Some of my fondest memories are with lazy foo's tutorials :)

https://lazyfoo.net/

mikhmha
0 replies
18h8m

I've been working on a game since quitting my job. Having some of the most fun in my life doing this. I used to find making games very overwhelming. But some time ago I realized that you can make game mechanics out of anything! There are no rules. Well - the rule is that it has to be fun!

And I played Baldurs Gate 3 a few months ago which really inspired me. I have been playing RPG games for a long time now but I never tried a real "TTRPG", most of my experience was playing JRPG's when I was younger. And I knew about DnD but never felt compelled to try it irl because it seemed "kind of lame". But then I played BG3 and I really understood what "RPG" means. The game made it all click for me.

jvm___
0 replies
17h22m

https://rockpaperscissorslizardsomething.neocities.org/

I had chatgpt make the code for this for me.

edfletcher_t137
0 replies
1d

This is a lovely book, thank you for putting it together! Immediate bookmark.

They really are fun. In fact making small games was my pandemic challenge: I decided that it was finally time to try these things. I ended up building a tool for cutting up and annotating tile maps first - https://tmt.computerpho.be/ - then used it to create a minimal browser city simluator, https://pc.computerpho.be/. These also served as experiments into building single-file "apps" for the browser, which was fun as well!

dimenoz
0 replies
22h21m
cjstewart88
0 replies
23h9m

I enjoy this kind of programming too! Here's one I made a while ago: https://cjstewart88.github.io/n/

araes
0 replies
21h37m

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/in...

JaDogg
0 replies
23h27m

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

GenericCanadian
0 replies
23h14m

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.

FrustratedMonky
0 replies
22h15m

That is impressive number of games And a lot of them look polished enough to publish. Did any make money?