Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

It's over! Time to start practicing for next year. What tips/tricks do you have?

A topic by HegerWorks created Jun 02, 2025 Views: 187 Replies: 4
Viewing posts 1 to 3
Submitted(+1)

Hey everyone! 

To all of you who put something out there for the world to see, congratulations. For all of you who tried to get something ready but didn't quite make it to the finish line, also congratulations! No matter what you made, you should be proud. Just putting yourself and your creative skills to the test is hard enough, but showing it to the world is a whole other brutal challenge.  It took me nearly 40 years to finally choose to just go for it, and every stumble on the way has been worth it. I was able to get through almost half of the games submitted before heading out on a camping trip and there were some absolute bangers in there!

Now, to the topic at hand, what did you learn this year? Any tips, tricks that you figured out along the way? Any eye opening revelations you had? What was your overpowered skill that saved the day?

I'll start: 

Don't hard-code yourself into a corner right at the start. Being flexible can save you days of working on something you grow to resent. For example, my first two days were spent putting together a puzzle platformer that I just didn't feel was working after about 10 hours of working on it. Luckily, I had been focusing on the overall necessities of a platformer (movement, collision, interactions, all as external event sheets), rather than the tiny details of the design document I had put together. So when I started some testing and didn't like where it was going, I was able to replan and re-use what I had done already into another platformer scenario. For me, scrapping the first idea after a failed prototype gave me the freedom to expand into something much larger than I expected to be able to get done. 

If you're curious what the first idea was: The title was 'Too Strong to Hug', and it was about a Demon Dad that was coming home from work to give his kid a hug, but on the way he had to lose all the powerups he had gained throughout the workday (ex. if on fire, walk through water) and take enough damage so that he lost his massive stature. Then after that you'd have to go back to work and battle in an arena, where each hero you get hit by can add status effects you'll have to work back off on the way home. So there'd be a balance between the health you need to survive the arena, and the health level you need to be able to give your kid a hug. That idea of balance eventually turned into the core of the rage mechanic in my final game (overpowered by rage = higher damage dealt, lower vision, damages you over time).

Submitted(+1)

This may seem like an obvious one, but try to leave time to playtest your game front to back once you think you’re finished. For example, in my game, I wanted to fix a bug for the win conditions, so I fixed it in one scene and pasted it into the others. I had forgotten that this code included the changing from one scene to the next when you win, and I had copied this from the final level, so now in the GDGames version it’ll bring you back to the menu after only the first level; wouldn’t have happened if I had playtested that level from that point and not just the third one.

Submitted

This is so important. Repeatedly playing through the game (and purposefully dying at times) saved me in the end. At one point the boss spawned every time I entered that room, which was definitely not ideal. I think a lot of us forget to play the game as someone who doesn't know the 'correct' path and we miss how others will experience the game. 

Submitted (1 edit)

Spend at least a day conceptualising your theme ideas before you actually begin coding. That way you have a more certain direction to head in.  Save at least two days for bug fixing at the end. 

Submitted

There is a developer I follow that does a jam (Pirate Software) and for that jam you are required to have a design document. I haven't done that jam but I took the idea of that and did a full design doc workup before any coding started. Even though I ended up changing the game to a new premise, I was able to redo my doc and then follow that to make things cleaner and simpler. I feel without that guiding document I would have tried to add too much on.