Mark Brown from Game Maker’s Toolkit is making a game. After years of deconstructing and providing valuable commentary on what makes games good, Mark is putting his reputation at stake and trying his hand at game design. Mark has tried making games before but never succeeded because he always started making his game from the wrong direction.

What is the right direction? Well… the answer is: Prototypes.

Mark starts with an ill-fated tale of a Picross-style game he made with folders full of pixel art, animations, juicy buttons but there was one big problem: it wasn’t any fun. Mark said it felt shallow, repetitive, and dull. In his own words:

It comes down to making two very wrong assumptions. Assumption #1 is the game always felt kind of cool in my head, so I just kind of assumed the game would be fun when I made it. Obviously, that was wrong. Assumption #2 is that I’m not able to find out if the game is fun until I’ve built the game.

It begs the question, how do you make a game that’s fun? Mark himself has the answer in another GMTK video about The Games that Designed Themselves (that I also wrote about). You have to focus on gameplay. In order for the final product to be fun and exciting, the core game play needs to be fun and exciting. The creator of Mario calls this 手応え (tegotae), which is often translated as “game feel”. To find this game feel, you need to build small prototypes around a single idea, play test them, and then follow the fun. Nintendo does this, indie game devs do this; this is the not-so-secret of the gaming industry.

My previous games… were built with a sort of blind hope that the game would be fun… But now it feels like I’m building on a really strong foundation and so all those other aspects: the story, the music, the artwork; that can be built with faith that the underlying foundation is solid. And so I feel like this is the way to start making games; building a prototype.

I love the part where Mark narcs on himself and says even though he’s figured out prototypes are the answer, he fell back to old patterns of tweaking particle effects, shaders, and UI elements. But he caught himself digging into non-essentials and got back on track. This actually reminds me of a work experience some years back…

I don’t talk about it much, but I was once hired by [REDACTED] to work on a video game that taught kids how to code. It felt like a dream project. I was hopping in late to the project, but saw a beautiful game built in Phaser so even I could contribute. There was one big problem, the game’s core concept — teaching kids how to code — wasn’t fully thought out. The coding challenges didn’t build on each other, there was no learning reinforcement, and we wrote reams of bespoke code to make the challenges work for what was essentially a one-off obstacle. The one thing the game had to do was to teach code, but we were elbows deep in megabytes of assets, sprite sheets, and dialog trees. This was manifesting in performance problems; the game was running at ~12 FPS on my decently powered Surface Pro. When I got asked about adding particle physics, I raised the surrender flag and we had some tough discussions. We did end up playtesting the game to some elementary kids and I forget the exact outcome, but the project stalled out… I think we were out of budget.

I wish it had materialized becuase that could have sent me down an interesting career rabbit hole. The people were great, the vibe was great, but it didn’t work out. I wish I could have showed up a smidge earlier in the process to take part in the prototyping phase. Not because I needed to control the process, but because it’s easier to explore collaboratively in the earlier phases of a project than to suggest sweeping changes and force concessions later in the project. Anyways, prototypes.