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.

Rigidity of Design

Often times, when I design something that works I have a tendency of just using that over and over again. One example of this is to copy and paste parts of working code into new code. Usually I need to change something, but it makes for an excellent starting point. But this also applies to UI design. When I find a design that works I have a tendency to try and copy paste it everywhere else. I usually have to tweak it a bit for things like space constraints, but this has the upside of a unified design.

However… as you may have surmised from the title, there is a downside to this. And that is when the old design just won’t work for what I want. Now you would think the answer is simple “Just do something different” and yes it should be that easy. But then comes the “rigidity”. You see, I like the idea of the design being “unified”, of everything looking and acting similarly. So the idea of changing a design that has worked up to this point is a hard one to accept. And I struggled with first one idea that just would not work, then another that was somehow worse. But eventually I got it through my head to “just change the layout of the design”. This gave me the room I needed and actually helped differentiate a specific part of the design so that it wasn’t confusing.

So I guess what I have to say is this: Don’t get stuck in one way of doing things. Even if it works it isn’t always the best choice.

Settings and Menus

Something I have been putting off for a while was a settings menu. I kept putting it off because “How hard can it be?” I figured it would be easy to slap together. And I was half right. The buttons and mechanics of the menu are/will be fairly easy to make. But… the ever looming questions of how to design the thing and what to include are a bit harder to answer.

Lets start with one of the simple ones: Volume Controls. Once I actually started thinking about it I was struck by a seemingly obvious question. The primary target platform for this game is mobile devices, and people tend to just use a phone’s inbuilt volume control when playing games. So… Do I really need a volume control? Or would a simple mute/unmute toggle suffice? Another question: Do I have enough distinct sound effects to warrant individual volume controls? And all these questions for one of the simpler parts of the settings menu.

One of the other problems I am having with the settings menu is another simple question: Where should you be able to access it? Seems simple and straightforward right? Que hysterical laughter of a man losing his mind. At first I was just going to put it on the main menu and be done with it. But some of these options feel like they should be accessible from the play experience (mostly the volume setting). The problem with that is this: The play scenes are already using 80-90% of the relevant screen real-estate and the remaining parts are so desperate that is might as well be 100% use already.

So where would I even put the settings? The two options I can think of are to have the play area temporarily vacate the screen to make room. And alternatively for the settings to just sit on top of everything else with a semi-transparent backdrop to make the settings stand out from the play area. And I don’t really like either option. So that brings up the question: Do I really need the settings to be accessible from the play scenes?

Simplicity in Brute Force Solution

In my game I have a hint system, standard in puzzle games. But my system always gave the hints for a given puzzle in the same order, top down, left to right. I felt this was stale and uninteresting. So I decided to add a random element to the order in which the hints were given. So I tried a method I thought of, involving a nested while loop, several variables, and a random number generator. Everything looked fine… until I tried it out.

It would work for a few presses of the hint button, and then the entire application would freeze. Most frustrating of all however was that when it froze it would not display any of the debug commands I had put into the code. So it was very hard to figure out what was going on. Then I had a brain wave. My first method was selecting one of the hints to display at random, then finding that hint to see if it had already been chosen. In the new method, I chose a random square and checked if it had a hint to display. Basically getting the same result by doing the process “backwards”. In fact this new function was half the length of the failure attempt.

All that to say. Sometimes I get stuck on a solution that I assume must be “the best” and refuse to see other solutions. And often times I see this solution as “the best” because “It is so complex it must give a good result. When I really need to remember an anecdote I learned in High School. The K.I.S.S. principle: Keep It Simple, Stupid.

The Danger of “Temporary” Elements

There is an old piece of advice I remember for writing. It goes something like this: If you aren’t ready to name a character don’t give them an actual name as a placeholder. The reason for this is that if the placeholder stands for long enough you will just attach that name to that character and never rename them, or have great difficulty doing so. You can imagine the clash that can arise in a high fantasy story with Grognar, Lethewin… and Steve. I purposely over exaggerated that example to make a point, but the point stands. But what does this have to do with game design? Everything.

