I’m an indie (and Newbie) game developer working on this game. Being a beginner, the game has bugs and unoptimised codes which makes the game slow. So Should I make a new project and copy paste the stuff from the original project or should I continue fixing the bugs and optimising the game.
Note:- I’m Just a Student so I have busy schedule and mostly can work once a week (but will work that full day/12 hrs) and I want to Publish the game as soon as possible
Engine Used:- Unity Free
Option C. Throw your first game away and build another project.
Like another Idea? I’ve got some nice ideas… but i don’t want to mess the good ones with bugs as a beginner
Bugs are inevitable. What matters is how much time you’re willing to put into fixing them.
Ya… but we can minimise them right?
You’d be surprised how often I’ve forgotten to put a semicolon in my code and I’ve been at it since 1995ish. 
For me it’s always an infinite loop:smile:
Make backup of the existing project, and then make improvements to the existing project. That should be easier than creating a new project and copying assets into the new project.
That’s what I’m doing right now… But the backups never gets used again(I’m lazy to do the same stuff so I update the project even if there’s bug and don’t revert back)
It’s just a matter of practice.
I wouldn’t be in a hurry to release this. If you are new, you need practice. I mean, this isn’t the worst newbie game ever, but it could definitely be better. You just need to practice all your skills until the game is good. And by good, I mean REALLY good.
I would say right now, the core idea of the game could work for some people, I mean lots of people LOVE American Truck Simulator 2. I guess theres something about it thats relaxing. And I feel like this game could have that quality as well.
The biggest thing I think that needs work is the UI. First off it’s using Unity’s default buttons, which is just bad show. And while I like the fact that there seem to be a lot of functions, it’s not intuitive what they all do, because they aren’t all labeled.
It also needs sound. I watched one of your little gameplay videos and it was silent. I don’t know if that was just how you recorded the trailer or if it actually is dead silent. This is not something people think about when they are first starting out, but people will notice a silent game immediately, it’s equally as bad as having terrible graphics. Even if you have to just find train sounds on the internet, find a way to add good sounds. I’d even say people are willing to forgive bad graphics a LITTLE if the sounds are good, especially if it has good music.
Personally, I just imagined the Thomas the Tank Engine Theme watching the train roll around, ha ha ha
So as a student, don’t be in a hurry to churn this thing out, practice with and polish this game until it is awesome, better looking, sounding, and functioning, than any game in the genre you’ve ever seen.
You’ve understood my problem… My project is kind of messy and not managed properly (some of my old codes are very dumb like… Means the code will have repeated stuffs instead of loops and functions). Also the UI is messed up I was like I made the UI while testing the game and didn’t modify or polish it so I’m now I have to do double work
So in that case, think about it like this; What is the time investment?
Would it take you less time to fix what you have, or dump everything and start again. This is something that is hard for us to answer. You know what your code looks like, so you should know how much work it would take to redo everything you’ve done.
If that amount of time seems smaller than the amount of time it would take to just optimize what you have, then maybe it’s a good idea. If not, maybe you should stick with your current code and just optimize it piece by piece until it works better. But this is something you should be able to decide on your own.
There are advantages to both. Maybe if you restarted, it would take you a fraction of the time to get to where you are, and this time it would work siginificantly better and more efficiently than your previous code. Or maybe it’s just how you’re looking at it right now, and fixing it would actually take less time than you think it would.
As someone who has used both approaches on different projects, I think both are pretty valid depending on the circumstance.
I would take a good look at the entire project, and see how much time it would take to fix the problems you identify. If it feels like the amount of time it would take to fix everything feels like it would take longer than just dumping everything and restarting, then maybe thats a good idea.
It’s kinda like if you crash your car. If it costs more to fix your car than it would to just buy a new car, maybe you should just get the new one and junk the old one.
Just a quick note to say something I almost always do in loops (depending on if I am simply looping a static number of times or not… obvious looping from 1 to 100 doesn’t need such things)… is to use a failsafe to prevent infinite loops.
For example, in my current game I am dynamically populating the dungeon levels with treasures and monster spawners.
So here is a bit of my code to randomly populate treasures
int failSafe = 0;
while (TreasuresLeftToBePlaced > 0 && failSafe < 500)
{
failSafe++;
... all of the logic in here
}
Just a loop counter that is part of the loop condition. This particular loop can never perform more than 500 iterations. Now depending on exactly what I am doing that may or may not complete the objective but the point is it can never lock things up by becoming an infinite loop.
Keep your original project & fix it. If you like trains & scenery that’s what you like and you should enjoy it. The hardware and software will catch up to what you envision doing for your game so don’t toss it.
both
I’ve been coding for eight years now, and every single time I open an old project (even a six months old one) I think “Did I really write this thing? How the hell did I manage to make it work?”. Coding is a continuous learning process, whatever you’ll do with your project now will look ugly to your eyes in future. My suggestion is to make it decent, don’t think about the code too much as long as it works, fix the UI, and let some people play with it. They’ll be the final judge for your game, if they have fun, the game is ready. (I am also the kind of person that can’t judge its own work and always think it’s bad). Once it’s published, you can decide what to do with it, if you have a good audience you can keep polishing it and add new features, otherwise you have something great for your CV and a lot of free time for your next project 
I don’t think that ever goes away, to a certain extent. The best advice I can give to anyone new to programming is to develop the habit of writing very detailed comments in your code.
I know people maintaining code I wrote 15 years ago and they always tell me how they initially thought the comments were overkill, but sooner or later all those details saved their bacon. Conversely, I’ve inherited old code with little or no comments and it’s a huge waste of time trying to get your bearings. You’re almost literally trying to get into somebody else’s head and understand how they interpreted a problem – and it’s even worse if that code has years of quick fixes and so on.
If I’m on a team I’ll often even comment other people’s code as I figure out what they were up to.
yeah that’s a good idea…
The worst moment is when you don’t understand your own //comments
Then probably I’ll have to fix my car