Monday, November 21, 2016

Snell's Laboratory - Adventures in the physics of light

The Game-A-Weekish program continues - Now with lazers!

Sub-Zero Squirrel Games




November 21, 2016 - Little Rock, Arkansas, USA

As we continue into this series of exploration, we continue to try out new and interesting concepts. This time we are looking into using the physics of how light behaves. This one gives me special pleasure, as there is a lot of math that goes on in this one. I find myself wanting to go into a whole lecture on geometry, trigonometry, and vector calculus, but I think I'll spare everyone from that. Let's just focus on the cool stuff instead. If you came here for the tutorial blog, please come back tomorrow!

The Base Concept:


A player controls a system in which a beam of light must be made to complete a maze. The player will be given various items to help them complete the path including: mirrors, lenses, and slits.These items can be moved, rotated, or otherwise configurable as needed to achieve the win state.

See this incredibly well drawn figure? Well, the circle is some sort of impediment, and the the two diagonal lines are mirrors that can be moved and rotated. There could be a host of other objects as well: containers of materials which pass but bend light (refraction) and devices which cause light to fan out into patterns (diffraction). While the wavelength of light is insignificant in the measurement of reflections on mirrors, it does have an effect on the other two systems. 

What we refer to as white light is a combination of all the various colors that our eyes can see at the same time. Each of these colors is a different wavelength than the color adjacent, with red light having the longest, least energetic length, and violet the shortest, most energetic length.
from Wikipedia
Note that the values for wavelength given on that image are in nano-meters. Look at the edge of a penny and divide that 1,000,000 times and it would still be a little wider than a nano-meter. So when light interacts with a prism which is a billion times larger than the length of the wave, it must be happening on the molecular level, which is pretty damn cool to think about. So the spacing of atoms defines the laws of refraction (bending) in materials, while the fine empty spaces between define the laws of diffraction (spreading) in vacuum and earth's atmosphere.

Finally, this gives that white light, where every frequency is of equal amplitude, due to atomic level interactions, will bounce a little differently, and produce the rainbow on the other end! Meaning you could build mazes where multiple color paths have to be completed.

SCIENCE!

Breathing life into the project.

The initial concept was top down. I really wanted to work in 3D for this one, so I initially decided on a potential orthographic view, but still work with models rather than sprites. So obviously, I spun up Unity3D and brought my first cube into the world. It's a nice cube. It has a size of one unit cubed and is white. I wasn't sure where to go from here, but I knew about RayCasting, and had used it to some limit in previous work.

Raycasting is a lot like the name implies. You choose a point in your world as the ray's origin. You then give it a direction in which to point. Optionally, you can add a maximum distance the ray can reach before not hitting anything.  In order to use raycasting, the ray needs to have an object to hit. That object needs a collider to be hit. The good news is that my cube came with a collider attached to it. So I whipped up a sphere, and added a raycaster to it via script. I dropped it at the center of the sphere because colliders are one sided and can't be hit from the inside. I aimed this device at my cube and got a hit.

This is when the math starts to come into play. I intended my cube to be a mirror, so I tagged it as such and started to look into the geometry of the situation. Mirrors are quite simple, you reflect away from a mirror at the same, but opposite angle that you hit it. 
The line marked as normal is always perpendicular to the surface of the mirror regardless of shape. A circle's normal is a line from the edge out that is parallel to a line from the origin to that same point on the edge. Mathematically speaking, the normal is always 1 unit long. 

The math is very similar when we start doing refraction, except now we are going to go through the material instead of just bouncing off. We've all seen the glass of water trick where light gets turned around backwards. Different materials cause different angles of bending, and that angle is related to the refractive index. Air is pretty much just 1, and water is around 1.5, in this picture, the glass itself is pretty much not part of the equation other than shaping the water.



Enough Geek Talk ALREADY!

Tell me more about the game, and less about physics! Okay fine, meet this guy:


