Games by D W O'Boyle

I think they'd look something like this!

So this is just a bit of a teaser for the game I'm working on. Barely any actual programming has been done for it outside of my project template. My last game also had this same size and it felt pretty good. Like the character doesn't feel too small, the world not too big. I considered going even smaller, 128x72. Honestly that looks kinda cool, but I don't think I'll do that.

So after releasing The One Who Struggles in 2021, I decided to build a template project to get stuff better organized and prevent myself from redoing a lot of stuff. Well I started a new dayjob in 2022 and could not make the time to work on the template anymore. Now I'm having the big game dev itch and have decided to use the partial template to make a new game.

If only I could find where I put the code to change from the initialization room to the first room...

Turns out I was extremely smart and put that code in the Async - Save/Load event. (Now I added that comment after the if statement to remind myself what the heck this code actually is!!) Essentially what this does is wait for the audio groups to finish loading and then go "OK, go to whatever room is the first room!"

I had completely forgotten I had done this. Fortunately GMS2 has a helpful "Search All" feature by pressing Shift+Ctrl+F, otherwise I don't think I would have thought to even look there.

They have their place to describe certain things, but I find myself increasingly using different terminology when thinking about game design -

unpolished ► unfinished

Finishing and polishing are extremely different activities. As every gamedev knows, polishing something is usually the opposite of finishing it. Many of the best games have unpolished features which work just fine and in no way make the experience worse. I find that talking about a feature as unfinished (or unbalanced, or badly implemented) does a better job of communicating the actual problem and what's needed.

During playtesting, every game inevitably gets feedback telling them to scope creep, add detail, sand the corners, etc. Requests for polish are usually not helpful. What are useful are requests to finish unfinished things, fix mistakes, or adjust things which are not working as intended. It will make it easier for us to communciate and give feedback if we separate these two things in language, and stop using 'polish' as a catch all for 'work'.

juice ► gamefeel

Juice is so narrow I feel like it misses the point... We've clearly moved past the screenshake era of indie games, and many of us have discovered how limiting juice-oriented game design can be. Retro games often have very little juice, but still serve up strong gamefeel which devs today are still trying to reproduce.

Just like polish, juice is usually either (A) a thing you try to slap on at the end to make the game seem adequately loved, or (B) a thing you get unnecessarily mired in at the expense of real progress.

Gamefeel isn't something you add, it's something you hone or nurture. Gamefeel comes out of the way core things are implemented just as much as it comes from the vfx and animation. It's the product of a vision for how each piece should handle and interact -- choices which are always informed by the technical, tooling, and labor constraints of the game.

flavor

Every game has gamefeel in a certain sense, but they have different flavors, and some are much tastier. Tbh I think flavor is probably the most useful way to talk about it. Some flavors are familiar and grounding, like a home cooked meal. Some flavors are factory-made, market tested and mass produced to appeal to a broad demographic. Other flavors are acquired tastes, imparting a strong impression which repels unfamiliar palettes.

Personally, I want to make the game which is, like... some really weird spicy fermented stuff you've never had before, which you dont rly love at first, but your friend keeps saying it's the best shit, so you try it and think it's OK, but then the next day you are just craving that flavor, and you start eating it all the time until it eventually becomes a comfort food and you learn how to make your own ferment at home because you need that salty musty taste which made you scrunch your nose the first time you smelled it.

Gamefeel v Juice is spot on. I would rather spends weeks getting the gamefeel right than add screenshake or sprite deforming juice. That stuff can help gamefeel at times, but often are bandaids. Screenshake, in particular should left to specific contexts and often gets put on everything. It's so annoying! Especially since doing screenshake well it really difficult.

I think there's a lot of benefit for gameplay designers to pay attention and learn traditional animation techniques. Stuff like smearing and over-extension can really add to gamefeel more than what "juiciness" can. Yeah, you can't do that stuff programmatically so it takes a different skills/roles, but it's worth doing.

Also an underrated thing is TRAILS. Putting some trailing effects on stuff can really make it look and feel cool. It's kinda a similar idea to a smear, but lasts longer. Like, if you have a homing projectile, put a trial on that shit and it'll look sick as hell every time! Got a pickup that gets magnetized to the character once they get close? Put a trail on it! Don't overdo it, of course, but even a subtle trail effect can help emphasize motion and look good in screenshots.

Another thing that I find a lot of smaller games get wrong about gamefeel is that LEVEL DESIGN is actually part of gamefeel. You're game will feel bad if the controls are often dissonant¹ to the world the character is moving around in. Like I often come across games that have pretty slippery platforming controls but then level design that demands a moderate to high level of precision and that's just not consonant¹! Slippery controls are fine if the game is designed around them. You can make the platforming just as tricky but you'll need slightly wider platforms. Or you could focus more on enemy placement rather than hazards. IE compare something like Super Metroid to Super Meat Boy. Both have wildly different gamefeels but still feel great because their levels designed for their controls.

1. Consonance, Dissonance, and Resolution - If you're not with these terms, they're mainly used in music to describe tension and release.
   Dissonance is basically when things don't mesh well. It's not exactly "friction" though the two are similar concepts. Like friction might be intentionally obfuscating information from the player, where dissonance when design elements work against each other. Dissonance can be a good thing depending on how it's used! It is a neutral term!
   Consonance is the opposite. It's things working in beautiful harmony. It's also neutral. Sometimes it's bad since it can be create situations where the player is relying on the same solution every time. Usually that's why you want to add a bit of friction, new twist, or something that creates temporary dissonance.
   Resolution is Dissonance becoming/giving way to Consonance. In games this can be getting a powerup (like when you get the SpaceJump in Super Metroid for example), changing/removing a hazard, or even just the player getting more familiar with/better at the game (often in the FGC you hear players struggle at the intermediate level between newbies and pros until they have a personal breakthrough. How you design with that in mind, I am not sure though haha).

My previous game, The One Who Struggles, had an alt-fire mechanic for each weapon. I really like the variety of strategy it allowed. Like the rapid fire weapon, Thorn, had a shotgun alt-fire, so you could run up and deal massive damage to the boss before it entered its invincible phase. I would purposefully design situations of the game so each of the different weapons and their alt-fires were useful.

For my next game I was thinking of having a similar system. However, you'll be able to freely aim in 7 directions on the ground and 8 in the air in that game. This limits the types of alt-fires I can put in. All the sudden one that shoots at a different angle isn't as practical since you just aim. There's also the nature of the weapons for this new game. They're very different. It's an interesting problem that I'm excited to solve to be honest.

Hopefully I'll have something to show in a few weeks. I haven't made time to actually program stuff really. This idea was also not part of the original idea so it's a bit of feature creep. Still it's not too bad as I've made the system before.