Modern Art, (as in we just recently made it)

Here are some new art assets we made for today:



A window in the lab, it might look a little transparent around the boarders, but when placed within the environment it looks built into the walls. Later on, we plan to change what the player see's outside to imply some time related hijinks caused by Dan's tampering with the time stream.

Another computer, we've got a retro thing going with our technology I guess.

Another pass at the desk, this time with a lot more surface area, and both of the in boxes share the same perspective as the desk. Looking good!

A closer look at the Timetanium, actual game size. This is the most precious mineral on earth, so I'm glad we got it to look sparkly.

Radioactive waste, I like how it's leaking and generally looks unsafe.

A couple of vents for the walls, they look pretty good when integrated into the environment.

A take off on the work desk, this is a chemistry station. Look at all those colorful liquids!

Some schematics for the Time-Bowler, giving the player some idea where this thing came from.

Here is the game space without anything in it, just for reference, if you want to see it with a bunch of stuff in it, play our current version of the game.

And a mock up of how the lab will finally look.

Finally, here is Dan Guymore, stomping around in his usual way. Keep on strutin' Dan!



Making Sound

iPhones have some major restrictions when it comes to sound outside of an app. There are two that are particularly tough to work around. The first is that no two sounds can be played at once; there is only one sound channel that can be played at any given time. The second is that sounds can not be preloaded. If a sound is to be played, it will always be loaded in that same moment, whether or not it has been played previously.

After a whole lot of mucking about and trying to figure out how to bypass the system, we decided to take a cue from music games like Groov on Xbox Live Arcade and only play a sound when the player is making an action. Actions would include picking up the timetanium, stealing the timetanium from a copy, entering the level, using a portal, and even walking. This way there will be a sound playing almost constantly, at least as long as anything interesting is happening. Since this will be taking the role of background music as well, the sounds will form an abstract musical piece when played in succession.

The solution for the second problem is fairly obvious: since the sounds can't be preloaded, make their file size very very small, so that it doesn't lag whenever a new sound is loaded. So what this all boils down to is that the audio will sound like SNES era wind-chimes. I don't see a problem with this.

Ghost Town

Originally, when the only idea we had for the game was the mechanic of time clones, we had a very different idea of what the gameplay would look like. For the setting, we envisioned a town which, at first, would be devoid of all life. The gameplay would revolve around the player populating the town with their past selves. One hop would involve the player going to various places and interacting with set pieces (or not), and on the next, a time copy would carry out those same actions. The working title we had for the game was 'Ghost Town.'

Needless to say, the concept changed a lot as we fleshed it out and discussed what sorts of things we might let the players do. In particular, we spent a lot of time speculating about how the players could interact with their past selves. We wanted the player and their time clones to be able to hand items off to each other; for example, the player could place an item in a square, and in a future hop they could return and (assuming their past version had already deposited the item) pick it up and use it for something. Or, the player could go to a particular square and press the button to pick up an item, so that they could later pass off any item they chose to the resulting time clone.

Inevitably, we began to wonder: what if you could kill one of your time clones? Discussion of this topic, and of the player's goal in the game, led us away from the idea of Ghost Town. The next phase of our game's design is a story for another post. Ghost Town could have been an interesting experience, if we'd gone through with it; it would have been more focused on art and creativity than gameplay, and it would have been much more experimental. But, as we never quite came up with a satisfactory goal for the player, it didn't stick. We could always try it out again later, but for now it's been put aside.

The Code Behind Time

When programming Isochronal Panic! one of the most important design concern was how to make the time copies. Let's take a look at how we did it:

Time copies work in a fairly simple and straightforward manner. Essentially, the player avatar always has a recorder object in it. The recorder keeps track of two lists of variables, the location the player is headed towards, and the current time whenever that location changes. When a hop occurs, the record is handed over to a new entity, which has almost the same code behind it as the player avatar, minus the control input. The copy then follows the steps layed out by the record exactly, by traveling in the direction specified for the the amount of time specified. Do this over again a few times and soon you've got a room full of yourself!

Let's take a look at some code:

this.recorder.recordObject(new Coordinate().startupCoordinate(this.destX, this.destY));