I call him "The Walker." I turns out, after playing around in build mode, I decided to bring in a FPS camera into the scene. instead of the orthographic point and click, you have to move around the room and interact with things like this. The head of the unit can be replaced with various devices such as mirrors, blocks of glass/water/etc., or diffraction gratings. There's a beam maker in the far back corner, and a target behind you which unlocks the door to the exit. You can adjust the position, rotation, and skew of the walkers as needed to get the beam to shine on the target. Once you've completed the puzzle, you get to move on to the next one. As you go they become increasingly more difficult. I imagine machines that change the refraction index of a block as another way of manipulating the light. Walls could have diffraction gratings that could be adjusted. Multiple colors of light can add a whole new dimension to the game. It's entirely possible that rooms may have solutions that we didn't intend, or even designs that are intended to be solvable in more than one way.

In the end, some good music and few pitfalls should make this a quite enjoyable game. So, let's do the rule check.

Rule Check:

Again, if you haven't been keeping up, the rules for this game series are as follows:

1. No project should take more than a week to build. (as if)
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?

So how does this stack up? Well, it's definitely taken more than a week to get it to this point. So, there's a lost point. I don't think it's a wasted effort. though. I'll come back top that. The second point has been acheived, you can open a door and leave, so A WIN. On the third note, there is almost no way this could be randomized. Each position has to be determined precisely in order to ensure the room will unlock. This would have to be a through composed game. (Side note, for musicians, look up "through composed song.") I think this is a somewhat original idea. I don't know of anything I've seen that is quite like it. Obviously, there are comparisons that can be made, but that's just true of art in general. 

I'll be devoting a complete other blog to the dev side of this project. I've overcome a couple of hurdles from which I think the indie community at large might derive some benefit. That will check rule number 5.

As for the money? Well, we can all dream. Or, we can take what we've learned here, and try to make it into something else. I feel like that best course of action is to take this back to the top down view, and make it more simple, like in the original drawing. I like how that would allow for the use of touch controls on mobile. The code I wrote for three dimensional  space still works just fine in 2D, we just ignore a vector.

I don't want to abandon this FPS idea, however, and I feel almost certain that we can incorporate it into The Lost Office, which is the original purpose of these projects in the first place, to explore game ideas and mechanics for use in that game. Then again, it has potential to be a stand alone game. You can make a difference here if your want. If we get enough support, we will move to full production on this title. In the meantime, if you have any ideas you'd like us to explore, please let us know. 

Stay Frosty,
~Sub-Zero Chuck




Friday, November 18, 2016

Game of the Week Series: Week 2 - The one where the game's not finished.

ICBM is not finished in a week! End of civilization delayed!

Sub-Zero Squirrel Games


November 16, 2016 - Little Rock, Arkansas, USA

It's been a month, not a week since I got well into the second game in our series: ICBM. 

The concept is simple. You have some rockets.They have a city. The obvious next step is to send your rockets and blow up their city. Lather, rinse, repeat.

Well, This shouldn't  too difficult to set up. We need simply a few basic ingredients:
- Gravity
- Masses
- Thrust Forces
- Colliders

Gravity is automatic in Unit once you've added a RigidBody to a GameObject. Add a Collider to a couple of objects so you can make things go boom. Hook a few keydowns to direct and add force to the rocket. Sometimes, these things don't quite go as planned. Unity requires at least one of two colliders to have a rigidbody attached in order to raise the OnCollisionEnter() event. You can also treat a collision as a trigger, without using physics. I got these fine points out of whack and created a pretty interesting result:



That's not how I intended to blow things up! Once I got everyone in the right collider/trigger, rigidbody/no physics mode, Things blew up way more nicely.

Live Dev Sessions have happened, and may continue


BTW, I've been trying something new, LiveDevSessions on Facebook Live. They might be a little boring right now. I might switch to Twitch instead, I don't know that watching somebody make a lot of typing errors and listening to the sound of the keyboard clack while staring at a whiteboard in the corner is Facebook material.  Twitch is more game oriented.

Either way, I hope these shed a little light on how we come up with and develop ideas. If nothing else, it gives me video to edit into a possible tutorial.


