So I noticed that a lot of games have the same issues. For the reason, I’m going to post a series of tips and common issues. Now, these are just from what I’ve seen and there is no ‘one size fits all’, so consider these just advice to consider, not strict rules. (Also feel free to provide your own advice for issues you see)!

Backups and Iterations of Your Game

So my tip here is going to be fairly basic.

When you have a time limit, upload your first working version. With itch, you can use butler, which allows you to first dump all the files you might POSSIBLY need into your project with that first version. This way, future updates will only need to upload additional files and modifications. It is much easier to delete files from your project than it is to upload them.

I upload 3 versions of the game: Archive (This is the very first working version and every major stable version), Stable (This is the current stable version without any major bugs), and Unstable (This is my hourly/nightly upload that is my most up to date version. This is usually unstable because it hasn’t been tested fully for bugs).

If you are working in a team, you might have a fourth version for your development team.

In addition to the uploads, I have 1 current version, 1 or more previous versions of the game (in case something seriously breaks in my current version, I can go back to a known working version), and potentially an off-computer and off-site backup. The off-site backup, I’ll probably backup once a week or once a month. The off-computer backup probably once a day or once a week.

 Basically, in regards to jams, have at least three branches that you upload as you work on your project.

Archive: This is your backup/last resort. This is your first working game or the pieces leading up to that if you don't finish on time. This ensures you have something to show if issues crop up. You can also make a second archive that is your last stable branch (so one 'stable' version before your current stable version).

Unstable: This is your incrementally updated version. This is may or may not work, but it shows your latest progress. Upload this every x hours or upload it before the date changes.

Stable: This is your latest good version that you know works properly. You can always replace this with the unstable version later if the unstable version proves to work fine, but otherwise, this is your entry.

When you are actually working in the industry, you will likely be doing something similar to this anyway, so you might as well get used to it.

Playtesting:

So one advice I have for developers is to set aside some time for playtesting, especially with a deadline. If you have a dedicated playtester, you can get away with a shorter playtesting period, but otherwise, set aside at least 1/5th of your development time for playtesting, with a minimum playtest time set aside of of how long it will take to play through your game three times. The reason is because you want time to fix your game if you find problems. If you happen to reach a point where you feel that you’ve playtested enough, create a backup and upload it. This way, you have something to show if things go wrong later. After you do that, you can try adding to the game and then playtesting. Again, set aside enough time to playtest.

Generally those too closely involved in the creation of something are either too critical or not critical enough.

When playtesting something you've worked on, there are a few things to consider, including:

• Having worked on the project, you are:
  • Better informed about your project than others. What seems obvious to you might not be obvious to others.
  • More used to the project than others. What might seem obvious to others might not stand out to you.
  • More prone to ignoring mistakes, errors, etc..
  • Able to work around mechanics and puzzles more easily due to knowing the intended solutions.
  • Have a hard time seeing alternative solutions due to already knowing an intended solution.
• For effective testing, you want to:
  • Be able to step back from the game. No longer see the game as 'your' game, but as 'some stranger's" game.
  • See the project from the perspective of a player: 
    • With no preconceptions.
    • With preconceptions from similar games.
    • That has just beaten the game.
    • That has spend a long time away from the game.
    • Doing a new run/from a previous game of a series.
  • Be able to consider playstyles different from your own/what you expect.
  • Really want to try to break the game. Look for ways that you can break the game.
  • Try the consider how the game might behave under different conditions. If you have a really powerful rig and a cheap rig, you can do a test on both rigs. If you have just a powerful rig, you can use emulators or other methods to simulate a weaker or different rig. (Like Windows 10 and Windows 7 and Windows XP might all handle the same game differently and have different bugs). One very common issue is the game behaving differently at different FPS values. So like a game might be fine at 30, 60, 120, 144, then break at 146 and higher. A game might also be fine at 300,144,120,60,30, then completely break at 28.
    • Test the game's deployed version. One way to do this is to upload to itch.io as a developer branch (mark it for your system) and use the Itch App. This will allow you to use a mode that should somewhat isolate the game so that you can test it. The benefit of this is that you are testing it in a way that lets you see how the final product will react because the game can act differently under different environments (test vs deployed vs actual environment).
  • Ignore your own personal feelings, but also consider in feelings. 
    • Example of why to consider in feelings: How is a scene supposed to make you feel? How does it actually make you feel? If your MC's father dying is supposed to be a sad scene, but you feel happy about it because the father was a jerk, then the scene isn't working as intended, as an example. 
    • You don't want your personal emotions to cloud your judgement. (Having emotions affect your judgement is normal.)