This line in the player object is called every time the coordinates of the clicked mouse, this.destX and this.destY, changes. A new coordinate object is created on the spot, and then sent to the recorder object that the player is holding onto. The recorder puts the new coordinate and a time-stamp into an array.

if (this.tick === this.record.duration[this.count]) {
 this.activateMovement(this.record.direction[this.count];  this.updateRequired = true; this.count++;}

This little block in the update function of the copy class is what reads the record made previously. Movement works the same as in the player, but instead of being controlled by coordinates from mouse input, it is controlled by coordinates stored in a record. The third line tells when the animations should be updated. The last line increments a simple count variable, so that when the time comes, the next coordinate in the array is read. This method is fairly simple and works pretty well under normal conditions. There is a major problem with it though: lag. It doesn't particularly cause lag, but when playing over the browser, especially on a phone, lag will happen. The first line of the above code is an if statement that will let the rest of the block run when the current moment in time, or tick, of the game matches the time-stamps in the record. If the game lags, then often times the tick variable will skip ahead a little bit, causing a few chunks of time to go ignored. If this happens near when the above code block should be executed, it might not get past the initial if statement. For instance, if an action is supposed to occur at tick 12 and some lag starts up at tick 10 and lasts till tick 13, then there's a good chance that ticks 11 and 12 will be skipped over entirely. The change in direction never happens, and the naughty copy just keeps walking in the same direction. We are already working on possible solutions to this problem.

Other Times

This week we're going to talk a bit about the various themes running throughout isoChronal Panic! When we started design on the game, we knew that all games need a conflict, something to engage the player. We had some more existentialist ideas at first, which we will get into in a future post, but for a while we were kind of stuck.

In most games, the bad guy is some sort of "other." A creature or life form that's abstracted away into being little more than a token representation of "bad." It's okay to kill these others, because they aren't like you, you know how it goes, "They stand for everything we stand against." Sometimes stories do a good job of humanizing the antagonists, giving them good reasons to do what they're doing and showing the conflict in terms of two groups caught on opposite sides of an issue where no one is at fault. That wasn't really going to work for us, though, we're making a little browser based game for hand-held devices, we only have so much time to dedicate to story and character development.

When we started playing around with time travel mechanics, and realized we wanted to really emphasize the cool gameplay mechanics over the story, we realized we couldn't spend a lot of time getting to much into the back story of the enemies. However, we didn't really feel like just making the antagonists the generic "others" as discussed earlier. For awhile the team was kicking around the idea of the only obstacle to your success being the environment, but that had sort of been done before. I mean, in the fiction of the world you have all of time and space at your command, (well maybe not space, but definitely time), so you could just pick your battles if you wanted. Why not just wait until the spikes in the pit had rusted over? Why not wait until those pesky walls surrounding your objective crumbled to dust before stealing your prize?

The breakthrough came when we started talking about how exactly players would interact with their past selves. We went through a bunch of "what if" scenarios, like "what it on this hop you get to someplace before your past version had pressed a button to let you through,?" Or "what if you somehow kill a past version of yourself? Wouldn't that throw off the entire chain of events you'd been building towards until now?" Finally someone out and said, "Man, dealing with your pasts selves can sure get annoying." And that's where we got our idea that your past selves could be the element in conflict in the game. Instead of giving players past versions of themselves as resources that are difficult for them to exploit, we instead exploit the fact that it's difficult for the player to foresee the results of their past actions and force them to deal with the consequences of not thinking ahead.

Using past versions of the player as antagonists also gives us an interesting opportunity to say something about game antagonists in general. The Other as used by most videogames is a way to pin the blame on someone else. Events within the game need to be fixed because of the actions of some outside force. All of your problems are the fault of someone else. Here, the enemy is you. You're going to have to take responsibility for your actions and acknowledge when you've made a mistake in order to fix it. The only antidote for the Other is the Self.

More Art!

Check out the new environment everybody:

Okay, time to fill it up with something:



The Basics of Time Travel

It's probably about time we discussed the mechanics of our game in detail. First, a few definitions to make it easier to talk about the gameplay:

• Dan Guymore: Our protagonist, and the character you'll be controlling. A greedy chronological criminal who exploits time travel technology for his own profit.
• Timetanium: Dan Guymore's (and the player's) objective; the goal of every level is to get as much Timetanium as possible. Timetanium is the extremely rare element that makes time travel possible, and as such is worth a lot of money.
• Time clones: What they sound like: past versions of Dan Guymore produced by his time-related escapades. Due to the nature of time travel, they're stuck repeating Dan's previous actions. Because of this, they get in Dan's way as he tries to repeatedly steal the Timetanium.
• Hop: A single pass-through the game area, in which the player gets the item and goes through the exit portal (or fails to do so).
• Time portal: Dan Guymore's entrance to/exit from the lab containing his precious quarry, the Timetanium. This is where the player must bring the Timetanium to successfully advance to the next hop.

