as the artist of my duo team, i had to redo a lot of the animated sprites because i'm not that experienced in animation :,)) i tried to wing most of them and learned that the best way to animate for me personally is to block everything out first before making everything pixel perfect :DD and that i should probably try out aseprite because i was animating sprites in clip studio paint x) aseprite has animation tools ive heard!!!! ^-^

• Joe's Actions Text Plugin for PGMMV creates child objects in the default Player Group when displaying text - this info was not in the included guide, and thus I spent maybe a whole day trying and failing to fix enemy AI that just flailed back and forth whenever text showed up on screen (they were set to pursue objects in Player Group). Moral of the story is: if something is wrong for mysterious reasons, check every aspect of your plugins I guess? xD
• Some accessibility things I learned - I need to learn to set up keyboard support because I guess almost nobody has controllers, which was a huge reality check. Also, I need to make games in 30fps from now on. I thought having a high fps would be fine since all my stuff is 2D and light on processing power, but apparently most people can't run even a 2D game at 60fps, so I need to suck it up even if I personally think it looks bad :/
• Also, something that totally changed the way I approach game design was the concept of "multiple brains" for objects or tasks. In short, don't be afraid to just spam controller objects for every little thing so your game can multitask better!

I think some of this might be only applicable to PGMMV and it's own quirks as an engine, but I hope y'all still enjoyed reading it!

Export and test a few hours before the submission. I know there's a few hours left and you could use those to develop the game further, but there's a plethora of things that can go wrong in an export that doesn't happen in an engine build, and the sooner you figure out which bugs are only in the export the better. We had a pretty bad one we found where the game closed when trying to go to the next level or retrying from game over, but we found exporting as a DEBUG solved it. I don't know if this is something we messed up or a quirk of Godot 4.

Additionally Git was a lifesaver, I haven't had the chance to properly use it in a project before because I was a little scared to use it, but it sped up the process a lot! As long as you stick to your branches, discard unnecessary changes, and back up before merging to main, you should be fine. I used the GitHub desktop app and I don't much like it, but it was free. And if you're using Godot, please close the project before pulling!

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. :)

The trouble I had for my game. which is a turn base battle game. is math and having to calculate over and over how much experience a enemy gives and how much damage one of them does for a move and the level to make everything balanced. 

I programmed everything myself outside of the character controller, and brushed aside things like UI since I assumed it would be easy. Sure enough my UI is ugly and boring, and wasn’t even finished. Similar story for the audio.

I have a better respect for the creative side of the game dev process now since it kicked my ass a bit haha. Live and learn