• For effective fixing of issues, you need to:
  • Understand how bugs and issues happen. The better you understand the problems (and solutions), the faster and more thoroughly you can fix problems.
  • Be able to understand what problems your fixes might cause and avoid those problems.
  • Be able to prioritize what is important and what can wait.
    • There is a development side to this choice: Budget, Time, etc. can affect that side of the decision.
    • You also want to consider in the user/player side of this choice: What issues are the players going to see? What will a player be willing to deal with and what will a player find frustrating to the point of quitting?
    • Balance what the players will want with what makes sense from a developer standpoint.
      • For example, players see new UI as being most important, then sound, then a few minor graphical errors.  Your budget provides enough to fix one UI issue, or two sound issues and one minor graphical error. Your time left allows you to fix two issues. Which do you choose? You could fix just the UI, which the players want most, or Sound and sound or sound and some graphic error. 
        • This is actually more complicated than just that as what will the players find most annoying. When they just started, what will make them quit before giving the game a chance vs what will make them quit over a longer period of time? Which is more important to prioritize? There are many more factors to consider and you also have the issue that you can't spend a lot of time making that decision because that is spending time and possibly money.

That isn't an exhaustive list, but those are some things to consider. I put some of the ones that are harder to do in italics.

Time Management: How you can use seconds of downtime to work on your game.

Okay, so some might know that when I was working on the project, I had a full time job, unexpected overtime, was working on 5 novella for a contest at the same time (technically 6. The rules did change for the contest though so now I have to change them to full novels), my game, several classes, taking care of family, and some confidential things. I also ended up starting about halfway into the jam.

Sounds like a lot? It was! So how did I deal with it? Scheduling and planning. First, I planned what I would have done on x dates. This way, I knew when to cut things short. Basically a part of project management is managing your time and budget and believe me, time is important.

Now, the next thing I did was pretty simple: I used all the time I had. You might think: Of course, that is just what everyone does. Well, I mean I used all the time I had. I went to the bathroom? On my way there and back, I’d be arranging the levels in my head, balancing numbers, adding to the story, etc. I had a break? I’d be working on my games and stories during those times, even while eating. Stop light? I’d also be working a bit there, though not so much that it was unsafe (don’t do this if you can’t pay attention to your surroundings while doing so). Even walking from my car to my door, unlocking my door, etc. I’d be watching my surroundings for danger while working on any little thing I could.

Do note though: Life and Safety first. It is better to fail the project than to lose your life since if you lose your life, you are failing the project anyway.

In my case though, I do have some advantages. I can be doing multiple tasks and several of them can be just automatic, so I can be thinking about my projects while I’m doing tasks. I also lack most emotions of my own (most of my emotions are emulated by copying others), so if something happens, like a friend dies, I can turn off my emotions and keep working. Even without these though, simply taking advantage of even seconds of downtime can help you do more with your projects.

There are other tricks that I can’t talk about that I used, but these aren’t tricks that would help most people. In fact, these tricks would slow down most people.

Typos, layering, and passability.

Typos are very common. One trick that I do recommend is that people try to have their scripts as an external file first. Use an editor with spellcheck/grammar check options (You can also run your json files through a spellchecker/grammar checker if you know how).

Another trick is to read out loud when you playtest or re-read your text. Hiring an editor or such is an option for some as well, but not for everyone.

Layering and Passability are very common issues.

For this, there are some fairly simple testss. Create a custom map for each tileset that uses one tileset you know has full passability. Now, every other square, you put one of each tile, then walk around each tile while trying to enter those tiles. This will let you test individual tiles for passability and layering issues, this way, you know how each tile’s passability and layering works for the next step. (And you can fix any obvious issues before the next step).

For the next step, have each map, but set your speed to maximum. Now, try to test every wall and floor tile. The max speed will let you test at a much faster pace.

Alternatively, if you remember the passability rules, you can visually test this. Just remember one important rule: The TOP layer is what determines passability. So if you have the floor layer, layer 1, layer 2 both passable, but layer 3 is impassable, only layer 3 matters. (Also remember that invisible tiles also have passability rules if they are the top layer!).

Also Alternatively, you can just test each unique wall/floor combination if you don’t have much time. This is what the previous step is for. If you know what to look for, you can test obvious issues for a faster, more focused test.