Why this one doesn't cut mustard...

I think this one needs to be shelved. Let's look back at the rules for this project:

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?

Rules 4,5, and 6 have more to do with the process rather than the game itself. I've been sharing with you as I go here and there. The rules that came into play here are the first three, about the game itself

Rule 2 was (mostly) satisfied. You could launch missiles at a target and destroy it. A health system was created and damage was done according to proximity to the location of the blast. 

Rule 3 is for replayability, I created a system to procedurally generate target cities, so that they could grow and change as you progress. I created five tiles for each of four zones, which could be randomly applied to a city of a given diameter. 

here's a result sample:



Rule #1: This game only took a short time to get the basic mechanics down. That's not surprising seeing as how I love physics based games. However, the more I worked on this game, the more I realized that for it to have any sort of forward progression, there would have to be a lot of things added to the game:

  1.  You must target ever growing cities. You should get ever better weapons to help.
    1. Improving your weapons would require some sort of reward and choice system. 
      1. Rewward and choice systems require some sort of ingamer economy
  2. The cities should have some way of rebuilding and later even defending themselves.
    1. Now the cities need some sort of A.I.
This project, before I knew it, was quickly scaling UP. I like this concept a lot, but I'd really love to see it done in 3D, with a globe style map, a whole political AI system and much much more. Then, it starts to remind me a lot of Sid Meir's Civiliation series. 

One final note: I had a hard time realizing a great UI experience for this one. Any comments you have on it would be greatly appreciated. 

This one goes on the shelf, AND itch.io

I often find myself going back to old projects and picking them back up. I'm pretty sure we'll come back to this. In the meantime, have fun destroying cities in this mini game I made out of this project.I took the last couple of days and made this a playable game. I added a quick GUI and gave it a game cycle with improvements along the way.

I stripped it down to its purest form. Three rockets against an ever growing city. Every city is random, so some are harder than others. Maybe you'll get lucky and all you get is a rural community you can take out in one, or maybe you end up striking the most heavily fortified 24 block city.

Your bomb becomes more effective as you go. For every 5000 points you earn, your blast radius increases by 50%. There is no limit to the radius or the size of the city, so this could get rather fun. I seriously doubt anyone will make to that point ever. There is no end of game scenario. You play until you can't win anymore. It's akin to beating sand with a hammer, but a little less tedious, and with explosions... and death.

You can find it here, for your Windows PC. Control are simple, space bar to burn thrusters, left and right arrows to change the pitch of the rocket. Your city awaits you on the other side of the screen, just waiting for you to bomb it to hell.

ICBM - free on Itch.io


What's next?


Part of the reason this one took so long was explained above, but also, Joe suggested another mechain to explore: prisms, and the way light behaves. I'm already well into this idea, and will try to give you more insight in my next post. In the briefest sense, light reflects, refracts, or diffracts through various mediums. There's a great study on vector math worthy of a Calc III class. Also, there's just a bunch of science that goes into this. The physicist in me loves it.

and I will name thee: "Snell's Laboratory"  



That's all for now. Until next time:

Stay Frosty,
~Sub-Zero Chuck















Friday, October 14, 2016

Introducing the "Mini Games Project" - or the one where Joe becomes a dad

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[]:

  1. for (int i = 0; i < alpha.Count; i++) {
  2. string temp = alpha[i];
  3. int randomIndex = Random.Range(i, alpha.Count);
  4. alpha[i] = alpha[randomIndex];
  5. alpha[randomIndex] = temp;
  6. }
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;


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



Thursday, April 28, 2016

We've got some news - Or Episode XI, A New Hope


Wait! That's not our logo. What's it doing on the top of this blog? Let me fix that:

Sub-Zero Squirrel Games
April 28, 2016 - Little Rock, Arkansas, USA

