Just as a programming-related aside: When you happen to be working on path-finding, make sure that it’s as self-contained as possible. I’m having a hard time right now trying to refactor some path-finding subsystems so that Marc can deal with a couple of tricky knockback-from-the-other-side-of-the-dungeon prediction problems. Some lazy coding I did months ago came back to bite me in the ass yesterday…

I get what you mean by that, but I have a hard time wrapping my head around the "how to" part. This is one of my biggest fears as a budding game developer: getting into the deep-end of a project and then having things (or the entire thing) break because of a new mechanic or something. Things I may not have even worked on for months and will have to re-learn just so I can fix them.

FDru wrote:I get what you mean by that, but I have a hard time wrapping my head around the "how to" part. This is one of my biggest fears as a budding game developer: getting into the deep-end of a project and then having things (or the entire thing) break because of a new mechanic or something. Things I may not have even worked on for months and will have to re-learn just so I can fix them.

It's like I need an intervention and I haven't even started yet.

Just make stuff. How else are you going to figure out how far to go in either direction?

I just had a set of side-effects end up causing problems because I assumed that the path-finding would never be called when we didn't also want to actually move the player. At the time that was a totally valid assumption and it held true for over 90% of the game's development so far. If I'd insisted on doing it without side-effects in that particular system, it would have taken me a lot longer to write in the first place. Imagine the possible time saved/wasted when that sort of thinking gets applied to every single system in a game... That's what experience is for: To help you make those decisions on the fly.

After I wrote that paragraph I took another look at the problem from a different angle and ended up with a solution in under an hour

dislekcia wrote: Imagine the possible time saved/wasted when that sort of thinking gets applied to every single system in a game... That's what experience is for: To help you make those decisions on the fly.

This. Every single programming job ever is a battle between get it done now or get it done right. Usually doing it right pays off, but it's SO BORING sometimes. Especially when all you want to do is tinker with cool toys and new tricks.

After I wrote that paragraph I took another look at the problem from a different angle and ended up with a solution in under an hour

Also this. I do my best work when I have someone to bounce ideas off or even just to distract myself. It's easy to get tunnel vision when you work alone.