A very common passability issue is ceiling tiles. Ceiling tiles are passable from the bottom (and with each other), so if you forget to add a wall, you can walk right up into the ceiling tile.

Volume Control.

Yes, I had this issue in mine as well.

Okay, one thing to note: The base RTP’s SE volume is roughly double that of other sound volumes. This is easy enough to solve by automatically halving the SE volume as a base level and then doing fine adjustments.

More difficult will be other volumes as it can be hard to tell when one music is louder than another. This, unfortunately, I don’t have much I can suggest except have a program running that shows you how loud things are and try to keep all the sounds within a certain range of loudness by testing each sound.

Points of no return

This should be a pretty short tip: Warn players when they are going into a point of no return and have the save BEFORE the point of no return, not after.

Also, turn off autosaves for sections where you cannot leave at will or cannot return. This way, your player doesn’t suddenly end up locked and have to start a new game. Players are more likely to give up on your game than to redo everything, especially with longer games.

Pigeonholing the Player

So, for most cases, you want to avoid forcing the player to play a specific way. There are exceptions, such as puzzles and linear story elements, but when you give the player options, make sure the player actually can use all the options (even if some might not be as effective, make sure they all can work). Players tend to not like it when, say, I’m playing a mage class for 90% of the game, then an enemy is suddenly immune to the mage class and I have to play some very specific class that I might not like to beat that enemy.

Players also tend to not like pointless choices. A few pointless choices is fine, but they should provide some sort of value to the player for picking them. A one line difference isn’t really anything of value. Players want their choices to matter.

Colorblindness and Deafness accessibility

Very common issue, but simplest thing to do if you are on Windows 10 is to turn on color filters. Turn on the monochrome (black and white) filter and see if you can see with that filter on. The more clearly you can see, the better. This isn’t a perfect way to do it, but it will at least give you a basic level.

Other things to do are avoid single colors, clashing colors, and low contrast colors when the player needs to be able to see something. Using pure red may cause problems with players that can’t tell red vs green, for example. You might instead introduce additional colors or use a chart to see what is a more compatible color for colorblind players. (Note that there are different forms of colorblindness).

Take me, for example. I can technically see the colors most of the time (I’m not technically colorblind, it is a different issue), but I can’t identify the colors. (I am sometime monochromatic colorblind, but that only lasts for a few minutes each year or so). As part of this, if there isn’t enough of a difference in coloration (not enough contrast), I can’t really see an object even if I know it should be there because mentally, I’m mapping each color to a reference. For example, apple are red, so I’m matching colors to the last apple I’ve seen to identify a color as red. This means anything similar also gets matched as red.

Similarly, deafness exists and deaf players exist. Sound puzzles are a huge issue for deaf players and it is recommended that you add in some sort of visual component for such players.

Brightness/Contrast/Gamma

So one thing for devs to remember is that not everyone has the same screen. What might be bright on your screen might be dark on another screen. This is why some games have images that are designed to be visible at the expected range of values. It is highly recommended that you have these settings if you have images that might be hard to see and to allow these settings to go fairly high/low as some players might have cheaper screens that may not display as well.

Now, if you can’t add in such an option to your game, it is best to err on the side of caution. Keep your visuals high enough contrast that a bit of excessive brightness/contrast won’t make important visuals invisible.

For the most part, don’t have complete darkness. You want the player to be able to see the area and you can do this while still maintaining the mood. There are exceptions, but do consider how a player who has never played the game before and is going in blind might feel. This goes with accessibility.

Now, if you are worried that a player might mess with your settings and make an area too bright and cheese the game, there are things you can do, although I’m not going to go into them here.

Tilesets and logically matching

This is going to be short, but basically, don’t put spaceship parts in a fantasy setting unless intentional and it makes sense within the story. Otherwise, you will get very confused players that feel something is out of place. This goes with any sort of mismatch that might occur, such as using a tree sprite and calling it a waterfall.

(To be continued in replies due to char limit)

Repetition: When is it too much?

Repetition is a commonly used tactic in rpg games in order to extend playtime or to hammer in a point. So when does that become too much? A simple answer is when the player gets sick of it, or really, just before that point.

If you have constant battles and all the battles end up the same, the player will start to tire of battles, especially if they don’t have a goal to push them through that tedium. If you have repeating scenes (see endless eight as an example), it can easily become tedious for the player to keep seeing the same scenes over and over again. Even replayability can suffer if the player feels like they are just repeating the same thing.

