Required reading for new developers

[WetWookie]

I keep seeing new developers run into the same issues over and over so here's a list of common issues and their fixes.

If your room seems to bounce when you press reset (or it does funny things with screen capture or streaming) it's because your rooms (or views) are a different size than your 'system' screens (rMenu, rInit, etc...). Make sure the rooms and views are all the same size (800 x 608 or 800 x 600 typically).

If you made a large room and put a camera object in to make the view follow the player and the room gets stretched out of shape it's because the room's view properties are not set properly. Your engine should have come with a template room. If you duplicate that to create your new room all of the settings for the view should be set properly. Otherwise you'll have to set the rooms view properties manually each time you create a new large room.

If you use a portal room as your menu screen where the player jumps into a new game portal or a load game portal it is best to label the portals clearly and put the new game portal farther away (or past) the load game portal to prevent players from accidentally starting a new game and overwriting their existing save file.

Some PCs will crash your game if you play three or more copies of the same sound at the same time. While the player can do some things to fix this issue on their end it's best to avoid playing multiple copies of a sound on top of each other.

If you have secret rooms you need to provide the player with a way of exiting the room without completing it with either a warp or by pressing escape. This prevents the player from getting stuck in an optional room that they cannot (or do not want to) complete.

Projectiles need to be seen easily. Don't use dark projectiles on a dark background (or light on light) and they should have a depth that places them on top of blocks.

Particle effects are nice but can cause issues if not managed properly. If you have an object in a room that uses the particle system you must destroy those particle systems, types and emitters when the object is destroyed to avoid having a memory leak. Additionally you MUST also destroy them in the objects Room End event (or call instance_destroy() in the Room End event). Studio for some reason does not run each object's destroy event when a room ends so you will need to take care of it for objects that use particles yourself.

When choosing aesthetics it is better to be subtle than flashy. Scrolling graphics, heavy particle usage and clashing colors will cause annoyance and eye strains.

Try to get all of your music near the same volume. You can use a free audio editing program like Audacity to adjust the sound levels.



Did I miss anything?

[patrickgh3]

I'll add a list for Studio-specific technical things. Some of these are in the readme of Yoyo's engine.

• Set all your music resources to be stereo. They're set to mono (which degrades the sound quality) by default, which is a poor decision on the developers' part.
  
  
• You must rename your studio project file from the default "Yoyoyo edition" one, or else save files will conflict with other games with that default name.
  
  
• In your Objects folder, make sure the block and platform are ordered above the spikes. The player will collide with objects at the top first.
  
  
• Export your game as a standalone exe or a zip, and not an installer.
  
  
• Consider including the .gmz source code file with your game, or a note in the readme to ask you for it, since there's no full GMStudio decompiler. This is more of a personal opinion, but I think it's overall better to include than not include.
  
  
• Actually read the whole readme of Yoyo's engine.
  
  

And some general things.

• Playtesting is super important. If you spend 100 hours making a game, you don't want a few segments to be huge roadblocks or a mechanic to be confusing. Spending like 5 hours working with playtesters and changing things can make your game be twice as enjoyable, not exaggerating. It can be easy to overlook playtesting when you're finishing your game and you're exhausted, but you absolutely have to have other people play your game and point out things you can't see. Hm, it might be nice if someone wrote a longer piece about playtesting fangames.
  
  
• Don't be shy about asking for help or tips. We have a lot of experienced and friendly game makers in our community that would be happy to point you in the right direction. The forums, the community Discord, or asking people directly on skype or discord are good places. Relatedly, you usually shouldn't post your problem or question in stream chats. It's not the place, and it kinda clogs up the chat and is annoying.
  
  

This is a good idea for a thread, thanks Wetwookie. If people post more stuff it might be nice to compile it in the first post.

[Kyir]

I've already written an excessive amount for new developers, so I'll just say all these points are solid and leave it at that.

[patrickgh3]

Here are some notes that aren't critical, but are good to keep in the back of your head.

Make your game stream-friendly

• Keep the stream bitrate in mind and don't make visual effects too crazy. For example, the VVVVVV boss in Classic looks fine on video but bad on stream. Most of the time this isn't an issue, but it's good to keep it in mind.
• Be aware that certain songs get parts of twitch VODs muted. It's a tradeoff between having music you want and being able to listen to VODs.
• Don't include inappropriate content that puts streamers at risk for being banned. It may be funny or artistic, but being able to stream games is more important than that.

Make your game speedrun-friendly

• Avoid RNG having too big an impact on time. For example when making a boss don't make one attack it can choose be twice as long as another. This also makes casual play feel better.
• Consider making cutscenes skippable or fast-forwardable. This also helps casual play since some people don't care much for cutscenes.
• Don't sacrifice parts of the casual play experience for the speedrunning experience. For example the grass encounter RNG in the pokemon area of run the marathon kinda sucks for speedrunning, but it makes casual play more exciting, so we kept it. I also think if you focus too much on making your game speedrun-friendly you'll be let down if no one speedruns your game, so I'd leave speedrun-related tweaks as afterthoughts rather than early-on decisions.
• When bugs and skips are discovered (and they will be), think carefully and consult with people who have run your game. Sometimes these exploits make the run interesting and sometimes not. You don't want to backstab runners by invalidating all times when it's not necessary. And if you do update, do it as soon as possible to minimize invalidated times.

[Derf]

Good thread. A few thoughts:

When choosing aesthetics it is better to be subtle than flashy. Scrolling graphics, heavy particle usage and clashing colors will cause annoyance and eye strains.

I agree with the general principle that graphics should never detract from gameplay, however what you say here isn't really true. It's very possible to pull off flashy graphics, contrasting colours, heavy particle usage & scrolling graphics without them causing annoyance or eye strain (though probably not all at once). The underlying principle here is solid, but I think this is less of a rule and more of a preference on your part.

Export your game as a standalone exe or a zip, and not an installer.

I think when people do this it's just because they haven't worked out that GM:S picks NSIS installer as its default export type; it's worth mentioning to newcomers that you can click the drop down to select a runtime application (.exe).

Don't include inappropriate content that puts streamers at risk for being banned. It may be funny or artistic, but being able to stream games is more important than that.

Though, to some people it's not. This is a good warning to those unaware, but for some (including myself) streaming ability is far less important than artistic coherence.

Playtesting is super important. If you spend 100 hours making a game, you don't want a few segments to be huge roadblocks or a mechanic to be confusing. Spending like 5 hours working with playtesters and changing things can make your game be twice as enjoyable, not exaggerating. It can be easy to overlook playtesting when you're finishing your game and you're exhausted, but you absolutely have to have other people play your game and point out things you can't see. Hm, it might be nice if someone wrote a longer piece about playtesting fangames.

Great point. To expand on this though, be discerning about who you pick to playtest. You want a good slice of skill level from your testers to ensure the game is interesting enough for hardcore players but not impossible for novice players & that the difficulty settings reflect this accurately. Obviously this isn't true if you're purposefully making a very hard game, but I think most people want to open their games up to as wider audience as possible.

Another thing to be mindful of when picking testers is if you're exclusively using friends. Sometimes it's hard to be fully honest with someone when you like them and don't want to hurt their feelings. If you think your playtesters might be holding back, push them to be more critical and try choosing people you are less close to in the future. Sometimes streamers like Stonk & Paragus can be good for this as you're getting their live reaction (though the chat should be taken with a pinch of salt in situations like this).

Also a longer piece on playtester both for what to do if you're a playtester & if you're the creator would be cool, yeah.