Hardware Maintenance

Early this week My long used laptop charger developed a fault. It still functioned, but part of the wire was frayed revealing the layer under the rubber coating. Not like it was sparking, but not something I wanted to take risks with either. So until I could get a new charger my work laptop couldn’t really be used as normal. So what to do with the day? Clean my keyboard.

 

I have a pair of mechanical keyboards for my two computers, and I had never cleaned them. I new the idea of how to clean them: remove keys, clean underneath, clean individual keys, replace keys. Fairly simple. But… I had no idea how to remove the keys safely. Then I got a special tool specifically for the job and it was off to the races.

Spent most of the morning cleaning my “work keyboard”. First removing the keys (carefully keeping them in order), then scrubbing under where they were. So much dirt, oil, and other detritus had accumulated that it took some work to get most of it out. Next up was blasting it all with a can of compressed air. As a side note, I’m not sure if I will ever get used to how cold compressed air cans get when in use. With the board itself (mostly) clean I moved onto the keys themselves. Nothing fancy for these, wipe them down with a wet cloth, then dry them with a dry cloth. Got the dirt rings off them and made them shiny again. Only took a few seconds per key, but that adds up for a full keyboard. Just put on a podcast and let the Zen of repetitive action take over.

While I was dealing with the keyboards a thought kept popping up in the back of my head. Near the end of dealing with the second keyboard I decided to check on that thought. And sure enough I was right. Turns out I had a spare charger that had been sitting in a box for several years. So now I have two clean keyboards and a charger in good condition. What happened to the old charger you may ask? Toothpick as a splint to keep that part from bending and some electric tape to keep it secure and safe. Not a pretty solution, but it works as a “new” backup charger.

With everything done, I replaced the keys and had a clean keyboard for the first time in… too long. The difference is like night and day.

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.

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.