Now, some players will have more patience with repetition while others will have less. Your goal is to focus on your target audience though. Will your target audience be okay with the amount of repetition? In most cases, you want to err on the side of less repetition. In other cases, you should have a specific reason for wanting more repetition.

Increasing playtime is a bad reason to increase repetition in and of itself. A player is more likely to enjoy less repetition and shorter gameplay than a longer gameplay that feels like a slog.

Healing. Why to have a source of free healing, why to skip it.

So a very common issue is healing. Healing plays a very important role in RPGs where resources matter and there are reasons to provide it and reasons to skip it.

So first, let us take Demon Souls as an example. Demon Souls did a very fine job at balancing their game for the most part. That said, you’ll notice that they have frequent healing points, but they balance this by making it so that using the healing also resets the enemies. This acts as a sort of balancing factor, which is often a reason why a developer might not want healing - it can be hard to balance. By making it so that certain things reset (and other things don’t) when you heal, this allows a more specific level of balance that is, to some extent, controlled by the player as well as the developer.

Now, some things to note:

Healing methods: There are generally several methods that this is done. Healing at checkpoints, healing at town, healing after battle, and constant regeneration are four common methods. Each has their own advantage. Knowing you will heal after battle can make fights easier to balance and also allow players to feel confident in fighting, which can help reduce the feeling of slog. Simply knowing that a healing point exist can make a player play very differently. Healing by action can add to strategy.

Healing HP: This can be extremely important as this allows your player to grind as needed (especially if there is an element of randomness). This also acts as a safety net if your player makes a mistake. This is why having a free healing (or some safe way outside of battle to pay for healing) is important.

Healing MP: This is a very important consideration if you have a mage type in your playable characters. Mages are often very weak in RPGs, especially in RPGs made by newer developers. Why? MP. Many games have a poor balance with mages and MP. Sometimes the spells cost so much MP that you can’t reach the next healing point before running out of MP, forcing your mage to spend long periods of time fighting with physical attacks, which can be simply annoying and tedious. Sometimes, the spells themselves are just too weak and aren’t really useful, so you end up having to spend more MP anyway. Now, this can be easily solved with MP Regeneration of some form. If your player has confidence that they can keep casting spells with some form of recovery option, they are more likely to feel less restricted with using magic.

Now, why might you not want the player to heal or have free healing? Specific cases, such as a roguelike. You might want the player to die every so often. You might have a game based on the player pushing as far as they can as a challenge run. There are other cases, of course.

Repeating events/Lack of sanitation

Now, some devs know I played a lot of games with my name as \V[1]. This caused some issues/weirdness in some games, especially when some long string was stored into variable 1. While not something most RPGM devs would have to deal with, string sanitation is something that plugin makers might want to consider and something RPGM devs might want to consider in if using a plugin that allows free input. Those that know me know I’ve done crazy names like “\n\n\n\n\n\n\n\n” or “kid, really now. Where are your parents?\nWhat? They let a kid like you wander around?\nWhat irresponsible parents.\nI’m going to go talk to them.” and such then walked around changing chunks of the story.

Now, another common issue is repeating events. Events that repeat when they shouldn’t and lock the player into an infinite loop, events that repeat when triggered even though they shouldn’t repeat because no switch keeps them from repeating, events that repeat whenever you re-enter a map because they don’t have some method of saving the event state. These are common issues to look out for and there are various techniques for having these not reactivate.

Movement speed: The effects on the player when you use various movement speeds

Now, there are benefits to reducing the player’s movement speed, but in many cases, it feels more frustrating for the player to have to move at a slower speed, especially a noticeably slow speed. This means when you slow down a player’s speed, you need to do so with a very specific purpose in mind.

Conversely, there are benefits to speeding up the player’s movement speed, but this can make the player feel rushed.

One thing to note is that these effects can be compounded by map design and size. A large, windy map can make slow speed even more painful. A tiny, straightforward map can make high speed feel even more fast paced.

Now, what this means is that you want your player’s speed to be based on several factors including map size and how natural the speed feels. This is a balancing act in many cases and goes a bit into the next topic.

Realism vs Comfort. When is too much realism bad?

So we all know that many developers and some players are always touting realism. They want the game to be super realistic. Gravity has to be perfect, we want a food system, injuries to individual body parts that have realistic effects!

