What we've done (?) this week: Feb 16 - 23

What haven’t we done this week?  A lot. . . we haven’t done a lot this week.  With school work and other things taking up a lot our time we kind of took a little break this week.  But even though we didn’t get as much done as we might have liked, we were still able to get a couple of things accomplished.  Mainly, we were able to create the basics for quick time events (if you don’t know what a quick time event is, it’s basically like a button will appear and you’ll only have a certain amount of time to click it and if you don’t click it stuff happens and if you do click it other stuff happens).  We decided quick time events would add another layer of interactivity to the game and keep the player a little more on edge.  Instead of just exploring the map and finding more information about where you are and your surroundings, the player will have to make sure they’re always ready to deal with what ever is thrown at them (perhaps, quite literally (well, “literally” in the game)).  So now a little bit more about how we actually created the framework.

The basics of it are pretty simple, when you trigger a quick time event a button appears in a random location and then goes away after a certain number of seconds.  If you click the button a “click button” method is called, if the timer runs out a “failed quick time” method is called.  All of that is fairly simple.  We had a couple of constraints on the button generation as we only wanted it to appear in a certain part of the screen, but that was easily solved by bounding the random number generator.  The most difficult part of actually implementing the quick time events was probably coming up with a way to show how much time the player had to click the button.  There were a couple of different routes we could have pursued: a count down timer that just displayed the number of seconds, a bar timer that gave a graphical representation of the time, and some others that I won’t talk about for the sake of brevity.  What we have now is a button that fades out over the amount of time you have to complete the event.  This method of showing how much time the player has was a little more difficult to actually implement than we first had thought.

Without getting too technical, the method we would use to fade the button would have a manually set update time.  Unlike the built in “Update()” method in Unity which gets called based on your frame rate, we would have to specify how long, in seconds, until our method was called again.  This led to the need for a little bit of math to figure out how long we needed to wait in between each method call, and how much to fade the button out for each one of those calls.  It turns out, all you really need is to define your “frame rate” for the custom update method.  So, for example, we have ours set at 30 frames per second.  If we want the button to fade out over, say, two seconds that means that there will need to be 60 update calls of the method.  This defines how much we fade out the button at every update call.  And then, it turns out, that our method is just called every 1/30 of a second (to achieve the 30 fps).  Seems pretty simple when it’s all laid out but it took us a little bit of work to get it all figured out and implemented correctly in the code.  But we do have a quick time button that fades out for the given amount of time.

That’s pretty much the biggest thing we have accomplished for this week, like I said, we were on a little bit of a break this week.  Even though this doesn’t seem like a lot it was an important piece of the foundation for this second act and one of the last major pieces that needed to be finished up.  Now, hopefully, we’ll be able to move on to developing more of the story for Act II.  To find out if we are really ready to move on to the story for Act II you’ll have to check back next week to see what we will have done this coming week.

As always, thanks for reading,

-Matt.

A list (story) of what we’ve done this week: Feb. 9 - 16

It’s been a week (and a day) and we’ve done some things that we thought you might like to know about so here they are.

First, I know I said in the last post that I was going to write a little something that went more into the plot of our new game and I haven’t done that.  But there’s a good reason why!  I was about to write the post when Austin sent me a message saying that he was going to met with a writer who was interested in this sort of thing and might be interested in helping us out.  So I decided that it would be better for everyone if I let the someone who’s more inclined to being elegant with their words write the story.  So that’s why you didn’t see anything more from us last week, but hopefully we’ll have a more professionally written story to share with you shortly!

So with that cleared up, lets get into some of the interesting stuff we handled this week.  I think the biggest thing we had to tackle was the idea of saving the current state of the game.  In our previous games we didn’t really do much saving beyond a few high scores.  But because this new game is more of a story we had to figure out how to make sure when a player comes back to the game they can pick up exactly where they left off.  This means not just having to save a few numbers, but having to save a whole slew of information.  So much information that our previous techniques would not cut the mustard.  Luckily, Unity has a great video tutorial on how to save game data even when a player quits the game (which you can watch here.  Aren’t they the greatest!).

