# 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.

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.

# Pruning Levels

As I get down to the last few things I need to do, I occasionally find “new” things to deal with. One of those things is something I haven’t dealt with in quite a while: What levels I am including in the finished product.

Initially I had made several passes of generating levels, until I had well over a hundred for each game type (over two hundred for the classic). But, short of going back and generating the hints for each of these levels, I didn’t really pay them much mind while I worked on the other elements of the game (UI design, Backgrounds, transitions, If I would have a tutorial, etc.). So I have decided now to go back through all the levels and prune some of them out.

Mostly this is for the early levels, the levels that are supposed to teach concepts. I thought I had a few too many and going through them again I believe I was right. I don’t want to linger too long on the very early concepts and have the player lose interest in the game before they get to the more engaging levels. But even beyond that I am going through and just discovering that some of the levels are just uninteresting or too similar to other levels and have noted them down for pruning.

Part of my methodology for this is I am going to make a first pass of the levels, note down which ones are up for pruning (and why), and then leave them alone for a little while. After having a short break from that task I will go back in and decide which ones actually need to be pruned. This is so I don’t get overzealous in the moment and get rid of something that would be difficult to recover. Slow and steady, rather than making rash decisions.

# Finishing Touches

I once heard someone say something along the lines of “Finishing the last 10% of a project is harder than the first 90%” and, oh boy, am I feeling that. But why would that be? For me and my project there are several reasons, most of which feel fairly universal to creative endeavors. Even if the specifics get twisted a bit dependent on the medium.

The first bit is setting the details in stone. Throughout the project I have been putting in elements of the game and saying, “that is a temporary label/position/color, I can change it as needed.” But now that I am reaching the end those elements can no longer be labeled as “temporary” and need to have a final decision made about them. Now you might say “That is just putting off the work until latter. Why didn’t you do this stuff sooner?” And the reason is simple: a bunch of my “temporary” elements have changed significantly over time, some of them have even been removed all together. So, if I had “done it sooner” it would have been wasted effort. But now those decisions need to be made… And it is just as much fun as it sounds.

But now for the bigger problem: actually getting my product on the market. And this comes with a bunch of questions. What platforms do I want to target? Do I want to charge for the game? Do I want to put adds in the game? Do I want to make a demo version? All these questions and I haven’t even gotten to the real problem (for me anyway): I don’t know what steps I have to take to get onto a given platform. I know I can just look it up, and in fact have looked up the steps before, but I respond to the process in one of two ways. Either I look at the steps and get overwhelmed, either by the number of steps or by things in the steps that I just don’t understand. Or I look that the process and go “Is that it? You must be hiding something. I must be looking in the wrong spot. Where is the real process!” And I know… I just “need to get over it” … Believe me I am working on just that, these are me problems and I am working on handling them. But in the meantime, I just keep pushing it off. What I really need to do is subdivide the problem and tackle the smaller parts, so I don’t get overwhelmed.

# What Would my Tutorial Have Looked Like?

A few weeks ago I discussed my reasoning for not including a tutorial in my game. But that was not a quick realization, and in fact I had a mostly operational tutorial at one point. But then I changed the UI layout and would have had to completely rework the tutorial… Anyway! So just to get it out there, what did my design for a tutorial look like?

Firstly My tutorial started with most of the (non-play area) buttons hidden. This was to limit the amount of information the player needed to take in at once. The first “level” of the tutorial was the most basic of basic patterns, the cross in the center of the play area. However I did three things to help teach the player. Firstly, I put some text up on screen explaining what was going on. Secondly, used the hint mechanics to highlight where the player was supposed to click. And finally, I disabled all the other play area buttons. This way I could introduce the player to the mechanics of what pushing a button did, while also allowing them to feel like they were making progress. I continued this pattern for a few “levels” moving the puzzle around to demonstrate that the point you click and the surrounding spaces toggled. But that the puzzle did not wrap around, meaning spaces on the edge affect fewer spaces than ones in the center.

After progressing to two move puzzles I introduce he “restart” button and stop disabling the nonrelevant buttons. This allows the player to mess up, to play around and still get back to the start, however I am still highlighting the correct moves for now. After a few of the basic two move patterns are introduced to the player I introduce the next button, the hint button. At this point I stop automatically highlighting the correct moves and let the player decide if or how many moves they want highlighted while also turning the needed moves up to three and (if I remember correctly, it has been a while since I looked at my old tutorial) finally four moves before the tutorial ended.

To summarize my tutorial set out to do four things. First and foremost I wanted to show the player what pressing any of the play area buttons did, some of my early playtesters were strangely mystified by this aspect of the game. Secondly I wanted to explain to the player what the “menu” buttons each did. Thirdly I wanted to introduce some of the more basic patterns found in this type of puzzle. And finally I wanted to introduce each element slowly, so as not to overwhelm with information.

# Controlling Colors and the Night Sky

Something I have been struggling with for my game is this: What do I do for the background? For a long time this was a non-issue as I did not yet have a theme, but one day I decided it needed something more than just a flat color. I tried a few things, but none of them worked very well. Then I found the thing that works, an image in Unity can have a color applied to it and this layers over the existing colors. With colored images this can look horrible, but on a white to black gradient it looks fine. So I popped into PowerPoint, mad a square, and applied a gradient fill from black at the edges to white at the center. After a bit of playing with the ratios I found something I liked and put it into Unity.

Now my backgrounds are a bit more interesting than just a flat color. But I decided I wanted more than that, I decided I wanted the background to react to the current state of the game. As such I had the color progress through a progression of colors dependent on the ratio of moves taken to moves used to create the puzzle and going to black if you go past that number.

This was all well and good, but the sudden change left something to be desired. As part of creating the star fields I discovered a function to have one color fade into another. In the star fields I only used the fading for the alpha value that controls transparency. But for this I needed the actual color changing part of the function. This came with a minor hiccup as I discovered a quirk of the function. In Unity you can layer a color on top of an image, and this color fade function layers another color on top of that. Once I figured that out (took a little while to figure out why the colors didn’t look right) the solution was simple: in the set up for a given scene set the base color to white, then use the function to set the starting color with a transition time of zero. I now have the correct starting color and no extra colors muddying things up.

I had now settled on the technical side of things (mostly, I did do a couple other things I am very happy with. But enough technical stuff for now) and now I needed to choose my colors. I had been experimenting with colors for a while at this point, putting different color progressions in each scene. But to make a long story short I settled on two principles for the background colors. Firstly, I decided to stick to a blue primary coloration, as the sky is blue even at night (it only looks black because of all the “light pollution” from modern electric lights in cities) and as stated in the post about the stars I was now going for a night sky theme. Secondly, was that the colors would progress from light to dark and back to light, mimicking the progression from twilight to night back to the dawn. But with the twist that if you go over the target number of moves it quickly drops to a very dark blue, showing you got lost in the night.

Perhaps I will change some part of this again in the future. But for now I am happy with were I have gotten.