Okay, let us stop there and examine the issues on the development side. It costs time and potentially money to develop all these systems. Having all of these in a game can also actually limit what the developer is able to do. Maybe you want to add in a system for fighting enemies with weapons. Okay, that is fine, but can a real person actually hold that 200 kg sword? Now, assuming you find someone who can hold that sword, could they actually swing it freely? Obviously no normal person could do so, so now with realism in mind, you need to further consider sword designs. Or you could scrap it and say you don’t need realism there. But see the potential contradiction there?

Looking from the player side, is it really that fun for the player to keep having to find food to eat, exercise in the game to maintain their weight, feel fatigue from adventuring, potentially collapse from built up fatigue over several days, etc.? To a certain extent, it can be, but it goes back to the developer to make this fun and that does take some work.

So there are two things to consider with realism: Budget and audience interest. Even someone who says they want realism might not actually want realism. They want things to be realistic and want a certain level of realism, but once it goes beyond a certain point, they start finding it less fun. This will differ from person to person, but it is something to consider when deciding on how much realism to have.

For the developer, it is a balancing act. You want your world to be realistic (for example, don’t have a monster that is immune to bullets in a cutscene, but takes bullet damage just fine in battle as that will be immersion breaking), but realism can and often should be dialed back when it comes to player enjoyment.

Basically, you want the player to feel comfortable when playing your game and have fun. If adding realism doesn’t add to that or even detracts from that, consider whether or not it is really worth adding.

Taking Criticism to heart. How to respond to criticism.

(Note, I fail at this still, so take what I say here with a grain of salt. Hopefully someone else has some good tips on this subject.)

So one thing all developers should love is criticism. Good or bad, it means someone is willing to give you feedback. Positive feedback tells you what people enjoyed. Negative feedback tells you what people didn’t like or what people think you could improve on. These are both important.

Look at your feedback from a neutral perspective. What is the feedback telling you about your game? How can you implement it? Should you implement it? Would implementation work with your vision of your game? Would the implementation improve the game beyond your vision? These are all just some questions to consider.

Now, one thing I fail at is responding to criticism. Sometimes it is something that I think most devs would agree with - when the criticism is unwarranted and revolves around acting in a way that essentially purposefully breaks the game. (For example, if a bug only happens if you edit a map outside of the game, then that criticism may not be valid (although it could still be)).

Other times, it can be somewhat hard to convey what you want to your reviewers. You might agree with their suggestions and have a hard time to say it. You might disagree with their feedback, but still find it valuable. That can be especially hard to respond to.

One thing I’m trying to do is to say something to show that I did understand their feedback, but to say why I might use it or not use it. This may not be the ideal thing to do, but it is something that is definitely hard to do well.

One thing to definitely not do though (and I can’t say I follow this well enough) is attack those leaving feedback you disagree with. You might disagree with their review, but definitely do not attack them personally. I’ve definitely seen this happen where some dev or another goes out of their way to attack those they don’t agree with. I’ve even seen devs make attacks on things like a person’s appearance, gender, etc. That is definitely crossing the line in any situation, so I don’t know why some devs think it is okay to do so just because they aren’t happy with someone’s review. (Plus, in some places, this may be illegal depending on how it happens).

Even for troll feedback, if you feel like you might end up attacking the person, it might be better to just ignore the feedback instead of responding.

Saves: Why to keep saves plentiful vs limited.

For most cases, it is better to keep saves plentiful. Let your player save anywhere that isn’t a sealed location or point of no return. Do NOT let your player accidentally lock themselves out of progression by saving in a point where they can’t go back.

This is very important because, let us say I enter an area that I can’t leave. You need to be a minimum of level 50 to survive even the weakest encounters, but I am only level 30. If I am able to save and do so, now I can’t leave, can’t load a save to escape, and am not strong enough to progress any further, so now I have to restart from the beginning. Many players will just quit at that point.

Outside of that sort of thing though, you want the player to save often because you never know if maybe the player can only play for 5 minutes at a time. Even if you have to figure out some way to explain it, still let the player save anyways.

Now, there are times when you might want limited saves. For example, maybe you want the player to feel like they are in a stressful environment and can only save so many times. Take horror games as an example. Many horror games limit your ability to save and part of the reason is to add stress to the player.

You might also have a very specific lore reason to limit the saves of the player. Whatever you are doing though, make sure that when you limit the player’s ability to save, to do it very cautiously. Only limit the save ability if you have a specific reason in mind.