Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Common Issues and Common Tips Sticky

A topic by AI Sin created Aug 19, 2021 Views: 366 Replies: 7
Viewing posts 1 to 4
Submitted (3 edits) (+2)

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)

Submitted (1 edit) (+2)

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.

Submitted(+2)

Wow, I really respect your dedication to game making (and you tried all the games too, right?)! It's really nice to share all this!

Submitted(+1)

Let us just say close to 10% of the ratings so far are from me. There were some games I didn't play though for various reasons.

I love games, so I want games to reach their potential. I am hoping though that everyone can share their own little bits of advice on issues that they might see.

Jam Host(+1)

Have you considered offering LP-style feedback on YouTube or Twitch? I don't know if you have time, but you have the exact set of skills a good critic needs, especially for RM games (since you seems to really understand the engine).

Submitted(+1)

I definitely want to, but I'm also not very popular, hahaha. I average 2 viewers a stream. Though I do get some people that watch my VODs later (since they can't watch live due to times). I do offer debugging though and that includes potentially streaming the debugging if the dev wants/allows, but I rarely get such requests anymore.

Jam Host(+1)

Thank you for taking the time to write this, as it is a useful collection of tips that anyone here can use to improve themselves as developers. I want to add a few things to this list, then I'm going to sticky this particular topic.

