Sometimes you need to start over

I don't mean a project, but sometimes it's best to just scrap a script even if it's complicated. I hate to do it and go around about doing all these hacks before I finally give up and start over, but I'm always glad I did it.
Lately, I've been working on this dialog manager for characters. I went through some tutorials that kind of did what I wanted and got something to work. Then the problems started as I needed to modify it even further.
Finally, I realized I had to just start over from the beginning because when I saw it actually working in the game, it wasn't what I really wanted.
It's not finished, but it's such a relief working on it now. I made it expandable so when I parse the dialog, I can add extra code numbers easily to give it different functionality. I'm not limited to how many lines a character, or set of characters, can speak. It's easier to actually write the dialog.
Anyway, I've done this so many times in different games and different languages, but I always end up thanking myself for trashing it and doing a complete rewrite after I got a prototype kind of working.

 

S*** happens that way sometimes. I hate it too, but most of the time it results in easier to read and more maintainable code thanks to understanding the scope and requirements of what I'm working on.

 

Deleting code = deleting bugs! = progress!

 

It sounds like you need to design more before you start coding, wrap your head around the problem. Maybe write a diagram or two of the interrelations in the new system. Refactoring and deleting code is always a good thing, delete an entire system because its unmaintainable is signs of something else

 

I used to have to scrap stuff a lot, it still happens but the difference is it is now a beneficial process rather than a process where I lose a lot of stuff.

The way I go about it now is no matter how fleshed out the idea, even if I have a full GDD, I start by doing some small throwaway prototypes, to get a better handle of what really is involved (work out the unknown unknowns - things you could never have anticipated as you dont know what you dont know lol) and also to get it playable nice and early to ensure its worth comitting to.

These prototypes are not written with reusability, clean code or any other important things in mind, the only importance is placed on speed of getting it playable.

Once ive done that, I throw away those prototypes, rescope based on my findings, and create my final development plan. This plan is usually much more realistic and easier to foretell timings of tasks.

This is called "rapid throwaway prototpying" and its a great practise when used correctly.

 

I do this too for smaller user stories. Or even for sub systems for larger systems. But its a bit counter productive for larger systems for example like an A.I system.

Thats why its so nice to write modular systems so you can easy prototype parts of a system. We do it all the time

 

Its true I would not do this for a larger system as throwing it away would be a waste of time, I usually do this for more simple gameplay elements and getting an overall feel of the game

 

It's only a waste of time if you haven't learnt anything. If you throw it away and replace it with something better than eventually saves more time than the old system, it's a win.

 

I agree with:

If you need to bin an entire system because you suddenly realize it 'wasn't what I really wanted' then I think it would be better to do a bit more planning beforehand, or at least find a way to prototype faster.

If you can't define what you want, you can be pretty sure that the code you write won't produce it.

 

It can be a pretty useful step along the way, though.

 

Isn't this just a less fancy term for refactoring?

Throwing away code and starting over is a normal part of my work flow.

 

What I mean is, you have to know what you are aiming to make, not necessarily what will end up working.

If you know what you are aiming for, you can easily see what the difference is between where you thought the target was, and where it seems like it actually is now that you've tested something.

When you do the above, the next step is usually refactoring, not binning the whole thing.

If the problem is that something turns out to not be fun, I'd say forget about creating a complex system and just build the dialogue UI or whatever with some quick and dirty hard code to see if it's going to be good.

 

It's become a regular process in 3d modeling for me.

Make a rapid prototype, trash it. Make a refined prototype, trash it. Take everything I learned, do work properly.

Sitting and thinking beforehand is necessary, but not too much. There is always stuff you won't know until you get 3/4 of the way into the work. If you spend forever planning, it cannot alleviate that, so it's wasted time.

Being able to think your way through problems before the work is only possible when you are iterating on something you've done many times. If it's new at all, just start working and expect to do things over.

 

Great input, guys. I was just building off some tutorials so no, advanced planning in that stage doesn't work out well because I was just trying to get something that worked. Happens a lot with me. I've found at some point if you don't like the way something is working and it needs to be redone, than the best thing to do is start from scratch and redo it. I can use a small amount of my old code, also. This is just one part of the game, not the entire game.
It really sounds awful, but once I get going on it, it's always easier than I thought. Enjoyed reading the comments.

 

It happens.

You'll have a lot less fun the first time you build your game around a key 3rd party system, encounter bugs you are unable to work around, and then eventually come to the conclusion you have to rip it all out and write your own replacement. You probably used the 3rd party system in the first place due to time constraints or lack of expertise in that area, so good luck

 

If you want to be technical about it all of us fit this description as we're all using a third party game engine.

 

No. Refactoring might involve throwing away bits and pieces, but throwing the whole of something away and writing it again is not "refactoring".

"Refactoring" is taking a piece of code that works and modifying it to increase its quality - readability, maintainability, internal structure - without impacting its output or how other things use that code. If you change how something functions then you are not "refactoring" it, you are "rewriting" it or potentially even "redesigning" it.

Any of which can be a perfectly valid thing to do, but some are harder to get management approval for.

For some classes of problem this is definitely the way to go. For other things I like to implement different approaches or solutions and then trial out each one. Kind of like concept art* for functionality rather than visuals.

* By which I mean what artists and designers do when generating and refining ideas, not the stuff you see in fancy books at game shops.

 

Completely agree, it was already stated in reply #3