So after a quick viewing we were in business.  We had a lovely singleton class set up that stored all the data and then saved it to a neat little file that it would then open up when we loaded the game and everything was wonderful!  But our time of care-free coding would be fleeting.

Thinking everything was working as we planned we moved on to another important aspect of the second act: day tracking.  We already had a great mechanic in place that kept track of time and faded the screen out as it becomes time for the player to sleep; all we had to do was increment the number of days and save it to our wonderful data storage class.  We hit our first speed bump when we realized that, because the sleeping method involved a fading element it was being called in our update script.  In other words it was being called roughly 60 times a second every second.  So when we tried to increment the days we were all-of-a-sudden going through about 60 days every second.  So a couple clever boolean gates later and. . . our game data class stops working. . . but we didn’t. . .we didn’t even touch the game data class. . .and in one second. . . everything came crashing down. . .

Initially we thought we had broken something in the game data class when we added the boolean gates.  So we took those out and it started to work again.  But as quickly as we (thought) we had fixed it, it was was broken again. . . 

In the end, it turns out that the scripts weren’t being loaded in the right order.  The game data class needed to be loaded first when the game starts so that the level loader class can look at the data to load the level.  By default, however, the scripts are essentially loaded randomly (which explained why it was working for a little while and then stopped working).  Luckily there is a way to manually set which scripts are loaded first (which you can read more about here).  So with that implemented we finally had our game saving data!!

We did get a few more things accomplished this week, most notably we got the swipe to move interface working for mobile devices and we got a good start on a few other game mechanics that we’ll tell you about when we get them finished up (hopefully next week). 

I hope you enjoyed our little weekly recap story and, as always, thank you for reading.

-Matt.

We haven't posted, but we've been busy

Hello again everybody!

It’s been a little while since we’ve posted something here, but that doesn’t mean we haven’t been working on some new and exciting stuff.  In case you missed it, we released Zen Balance back at the end of November last year; and ever since then, we’ve spent a good deal of time thinking about what we wanted to do next.  The brain storming process, combined with some vacation time for the holidays, meant we didn’t really have a lot to talk about.  But now that we’re back into a rhythm with school and work and so on we are going to have some more regular updates about the newest project we’re working on.  So speaking of that newest project . . .

Over the past couple of months we’ve started working on a new game that we are super excited about.  This new game is going to be a little different form the previous games we’ve done.  It will be a text based horror/suspense game much in the likeness of other games like Lifeline or A Dark Room.  We wanted to make a game that was less like a traditional arcade or puzzle game and more like an interactive story.  A game that wouldn’t require a huge amount of art or graphic design, but could keep audiences fascinated through an intriguing story line.  We spent a good couple of weeks coming up with different ideas for stories and how we wanted to add an interactive element to them.  

In the end, we came up with an idea for a survival game that puts your problem solving skills to the test to try and escape the murderous hands of the person who has just kidnaped you.  The interactive part of the game is designed to be more of an open ended question; requiring the player to pick up on subtleties in the gameplay to solve problems rather than a more straight forward approach.  Our goal with this idea was to make the game more complex and try to draw the players into the story by making them really think about the character and the situation they are in.

Over the past month or so we’ve been moving forward with this idea and have stared coding some of the game.  At a higher level the game is going to be broken up into multiple acts.  (At this point we are thinking three acts, but that may change as things move along.)  Right now, we are in the process of working on act II, which is an exploration part of the game.  This act gives the player a chance to do some investigating and learn a little more about the situation they are in.

To keep this post from going on longer than it already has I’ll wrap things up here.  Over the next week or so I’ll try to write some more up on the story/plot of the game and some more about the actual programming we are doing, so be sure to check back for those.  But for now, we figured we would just give you guys a quick update post and let you know that we are (and have been) hard at work on a new project that we are super excited about and we hope you’ll be excited about too.

As always, thanks for reading,

-Matt.