In game design it is an all too common thing to get an element 80% working, and then decide it doesn’t fit. Or perhaps it doesn’t mesh with who you are doing something else. Or you go in an entirely different direction. The point is that you will have many ideas that get left in the dust. Many might even be fully functional before you discard them. But how you discard them is important.

One piece of writing advice that has always stuck with me is to write the first draft. Then delete that draft and write it again. This stuck with me because I can see the logic of it, but it is so antithetical to how I do things. The logic is that now that you have done the thing it will be easier to do it again, but better this time. And it actually makes a lot of sense. But, a part of me is violently opposed to destroying my old work. If I ever try this piece of advice, instead of destroying the old work I would seal it away out of my reach.

Back to game design, I am a strong believer in making multiple “save states” of my work. These save states are snapshots of different points in development. Often when I make these I need to duplicate all the scripts and prefabs I use so that I can leave the old version alone and largely functional. But what does this have to do with reviving discarded ideas? Simply put, when I discard a piece of code I have written I very rarely delete it. Perhaps I comment it out. Or I leave it in an old version. Or I simply remove the script without changing it at all, just leaving it in a file somewhere for latter. What this means is that if I discard something. Then decide I need it after all later on. It’s always there, ready to be revived.

Eventually, I’m going to have a hell of a time cutting out all the extra files I don’t need in the final build. But in the mean time, I have the entire history of my design process at my fingertips. And that means that while an idea might be discarded, it isn’t gone.

When I need to add a new feature to my game I need to code it in (Duh). But it isn’t always as simple as that makes it sound. Each scene is it’s own world and what I do in one scene does not always translate to another scene. No, if I want something to carry over I need to set it up special. Thankfully I long ago created an object that carries over between scenes, its entire purpose is to carry variables between scenes. But interacting with this object can get a bit weird at times.

One of the main reasons for this is that each time I load a scene my scripts have to go and find that object (Named dataHolder). And you might think this would be simple: “On start find thing” and it is… until it isn’t. You see I discovered something about the Start part of scripts. If you have more than one in a scene they all try to run at the same time. Doesn’t sound too bad, until Script B needs Script A to have set something up, but Script A hasn’t gotten there yet.

My solution? Have only one Start section in my “controller” script and have it access functions of the other scripts that run what their Start sections would have run. But how does this relate back to my dataHolder?

I needed a new variable for volume control, so obviously I would shove that in the dataHolder. But what would access it? Now the solution should be obvious to you, after all I just spent two paragraphs telling you why it is the solution. But my first instincts where to have the script that needed that variable go looking for it. But when that one variable turned into 2 or 3 variables and one needed to be translated from one form to another… not a viable solution. So shove it in the controller.

And I went to do that. And everything just seemed to work. Nice and simple, barely any programming involved. Makes me suspicious any time the solution is so easy. But this time I think it really was that easy. Because I put it in the right part of the interconnected web of scripts.