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.

So close to the end and still so much to do

Posted on by

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.

Sounds Effects

Posted on by

One thing almost no game can go without is sound effects. And my game is no different… but where do you get those effects? For some things the answer is simplicity itself and others take a bit more creativity.

First up was determining what needed sound effects. My basic first list was: changing level, new puzzles, restarting puzzles, and pressing a play area button. And the last shall be first, for I instantly knew what I wanted to do for the play area buttons, a simple click sound. But where to get it? I could look around online and get a sound generating program or look for free to use sound effects, but I had a better idea. I simply went into my room, pulled up my phone’s recorder app, and recorded flipping the light switch. Transfer the file to my computer, clean up the file format a bit, and presto I have a simple clean clicking sound for my game.

But that left a few other sound effects, and no real easy things I could record to get an sound for them. Which is where I go back to something I mentioned before: a program that makes sound effects. After a bunch of fiddling with that program (random generation within a genre and tweaking things here and there) I got the other sounds I am now using for my game. However I am thinking I might go back in and see if I can make new sounds, now that my theme is decided.

Pruning Levels

Posted on by

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.