41–50 of 87 posts
[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...
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 o…
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!
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
Earlier quoted context omitted.
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 i…
The first release of Civilization was a board game.
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 ga…
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?
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.
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 :)
Earlier quoted context omitted.
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…
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 i…
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.)
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 ga…
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.
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 other…
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 ga…
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!