It's been a while since we last talked, and I would like to fix that. So here we go:
What a a crazy fourth quarter this has been! I've moved from my longtime home in Little Rock for nearly 20 years to Raleigh, North Carolina! My partner and I spent the better part of three months doing nothing other than going to work and getting the house in Little Rock ready for sale. I took a transfer position which moved us here. Joe is still in Little Rock and his little girl is starting to talk and do all those things that children do.
As you can imagine, this has caused us to put aside game development for the last several months while we try to get our lives back in order. Suffice it to say, at least for myself, that is finally starting to happen, and finally, game development can resume. I'm really looking forward to it.
I've got myself an office/studio set up in the new home. Here, have a look:
Pretty sweet! right? Yes, I know my desk is messy, but I'm still in the process of figuring out where everything should live. If you didn't already know, we write all of our own game music as well, hence the instruments.
Otherwise, I'm about to tear this office up making some pretty sweet games.
The first order of business will be getting back to work on Bee Line!
It is a very basic version demonstrating the base game play.If you haven't tried it out, yet, we would really like to hear your feedback, even more so now that we're about to embark on the games completion.
Learn about Bees while making fun art!
The object is to find your way back to the hive. Be careful, because that journey requires energy, but do not fear because getting nectar from a flower can recharge you! There are other obstacles along your journey, however, as spiders might catch you in their webs, and fish and birds may try to eat you!
(Not yet available on Apple Devices)
So, to finish this out. While we were originally hoping to have finished this project by the end of the year, life, as it often does, got in the way. Now things are settling in, and we can finally get back to doing the things we love, rather than the things we have to do. Adulting is hard, but games makes it better.
I just sat down to start this blog and realized it's been exactly one year to the day since we've posted anything. There's a half finished on sitting in the drafts folder that I started about three weeks ago and never got around to finishing.
Nonetheless...
This past Friday afternoon, instead of being a productive member of society, I decided to see if our measly stats on Itch.io had magically blossomed into a cult following.
It hadn't.
But for some reason, I continued to click around the site until I ended up in the Game Jam page. And right at the top, dead center of the page, it told me that the xkcdGameJam was just getting started. I'm a huge fan of xkcd, and have spent hours lost on their site reading comic after comic. I'm not going to chance losing you just yet, so if you want, there's a link at the bottom of this post.
So I spent a little time clicking around xckd randomly until i fell upon this gem:
Being both a fan of Hamster Balls (if you've been with us since the beginning, we started out on a project called Huey the Hamster, which we were not yet ready to build) and The Flaming Lips, i couldn't pass up a chance to make this into a game. So I took my findings to Joe, told him what was up, and we agreed to take on the challenge of making a game in just one weekend.
This was Friday afternoon. Submissions were due by Monday morning, 5AM local time. Plus we both had agreed to volunteer at the Cosplay Con which was on Saturday.
It turns out Joe is also a fan of both xkcd and The Flaming Lips, so he set off immediately to make a Wayne Coyne with running animations. Have a look at this:
notice the beautiful long curly hair and goatee. I said, "Yep, that's Wayne alright."
In the meantime, I started playing around with the Hamster Ball. Simply enough, it's a circle. We add some physics to it, and a way to control him. Simply put, run left, run right and jump. I'm particularly proud of the jump mechanism, since you don't really jump the ball until Wayne hits the top of the ball. In other words, you hit jump, Wayne jumps, hits the top, the the ball goes up. We tweaked on that a little and discussed what other things we might want in the game. Then it was dinner time, and we both called it quits for the night.
Come Saturday, we both went to work at the Cosplay con, which meant we weren't getting any work done on our game. However, since time at the Con wasn't intensive or require a lot of interaction with others, we had time to decide what we were going to do. We settled on which mechanics we were going to try to incorporate and which assets would need to be created in order to bring it all to life. Now here's where only having a couple of days to complete a game helped us out. We have a BAD habit of starting out on a project, and keep trying to add new concepts and ideas to it as we go. What should be a simple project that should only take a couple of weeks, ends up taking months, or in the case of Super Laser Jail, over a year. Our word of advice to each other:
So we settled on just a couple things.
The comic (see above) definitely shows the shove mechanic being employed. So we made a pushy-shovey guy
It's agame about crowd surfing. Hitting the ground needs to be a negative
There must be unicorns. Wait, that's a TFL song. There must be beach-balls, and they should be bouncy. Someone should be throwing said balls. We cloned the pushy guy and gave him an unlimited supply of balls.
No matter which show you go to see, some drunk dude will be throwing bottles. Back in the day, those might have even been glass bottles. They'd be plastic today, but it's a game. Clone the ball throwing guy, and give him some bottles instead.
Put all those together, and it looks something like this:
Late Saturday afternoon, we finally get back to our respective computers and get to work. We realize that this is a platformer/runner and start our first level. We worked for a few hours and then called it for dinner with our respective families.
Sleep.......
I woke up Sunday morning raring to go early. I saw that Joe was on, but just wanted to get some work done. I ran across an issue which was plaguing me to no end: Raycast2D in Unity will hit the inside of the collider from which it is cast.
WTF?
This is NOT how it works in the 3D physics engine in Unity. The sides of 3D colliders are one way, outside-in, and not the other. I know this because of my work on the refraction and reflection of light for Super Laser Jail. I could not, for the life of me, figure out how to get past this. I tried ignoring raycasts on certain layers, but could implement that until I finally learned about bit shifting. Bit Shifting is a way of encoding the individual bits of a byte. You look at the individual zeros and ones as on/off flags. Finally, I got my raycast working and we could move on to other things.
Mid morning, Joe and I start a video chat and work together like that throughout the day. Pro Tip: schedule breaks ahead of time, so you know when you're going to break. Otherwise, you keep working until you're exhausted/starving and you aren't as productive. We could have done better on that edge.
The best part of the experience is that we got to work on things together, at the same time, and we used Unity Asset Server as a transfer system. We both kept the project up to date while at the same time having some version control in case something went incredibly south. It's hard to demo a game across a network, so he would be able to play it in his copy of Unity as well as change assets in mine on the fly. If you're looking for a free version control system, Unity's Asset Server is not the best out there, but it definitely works well for a free service.
The time constraint meant that we couldn't worry too much about little buggy things or even making the art look great, which it does look pretty good for what it is. This also meant we didn't have a lot of time for sound, which upsets me, as I really like that part myself. We found some decent sounds online and used those, including an actual sample from a Flaming Lips song (The W.A.N.D.)
All in, we turned our game in late Sunday night, after both our families has gone to bed, and although I didn't have to work the next day, Joe did. I think we both went to bed ourselves happy and proud of what we were able to accomplish.
We think you'll like it too. The link to play is at the top of the page. Here's a zen Wayne Coyne:
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.
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:
You must target ever growing cities. You should get ever better weapons to help.
Improving your weapons would require some sort of reward and choice system.
Rewward and choice systems require some sort of ingamer economy
The cities should have some way of rebuilding and later even defending themselves.
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.
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.
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
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.
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:
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[]:
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!
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 smallto 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:
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.
