I’ve been working pretty seriously on a project in my spare time for over a year now and I’ve gotten to be pretty good with git. I know that the best practice is to make each commit a tiny change… and I try to do this as much as possible but I keep learning new things that force me to completely overhaul the game architecture. Eventually I’ll get to the point where I’ll have base systems that stay pretty much the same regardless of feature branches. I would really like to get to a place similar to Dwarf Fortress: the creators made the base game years ago, and they’ve just been adding to it ever since as a love hobby. How often do find yourself overhauling your codebase?
Not exactly sure what this has to do with Git.
But the feeling that your old code is garbage and that you can totally do better now is completely normal for beginners, because it shows that you are learning, getting better and have a better understanding of the problem you are trying to solve.
A different approach would be to make small projects that only try to solve one part of your game. For example a test project to play around with navigation. And another test project for playing music in the background while you change scenes. And another test project for building a save system or an options menu etc.
Well I don’t keep overhauling my code because I am getting better as a programmer, I keep overhauling it because I am slowly dialing in on my vision for the game which lets me know exactly what systems deserve to be hyper optimized and which ones are not worth the time.
For example, right now I’m overhauling my world generation pipeline.
I already have a beautiful, working chunking system for pre-computing mesh data (hex grid topology, height maps from noise functions and normals). I am currently able to bring a chunk to screen in ~15ms which is plenty fast. But the problem is that I structured the code around the 3d space when I what I really need is for the core game systems to run entirely on abstract grid logic with a 3D render applied on top. This will allow the game to be much more easily ported to mobile as a 2D / 2.5D version and on desktop as a 3D version because the underlying systems are not tied to godots node API.
I think that overhauling code is bad thing most of the times, because it halts development and creates perfection & micro management within the game
i prefer small refactors in places that i know i use often and that i know might cause ton of problems
Sometimes, if i really need to throw out entire codebase, i realize it’s because of laziness, bad planning, lack of motivation or other reason that makes rewriting seem new and exciting while it’s pretty much negative progress
It depends on situation tho, if you’re making small game, then refactor might be better than if you do giant game you don’t know if you’ll ever finish, why invest in something today that might be forgotten tomorrow?
1 Like
I think that git, with its various tools for amending existing commits, encourages an obsession with a “clean” history. I also think that this is very much a bad thing.
Typically there are only two commits I care about: the one I’m working on, and the previous one. I commit whenever I add a new feature and the project runs, but I don’t care how many other small changes I made while working on that feature. By the end of the day, I’ll probably never look at that commit again, so why bother making it clean and pretty?
I’m not against version control. I use it, and it has saved my ass several times. But I also don’t obsess over it. I make sure that the amount of time version control saves me is more than the amount of time I put into it. Also, I use fossil (which has no tools at all for amending existing commits, by design) instead of git.
1 Like
that is very true. It interesting to think about how even a universally beloved game like Halo 2, with millions of players worldwide, most likely never has anyone scrutinizing its deep inner workings. Theres just not enough time in the world. All the mountains and mountains of work that goes into a video game boils down to the player experience. The feeling of the game is remembered, everything else is forgotten
it a wild art form
1 Like
Hmm. I am not certain that is true. I think the idea is for the change to be about one thing. So this commit changed the player_controller. This commit changed the chunk_manager etc. Not small changes, the changes can be massive, but for one purpose at a time.
I think this is reasonable in a large project, or a mature code base, or with strict practices for larger teams to maintain control and responsibility, but you cannot possibly keep to that as an indie dev developing a game. I think as @rainerdeyke pointed out, for us git is a way to revert back to the previous commit and that is it. I only do commits when a chunk of something I have been working on is now working. But I try to keep my work chunks to a few days at most. I get the game (in whatever state it is in) into an error free and bug free condition, then commit.
I also duplicate projects and create new repositories whenever I am making a big branch change. So recently I changed the player input style from free movement to mouse click input and path finding. When I thought to try that out, I created a new repository, duplicated my project and started implementation. Now I can jump between the two to compare the differences in game feel.
All the time during prototyping. I suppose that is the point of prototyping. For instance I recently thought of a better way to transition between maps. Implementing it meant refactoring the entire chunking system. So I duplicated the project, created a new repository, and started overhauling again.
However, when it comes to making a final build, overhauling is out of the window. The only time then would be if I had done something terribly wrong, and if it happens, it is a disaster as all your planning and timelines go out the window too.
So during prototyping, yes all the time. In final builds, hardly ever and if I do, it really hurts!
1 Like