When it comes to creating video games I’m really really good at not creating them… I am great at starting then, over and over again. It got me thinking, why do I start from scratch every time?
My questions are, do you start from scratch every time when building a new game? Do you have a list of small scripts that you use over and over again to speed up the prototype phase?
My general conclusion is that it’s a very smart thing to have and use small bits (even large bits) of code that one finds him/herself constantly using… like bit and pieces of LEGOs we use regularly to build the foundation of games. Starting from scratch feels silly to me and very inefficient at this point…
Yes, absolutely. Nothing more exciting that starting a new project!
Again, absolutely yes. No point rewriting a state manager, a turn manager, an audio manager from scratch every time. I also many times think “Oh I did this in another project too” and go and scrape the code from there to re-use, although these usually take a bit of refactoring.
That is very common. What really helped me was realising that I am actually prototyping and not creating a polished finished version. Get that hard stuck in your head, and it really isn’t a problem to restart again and again. Also polishing and optimising can all go out the window too.
It is only really a problem if you are still doing this when you are building a release version. Again there I would start again to begin a release version, but you should not be restarting this over and over. Sometimes you do, perhaps once, if you realise some architectural or structural issue arises you had not considered before and refactoring would be a real mess. But if you do at this stage it is a real disaster, pushing back all your timelines and planning.
But when prototyping, starting again and again is great! It is also a lot of fun going back to previous versions to see “Did this new idea really improve things”. Also starting again is sometimes more like duplicating a project before heading off in a different direction. Not actually starting from scratch.
Generally, yes. I copy files & folders from my collection into the game.
AFAIK Godot doesn’t have a good workflow for moving full scenes between projects–it’s very likely that path references will break and it can be a hassle to fix those up sometimes.
Yeah, that’s what I’m thinking about. I was talking to Claude the other day about this very thing and ended up creating a kind of repository of little bits of code.
It started with me wanting to create components that I could use and reuse in lots of my games. And then it also includes little bits of code that are not necessarily components but just good to have. And I have now a really cool little web app that lets me create code and lets me set a verify flag that the code actually ran in Godot. Set categories for what the code does. And the most interesting part of this is that there’s a separate tab that lets me create Scenes quickly so I can quickly grab any node that exists in Godot and add them to a scene, customizing the root Node and everything.
It’s essentially the same as creating a scene in Godot, but I can create several Scenes super quickly and then just export them into my new project and they’re done. I can customize from there… I haven’t actually used this in a real world project so I don’t know if it’s efficient or just annoying, but if anyone would want to try it just let me know!
no matter how good code or how much of it you’ll have, unless you know why you stop making games and start over again you won’t finish them
try to find why you don’t finish projects, maybe you loose motivation when you have to make art, maybe you love the feeling of having fresh start and doing everything perfect this time, really that’s the most important, cuz if you know this, you can fix it, and finish games
100% agree, I mean we can treat things with Band-Aids or like take a pill for a headache but you won’t know the root cause unless you dig deep. Part of it for me is the struggle of dealing with any kind of obstacle, mixed with a lack of self-confidence and motivation when things get hard. It’s a really good skill to have to just be able to push through resistance. The skill of consistency probably pays off more than anything else in life. Just being constant about something and go through with it.
This is part of what I understand for myself and I’m definitely working on it.
I think people see this as “pushing through resistance” but it’s not the case really, discipline is thing you should avoid at all cost and be last resort used on small scale, for most people it causes stress, procrastination and burnout
Better way of working is playing with motivation, things like reward systems, passion, managing dopamine levels through different techniques or just visible progress can motivate you and give you real momentum that will help you finish the project, this doesn’t mean you should only work when you want, this mean you shouldn’t feel you don’t want to work instead
I think reusing small, well-tested systems is one of the best ways to speed up development without losing the flexibility of starting a fresh project. Things like state management, audio, input, save systems, and common UI components are worth keeping in a personal toolkit.
At the same time, I like the point about prototyping. Restarting a prototype isn’t necessarily wasted work if you’re learning from each iteration. The important part is knowing when you’re experimenting and when you’re actually building the version you intend to ship.
I think the biggest point I wanted to make with this post is the value of having a personal toolkit, exactly like you said. It’s not really about whether you start fresh or not. Starting from scratch is fine, and there’s a right time and a right reason for it. But the best use of my time is when I’m building with code I already know works.
It’s kind of like if every time you wanted to play with Legos you had to melt the plastic and remold the pieces first, instead of just using the ones you already made. Maybe that’s a bad example, but that’s about where my head is at…
That’s what got me putting together a repository of my own components and scripts, and it turned into a rabbit hole and I ended up building a whole web app for it. It’s working now, so here it is: Go.HelpYourSelf
Short version:
keeps your own scripts and components in one place, with tags so you can find them
lets you BUILD Scenes trees, attach scripts to nodes, instance one scene into another
exports a zip with real .tscn and .gd files at the right res:// paths
create a folder structure for you so everything is just a drag and drop
@hatmix that last is about what you said about path references breaking and stuff.
The Library starts completely empty on purpose. No built in components or scripts, you build it and supply that from all your old games and stuff. It is all saved in your browser cache and you can export that for a backup. (If you delete your cache history it’s all gone)
Still rough in spots. If you try it and something breaks, tell me. Or if you like it, tell me!! Please. I need to create a video for it to explain things…
This is a really cool evolution of the idea. I especially like that the library starts empty and lets developers build their own collection from components and scripts they’ve already tested in real projects.
The ability to build scene trees and export proper .tscn and .gd files with the correct res:// paths sounds genuinely useful. It could save a lot of repetitive setup work when starting new projects.
And I think the idea of creating a video walkthrough is a great next step—it would make it much easier for people to understand the workflow and see the tool in action. Looking forward to seeing how it develops!
Thanks, that’s very inspiring to hear you say this stuff. It’s exactly how I was thinking when I built it.
But I wasn’t sure how people would feel about it. I’ll work on a video today The important thing is to always export your work so you have a backup of it. It’s all just saved in your browser cache.
It’s better if you’d still be carefull with this library idea, when you start project you need to prototype quickly and you shouldn’t invest into your code much, it’s very easy to change good solution to a overcomplex obstacle
I definitely agree that you have to watch out for overcomplicating things early on! But I think there’s a difference in how the library is being used here.
The point of this library isn’t to avoid writing code forever. It’s to reuse tested, working logic. The key is making sure these are components built with a composition approach, not tightly coupled code full of heavy dependencies.
If a component is written right, it’s generalized, you can attach the same movement or health component to a bird, a dog, or a npc, and it works independently without breaking the scene if you take it out. That’s what actually enables rapid prototyping… that’s my two cents. Dropping in self-contained, predictable pieces that you know already work, rather than building a complex, rigid system that take a long time, every time.
it’s good if you could test that in practice, by that i mean make such library and try making few games, maybe game jams with it, then you’ll have proof it works and how well + what to fix
Please. I need to create a video for it to explain things…