Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(+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

(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.