1. Versioning (Iterations): It cannot be overstated how important a beta branch is in game development. Think of it like a gap between your unstable branch and stable branch. Once you have an unstable branch (also called a developer branch) that is clear of any gross game-breaking bugs, but still needs more refined bug-testing, push it to the beta branch. If this is a non-jam game, you'd give your testers (whether it be internal QA or an open beta or whatever) who will test it beyond what you're capable of doing (you're going to be blind to your bugs eventually). Once the beta branch is tested, approved, and ready for the general public, push it to the main/public/stable branch. For contests, your idea is just fine.

2. Playtesting: You go over a lot of amazing points here, but I want to touch on something that a lot of new developers forget about... "halo testing". Whenever you fix a bug, you want to test the areas affected by that fix (like a halo expanding outward). So if you fix a map event, test the stuff the player can do leading up to and after it, as well as anything that uses the same switches or variables. This can considerably increase the length of test time, but it can fix issues that would break your game during runtime that you hadn't even considered.

3. Time Management: I remember that you brought this up on another game's page, and while I agree with it, organization (project management) is just as, if not even more important. Not everyone thinks like you do (using downtime to develop), and not every person can. We're all wired differently, and it's not fair to assume that a person can use bathroom breaks (like mentioned in your post) to brainstorm their game. For example, I'm a lot like you (we used to make jokes that my best ideas came to me while I was on the toilet), but my wife Teal is not. However, everyone can benefit from real project management skills. You don't need to be a SCRUMM master, but you do need to have a good grasp of the concept.

4. Typos: You sum it all up with this line "Another trick is to read out loud when you playtest or re-read your text." This is something I've been using forever with my writing. It works. Every time that I haven't done this, I've made ridiculous errors. Every time that I have done this, I've been as error free as a human can be.

5. Volume Control: This is different for every developer and every player. We had to manually adjust the volume for every game that Teal played before starting the stream or coming back from BRB. You are correct in your advice, and I try to advise defaulting to 60% for RM games' volume, but I wanted to add that streamers should always test their volume beforehand.

6. Points of No Return: I couldn't agree more. You should show it and have it be said in character, though, if at all possible.

7. Pigeonholing the Player: I saw this firsthand in this jam. Teal has a very different way of playing than Hawk, for example, and problems that stumped her Hawk breezed through. And visa-versa. In almost all cases it was because the developer had only allowed for a single solution. Options are key to a good UX.

8. Colorblindness and Deafness Accessibility: Yes. Yes! YES! 100% this! (ahem... moving on...)

(I'm skipping the next several because I essentially agree with what you're saying and can't add much without repeating you.)

9. Realism vs Comfort: My advice is to always err heavily on the side of comfort (most if not all games created by AAA studios follow this metric). People don't play games to immerse themselves in real life, they play them to escape it. Even some of the most realistic physics-based VR games I play (VR usually has to have a high element of realism) allow for more than enough comfort at the sacrifice of realism. So... yeah... comfort wins over realism.

10. Taking Criticism to Heart: Most of my online career with Teal is built on giving feedback, but you hit the high points here. I want to expand on a few things that I hope will help developers in the future. (1) Any meaningful criticism is going to be levied on your project and not you, so don't take criticism of your game as an attack on you, your life, your time, or anything else. It's not about you, it's about your game. (2) Never defend or retort against criticism. Only respond when clarification is needed on either end. If a player sees something in your game, you are far better off trying to understand why they see it that way instead of explaining why it was created that way (unless they ask, of course). (3) The proper answer to any and all criticism is "Thank you for the feedback." If you feel your hackles raise at a piece of criticism, just copy and paste that line, and then walk away. Trust me, you don't want to engage when you're upset, and you definitely don't want to argue. If you think of a clarification point later, come back and ask. (4) Not all feedback can be used, but all feedback can give you insight. If someone trashes your project in a review, you only need to step back and ask yourself "Why?" Unless it's an obvious troll, the answer is not "They're wrong." (5) Never attack. Never. You will get a bad reputation. Streamers, Let's Players, and Game Critics talk behind the scenes. You don't want to get a reputation as "that dev."

Good stuff all around, Al. You've given a lot of great feedback in this game jam. Thanks for participating! :D

Submitted (6 edits) (+1)

My version tips was a bit more geared for contests/jams since this is a jam that I'm posting this for, but you definitely made it more clear for how to do it properly beyond contests.

(Note, the 'you's I use below here are generic and not directed at anyone in particular).

So some further emphasis on things that I think are especially important:

Testing is a very important thing that usually gets skipped or gets a lot less attention than it really needs. People like me who usually become more aware of bugs over time instead of less aware are rare (though things like time and hardware still limit my ability to test. That and bugs are only one aspect of testing). You can call people like me exceptions, really. For most people, you need a variety of testers that can test various problems. You might have your primary testers that will do the preliminary testing, but once they are done, you might want to hire a new tester because someone coming in with a fresh perspective might be able to see bugs that someone too familiar with the product might miss. Beyond just testing for bugs though, you also want people that can test for issues unrelated to bugs. Balance, pacing, and other elements of UX are all important to test for. One thing I highly recommend is that whenever you think you have a stable build, have someone test from the start to the end. A lot of companies rely on level specific testing. This is fine for most things, but sometimes a bug can occur because of something that happens between stages/levels. Maybe the item you picked up from 10 hours ago ends up triggering an event it isn't supposed to in a later stage, for example.

And yes, testing your changes and any possible side effects your changes might have is extremely important. If you don't have time to do a full test, at least do that much!

Yes, project management is extremely important, especially as a project grows. Good project management can really make or break a game project, especially when deadlines are involved! Time management is, in some senses, a small part of project management. I focused on time because a lot of people seem to have issues with that, but project management is very important. Definitely saw a lot of projects where project management could have made a huge difference to the resulting project. 

One tip I have related to project management for jams is to set two goals: One goal is your minimum level. Plan your project to meet that level. This is going to be based on what you are almost certain you can do. Next is your expansion goal. If you have remaining time, what do you want to do? Now, Look at what is common between both versions and these are what you want to work on first, if possible. For example, if battles aren't necessary for you to finish your game (fighters and arcade shooters are examples of when you need battles), you might want a complicated battle system, but are willing to settle for a less complicated system if necessary for time reasons. In that case, you might want to not work on the battle system until later (so you don't have to redo balancing later on). Then, once you've reached the point where you have to work on your battle system to continue, you can look at how much time you have left and set your goals for the battle system there.

This sort of management can be especially important if you are still learning the engine. As you work on your game, you might understand the engine better and this can make the harder parts of the project easier. Think of it like you might want to learn how to kneed clay before you make a bowl. You might want to make a ceramic bowl before you make a ceramic ocarina. Building off easier steps makes it easier for most people to do harder steps. Exceptions apply, but don't plan on being an exception unless you already know you are one. Even if you are an exception, you still might want to start off with the easier tasks because it is motivating to get more stuff done. 

Believe it or not, motivation, morale, and rest are extremely important and are things that I believe should be a vital part of project management.

To go further on attacking your critics, not only will you potentially anger reviewers, let's players, critics, etc., but you might also end up with a bad reputation from other developers, publishers, and even players. It can go further than that as well, so definitely never attack your critics. 

This is really more a rule than a guideline. Let me put it this way, I know people who won't buy certain things because the creator was shown to be very disrespectful/discriminatory to certain groups of people. You also don't want to later on end up not hired because you pissed off some recruiter's brother and that brother told the recruiter all about the incident. Or just as bad, your supervisor goes on youtube and sees you blasting off personal attacks on someone. Even if unlikely, don't think it can't be traced back to you just because you don't use your real name. These are all possible outcomes that are just not worth it over a comment you don't like and caused you to lose your cool.

Also, be aware that a simple difference in perspective can anger someone. Like, I tend to say phrases like 'you want', 'you don't want', 'you should', and 'you need', but there are people that will grow angry with such word choice. For those people, I have to be extra careful that say "I recommend'. Even if I mean the same thing with both word choices, the other party might not see it that way. Even a casual phrase like, "You are beautiful", can be considered sexual harassment (people have lost their jobs due to saying someone was beautiful. One woman adamantly demanded a guy to be fired for basically saying she looked nice).

Basically, this advice goes beyond just reviews, but in interactions with others in general.