As we move into the last leg of the jam, we invited this year's mentors to share their most important advice for finishing and releasing games in Discord. Here are their responses!
Trevor Powell
Most important piece of advice for shipping projects? Pick a date/time to institute a ‘feature lock’. Sort of a “after this date, nothing new is going into the game” deadline, and you then shift your attention to making what you already have be as good as it can be. Spruce up textures, tweak models (if you can do that safely), and new code should only be bugfixes from that deadline until release.
Gives you a chance to polish and make everything nice, once that constant mid-development churn has stopped.
Cheeseness
My advice on shipping things is to make sure you're stopping and taking breaks. It's very easy to feel like there are gains to be made by sacrificing sleep and rest in order to hit a deadline, but in my experience, having a clear head and being refreshed has dramatically more benefits.
You'll often need to make difficult decisions toward the end of a project about what to trim and what to keep, what to spend your time on and what to ignore, what to polish and what to leave be. People who're running on empty (or worse, running below empty on the borrowed energy that stimulants give) don't make their best decisions or do their best work.
Planning with the expectation that you'll be taking breaks and not overworking yourself also gives you some buffer to work with if you encounter something unexpected toward the end of a project (which almost always happens!) that you otherwise wouldn't have.
mdiluz
I'll offer my advice in terms fixing those last remaining issues but also for future projects from the very beginning, to help in these final stages.
KISS is a principle I try to adhere to in every bit of work I do, I know it as "Keep It Simple, Stupid". The wisdom I take from it is that simple, easy to explain solutions are almost always the best ones, that most of the time the stupidest, most direct or "dumb" way of doing something will be all you need.
Reducing the dimensions of the problem and using a minimal number of variables really does help when it comes to measuring, tweaking and optimising too - so KISS is also the principle way to avoid your system's output quickly becoming chaos and impossible to reason about.
If you take it to its logical conclusion, and I often do, the solution to a problem is sometimes to just let it happen and even use it to your advantage. Not all problems players have, or users find, actually need a fix or a software solution - sometimes it's OK to let players make mistakes, or let users see the cracks in the system so they better understand it as a whole and can work through any future unexpected issues.
Basically, just Keep It Simple, Stupid.
Akien
I guess don't underestimate the time needed to actually make and publish a release. Too often I see people who work on features/bugfixes up to the very last hour and then they struggle getting a functional build exported and uploaded on itch. My advice:
- Test release builds early on, don't wait for the last minute. Especially for Godot, but might be applicable to other engines and framework, things that seem to work in a debug build (running from the editor) might not work in a release build, as a release build is more optimized and less lenient with errors. It sucks to have to publish a debug build with worse performance because you didn't account for these errors during development and your last-minute release build is crashing.
- Remember that you can upload builds early, and update them as much as you want until the deadline. So create your jam page ahead of the deadline, upload builds, get some friends to test them to make sure they run on the platforms you want to support, etc. All this is part of the game development and you need to have that process well oiled to relieve yourself of the stress of possibly missing the deadline for submission. Then you can hack at your game all you want to the very end and just upload new builds along the way.
- If you have some time, give some polish to your itch submission page. It doesn't have to use super fancy custom CSS, but make sure to include some screenshots, and/or video/GIF showing the game in action. Following my previous advice, if your game doesn't include a tutorial / controls overview in-game, make sure to explain the controls on the itch page (but in-game - or both - is better). Give yourself and your team members a shoutout with links to their social accounts, if they want. Some players might want to follow you :)
- If your tech can export a web build, that's also nice to have on itch, but again that's something you should test early on. It has pitfalls for all engines (audio issues, bad WebGL performance on some browsers/OSes - like Firefox on Linux :(, etc.)
kubecz3k
First of all you need to prioritize things correctly, think about what's the difference between a playable game and a half baked prototype, ask yourself following questions:
- Does your game have clear "completion" conditions? Is it possible for the player to achieve them? If not focus on that, there is no game if player cannot win, simplify if you must!
- Do you have any kind of tutorial? Will it be possible for other person on the other side of the globe to just download the game and start playing? It's definitely worth to have tutorial in some form, the beauty of it is, it can be done very quickly, in most cases an image displayed at the beginning of the play will do (bonus points for binding F1 key)
- Releasing a game is not only about programming, keep that in mind and be smart about it Are you trying to tackle an issue for 90 minutes without a success? I will not advice you to go take a walk since most probably you have only couple hours left, but maybe it's a great time to create jam page for the game? Or test the process of generating a playable build?
- So, you got your playable build, the game has a jam page and there is still some time left that you would want to spent on adding some polish to the game? Great! Are there any sounds in the game? If not I think that it will might add the most to the "game feel" with the least effort. Start with some background music it will help to hide the fact there is not so much sounds in your game :) Then add samples for the most common actions like jumping, shooting, dealing damage and voilà! You have just improved the feeling in your game by a great factor!