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.

Tutorial or No Tutorial?

For a while I thought my game would need a tutorial, for two simple reasons. Firstly just the simple fact that most games today have some form of tutorial. And secondly because when I tell people “I am making a game based on lights out” they tend to not know what I am talking about. And even when they get the game in their hands it takes them a while to actually understand the mechanics. So the answer is obvious right? Make a tutorial.

Except… making a tutorial is no where near as simple as some people will have you think. I making my tutorial I had to basically recreate all the systems in my game in a… disassembled form, so that I could disable and enable various parts based on how far through the tutorial the player was. I never got it fully functioning, mostly because before I had it “finished” I re-did all the UI. And since I wanted the tutorial to mirror the main UI (while also slowly phasing in UI elements as needed) that meant the entire tutorial would have to be re-made (including most of the programming).

Now starting near, if not at, square one on a tutorial level I asked myself “Is this really necessary? Do I really need a tutorial?” and the answer I came to was: no. And again there were two simple reasons for this. Firstly, I looked at other “Lights Out” games. And none of the ones I found had a tutorial. At most a similar game had a screen of pictures and text that explained the mechanics (Badly. That game needed to be seen “in motion” to be understood.), and that lead to realization number two: I already had a tutorial built in. Yep, from the start I did the same thing as all the other Lights Out games did with there first few levels, I made them super simple 1-2 move “puzzles” that served to show how the game works, served to show what pushing the buttons did and what certain common patterns looked like. The more I thought about it the more sense it made, my testers got better at solving puzzles as time went on, meaning they were learning how to play… except when they were “making a pattern” or otherwise just playing around with it.

So, did I need a tutorial? Yes and no. I do need a way to instruct the player on how to play, but I was stuck on this idea of “what a tutorial is supposed to be” and not seeing what I already had. As with most games, mine needs a tutorial. But also as with most games that tutorial does not need to be a ham fisted “Hey player! THIS is how you do thing.” It can be more organic and integrated into the game itself.

Comments Comments Comments

For those that don’t know, in programing comments are a piece of text that is ignored when the program is run (had to rewrite that about 3 times to avoid using words like “compiler”. If you don’t know what a comment is, a compiler would just confuse you more.). Now you might think: Why write stuff that just gets ignored? Two reasons, both very simple. The first is that you might temporarily comment out a piece of code so that it stops running, useful when you want to disable something without deleting it. And the second reason is: documentation.

Now I am a one man development team, that means I have written all the code (except the base systems unity provides) that goes into my game. As such, I can remember why I wrote a piece of code a specific way fairly easily, taking only a minute or two to re-read a few of the functions. This however means I am a bit… lazy when it comes to adding comments about what things do.

Now I could make excuses about the process being iterative and not wanting to write out an explanation for a line of code that is likely to either change or go away. But the truth is that during the coding process I just forget to write the comments and after I get it working I just move on to the next thing.

That brings us to the solutions for this. The first immediate one is that every now and then I go back in and add comments to my code. A long annoying process that will have to do until I can develop the habit of commenting as I go. The other solution is having other people to work with that can and will look over my code. I know myself, doing something for myself? Sloppy and it just needs to work. Doing something for someone else? Detail oriented, dotting my i’s and crossing my t’s. That extra pair of eyes will force me to develop the good habit of commenting as I go. But that is not going to be a quick process, so for now? Back to adding comments to everything… all at once.

Text and the Importance of Font

Something I have known I would need to do, but had been putting off, is to find a new font for my game’s text. I had for most of the development been using a “default” font that came with Unity, perfectly functional and great for experimenting with to learn the ins and outs of TextMeshPro… but that is the only good thing I could say about it. It wasn’t an interesting text.

The first step is one I didn’t consider until I started getting into it: What fonts can I legally use? After some digging I found a few sites that listed if the font was free for commercial use. But digging around a bit more I found what should have been obvious: Google has a repository of free fonts submitted by various people. So that is the source of my font settled, but there is another problem.

But, when it comes to picking artistic styles and the such I don’t have much confidence. As such I asked for some advice on fonts I should use… and got instruction on how many fonts I should grab. And so I sought out 2-3 fonts. The minimum being 2 fonts, one for the buttons (aka the text that the player will directly interact with) and another for instructional text (aka the text that just sits on screen giving information), with an optional third for titles and such. At first I was given to sets of paired fonts to try out, but most of those fonts had hidden issues that made them unsuitable for my game (mostly in the size of line breaks).

These initial text suggestions focused on readability and a “futuristic” feel. But once I started exploring Google’s repository I found another style I was drawn to. A more flowing style that gave a “fantasy” feel. I felt that fit better with the theme of a night sky I had created with the stars. But a new problem arose… this text sacrificed readability for a fancier form. But no problem cannot be overcome. This initial font I found would become my title font and I found two more similar, but much more readable, fonts for both the buttons and instructional text.

Adding Theme and Stars

For most of the development of my game I have specifically avoided theming any element of the game, focusing instead on purely mechanical elements. Basic button images, abstract shapes for icons and simple monochrome colored backgrounds. As development progressed I eventually shifted into trying to make the elements look better of course. Adding a simple gradient to the background, having the background color react to the game state, and custom (if simple) images for the buttons.

