Design Taking some time to make things easier for the long run.

F

fxokz

Guest
In my project it has become increasingly difficult to feel in control of the outcome of my code, I sort of just keep adjusting values until it feels right. I have come to a point where I'm considering to rewrite a fairly large portion of code so that there is :
  • less confusion
  • easier to add new things
  • easier to create variation
  • More control over outcomes
  • efficiency
You see, ideally I would have wanted to program the game in such a way where I wouldn't have to worry about these things a few hours or.. a few days or even a few months into a project. But that to me seems unrealistic even to a master programmer. I don't think anyone perfect in that sense. I always seem to take the easy route to make things work faster and speed up the progression to get to the next thing. But I've slowly come to the realisation that it never works out.

How often do you guys rewrite something that in your game feels fine but in code looks rather disgusting and hard to understand/add to. Also, what's the longest time period you have spent on just rewriting code..

For me it would only take a few hours which is literally nothing to complain about but I thought id bring up the topic since nobody really discusses things like this.
 
I used to be an adventurer like you, then I took- no but really I was the same way lol, especially with my first project. Whatever I could do to make something work, that's what I did. Little did I care about organization or any sort of abstraction at the time. I worked on it for a couple months until I realized it all needed to be redone one summer. Boy was it hell...but even to this day I'm quite glad I took the time to go back and fix everything and make it actually easy to comprehend. If I hadn't done that I probably would've given up on the project, which wasn't an option for me considering how passionate I am on finishing it. Yes it's still a work in progress (I have yet to put it out there for people to see for security reasons, but that time will come). I try to keep my code as readable as possible so that when I go back after taking a few weeks off, I'll know where I'm at.
 

Yal

šŸ§ *penguin noises*
GMC Elder
I also kinda agree on this, it's very easy to "get things done" with kludges and duct tape and sometimes it's more important to get something done AT ALL than getting nothing done, but done right.
Here's my advice:
  • If it ain't broken, don't fix it. Players won't see the code quality, only the game content. Only fix code if it makes things better for YOU, as in, it makes it easier to work on your game.
  • DRY (Don't Repeat Yourself). As soon as you copypaste several lines of code, make a script or loop or something instead.
  • Use arrays and execute_script to keep data and code abstract, you want as little inline code as possible.
  • Use finite state machines, they're easy to extend and you have a ton of control, especially in terms of flow. You can make incredibly powerful state machines with
    Code:
    if(state != noone){script_execute(state)}
    but switch statements work just as fine for small enemies and stuff.
  • When you use a hack, make a comment about it so you're aware of it. Pushing something past the breaking point will break it, and if you're not aware something is wet toilet paper levels of sturdy you can easily do this by mistake.
  • Always make your assumptions explicit, and preferably write them down. Stuff like the first line of a script commenting on what the arguments are supposed to be and which cases are known not to work can save you a lot of headaches later and give you a head start on figuring out what causes bugs you experience.
  • Always try to decouple systems so much you can just drag script files into a new project with no changes whatsoever, that's really handy and a vital part of my workflow.
 

RangerX

Member
That's the thing. There's a "hack" and there's a "fix".
I suggest you FIX things up and not HACK them. If your systems or the way you organised your stuff doesn't let you fix it, then redo/rethink it because it means it wasn't well designed/thought out at first.
This way you will learn to code better, in a more organised manner and your future games will take you TREMENDOUSLY less time to make.

I would only "hack" in the last minutes of a problem if you REALLY need something fixed because of a real reason and you have no choice. Per example, a game you submitted to a console maker like Sony and they report to you that X bug is a "must fix" to them.
 
F

fxokz

Guest
If it ain't broken, don't fix it. Players won't see the code quality, only the game content. Only fix code if it makes things better for YOU, as in, it makes it easier to work on your game.
Yeah everything works 100% perfectly when playing the game etc. but the programming behind it is the equivalent of putting a band aid on a cracked wall.... its literally impossible to add in new things without making it more confusing and hard. that's why I want to completely hack it and redo it and make it better no?

I suggest you FIX things up and not HACK them. If your systems or the way you organised your stuff doesn't let you fix it, then redo/rethink it because it means it wasn't well designed/thought out at first.
fixing is sort of what I mean, I'm going to redesign the programming behind it. not completely change the way things work.
 
Top