Let me backtrack a moment. I know why that logo is at the top of the page. We're going to ComicCon! We're not going as visitors, mind you, but as exhibitors. We got our booth yesterday, right in under the wire. We had almost forgotten it was coming up, as this time last year, we were no where near ready to show anyone anything that we had dreamed up yet. We did manage to go spread some propaganda: Little cards with our branded logo printed on one side. We left them all over the place, hoping people would pick them up and look us up as a result. It wasn't very successful as far as we could tell. There might have been a slight uptick on website stats over the next couple of days. It's hard to tell when numbers are so small to begin with.

The upside is that now, 11 months later, we have a game to actually show people. We're so close to producing the final product right now that we're sure we can be ready. To that end, we want to thank all of you who have helped us find and squash the various bugs we intentionally wrote into the code so you could find them and think that we're merely human after all and not actually game code gods, which we are, of course. Why would you think otherwise?

If you're in the Central Arkansas region and would like to bask in the glory of our greatness, please come see us the weekend of June 11 and 12. There will be snacks. We will not provide said snacks. We're pretty sure that's up to the food vendors. 

New Deadline, Production Release - June 1

We feel this is completely reasonable, given the state of the game at this very moment. On that topic, if you're not already playing our Early Access Beta, stop reading this, and go download it now:



For those of you already testing, we'll be dropping a couple more updates in the next few weeks as we expand a few things, finalize a accounts for Facebook, add some more music, etc. 

One last thing...

We heard you like videos. Here's one of the opening story:


Until next time, Stay Frosty,
~Sub-Zero Chuck


Wednesday, April 13, 2016

Too Much Clutter - or how I finally decided to make a dialog box

Sub-Zero Squirrel Games
Wednesday, April 14, 2016 - Little Rock, Arkansas, USA

Man this canvas is getting a little cluttered. The hardest thing we're working on right now is the Graphical User Interface, which I will just call GUI like a good nerd from here on out. With all the various settings, options, requests, information, feedback, and other stuff we the games needs to let you know what's going on and what's next and how you prefer the experience, the various parts are starting to get a little crazy. There's a bunch of stuff you don't see sitting off screen waiting for it's moment of glory. Check out this comparison:


On the left you see the exploded canvas waiting to be brought onscreen, which you see in the right. The canvas is an overlay on the screen, separate of the camera, which is why you don't see the game objects (ship. moon, etc. ) on the left. There's a lot of stuff hanging over the edges. But wait, you can't even see all the various layers beneath stuff. Believe me, it's a lot of stuff.

You don't believe me? Well, let's just prove it, here's a picture of the animation tree...



It's only going to get worse as I go. I need a better solution.

My AHA moment

