The fourth "mentor advice" thread offers some of this year's mentors' favourite development tips and tricks that they've picked up across their years of development experience.

Trevor

3x^2 - 2x^3.  Any time you have a value which goes from [0..1] over time that you're using to control something visual, pass that value through 3x^2 - 2x^3 to smooth out it its rate of change.  Some engines provide this function (or another function like it) under a name like "smoothstep".  I like 3x^2 - 2x^3 because it's easy to remember and works everywhere! 

StraToN

Not exactly a tip nor a trick : learn to use the debugger of your tool, if it features one. This can save your life.

jotson

Don't be clever. Write simple code that works and is easy to read and understand. Clever code takes longer to read and understand when you hit a bug 2 months later and you've forgotten what you wrote. I never write clever one liners when three lines will do. Future You will thank you.

Akien

Embrace the mess. A jam is hectic, and the goal is basically to produce a prototype to test a game idea, and challenge yourself by exploring new skills. It's fine if your code is a mess, if your art is janky, if your story doesn't make sense.

If you do reach a point where you really like your prototype and players resonate with it, it's fine if the implementation is a mess. If you decide to keep working on it, you'll replace the mess gradually with more time after the jam.

Cheeseness

I like to get my menus implemented early. Trying to retrofit a menu that can manage game state in a project where things haven't been written with that in mind is always a lot more annoying for me than feeling like I'm being premature by starting with a menu.

If I'm working with a team, it also lets me get credits in first thing and make sure I acknowledge my collaborators when during a jam, it might otherwise be difficult to prioritise and fall by the wayside at the last minute.