With these definitions in mind, here's how an average hop will play out:

Dan Guymore enters the lab through the time portal. On the first hop, there are no time clones. One will be created for each successful subsequent hop. Dan then steals the Timetanium from its container and escapes through the time portal. The player will have to be careful to weave their way around time clones in the lab, but also think ahead to keep from interfering with their own future hops.

But it's not so easy as it sounds. The time clones can also steal the Timetanium, and if they get it to the time portal first, Dan Guymore is left with nothing, and the player is sent back one hop to try again. If, at any time, the player wants to start the level from the beginning, they just need to enter the time portal without the Timetanium.

There will be many levels throughout the game, with varying environments, Timetanium and portal placements, and a few other surprises. A player completes a level when they've accumulated a certain number of successful hops.

That just about covers the basics. Now that we've established this fundamental information, we're ready to delve into the nitty-gritty of the game in future posts.

The Artful Dodger

Hey everyone, let's look at some art:

Here is our new draft of the basic environment that the game takes place in, what we like to call a stage:

Cement floors, rusty drains, kind of looks lit by flourecents? And it's in perspective. We're on our way with this.

Let's look at the stuff we're going to put in the room.

Tesla Coils:

Security Doors:

An atomic clock:

Roman columns:

An office desk:

A dinosuar skull



Some pipes for the walls

Now the important stuff, meet our main main, Dan Guymore:

His objective, the Timetanium:

And his means on egress: The time portal:

Finally our new game logo:

Thanks

Welcome To Isochronal Panic!

Hello everybody! We're the IsoChronal Panic! Design Team. In total, there are three of us, Edward Golden, Jonathan Saunders, and Ethan White. We are Interactive Media and Game Design students at WPI, and IsoChronal Panic! is to be our Major Qualifying Project.

Now that you know who we are, let's talk a little about what it is we do around here. We are designing a game, as you can probably guess from our team name, the game is called IsoChronal Panic! (just to let you know, the exclamation mark is part of the name, although that doesn't mean we're not excited about that last sentence). While we're still slaving away at the game in an attempt to make it the best game it can be; we thought we would start a blog to keep you in the loop with the games development. Over the next few months of development, we'll all post here from time to time to let you know all the cool stuff about our game. Each of the designers will post about the work they're doing, and how that work will make the game fun for you to play.

Okay, perhaps you'd like a few more details besides that we're making a game and have a blog, hmm? The game itself is a simple game for web and mobile devices, playable with mouse or touch screen. In the game, your only objective in each level is to go into a room, grab an item and leave within a time limit. See, didn't we say it was simple?

"Well then," you say, "what keeps this game interesting? A tight time limit? Switches to puzzles to solve? Moving walls? Shifting control schemes? Fearsome obstacles and enemies?" Well, we're sorry to tell you that such is not the case. The only things in each level are the objective, which is always in the same place; the static environment, and the player;  the challenge is that you have to run each level several times over to advance to the next one.

"Well now, you're just dragging this whole thing out, aren't you?" you say, "Making us run the same level over and over again and nothing changes? I can just do the same thing I did last time and still win. There, I've beaten your little game and I haven't even played it." Well played dear reader, but something does change. Back there, we only said that there is only one kind of environment per level, and a level consists of the environment, the item and you. Same environment and item, different you. Or rather, different "yous."

IsoChronal Panic! is a game of time travel. It's all about thinking ahead, and behind. Yes the point is to steal the same object over and over, but can you trust yourself not to steal it before you do? Of course you can't, otherwise there would be a time paradox.

We'll get deeper into the particulars later, but for now stay on the look out for our next update.