MFGG Forums
Game Design Discussion Thread - Printable Version

+- MFGG Forums (
+-- Forum: MFGG (
+--- Forum: Developer Discussion (
+--- Thread: Game Design Discussion Thread (/showthread.php?tid=570)

Game Design Discussion Thread - HylianDev - 02-26-2018

So this is an experimental thread. I tend to not like megathreads but it's a start, and hopefully it causes more specific threads to branch out.

I'd like to start a dialogue on MFGG about good game design. I hope we can have critical discussions about what makes games good, what makes them bad, and how to apply that to your games.

So I'll start out with a few subjects that I think are important to game design, either at its core or as good ways to polish your game:

Accessibility & Obeying Standards

I made these two one point because they sort of go hand-in-hand. Standards are there to make programs as accessible as possible. Things like:

- Standard control schemes, so that people stand a decent chance at figuring out your game's controls without looking at the settings. WASD, Z and X, etc.
- Control customization, so people can make your game fit their style, or work around a broken keyboard or a physical disability.
- Standard aspect ratio. Your game will work at any ratio in windowed mode, but it will only look good at one ratio in fullscreen, and that is your player's ratio. Most monitors tend to be 16:9 widescreen (even phones are pretty close to this most of the time), so I recommend using this ratio pretty much every time.
- Gamepad support. Lots of people own controllers for their PCs now, and the Xbox controller has carved out a pretty sweet standard that's relatively ubiquitous, so this is fairly easy to achieve. I wrote a thread on it on the phpBB forums. "but hylian, none of your games have gamepad support!" yes but all of my games are either made in flash 8, which has no gamepad support, or are Spoopy Mario Teaches Typing, which has no gamepad support for obvious reasons

A good engine is a valuable asset

One thing that the MFGG community has done very right -- whether or not the execution is all it could be -- is that there's a strong emphasis on engines. There's a lot to be said about just sitting down and making your game from scratch, but that isn't always the right thing to do. In fact, if you're making a Mario platformer, why wouldn't you take one of the several pre-existing engines that does a whole lot of great work for you already, and use it to design your game? Reinventing the wheel kills lots and lots of projects.

But the big flaw in our engine-focus community is: everybody is afraid to use them. For several years, the MFGG culture was staunchly against the concept of the "Hello clone", to the extent that people actually believed a good game could never be made with it (which has been proven wrong a time or two). I think this notion is having a negative affect on the fangaming community. If you have a great game idea, and you're good at level design, then not being able to program should not be a barrier to your success (nor should being able to sprite, for that matter, which is part of why the mainsite exists).

Even if you choose not to use an existing engine though, it would help to program your game like one. No, I don't mean that you should recreate every Mario powerup and enemy that has ever existed just for your game. What I do mean is, your code should create usable assets. For example, if you're creating a traditional Mario platformer, you should have a Mario object in your objects that you can drag into the level, and he'll just work. The camera will follow him, he will control properly, etc. The same should go for your enemies, other objects, your level exits, etc. They should all do whatever they're supposed to do without having to heavily tinker with them every time. This helps divide the design process up between programming and level design, and makes the whole process way smoother.

What is some game design advice that you would offer to other MFGGers?

RE: Game Design Discussion Thread - Mariotroid - 02-27-2018

I thought this thread would go into more detail on the design process. Anyway, here's my words on this:

Play around with brainstorming a mechanic. See what you could add as the main core mechanic for your game.

Examples: a hockey mechanic, a punching mechanic, etc.

Brainstorm your protoype.
Determine what enemies will best showcase your mechanic.

Write a design document.
This will help guide you through development and decide what the next steps will be; and also you'll have freedom to write down what you want to do before you develop it. Always refer to your design document and write more into it as the process goes along. Think of it as a guide that helps your game development and that you add to as you add to your game.

Design first levels last as you will know how best to showcase your mechanics.

Finally, make sure you add more difficulty as the game progresses. Simply make it easier for the player to die as the game goes along. So make the level have more density of enemies and more areas open to fall to your death, etc.

RE: Game Design Discussion Thread - Yrr - 02-27-2018

90% of levels in fangames I play are just kinda slapped together randomly, theres rarely any thought into progression, introducing new concepts, or teaching the player mechanics.

Don't be afraid to spread your mechanics out across a number of levels, instead of just introducing them all at once in the first level.
Introduce them incrementally in isolation and then gradually increase the complexity and combine them with other mechanics.

The first instance of a new mechanic should always be the simplest version of it, so you can teach the player how it works before asking them to deal with more difficult/complex variants.

I know Nintendo does it, but don't just abandon your mechanics immediately after introducing them, reuse them in new and creative ways throughout the game.

I would also disagree with the previous post's description of difficulty, you should increase difficulty by testing mastery of mechanics rather than just putting more hazards in.