[HN Gopher] Making small games, which is fun in itself
___________________________________________________________________
Making small games, which is fun in itself
Author : breck
Score : 235 points
Date : 2024-01-03 14:42 UTC (8 hours ago)
(HTM) web link (abagames.github.io)
(TXT) w3m dump (abagames.github.io)
| 8organicbits wrote:
| 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)
| memalign wrote:
| Your toddler game ideas are thought-provoking. Thank you for
| sharing!
| klyrs wrote:
| Hahaha, life hack, if my youngster wants more screentime he can
| spend it playtesting :evil laughter:
| netghost wrote:
| 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.
| dash2 wrote:
| I really enjoyed Find The Pig!
| prakhar897 wrote:
| 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]
| felipemnoa wrote:
| >>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.
| 3737hdhd7372 wrote:
| 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
| hesdeadjim wrote:
| 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.
| tarruda wrote:
| 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 wrote:
| 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.
| alectroem wrote:
| 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 wrote:
| 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.
| tarruda wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| GuB-42 wrote:
| 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.
| derefr wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| panzagl wrote:
| The first release of Civilization was a board game.
| meheleventyone wrote:
| I don't think the board game and the videogame are
| related other than sharing the name and the former acting
| as inspiration.
| derefr wrote:
| > 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.)
| bcrosby95 wrote:
| 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.
| adamrezich wrote:
| 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.
| grantismo wrote:
| 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
| edfletcher_t137 wrote:
| 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!
| yrandom wrote:
| 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.
| jessecoleman wrote:
| 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 wrote:
| 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 wrote:
| 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
| mteam88 wrote:
| 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 wrote:
| 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.
| JaDogg wrote:
| haha, nice mine are basically what I wrote as demos for Yaksha
| https://yakshalang.github.io/demos/
| GenericCanadian wrote:
| 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.
| cjstewart88 wrote:
| I enjoy this kind of programming too! Here's one I made a while
| ago: https://cjstewart88.github.io/n/
| dimenoz wrote:
| In the same spirit:
| https://www.chiark.greenend.org.uk/~sgtatham/puzzles/
| FrustratedMonky wrote:
| That is impressive number of games And a lot of them look
| polished enough to publish. Did any make money?
| araes wrote:
| 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...
| mortallywounded wrote:
| 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/
| redbell wrote:
| 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!
___________________________________________________________________
(page generated 2024-01-03 23:00 UTC)