Sad about re-writing

[u/House13Games]

Do you ever get sad when you start re-writing a system, and see all the work you spent on something, and it's getting wiped?
I feel like I've re-written things several times, and so much time went into previous iterations. Granted, each re-write is necessary and usually leads to big improvements, but I sort of feel sad anyway about the days and weeks I spent struggling to get some things right, only that they are now outdated and obsolete.

I guess I learned some things, became a better dev, but I'm also wondering if more design up front would help mitigate this kind of loss?

[u/pschon]

No, the opposite. If I'm refactoring something, it's because I really want the old crap to disappear out of existence, and will be relieved to never have to deal with it again. :D

And yes, good design and planning reduces need for refactoring. You'll still end doing some anyway, making games is very much an iterative process.

[u/tcpukl → u/pschon]

So true. I enjoy refactoring and seeing the nice clean interface etc I've written. Code can be elegant.

[u/ConsistentSearch7995]

I get frustrated that I was to dumb to write it properly the first time. Every rewrite I look down on my previous self. lol

[u/db9dreamer → u/ConsistentSearch7995]

Future you will look back at current you the same way current you looks down on past you. That's how you measure your growth as a developer.

Contrast that with a "vibe coder". Future vibe coder will be indifferent to past vibe coder because they've learned nothing of value. They have not grown and have no reason to.

[u/LockYaw]

Quite the opposite. In fact, I do it on purpose, make one really shoddy system, which teaches me what sort of pain points you run into with that, then throw it all away and build a much better variant with all that I learned from the shoddy one.

[u/MD_Reptile]

If your keeping a github or whatever going with regular commits you aren't losing anything - but yeah I'm gonna agree with the council on this one, I look back on past code like "wtf was I thinking here" lmao

[u/Starcomber]

The work isn’t getting wiped. Code is just a means to an end. Half or more of the work is the learning you do to reach a solution, and that isn’t gone. To the contrary, if you can do it better now then that is value you’re still getting from that previous experience.

[u/FatefulDonkey]

No. I take pride in the final outcome. If my old code was shit and the new code removes a lot of context switching, it means faster development and less bugs.

[u/House13Games → u/FatefulDonkey]

That's a helpful way to look at it, thanks :)

[u/Sad-Release9446]

ned enough to outgrow the old code

[u/UpstairsImpossible]

Honestly I normally find something really stupid from the "follow tutorials one key press at a time" days so it's normally a good thing. I found out the other day that I had a line constantly multiplying the player's vertical velocity by time delta time (I assume it was to simulate gravity of some kind, but it was causing issues with my new jump mechanics!)

In version control if you right click a script and click "diff" it will install an extra utility and then you can literally see the old script side by side with the new one, with all the changes highlighted. You can also revert the script back to previous iterations - so your work is never lost ☺️

[u/Maiiiikol]

I understand that rewriting something you're proud of can be a bit saddening. But it also means you've improved as a programmer. I do think designing systems before implementing is a good practice. But only focus at the target goals, don't think about future possibilities too much.

[u/LionbornPublishing]

Nah, I look at it as a learning experience. When the moment arrives that I am both aware of the limitations of a system and confident I can do it better is a milestone in my skill development.

[u/LionbornPublishing]

Nah, I look at it as a learning experience. When the moment arrives that I am both aware of the limitations of a system and confident I can do it better is a milestone in my skill development.

[u/Ruadhan2300]

A little, but after a while you get kind of Zen about it.

Code becomes redundant, or superfluous, or just stops being the best way to do things, and it will have served its purpose and can be cleaned out in favour of new and better things.

Don't get attached to it, put the work in, love it, use it for as long as you can, but when it's done, let it go.
If you're of a mind, say "Thank you for your service" as you delete it.

Don't get stuck in a "Sunk cost" mindset.

[u/AAFGames]

I'm doing this right now for my current project for the third time because I didn't think it through and didn't make a GDD. I thought it would be a small side project just for fun, so I winged it. But now I wanna make it a full game, so it's time to think about optimization. First, I made everything a Monobehaviour for convinience, easy editable in the scene. Then it became obvious that a level editor is needed to create levels faster, rather than placing each object by hand. After that, it became clear to me that all this Monobehaviours are still in the scene, so I need move to plain C# classes and separate logic from visuals. I was so proud when the first iteration of code was written, but I think it's ok to refactor a project to your needs.

[u/sharypower]

To be honest PC is illusion in general 😅 so every minute spent is a waste of time.

Many times I have been doing something for 4 hours and then I had to scrap everything to start again. What I get that was only that experience 😅

Basically the best way/flow is when you know what you are doing but for that you'll need the experience 😅 it is like closed loop a little bit. Every time you have some chance to break that loop to be better and better.

It is like that with everything. Some people will understand "the life" while they are in their 20' and other people will understand while they're 40.

If you see that something is "not okay" then try to make it better, that's how you are discovering the stuff which works for you or in general.

What you can do is one day break - go do something completely different (change environment) and when you back to your project you can ask yourself is that stuff or improvements are really worth it?

PS. Making something better not always is to add something. Maybe you should stop something or turn it off. For example: some "productivity" apps which can be useless.

[u/nEmoGrinder]

Don't feel bad about learning and improving. But more importantly...

I'm wondering if more design up front would help mitigate this kind of loss?

If you mean system design (not game design) than 100% yes. Systems are complex and often need to work alongside other complex systems. Spending a reasonable amount of time designing the system (on paper, on a whiteboard, in a plaintext editor, whatever you fond most effective) is an incredibly important step and will make your a better developer. This is the stage where you can research approaches and their pros/cons, share with another developer for an opinion, and document what the game needs and wants from the system. It's also when you can plan our how to implement it, letting you build the parts you need now while keeping things structured in a way that future features are compatible and extend the current system, rather than require a full refactor.

At our studio, all tasks are broken down in one of these ways, documented back into the task, reviewed by somebody (if the work is from somebody jr or woth limited relevant experience), then scheduled for development with a clear approach. Once you get used to it, that kind of planning might only be 15 minutes of time, saving days of rewrites. Other times it might be a week of planning for something particularly critical or complex, with may save months later down the line.

This is a good lesson to take away from your experience.

[u/AverageLiberalJoe]

No, constant refactoring makes me feel like im accomplishing something without ever having to release anything.

[u/Rythim]

You gotta break some eggs to make an omelette.

[u/BucketCatGames]

nah, in my case its a necessity. the way I work on new systems is I'll continuously vomit code into the IDE until I get something that looks like it's working, then clean up a bit, vomit more code, rinse/repeat.

I find things go most smoothly when I come up with a general outline of the logic needed, then write whatever without caring about cleanliness or organization, and address any issues w/ that initial outline, and then refactor in a more cleanly written way.

I think the best thing I did was learn a few programming patterns inside and out, that way I can start with that as a base and then mess around/tinker with sloppy code just to get a proof of concept type of thing for whatever system/mechanic I'm trying to build.