But not directly. It doesn’t really matter what you name things as long as the design team knows what is going on. However, What names you put on buttons, what names you give to play modes, what text you put in descriptions, that all maters. And unless you are careful your subconscious may latch onto the “temporary” element and not want to revise it. For instance, when I put a temporary title on my game’s main menu I also put “Name WIP”. Turns out I used the placeholder name anyway… and don’t regret it, it led me to a theme I like.

But with all that said, my main point is that this can also apply to other elements. More than once I have jury rigged a solution to a programming problem and been reluctant to replace that solution with a more elegant one. Similarly, design elements can be hard to replace because of how long they have stood or how long it took to make them. (That second part is called the “Sunk cost fallacy” and deserves a deep dive of its own.)

The primary solution to this problem is to be aware of it and account for it in your thought process. If you need a temp name use something nonsensical or something like “title goes here”. If you are putting in a temporary element, first ask yourself “Do I really need this now? Or could it wait?” When jury rigging a solution perhaps take the time to just learn to do it right the first time. (deadlines might make this one tricky.) Just remember that “temporary” solutions have a tendency of becoming permeant if left alone too long.

Updates for Work Environments

So… I have been working on this game for a while. Naturally, during that time updates have come out for Unity. And almost every time I downloaded the latest version as soon as I could and updated my project. With one glaring exception. I am still using the 2020 build of Unity.

That build is still getting updates, and I install those whenever I can. But there is now (what appears to be) a fairly stable 2021 version and even a 2022 version available for download. So why wouldn’t I use the latest and greatest version of the engine? For a few reasons as it turns out.

Firstly, when you are in the middle of development you don’t change up the version of a program you are using without a very good reason. Updating always has risks. Perhaps that system you are relying on got tweaked just enough to break one of you mechanics. Or maybe a feature you relied on got changed out for a new one that works differently. Learning these new systems and idiosyncrasies takes time and can bog down a project to the point of an all out stop.

This is not to say you never update a program to a new version. Sometimes those changes that can bog you down? They might be exactly what you need to make something work or speed up production. Or perhaps your target platform changed somehow and the new version can handle that change better. As such, one shouldn’t  dismiss newer versions out of hand. But only done after long consideration.

With all that said, even if the newer version had something that would benefit design work game, I wouldn’t update at this point. The reason is quite simple: I am too close to the end. It makes no sense to refamiliarize myself with the new placement, layout, and controls of the various Unity systems at this point in development. Updates to the current version? Certainly, in fact I downloaded one as I wrote this. But, frankly, rather than speeding up development, at this point the time taken learning new systems could as much as double time I need to finish this project.

So the newer versions of Unity will simply have to wait for my next game.

Nothing Like a Finish Line

When the finish line of a project is in sight a lot of things start coming into stark relief. The first, of course, is the relief you feel that it is almost over. But the next few are the important ones. The next thing you realize is that all those “good enough for now” solutions you had? Yep, need to deal with those. Any niggling doubts about design sitting in the back of your head? Better bring them out and examine them now before its too late. Had any last ideas? Better hurry and figure out if you even want to try them.

In short the finish line, or any kind of deadline, can force you to make decisions about a project that you otherwise might put off as “less important”. Not unimportant mind you, just things that can wait for a bit… and then a bit longer. And before you know it, the finish line is in sight and you haven’t gotten around to them yet.

And sometimes, this deadline can even help you find things you didn’t know you needed to address. For instance, I have been happy with my scene transitions up to this point. But in light of the finish line fast approaching I thought “Could I do better?” And so I tried something new… and loved the effect. And in deciding on that new effect I also chose to change a few other effects I was using.

As the saying goes “limitation breeds innovation.” And that limitation can be almost anything. Limit on the medium used, on budget, style, or even time frame. And nothing is quite as effective a deadline, and therefore a limitation, as the finish line.

So much to check and so many fiddly bits to bop

I have “finished” pruning the levels for my game. In truth I could spend a great deal more time fine tuning what levels I include, but what I have will suffice. And now I move onto the next step. Now I am going through each scene and checking for any scripts I left in place “just in case” but are now unneeded or redundant. In addition I am checking to see that everything is connected properly. While some scripts can find the objects they need themselves, other scripts need to be pointed at the objects they are dealing with. And now I am in the tedious process of ensuring all those links are correct. On top of that a few scripts need to have these lists updated to account for new or changed objects… Which is even more tedious than simply checking that they are correct.

