Setting up for More Playtests

Last time I talked about feedback from playtests. But that is actually putting the cart before the horse a bit. Because obviously before getting feedback you have to have a playtest. And before you have a playtest you need a test build. And… well let’s pop the stack and start at the beginning.

First step in getting my game ready for playtesting was to remove the development objects. In short I have an object that keeps track of a bunch of data between scenes. This object gets created when you start the game, never unloading. But when testing my game during development I don’t want to navigate all the way through my game just to test a minor fix. So during development I just put that data holder object in all the scenes. There are a few times I have to remove it in order to test some things, but they are few and far between.

The next step was shoring up the “in progress” items. This time it was the settings tab in the main menu. I ended up removing a part of settings that I had thought might be a good idea, but latter developments had rendered unneeded/clunky/over complicated. This left me with a slap dash UI design, but everything is functional so good enough for testing.

After a few more last minute fixes/finishes It was time to make a build. This part was easily the most straight forward. Just click the button labeled “Build Game”, give it a name, and wait for it to finish. Installing it on the target platform was a little more involved, but only marginally so.

The biggest hiccup I encountered was attempting to install the game on one of the target devices. It was an older phone no longer in active use (no sim card) and just getting it set up was a bit of an ordeal. But then the real problem showed up. It just refused to install the game. So, bad news: the main device I was going to let people test the game on won’t work. Good news: I could install it on my main phone, and might be able to find another device to use.

Out of Date Tutorials

One of the greatest strengths of my generation (and the following generations) is that, by and large, if we don’t know how to do something, we just look it up. The internet has put most skill sets a few searches and minutes or hours of research away. Don’t know how to format that file for your presentation? The internet can tell you. Don’t know how to make a resume? The internet has plenty of examples. Don’t know how to change the oil in your car? The internet has plenty of tutorial videos, probably even has one for your make and model.

So why do I bring this up? Because there are plenty of programming things that I have no idea how to do. And so I go look it up. And I usually find a way to do what I am trying to do. Or a way to do a similar thing that gets the job done. Along the way I usually find at least one thing I wasn’t looking for, I didn’t know, and could be very useful.

So, onto the point. I have been getting close to the finish of my game… and finding these last few steps the most annoying, mostly by virtue of going in blind. The step I am working on now is integrating adds into my game, so that I can hopefully make some money from this. But, as the title suggests, the first tutorial I found to do this was out of date. The tutorial was less than a year old, and at first it only looked like some cosmetic UI changes had been made in the process since the tutorial was made. But… once I got to the coding part of the process, everything started returning errors. That is when I knew something was wrong.

But As stated above, I just searched again. Quickly I learned that the tutorial I was using was for version 3 of the integration and the current version was 4.3. Understandably the process had changed significantly. But a new tutorial was quickly found, and the fundamentals were largely the same. It just used different tools to accomplish the same thing. Importantly the new version did allow for more control. However even the old tutorial was not a waste of time. As I learned a useful bit of programming to do something I didn’t know how to do (but which I knew must be possible). And, as with the old tutorial, the new also taught me something I didn’t know. But more importantly this new tutorial explained why it would be useful. After all, simply knowing something is no where near as useful as understanding it.

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.

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.

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.

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.

Old Code. When to change it and when not to

As part of my comment pass on my code I started to notice a few parts of my code I should change. Most of these changes were along the lines of removing superfluous {} pairs in for/if/while statements. These got in because when I am first writing the code I like to have them for definition of the areas and because I am never sure how large a given statement will get. So better to just put it in at the start than to figure out where I need it latter.

However, in going through the code again I realized I could remove a fair number of lines of code(around 10-20 lines in my longer scripts), making things a bit cleaner. I also realized that a small for loop should be in its own function, and called by the game as needed, rather than being in the update section constantly being run.

Now on to the bit of code that sparked this post.

When I was first making this game I had a bunch of ideas. These included having a level editor and being able to share level codes. As such I needed to create a “password” system for these codes. Something that would be abstract enough that a casual user might not realize what was going on but that also carried the relevant data. Then I realized that the base game (all out) was basically a 25 digit binary string. If I took that string and split it up into 4 digit sections (with a trailing 1 or 0) I could then convert those to base 16 (0-9, a, b, c, d, e, and f for the additional numerals). This solved both problems of making the passcodes look like gobbledygook while also preserving the data I needed. (I was also a bit proud of figuring out how to do all the math on my own without using any sources)

When creating the Match puzzle variant it was a simple matter to append a second string for the end state as well as the original start state. Decoding it was a bit more challenging, but simple enough. With all that in place I went about making the 200+ levels for each game mode using this passcode system. By this point I had already abandoned the idea of a level creator, or of ever letting the player see any of these passcodes, but I had a system that worked, so why change it?

Then I made something for which the system would not work.

I created what I call the “Chromatic” version of the puzzle, where each box has 4 states (one “off” and three different “on” states). By the way, it is called chromatic because at first I used different colors to differentiate the states, but quickly changed that as soon as I remembered color blind accessibility, back on target.

The observant have already seen the problem. While the base and match puzzles were basically binary strings of on or off, this new puzzle type didn’t share that simplicity. However, this did not present the problem one might think it would. I simply had the puzzle generate 25 digit codes with 0-3 to indicate a given button’s state. simplicity itself.

Now back to the present. I was looking over my code and re-discovered this discrepancy. The function that interpreted codes for two of my puzzle types was well over 100 lines long, and the function in my “chromatic” puzzle for the same purpose… was less than 20 lines. So I immediately thought “should I just replace this old, outdated, code?” And the answer I came to was: no.

There are two reasons for this. First the less important reason: The code still works just fine. That is not to say it couldn’t work better, but it is functional and not causing issues, which means I don’t have a good argument against the more pressing issue. That being, how long it would take to replace it. Replacing the actual code wouldn’t take much time at all 60-80% of the job would be simple copy and paste work. The real problem is that I have a bit over 400 level codes between the two level types that use this old passcode system, and I would need to either convert them all or make new ones. And that is simply more time and energy than making this “upgrade” is worth.

If I ever find a more pressing reason to make the change I will take that time to do it. But until then this side grade is not worth the several weeks of effort it would take to accomplish.

So when do you not change old, outdated code? When the effort to do so outweighs the benefits of doing so.