But more recently I have decided to try and start actually incorporating a theme into the visuals. First step: What theme should I go with?

If you read the title you probably know what I went with, but let me tell you the process. Firstly I have been using a temp name for the title in the main menu of “Sky Lights” as such I have always had a bit of a star/space theme in the back of my mind. But when I was first making the game the ideas of a circuit board or even magic scrolls where also present as theming ideas. However, in the intervening time I have taken to using transparency as a big motif in the images I use for the game, and so the idea of putting a shifting star field behind everything captured my imagination.

So, step 2. I have decided on the theming and the first element I was going to add. Now comes my favorite part: implementation. First was to make 3 “star fields”. This was a simple, if tedious, process. I don’t have a good graphics editing program (or looked into free options yet) but have found that PowerPoint makes a good fall back for quick prototyping of simple shape designs. A few tweaks to object settings latter and I had a “star” to copy around a space. A giant transparent box behind everything to set boarders and I just needed to arrange the stars. 3 patterns made I whipped up a script to cycle through them at random via random intervals (fade in/out times and time sitting on one image randomized each cycle). It looked nice, but I had a few ideas to improve it.

Idea one, instead of one big “Field” behind everything I would have 5 “Fields”, one in each corner for the main stars and one big one for extra stars. At first I tried making the corner “Fields” overlap slightly so that it wouldn’t be as obvious that there were 4 distinct quadrants, but quickly discarded that idea when the overlapping areas got overcrowded and actually drew more attention to that.

And so I moved onto idea two: Rather than having 3 big “star fields” to cycle through I would have 3 sets of 3 smaller “star fields” each set to its own cycle rate. Trying it out I loved the effect. Theoretically I would want each “star field” to only be one star and have something like 16-22 sets per corner… but that feels like extreme overkill.

Idea 3, because yes we aren’t done yet, was fairly simple: vary the size of the stars. This is where the 5th “Field” comes in, it includes smaller stars, a few normal size stars, and one collection of larger stars. The smaller and normal stars are on a normal cycle and exists mostly to hide the “line” between the 4 corner “Fields”. The large stars originally also cycled through a set of 3, but after talking with some people one thought changed this idea: “Larger stars wouldn’t completely disappear while smaller stars were still visible”. So I set a single large star set to simply flicker (going to a low opacity rather than a 0% opacity and then back to 100% opacity) and it looked good. I latter cut that single image into 3 images to put the flickers on different cycles.

Buttons and UI layout

So most of the game has been designed and is working, what comes next? Making it look good… and making the UI make sense.

At first I just put buttons in as I needed them. Need a restart button? Here’s one. Need a stats screen? Here is a button to bring it in from off screen. Need a hint button? Getting a bit cramped but I can fit that. As you can imagine this did not look “good”. Functional, but not good.

So I did a pass to see what was actually needed. Obviously the main menu button and main control buttons (restart, hints, new puzzle for randomized) all needed to be visible all the time. But a few buttons could be hidden, such as the level select buttons and the custom difficulty select, when not in use. I also came to the decision that the hint button should be disabled after the player starts the game, since with player input the hints might no longer be relevant. As such I had the hint and restart buttons overlap with only one of them active and visible at a time (saving some screen space).

Back on the main menu it now starts with a selection for what kind of puzzle you want (classic, match, or “experimental” (still need a better name for that one)) and then slides in new options for if you want levels, random, or to go back and pick a new puzzle type.

While I am still deciding what the buttons are to look like, I am happy with the layout I have now created.

So, Where am I?

Been a while since I last posted about my game. As such this post will be a catch up that assumes you have read none of my previous posts about my game.

So, what game am I making? I am making my take on a classic game: Lights Out. In the game you have a 5X5 grid of lights with some number of those lights turned on. Your objective is to turn them all off (as the name suggests), the cavate is that if you press one of the lights the lights adjacent to it also toggle on/off. This creates a puzzle for the player to solve. It took me a bit to figure out the background logistics of how to make this work in Unity (that “Right way to do it” mind set I had getting in the way here and there) but eventually I got the basic game working.

That is when I started making my takes on the game. The first alt version I call match pattern. In this mode rather than trying to turn out all the lights you are trying to match a given pattern of lights. The second alt version adds a different dimension. In the basic and match pattern game the lights only have an on and off state, in this new version the lights have an off and 3 on modes with the objective still being to turn them all off.

So far we have 3 versions of this puzzle game, but where are the puzzles? Now, I could (and sometimes do) hand make these puzzles, but instead I created a program to create these puzzles for me, basically by working backwards. The program starts with a blank grid (or a completely randomized one if creating a match pattern) and simulating moves until it reaches the number of target moves desired. Using this I both created 100+ puzzles to progress through for each mode and a randomized version for each mode.

Since creating all of this I played with creating a tutorial (but have currently put it on the back burner as the game feels self explanatory enough) and several passes on the UI elements. Now I am working on the visual design and figuring out how to get the game published to the Apple and Android stores (and pc if it is viable).