And I Thought Making the Game was Complicated

So my game is approaching the point of being done. That is to say, while there is always¬†something¬†that can be worked on, it is feature complete and working. I just have a few more features to iron out, mostly quality of life improvements for the player. So, what’s next? Getting it into the hands of players (and hopefully monetizing the thing).

The problem is that actually getting an app on to an app store is a long and annoying process. At first I thought it would be simple: make a profile, submit app, get approval (after inevitable edits), app in store. Simple and straightforward right? Wrong. Even just a cursory glance at the actual process showed me it would be much more complicated than that. Lots of steps to secure the project, steps to make the submission secure, steps to make sure the app isn’t malicious. Add onto that an almost $100 cost to have the honor of being able to submit apps for Apple’s consideration.

At first all of this was paralyzingly overwhelming. Where do I even begin? What does any of this mean? What is going on? But then I calmed down enough to remember the simple fix to being overwhelmed: take it one step at a time. In this case I am aiming for both IOS and Android distribution, so just focus on one for now. Make sure I understand each step before moving on to the next. And try not to get sidetracked and add more to my plate.

Of course, when looking up tutorials on how to do this I found a tutorial on adding ads to Unity games. Something I need in order to monetize the game… Will this ever end?

Trepidation and Momentum

Often with my work I feel a sense of oncoming dread. Not quite full on fear, but anticipation of hardship that leads to anxiety. Hence, trepidation. I know I should ignore this feeling… But you try ignoring gut instinct. Not so easy is it? Usually this comes about when I need to make something new in my project or need to learn a new technique or skill. I just have this expectation that things will go badly. And the “logic” of my fearful mind is that: as long as I don’t start the thing, the bad thing won’t happen. I know this is foolish, I know it is nonsense… and yet…

So where does Momentum come into play? Momentum is the other side of the coin. Once I work myself up enough to get past my trepidation the coin turns to its side. No longer shackled by trepidation I can get work done, but I am not yet fully productive. But if I maintain this long enough I fully flip the coin to momentum. That is when I have gotten so into the work, done thing after thing without stopping, that I don’t have time for trepidation to set in. In that state I simply don’t have the time to think about “What if this goes bad?” and just get on with the work.

Sometimes my work slows down and the coin flips back to its side or even fully back to trepidation. But that is why it is “trepidation and momentum”. Like a rolling stone gathers no moss, once I get moving I have no time for trepidation.

Reviving Discarded Ideas

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.

Navigating the Web of Scripts

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.