Next up is an effects review. First I will be checking the scene transition animations to ensure all are acting correctly. Then check the various settings for speed and placement to ensure I am happy with it. With that done, I will move onto the question of if I will be keeping a particle effect on button press for the play area. The central question being if it should remain and be updated to a more theme appropriate design. Or if it should be removed entirely.

And the final short term goal: If I should rework the hint system. Currently, hints are given out in a grid pattern starting from the top left and working across each row. Each press of the hint button gives the next hint in line. This makes the hints fairly predictable. Which can be good. But with a certain method makes the puzzles very easy to solve with minimal hints. The solution? I am not sure if it needs one. But if I was going to change the system I would make the hints come out at random. But… that will take a fair bit of tinkering with systems to make it possible. And I am not even sure if it is needed. So for now I just need to think about it while I work on other things.
And even writing this I think I worked out a solution for the “how to make them random” problem. So progress I guess.

So close to the end and still so much to do

So for a while I have thought I was so close to the end of my project. But then I sat down and actually listed out all the things I still have to do. And even then it was not a short list, with several of the steps having long sub-lists. So what are some of those things to do?

The first obvious thing is to check all the scripts in the project. Remove anything unneeded, make sure all the pointers are looking where they need to, and a few final checks on scripts to see they are working the way I want. While this is the first step, I will also likely repeat this near the end. Firstly as a final percussion in case I messed anything up in the meantime, but more importantly so I can make a new project folder that includes only the files needed for the end product. As of now my project folder holds archives of most of the old scripts, scenes, and assets, in case I ever needed any of them. But once I am ready to publish that won’t be needed anymore and in fact might get in the way.

Next up is a review of the effects I am using. Part of this is linked to the script review as much of the effects are controlled by scripts. But I still hold them as different steps because of their different purposes. This step has two objectives. Firstly to check all the transition effects to see they are happening at a speed I want. And secondly to review an effect I added and almost forgot about: a spark effect on activating a play area button. This effect was included to highlight the button the user selected and make it stand out against the other buttons that also changed. However the spark effect was decided on long before my theme was decided and I need to decided if it still fits in the theme, needs to be changed to fit the theme, or needs to be removed entirely.

Next up is fairly simple and to the point: final sound design. Just need to do a review of all the sound effects and make sure I don’t want to replace them.

Then I will be implementing something I have been meaning to include for a while: an options menu. This will include at least three things: volume control, credits, and an option to reset completion data (with a confirmation selection). There is one thing else I might include that effects game play… but I still need to do a lot of thinking about that one.

Once I have everything pretty much the way I want it I will do a review of the UI design. I will be reviewing it with my father, whom I respect in this subject (even if I but heads with him rather often) and who has lots of experience in the field. This will undoubtedly lead to some redesigns and possibly the need to create some new assets, but most of my UI up till now has focused on functionality rather than design, so high time to change that.

After all that I need to get my game in front of some fresh faces for beta testing. Hopefully they won’t have any major feedback. But I also hope they have something I need to change so I don’t get paranoid about having missed something.

Just two steps go and they are fairly related, but one must start with: monetization. The first step will be figuring out how I want to monetize the game. A one time up front payment would be simplest… but with the number of “free” alternatives I would be unlikely to get many people willing to pay. Next up is a free trial that is unlocked by a onetime payment. More likely to get people to download it, but more complicated to implement. And finally is implementing banner ads. I need to look into this option, even if I don’t end up using it, to see how it works. Odds are that this option would require me to rework the UI to make room for the ads. But the advantage is that the game is fully “free” to play and therefore competes on an even ground with the other games in the genre.

The final step is the same for basically all games: publication. This one will require a bunch of tedious research and set up work. Deciding what platforms to publish on. In what order or all at once. What are the different rules and requirements? So on and so forth. Honestly this is the step I dread the most. Not for some “fearing the finish line” reason. But because it includes the most things I am almost completely uninformed about, and therefore most likely to screw up. But that is life, and I will deal with it when I get there… still a bit intimidating.