In my years of writing software for people to use, I've learned that you have to be careful about when you let people click buttons in your application. In general, users will find amazingly unique ways to mess up your carefully crafted logical program. So, you have to ask them if they really mean to do what they just asked your program to do. Now, in any .Net situation, I'd simply just pop open a dialog box, and ask them a question, "ARE YOU SURE YOU'RE NOT AN IDIOT?" (Yes, I've actually used that question before in  program at work.) 

But, in Unity, there's no such easy call just built in, and besides, anything we put on the screen should reflect the design on the rest of the game, and not be some generic OS provided message box. 

I know I'm not the first one to stumble across this simple solution, but I'm going to share mine anyway. It's short. sweet, to-the-point, and could save someone else a lot of work. 

The rest of this post is all geek speak, if you're interested in that part, keep reading. Otherwise, play the game already:





I created this dialog box starting with an Image on the main canvas, which has been tagged "MainCanvas" and is a prefab which is used in every gameplay scene. It has an invisible full screen image behind it, so that it becomes modal. I attached a script to it, made a new prefab, dropped the whole group of canvas objects into it, then deleted it from the scene. 

Here's the code attached to this new prefab: 

using UnityEngine;

using System.Collections;
using UnityEngine.UI;

public class DialogBox : MonoBehaviour {

//this is a modal doalog box for TFOS
    //this string right here is the name of the function to call when the
    //player has responded:
    public string CallBack;
    
    //a list of character images to choose from, and a way to set that choice
    public Sprite[] Characters;
    public int CharaterIndex;

    //options for the dialog
    public string Message;
    public int Alignment;
    public string ChoiceOne;
    public string ChoiceTwo;
    
    //references to the parts of the dialog that need to change
    public Text ButtonOneText;
    public Text ButtonTwoText;
    public Text MessageText;
    public Image CharacterImage;

    void Start()
    {

        CharacterImage.sprite = Characters[CharaterIndex];
        MessageText.text = Message;

        switch (Alignment)
        {
            case -1:
                MessageText.alignment = TextAnchor.UpperLeft;
                break;
            case 0:
                MessageText.alignment = TextAnchor.UpperCenter;
                break;
            case 1:
                MessageText.alignment = TextAnchor.UpperRight;
                break;
        }


        ButtonOneText.text = ChoiceOne;
        ButtonTwoText.text = ChoiceTwo;

    }

    public void OnButtonOne()
    {
        Debug.Log("Sending Choice: " + ChoiceOne);
        GameObject.FindGameObjectWithTag("MainCanvas").SendMessage(CallBack, (int)1);
        Destroy(gameObject);
    }

    public void OnButtonTwo() 
    {
        GetComponentInParent<CanvasManager>().SendMessage(CallBack, (int)2);
        GameObject.FindGameObjectWithTag("MainCanvas").SendMessage(CallBack, (int)1);
        Destroy(gameObject);
    }


}

Now I just need to add a reference to this new prefab into my main canvas manager script, and instantiate a new one whenever I need to ask the player a question. It could be any question, but let's ask them about Facebook:

//the prefab is a UI Image, with attached components
public Image PrefabDialogBox;

public void OnFBInteract()
    {
        if (FB.IsLoggedIn)
        {
            Image _DialogBox = Instantiate(PrefabDialogBox);
            _DialogBox.transform.parent = transform;
            _DialogBox.transform.position = new Vector3(Screen.width / 2f, Screen.height / 2f, 0);


            DialogBox ThisDialog = _DialogBox.GetComponent<DialogBox>();
            ThisDialog.Message = "Do you want to log out of Facebook and remove the information?";
            ThisDialog.ChoiceOne = "yes";
            ThisDialog.ChoiceTwo = "no";
            ThisDialog.CharaterIndex = 3;
            ThisDialog.Alignment = 1;
            ThisDialog.CallBack = "FaceBookLogoutreply";


        }
        else
        {
            Image _DialogBox = Instantiate(PrefabDialogBox);
            _DialogBox.transform.parent = transform;
            _DialogBox.transform.position = new Vector3(Screen.width / 2f, Screen.height / 2f, 0);


            DialogBox ThisDialog = _DialogBox.GetComponent<DialogBox>();
            ThisDialog.Message = "Can we access your public Facebook profile? We need to be able to notify your next of kin.";
            ThisDialog.ChoiceOne = "yes";
            ThisDialog.ChoiceTwo = "no";
            ThisDialog.CharaterIndex = 2;
            ThisDialog.Alignment = -1;
            ThisDialog.CallBack = "FacebookLoginReply";


        }


    }

    public void FaceBookLogoutreply(int Choice)
    {
        if (Choice == 1)
        {
            FB.LogOut();
            //TODO: clear any FB data we've requested
        }
        else
        {
            //player chose not to log out, or something else
            //Do.Nothing();
        }

    }

    public void FacebookLoginReply(int Choice)
    {
        if (Choice == 1)
        {
            //TODO: log into facebook

        }


    }

So there you have it. No more creating permanent instances and cluttering up EVEN MORE of my canvas with simple yes/no questions. I still need to leave in those parts which will be animated in and out, but that's just what it is, and I'm not going to complain.

Until next time, Stay Frosty,
~Sub-Zero Chuck

Friday, April 1, 2016

Crossing the Finish Line - or where we get ready for the next hurdle.

Crossing The Finish Line

Sub-Zero Squirrel Games
April 1, 2016 - Little Rock, Arkansas, USA

It's Friday night, and officially since it's still before midnight in the time-zone in which our studio is located, we managed to get out a fully playable game, from start to finish. That's not to say that everything is worked out, and that the game is everything we want it to be, but

Early access is live, and we want you to join us

Get a very sneak peak into Teratrons From Outer Space today, and when we release the final version, you'll get free of charge, the premium no-ad game. Not only that but you'll also get to see first hand the progression of the game as we take it from a fully playable (if yet a little buggy) creation to the fully progressive game it will become in the next several weeks. Hopefully you'll give us feedback as we try to balance the difficulty settings tweak the game play until the fun is turned up all the way to 11. 

At this point, we don't have too much to say. This last week has been grueling, but we feel like it has been worth it, and that you'll enjoy this early release of Teratrons From Outer Space. The best part is that it only gets better from here. 

Head on over to the Early Access portal, you'll need to log in to the google play store to access the game. Here's a link:




Stay Frosty,
Sub-Zero Chuck

Friday, March 25, 2016

Crunch Week Begins - Or the one where we become bald over a period of seven days.

Crunch Week Begins

Sub-Zero Squirrel Games

March 25, 2016 - Little Rock, Arkansas, USA

We promised you a game.

When we started we figured we would have this thing down in a couple of weeks. I mean, how hard could it be? It's such a simple mechanic, and we already have a working prototype that people genuinely enjoy. After realizing that the projects we are seriously passionate about, and really want to make into really awesome games, Huey the Hamster  and The Lost Office, would take entirely too long to bring to fruition, and would probably not make for a suitable first game for us.

We promised you Bouncy Adventures.

It was the very first concept we came up with, because a bouncing ball was a very easy mechanic to set up, and to be truthful, it was really more just the two of us figuring out how all this stuff worked. By the way, we're still trying to figure it out, we've just gotten a lot better at it then when we started. Bouncy Adventures has it's merits: the prototype was showed some very promising designs. My personal favorite out of that was the "Night Cannons" designs.


You can play this prototype if you like. It's available FOR FREE for PC and Android on our IndieDB page. We tried to force it into some type of world tour of ancient and modern sites via pinball. It felt forced, and eventually, forced us to quit the project. It's not a bad game idea, we just lost interest. So, no Bouncy Adventures for you.

Then we promised you:


And we told ourselves we should be finished by the end of the year when we started in Nov. 2015. By January we thought we had it all figured out and that we could put this thing together in no time. "We should be done sometime in January," we told ourselves. 

We were wrong.

Yeah, the initial work didn't take too long. But, we wanted the game to have some real game play, and not just another simple color match game. We also wanted it to have some personality, as we continued to develop new tactics, and advancing the difficulty over time without just speeding things up, we also began to envision characters and story line to go along with the game play, and give some depth to what you're actually doing when you play the game. 

YOU ARE DEFENDING THE VERY EXISTENCE OF LIFE OF EARTH!

As you will soon see for yourselves, it's going to be worth delaying release on this until we're done with it. When March 1, our officially published release date on SlideDB, starting creeping around the corner, neither of us gave it much thought. But that day, we set our sights on next Friday. And we're staring down the barrel the whole time. 

We're aiming for a complete game, with all the levels in place, as well as all the options, We're aiming to have all the characters in place, and the story line complete. We're aiming to have all the bugs worked out, but we're not aiming for production release just yet. 

Next week's release is supposed to be our full length Beta Test. We have an offer to make you: 
Beta Test our full game FOR FREE and when we go production release, we'll give you the AD FREE premium version at no cost. How can you turn that down? I must admit, there's a catch, we just need feedback from you. 

You also get a chance to influence any changes we make as a result. Then the game becomes a part of you, and you it. We would also like to publicly thank our testers in game.

So, we promised you a game. And (insert your choice of expletive here) you're going to get that game. Things are looking good, and we're super excited. 

BTW, I also promised you some character introductions, here's one: Dr. Allen Astronamor, penned by Matt Barnette and inked by SZ Joe. Here he is looking a little bit intrigued about something:


Stay Frosty
~Sub-Zero Chuck