Our team had good time with this jam. Maybe some fatigue near the end. We are all gamedev students and have done a few games together before so we were already comfortable working together and had a shared idea of the tools we would be using, how we should work, share tasks and what we are going to use.
Some of the things we did I think are important:
.1 Communicate with teammates
I don’t only mean sharing tasks, progress, what tools you are going to use and everything else that goes to project normally. You should also talk about your expectations for the project. Why are everyone participating the jam? To win? To have fun? To learn new things? As differences in these will cause friction in the team. I’ve seen it happen before. How about, if there is a price, how is it shared in case you win? It’s often better to talk it out beforehand so there are no disputes. How about work hours and work time? Are you going to do it together after work/school/etc? By passing notes if some do it in the morning and some in the evening? How about if some can contribute less hours? Will it be a problem for some? For our team we have similar situation in life so it was clear that we would be doing the work during evening for the most part and communicated over discord during our work time. We also talked out the goal of this jam and for us it was to have fun. As for the price. Do as I say, not as we have done. We have not had explicit conversation about it but I’d say everyone has assumed even split in the case we win. I highly doubt there were any other ideas about it at any point.
.2 Using version control
It makes sharing your work easy as long as you know basics of what you should and shouldn’t do and communicate well enough. Rolling back / inspecting breaking bugs in code is way easier as you can compare changes between any versions you have. Works as a backup. My recommendation is ‘Git’ and it is what we used.
.3 Build often and test it on target platform(web, windows, etc.)
It helps to ensure there are no unexpected hiccups with the build. For example the unity player didn’t work as I had thought it would with itch.io and because of this guideline we knew to tinker with it from day 1 to make sure our game works well here.
.4 Submit playable versions early and often enough
This is to make sure you have at least something submitted by the end even if there are problems on your end or on the servers. There were a few teams in this jam that missed their mark on this one and it happens in every jam. At least on itch.io you can update the files until time runs out. Take advantage of that. This is even more important in jams like GMTK which basically break the servers every year on the last submitting hours.
.5 Have something playable quick.
Polishing, testing and fixing bugs often take more time than one might think. We had our games first playable version after the first day. Namely the level itself, the spawners, rats including their ‘AI’, player and killing them but everything was just boxes on screen besides the background. On the second day we had completed everything gameplay wise. Streaming was added as secondary thing to keep track of as smacking rats alone was not that interesting. The remaining 3 days were used to add the art, learning to animate in unity, adding sound effects, polishing, testing and tweaking the game and the UI.
.6 Have it tested by other people
Gamedevs quickly become blind to the rough edges of their darling. We had the game tested by at least a few friends every day to make sure there are no bugs and to see where it could improve. Things like the ‘light’ from streaming setup and the button prompts were added because of the feedback we got. I had naively thought that, “The streaming part is explained in the starting menu, surely people should know how to play”. Of course not. People want to start playing as fast as they can and skip it all. So the prompts were more than necessary to have good experience. We also updated the menu layouts a few times because of feedback. When testing with other people remember to keep quiet at least the first 10-ish minutes depending on game length to see how a player without the dev behind their back would struggle. It can be quite humbling and also quite a struggle to not say anything or help in any way. And as a final note. Bribing testers with snacks can be a good idea and strangers often give more honest feedback than friends and family.
.7 Have a web build if you can
People seem to mostly follow the path of least resistance. So more often than not. Games that can be played as soon as you enter the web page get played more than the ones that you need to download and install to play. At least by my experience. And also the statistics on ‘number of ratings’ in this jam.
.8 Premature optimization is the root of all evil
Jams are one of the few places where you can take enormous amounts of technical debt(make solutions that will hurt you in the long run) and never pay it back. Don’t worry about whether the code is good or not. Just get it working as fast as you can without breaking the game. Players care about the end result and so should you. Not about what’s under the hood. And you won’t be tinkering under the hood more than the duration of the jam anyway. So go wild. Same is more or less applicable to other areas as well. The goal should be best delivery in the given time and theme of the jam.
.9 Take the cheap optimizations
This may sound a counter to the previous one but hear me out. Some things can be optimized by right choices beforehand. There for it won’t cost you any precious time during jam and should be taken. These can range from choice of tools to the specifics of asset creation. For example you might be able to iterate faster with Godot as it seems to be way faster than Unity or Unreal both in editor and with build times. Take that with grain of salt as I’ve used Godot only a little so far. Another is texture sizes. Dimensions in power of 2 will be more optimal for memory usage. I wont be going into technicalities on that. Putting it simply the side lengths should be from the following list but they don’t have to be the same for both sides. [2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, and so on] There are more of these, many won’t be obvious and will depend on platform. So the best way to learn about these is to get to know your tools, platforms in depth and/or talking to more experienced developers about these.
Now all of this is just my opinion and some of it is bound to be wrong at least on individual cases.
THE COMMENT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE COMMENT OR THE USE OR OTHER DEALINGS IN THE COMMENT.
Sorry for the dry humor. :)