Summer "vacation" ends, an announcement, and a baby...
 |
| Sub-Zero Squirrel Games |
October 11, 2016 - Little Rock, Arkansas, USA
Well that was refreshing. While an unintended break seemed to put the halt on some game development, there were definitely other things being developed in the SZS family. First and foremost, please welcome Evelyn Rose Hassell to the world (pic at the bottom). As you might imagine, Joe has had his hands full for a couple months. Congratulations are in order to Katie and him.
So, I'm going somewhat solo for a couple of small projects in the meantime. I sometimes need to vary projects for a while, and come back to older ones or I get bored. One of my favorite concepts we've worked on in the past is "The Lost Office," which you can read more about on our IndieDB page for the project. It's the kind of game that would contain a lot of mini games within: mostly as types of puzzles. So I've tasked myself with building a bunch of them over the coming months in between updates to Teratrons From OuterSpace
I'm going to call him "Game a weekish."
He came to me a dream, and I forgot him in another. Actually, I was just bored and decided to see if I could make a complete game in just a couple of days. My goal was no more than 40 hours from start to finish. My first attempt came out okay. Here is the finished product:
Here are the rules as I've made them up along the way.
1. No project should take more than a week to build.
2. The game must have a start, a mechanic, and a win condition.
3. The game must have enough randomness to be infinitely(ish) playable
4. The idea doesn't have to be wholly original. practice is practice
5. Share the process of discovery with the community.
6. Pay a bill or two?
Anyway, I decided to attack the slide puzzle first. What I failed to think of early in the process is that I would create rule number 5, which means that when I'm finished, I have something to share about how the process evolved. So I don't have really good documentary materials to draw upon this first time around. I promise to do better next time.
There WILL be a next time, I've already brewed up the next concept. But back to the business at hand.
The road to Slidesville has a few turns and corners before it brings you into downtown where the streets are all square and everything tries to move into the one empty space (I was going to park there!). The traffic is a nightmare until you're through, but I found a few guideposts along the way.
If you want to download the Unity project I used to do this including all the code, but not the art, you can find it here: http://subzerosquirrel.com/UnityProjects/SlidersTutorialPackage.zip
The idea is simple enough, create some tiles, make them move when you click. You need to constrain them, and move them within a grid. The math geek in me loved this part. Declare yourself a 2D array of GameObjects and get to work:
for (int i = 0; i < GridSize; i++){
for (int j = 0; j < GridSize; j++){
GridTiles[i,j]= Instantiate(Tile);
GridTiles[i,j].GetComponent<TileScript>().var = somevar;
etc...
}
}
Don't forget that when you position your tiles, that you are positioning them left to right, top to bottom, so y positions will be negative from the top down. Otherwise, you get some very confusing responses from you tiles.
Don't forget to add some randomness. Check out this nifty bit of code that follows. It's called the Fisher-Yates shuffle, and it looks something like this for an array of string[]:
for (int i = 0; i < alpha.Count; i++) {string temp = alpha[i];int randomIndex = Random.Range(i, alpha.Count);alpha[i] = alpha[randomIndex];alpha[randomIndex] = temp;}
source: http://answers.unity3d.com/questions/486626/how-can-i-shuffle-alist.html
Which just shuffles all the tiles into a fairly random order. I used this concept to create an int[] which held the index order for my actual tiles. Excellent! But there's a problem I didn't know about at first. As I was testing my project out, I couldn't solve one of the puzzles...
I just couldn't solve it. There was no set of moves that could possibly result in a correct solution. NOT ALL RANDOM ORDERS HAVE SOLUTIONS!
I had no idea. It turns out that if there are an odd number of value inversions in a list, then the puzzle cannot be solved (citation needed).
Here's a simple example:
You cannot solve this puzzle, ever:
Two is greater than one, so 1 inversion.
Two is less than three, so 0 inversion
+ One is less than three, so 0 inversions
1 total inversions (odd)
nor this one:
which I'll let you figure out on your own. (the answer is:
int InversionCount = 0;
for (int i = 0; i < TileCount; i++)
{
for (int j = i + 1; j < TileCount; j++)
{
if (GridTiles[i].value > GridTiles[j].value)
{
InversionCount++;
}
}
}
: which comes out to 15).
We have a winner.
So we have a mechanic (sliding tiles), a startup scenario (shuffled tiles), and a win condition (get all the tiles in the right places).
The simplest way to check the win condition is to iterate through the grid, and make sure everything's in the right order. Do this at the end of every move and you can't miss. We're dealing with four bit numbers here. There's no real math to do.
But what about some feedback along the way. Games are more enjoyable, no matter how simple, when you give the player an audio-visual response to their actions. For example, if a move results in a tile moving to its home square. But the tiles can be in any configuration after any move. So tell them where home is from the very start.
There are a couple different ways to do this. You could build them all then shuffle them (which now that I look back is a better way) or you could figure it out from their value;
Given the following grid:
| X → | 0 | 1 | 2 | 3 |
| Y = 0 | 0 | 1 | 2 | 3 |
| 1 | 4 | 5 | 6 | 7 |
| 2 | 8 | 9 | 10 | 11 |
| 3 | 12 | 13 | 14 |
A quick empirical study reveals that the value of the tile is related to its position such that (with zero bases indices)
Z = x + y*GridWidth (GridWidth is a non zero number!)
For Example: 14 = (2) + (3)(4), so you know 14's home position is (2,3).
BTW, that works for any rectangular grid, not just squares.
or to reverse the process:
int Ypasses = 0;
while (SolutionIndex > GridSize)
{
Ypasses++;
SolutionIndex -= GridSize;
}
HomeCoords Result = new HomeCoords(); //struct { int, int }
Result._X = SolutionIndex;
Result._Y = Ypasses;
or to reverse the process:
int Ypasses = 0;
while (SolutionIndex > GridSize)
{
Ypasses++;
SolutionIndex -= GridSize;
}
HomeCoords Result = new HomeCoords(); //struct { int, int }
Result._X = SolutionIndex;
Result._Y = Ypasses;
now, we can simply check the tiles home position against its current position, and do something nice for the player when the tile gets home.
I chose to flash the tile and play one of 4 random, pleasing, and tonal sounds in the same key as the music. Tiles will often reach home several times before the puzzle is finished, it's important that the sound be musical in some way. The music was (mostly) in C major, so I went with four high pitched triads from the major scale I, IV, V, vi. The reason for the high pitching is so that
1 - It will stand out from the musical background
2 - The triad will sound pleasing regardless of the root below it at the time from the music.
I should probably stop babbling on about music theory. I could do a whole series on game music and sound design theory. That's for another day. Here's a quick video
By the way, I removed all the music and sound from the project, as well as a portion of the art. You can't have everything for free.
There's really a lot more that I could do with this. The simplicity of the platform allows for all kinds of permutations. Perhaps, you draw pictures (i.e. dickbutts) or take photographs (most likely shower selfies) or any kind of order-able set of related numbers, equations, so on and so forth.
Passing the test:
Let's check our rules again:
1. No project should take more than a week to build.
2. The game must have a start, a mechanic, and a win condition.
3. The game must have enough randomness to be infinitely(ish) playable
4. The idea doesn't have to be wholly original. practice is practice
5. Share the process of discovery with the community.
6. Pay a bill or two?
How did we do? The build time was actually less than 48 hours or so, including art and music. The game can be started, played, and won. With over 60,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 possible start up puzzles, it's damned near infinitely playable. Not an original idea, but it definitely has my take all over it. I wrote a blog about it.
The last one remains to be seen.
What did I learn? Aside from the hurdles already mentioned above and the lessons learned there, I learned I can't do one of these in just a week. If I didn't include the tutorial/social aspect, then sure, I could grind them out; but that defeats the purpose of discovery and sharing. In fact, I'm making sure to document what I do as I get into the next project. I'm hoping for a video out of this one.
What's Next?
My next project is going to be called ICBM. You get to launch missiles and destroy other civilizations, and take their loot, so you can build bigger missiles to destroy bigger civilizations to take their loot so you can build bigger missiles to destroy bigger civilizations to take their loot so you can build bigger missiles to destroy bigger civilizations to take their loot so you can build bigger missiles to destroy bigger civilizations to take their loot so you can...
(how much of that did you really read?)
The trick to this game is you can only control your rocket as long as you have fuel to burn. I foresee some issues arising with touch controls. I'm going to need to create some virtual touch-zones to control the game. We're going to need multiple controls, and on top of that we'll need to create an economy, store, and up-gradable rockets. This should be fun!
Until then, Stay Frosty!
~Sub Zero Chuck
