Author Archives: Justin Bretschneider

Reviving Discarded Ideas

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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.

What Does A Game Need To Be?

Posted on by

Recently I saw a post online stating that a game does not need to be “anything”. And this argument has some merit, but I think games (and all art) actually have one requirement: they need to be “interesting”. But what does that mean? Because some people don’t seem to understand what I mean when I say that. So here we go.

Lets start with a simple definition of what interesting means. Interesting: Adjective, arousing curiosity or interest; holding or catching the attention. So in short it means to hold attention. But what I mean has a little more nuance to it so lets dive into that.

Lets start with the obvious, games that seek to be sold for profit need to be interesting in order to do that. This does not mean the game needs to be “fun”, “thoughtful”, “challenging”, or “complex” but it absolutely needs to be “interesting”. If it isn’t it gets rightfully left in the dust and forgotten. A game can be a bombastic action piece or a somber reflection on depression. Totally different games for which the only thing they likely have in common is that they are both games and therefore interactive but both can be just as “interesting” for totally different reasons.

In writing this I now see what the “Games don’t need anything to be called games” crowd is talking about. And it is fairly simple. The games that fail to capture attention… are still games, even if they aren’t commercial successes. But my counter argument is that those games were still at least trying to be interesting. However they lacked something, whether that be budget, vision, timing, graphics, playtesting, whatever, that prevented them from capturing the attention of their audience.

But you may have noticed I have made a point of talking about games “seeking to make a profit”, and that is because there is another type of game creation. That is when a creator makes a game for themselves. And I would argue that this game still needs to be “interesting”. Let me explain. When I say interesting that comes in many forms. Yes the primary form is that the final product finds the experience interesting. But when discussing a creation without an “end user” what needs to be “interesting” about it? The process itself. If neither the process of making the game nor the envisioned final product are interesting, I honestly cannot imagine someone creating that piece. (This of course ignores making the game as a job or commission)

And I would apply this to all forms of art. If an artist is making something for their own enjoyment/betterment I can only imagine them doing so if they find the process or goal to be interesting. That could be a painter wanting to use a new type of paint and playing with that. Or the same painter might just really want to paint that one composition just to have done it. Or a rapper might be experimenting with new rhymes just for the joy of the craft. And a game maker might challenge themselves to use a new tool or work in a new genre to get a new experience. But all of these endeavors are sustained by the artist’s interest in their craft. Therefore the craft itself or the final product of said craft must be interesting to, at minimum, the one creating it.

But this might all just be my ADHD brain not processing something that others find blindingly obvious. Perhaps I will try to defend the “games don’t need to be anything” angle next. Perhaps I should, after all it seems to be a shockingly niche opinion for something so demonstrably true.