3 ms·

I work on small teams making video games. The hard part is figuring out what to make. The faster you can see your ideas play out in game and process feedback,

I work on small teams making video games. The hard part is figuring out what to make. The faster you can see your ideas play out in game and process feedback, the better. And any given piece of leaf gameplay code, at the time of being written, has a decent chance of being rewritten or deleted. Usually engine/tooling code doesn't work like this, and there's also systems in between the engine/tooling and the gameplay code that are written to make gameplay code very fast to write, and those in-between systems also don't get iterated on like this. But most of the time is spent figuring out what to build by building something and iterating on it, and the perfect commit sounds like an excellent way to not get anything done in this context. I'd like to make 5-10 changes before lunch, play or spectate a playtest in the afternoon, and process feedback afterwards, as well as fit in a design discussion that's not necessarily about anything that's currently being iterated on.

simonw 4y ago
This sounds to me like what I think of "prototyping" in my own process. When I'm prototyping I'm often not working with version control at all - or if I need to track changes over time I'll work in a branch (or sometimes even just a GitHub Gist, which is effectively a cheap separate repo). Once I've prototyped my way to a design that I like, I'll craft a proper commit with tests that captures the new design.
sreevisakh 4y ago
The perfect commit is useful only when you're ready to publish. Development can be chaotic with all the half-done or possibly-wrong code. You don't need to worry about all those standards while you're still developing. The perfect commit is then crafted out of the chaotic development branch by editing the history. I keep the original development branch alive for reference, while the crafted commit is submitted to the maintainer.

simonw 4y ago

This sounds to me like what I think of "prototyping" in my own process. When I'm prototyping I'm often not working with version control at all - or if I need to track changes over time I'll work in a branch (or sometimes even just a GitHub Gist, which is effectively a cheap separate repo). Once I've prototyped my way to a design that I like, I'll craft a proper commit with tests that captures the new design.

sreevisakh 4y ago

The perfect commit is useful only when you're ready to publish. Development can be chaotic with all the half-done or possibly-wrong code. You don't need to worry about all those standards while you're still developing. The perfect commit is then crafted out of the chaotic development branch by editing the history. I keep the original development branch alive for reference, while the crafted commit is submitted to the maintainer.