Welcome To a New Era

Hello everyone. Exciting times at the isoChronal Panic! offices. While Alpha testing was supposed to start last Monday, we found a bit of a bug in the code and decided to hold off a bit before releasing it. We just recently squashed that bug and are polishing things up for the Alpha release later this week. In the mean time I have some more art to show you, and it offers a tantalizing look at how we are going to handle the concept of levels in the game.

Eagle eyed players out there may have spotted that the two computers in the test level are looking a bit older and spottier than they used to. What happened to the polished machines we saw several art updates ago? Don't worry, they're still around, in fact they're even in the game, if you don't know what I'm talking about have a look at the images below:



An old computer console. Looked kind of out of place with the high-tech door and containment force-field in the current level.




An old reel-to-real relay computer, those things are ancient. What is this the 1960's?

 At first we sort of wanted the time period Dan Guymore was in ambiguous, hence the old computers mixed with advanced technologies. But then when we got more into the particulars of our timestream we decided we needed to be more exact with where (or more accurately when) Dan Guymore was in the timeline. Eventually we decided that the two computers were old relics maintained out of nostalgia by the guys working in the time lab, but recently upkeep had been neglected for whatever reason.

So if the two computers are old relics now, that must mean they were once top of the line back in there day. That sort of gave us the idea of having various objects serve as ongoing threads between different era's. To that end, we remade the lab into it's 1960's digs. Here have a look:

 

Nice shag carpeting.

Nice huh? Let's have a look at each of the elements up close. Of course I'm going to skip over the stuff we've seen already.

Anyhow, we wanted to acheive three things with the differences in artwork between eras. First and foremost we wanted to show how objects change between eras. Somethings like the pipes and vents are pretty constant between this era and the previous one, but other things have changed. For instance:



Chemicals are chemicals now matter what time period you're in, glass beakers work no matter what year it is. Much more fickle are the whims of interior design. The modern industrial gray desk just doesn't fit with the sensibilities of the 60's, so we introduced this jazzy little teak desk design to spice things up.

Same goes for the office desk. The paper trays are strickly functional, but the desk is now a lot more decorative.

Notice anything weird about the skyline just now? It might be hard to see against the white background, so I'll enlarge the image for you.



See the crane in this one? It's adding the finishing touches to the Space Needle, also the skyline in general has shrunk relative to the more built up skyline of the previous era. Just wait until you see both of them in game, then you'll see what I'm talking about.



Our desk jockies still need someplace to sit. Instead of that purely functional chair from the modern era, we now have a little more fun with an oak roll chair. Granted rolling chairs weren't common in the 60's, but we figure these guys are ahead of their time as far as technology goes, for obvious reasons.

Another one of the themes we wanted to drive home with the art is the idea of finding different solutions for the same problem. We use this theme not only because we have to find a way for the past era's to experiment on and hold the Timetanium with fewer technologicakl resources than the era preceding them, but also because we want to encourage players to find different ways to solve the same puzzle of getting the Timetanium to the portal in different ways. Here are a few examples:


The researchers in the 60's don't have the benefit of having sliding steel blastdoors on hand to secure the room, so they're going to have to make due with a stout oak door instead.

 

Whereas before we had the Chrono-Bowler blueprints tacked up onto the wall, in the 60's era all that's on hand is a chalk board. This doesn't so much show the difference in technology between the different era's (I'm pretty sure they still drew blue-prints back in the 1960's), but rather how far along the development of the Chrono-Bowler was. Having the designs and formulas being up on a chalk board gives the impression that this is all kind of theoretical at this point. Although from the looks of things, they've come through with some kind of breakthrough just recently.

Each era is going to have to deal with the problem of how to keep the Timetanium secure, (and fail at it since Dan get's away with the loot every time). The high-tech magnetic field from the previous era isn't going to cut it here in the 1960's. This contraption is one part nuclear core, one part isolation chamber, and one part diving bell.

Finally we also wanted to use the items in each era to sort of tell the story of how the world came to be, why something was made, and who made it. Let's look at the objects that tell the story of the game world:


Here we sort of see the origin of the Chrono-Bowler. The nameless mad genius who invented the Chrono-Bowler which Dan uses in his history spanning crime spree was apparently known to wear a Bowler himself. Although the inventor himself isn't really important to the plot as a whole, we thought we'd leave traces of him throughout the level.

With this poster, we get a hint at why the Chrono-Bowler was created, or at least begin to understand the setiments of its creator. Perhaps the Chrono-Bowler was meant as an instrument of peace, and the inventor wanted to use the wonderous creation to bring us all together? Or maybe he's just reflecting the attitudes of his time. Who knows?

The display case doesn't so much explain a lot about the Chrono-Bowler's inventor, but rather it will provide another thread between eras. I haven't add some elements to this official release yet because I didn't want to spoil things before we get there, but this case will hold a few relics from next era in our trip back through the timeline, once again showing a link between the different eras. I'll show you the full display case during the next art post, where I introduce the third era we'll explore as Dan Guymore.

So that's a sneak peak at the 60's era. We still have two more era's planned for the final release, but let's take things one at a time. Until next time, see you later.

My, How Time Flies

Hi everyone,

Sorry for the delay, but we're back with some big news. A lot of things have been clicking into place recently, and we're just about ready to come out with the Alpha Version of the final product. This comes with several different announcements: first, obviously is the date of the Alpha Test, Alpha versions of the game will be going out August 6th. Secondly, we're actively looking for play-testers, so if you have a touch enabled phone and want to give isoChronal Panic! a try post a comment and we'll arrange to send a version to you in the upcoming Alpha test.

These great steps forward started with a breakthrough started with our finally nailing down Touch technology. We're looking to make a blog post about that as soon as we get the Alpha out the door. Jon is going to be tackling that article because it involves a lot of technical detail. So look forward to that coming up.

Other than that things have been a bit less glamorous, mostly we've been smoothing out the animations and doing touch ups to all the visuals. If you want to see how things are looking now, check out the most recent version here.

Look for this blog to be a lot more active in the coming weeks.

isoChronal Panic! 1st Monthly Tech Demo Live Blogging Extravaganza

Hey everyone, we've been sort of quite for a bit, but that's all about to change right now! For the last couple of weeks we've been really putting our noses to the grind stone to get the game into a shape where we can start showing it off. To get us all motivated we agreed to have monthly tech demo's and live blog our progress.

Before we begin some quick notes to get everyone caught up on changes made in the recent months:

• First up there are going to be some changes to the blog. Rather than have everybody making separate posts, I've been designated blog master. As such, I'll be collating the information from Jon and Ethan into two blog posts per week, and if they make any huge breakthroughs on the game, they'll come in and explain it to you first hand.
• We've made a lot of upgrades to our production process, the most evident being our switch over to SourceForge for version management. We had been using Dropbox previously, but we found out that for whatever reason, Dropbox was losing our files from time to time and costing us serious amounts of time and effort keeping versions straight. The migration to SourceForge wasn't easy, but it's really helped to pick up the pace of progress.
• We've also reworked the code architecture for the game, making it much more streamlined. You'll be able to see pretty much all the game mechanics implemented on the browser version posted below, with Touch Screen implementation to follow soon.

So to give you some sense of how this looks from our end, right now we're working at a computer lab, getting everything in order for the ongoing tech demo's by integrating all the work we've been doing over the last few weeks into one coherent game. All of the alpha art is in there, and our most up to date tech.

Looking at what we've made it's all looking pretty good, but there's still some work to be done. Seeing how it all looks together, the art style is starting to click, but important items like the Timetanium or the Time Portal definitely need to be called out more, either by making them glow, or just being brighter. Also by a happy accident the time portal jutters and wobbles, implying instability, but it could definitely use some visual effects to get that across. On the technical end of things, copies aren't colliding with the obstacles and sometimes get lost as a result. Also while we've proved our level swapping code works, the stage it switches to is just the background with no objects. We need to start building more levels to really put the game through it's paces.

That's it for our first tech demo! See you next month where hopefully things will be ready to move into playtesting. If you want to check out the game so far, you can find it here: http://users.wpi.edu/~jonsaunders/isochronal_panic/panic_index.html

Bringing It All Together

Hey everybody, we here at isoChronal Panic! are getting really close to having our first level done. All the art is in, and I thought I'd give you a look at how things stand now.

Originally we thought we'd really stress the outlines of the shapes with thick border lines around each shape, for example if you were looking at a 3D cube and could see three of its faces there would be an outline around each of the three faces. However we moved away from that, and instead emphasized our shapes through contrasting colors. You can see the difference in the two art styles in the example below:

This is the original design for some wall pipes throughout the lab, see how there is a thick dark gray outline around all the shapes? It certainly helps the pipe stand out, but you can't really see the small bolts for their outlines.

Here's the same pipe again, although we changed the look to match it's place in the level. The different segments of the pipe are differentiated by contrasting shades of a certain color, in this case gray. The bolts are a light tone, the pipe itself is medium gray, and the fittings are dark gray.

Don't our game is as dull and lifeless as all those brown and gray games on the consoles, there's a lot of color in this game, and adding more a lot of color was one of the big things we did in the first levels art design. Take a look:

We've got some nice warm chemicals for the chemistry set on the table . While the desk itself is brown, it helps the brightly colored vials and beakers stand out.

The wet floor sign from before, now a lot cleaner and focused on the bright yellows.

We even have some rich blues with the redesigned blueprints. check out the fold lines on the  paper, the blue prints now look like they've actually been handled by someone.

As you can see, a higher level of detail has been added to the new art assets. We're trying to make the different objects interesting without overloading the art with details you just aren't going to see. Here are a few examples:

Now the window looks out  on more than just sky. This view gives players a sense of where the lab is in space. They can now tell they're on the ground floor, (which makes sense), and that there is a city out nearby. The city is just an skyline, but there was no reason to get too detailed with the city itself.

The rug has a bunch of little fibers and knots in it's weave. If you look closely you can see that they're all just the same shape. Areas of more solid color just don't have the little details in them.

Even the stage itself is more detailed, there are now little cracks in the floor, and the whole lab seems to have a lot more texture to it.

Let's see how this looks all put together:

Alright, can't wait to start playing in this new environment.

Story Time

Time travel is a fun little subject, there are a lot of possibilities inherent in the concept. First the very idea of time travel plays upon human nature as it is only natural to rail against the oppression felt at the hands of the clock,as time continues to march forward no matter what we do. The rigid linearity of time means that we only ever get one chance at something, and the constant theme of predestination in time travel tales is a bit of a rationalization of this; it always seems to turn out that the way things happened were the best way for things to happen, otherwise that would mean that the decisions we could have made in the past could have turned out better, and with how time works in reality, we'll never actually be able to experience the benefits of having chosen correctly. Both the premise and the moral of the story are reassuring fantasies.

Using time travel as a narrative device also allows authors to play with perspective. People only ever experience time linearly, but through imagination and memory, can mentally project themselves either into the past or the future. The problem with perceiving the past and future in a purely mental sense of the word is that we can't actually tangibly change anything. No matter how many times we relive a memory, the past remains the past, and no matter how thoroughly we predict the future, it is still just a guess until the appointed time arrives. In time travel fiction these rules change, being able to foresee the future will allow you to change it, the past can be relived exactly as you remember it, only this time you can change things for real. Heck, with time travel it's possible to uncover events in the past that allow you to change the future, or use information from the future to change the past. The linearity of time is soundly cast aside, and whole new realms of perspective open up to the reader.

But enough about time travel as a high concept, how is isoChronal Panic! going to be using incorporate time travel into its story? Well, in the world of isoChronal Panic! time travel is possible thanks to a special element called Timetanium, the only problem is that there is a very limited quantity Timetanium, well in the physical sense of the word. You see all the Timetanium in the entire universe was created in the form of a giant crystal at the dawn of time, that's all the Timetanium there ever was, or ever will be... at one time. Because Timetanium exists throughout history, that means there are an infinite number of individual instances of Timetanium throughout time.

Our main man Dan Guymore may not be an astrophysicist, but he understands the concept in general. His cunning plan is as such: If 1.) Timetanium is extremely rare then that means it's valuable and 2.) Timetanium allows for time travel, and 3.) If one Timetanium crystal sells for a lot of money, than more than one crystal should sell for even more. So it stands to reason that he can use the Timetanium to go back in time to steal more Timetanium and thus get a huge payday by selling off thousands of different Timetanium crystals. In order to get as many Timetanium crystals as possible Dan must start in the his present, (i.e. our future), because if he tried to travel into the future to steal the Timetanium there it wouldn't exist because he used it to power his Chrono-Bowler to travel there to get it. Anyways by starting in the present and working his way backward to the dawn of time, Dan can steal every instance of the Timetanium in existence. Sure it might cause massive chronological instability as time clones of himself pile up within a small cluster of seconds, but all the money he stands to make will make it worth it! It's the perfect plan, nothing could go wrong with it, and even if something did, he could just go back in time and fix it, it is truely the perfect time crime.

A New and Exciting Future

isoChronal Panic! is all about blazing new frontiers in game design, this desire to do something new was at the heart of decision to develop the game for smart phones like Android and the iPhone. By working with these new platforms, we have to work within the constraints these new technologies bring with them in the early days of their development, as well as take advantage of the new possibilities they offer.

As I mentioned earlier, isoChronal Panic! is being developed primarily for Android and iOS, and while we'll also releasing the game for regular browsers, our main focus is for mobile devices. This means utilizing touch controls, and deciding exactly how to use the touch screen was a challenge in and of itself. We considered several different control schemes: having the player drag their finger across their desired path, a little pop up control pad, or even a simple grid system. In the end, we settled on a simple touch to move mechanic; the player just touches where they want to go,and Dan Guymore will go there on the straightest possible line. This seemed the most intuitive use of the touch screen technology, allowing the player to direct his character with a minimal number of inputs, and because the player taps where they want to go with their finger they'll know exactly where they're going after inputting a command.

While ease of use for the player is one of the benefits of working with smart phones, they also have their own particular issues. For example the iPhone does not allow browser based games to preload sound into a game, and only allows for one channel of sound at a time. This makes adding sound into our game a bit tricky, we have to figure out a way to play some manner of melodious sound in the background, while also interrupting that sound to add in sound effects that give the player auditory ques that they, for example picked up the Timetanium and should proceed to the exit portal. Nobodies figured out how to do this yet, most iOS developers have to go through the Apple Store to access Apple's tools to handle sound, or just do without sound for browser based games.We're hoping to get around this hurdle by thinking around corners. While all the details aren't sorted out yet, we've got a few tricks up our sleeves. To get around the preloading problem, instead of music being made up of one large sound file preloaded at the beginning on load up, sound will be broken into several extremely small snippets perhaps individual MIDI notes that will load in real time. The background music, instead of being a specific composition, sounds will be played based on an algorithm related to the players position, and how close the player is to temporal copies of himself. We're still working out the details, but we're pretty close to something no one has ever done before, and that is what we're after with this project.

Early Difficulties

We've been working on this project for several months now, and made considerable progress. But it hasn't all been smooth sailing. The issues which have given us the most trouble are getting the game to work on touch screens, figuring out how to handle sound, and the particular nature of the basic structure of our code.

Touch compatibility

The touch, in particular, has been a thorn in our sides for too long. Everyone expected it to be a fairly minor addition, which would take a week or two, tops, to implement. It's been more like two months at this point, though, and while we're closer than we once were, it still hasn't clicked for some reason. The first few attempts didn't work at all, until this little section of the code in our GameObjectManager was fixed:

   // watch for keyboard/mouse/touch events   document.onkeydown = function(event){g_GameObjectManager.keyDown(event)};       document.onkeyup = function(event){g_GameObjectManager.keyUp(event)};   document.onmousedown = function(event){g_GameObjectManager.onMouseDown(event)};   document.onmouseup = function(event){g_GameObjectManager.onMouseUp(event)};   document.onmousemove = function(event){g_GameObjectManager.onMouseMove(event)};   document.ontouchstart = function(event){g_GomeObjectManager.touchStart(event)};   document.ontouchend = function(event){g_GameObjectManager.touchEnd(event)};   document.ontouchmove = function(event){g_GameObjectManager.touchMove(event)};

The last three lines used to begin with document.touchstart, document.touchend, and document.touchmove, but we eventually realized our error. (I realize that these would normally all be event listeners, but that didn't work when we tried, probably due to our code structure which I will discuss later)

With this minor fix, we got touch working a little bit. The game can recognize when the screen is touched, since the title screen, when touched, launches the game. However, the player is supposed to be able to drag their character around the game environment, and this still isn't possible. I suspect there's something wrong with the way we're getting the coordinates out of the touch event.

Sound

Next, there's the question of what we're going to do about the game's audio. This will take some consideration since we want the game to be playable on the iPhone, but Apple has restrictions for sounds in HTML5; mainly, that only one sound file can be played at a time, which makes combining sound effects and music way more difficult. But we still want to try to do so in our game, if only to prove it can be done. There's also the problem of getting the sounds loaded, since they can't be pre-loaded. When we tried, the game would say each sound was loaded, and then unload it as soon as a new sound was loaded. As such, the sounds all need to be loaded only when they're being used, which means our sound files need to be really small to load easily in a short amount of time.

Uncommon code structure

Finally, there's the way our code was set up. It uses a class-based structure, but all the classes are actually just constructors. This was based on a tutorial we found when we first started the project, but now we realize that it might have been better to use a more standard method of arranging the code. Problems are difficult to fix, since many of the potential fixes we find are incompatible with our code the way it's set up. Currently, we're working on making some changes to make the code more manageable.

At least some of these problems probably have fairly simple fixes which we only missed because of our inexperience, but at least we're learning how to handle these kinds of problems in the process. After all, this entire project is a learning experience.

Art Show

Let's look at this weeks art shall we?

Let's start with something familiar, the vents have been tweaked a little to be in scale and flush with the newly sized-down walls.

Another item you might recognize from before is the office desk, although this time the In and Out boxes make sense in perspective.

The security doors have also been adjusted for scale, perspective, and are now a lot more subtle in their outlines.

The chemistry set also got a face lift, except this isn't like the minor tweaks of the desk and vents, it's looking  a lot sleeker now.

Alright, enough with the old stuff, let's have a look at what's new. Check out the new area rug, to give the lab a bit of a more lived in feel.

Also, we've got two dests and no chairs? This is unacceptable! We picked this little beauty up at a yard sale, the guy there told us it was authentic Quaker craftsmanship, and I for one believe him.

Finally, a reading lamp, for looking over lab reports late at night.

So what's this all look like when put together? Something like this:

Finally a look at Dan Guymore, fully ambulatory:

Front

Back

That's all for this week, I think by next week we'll have a whole level to show off.

Art Heist

"Good Artists Borrow, Great Artists Steal."

-Pablo Picasso (attributed).

Stealing a sentiment from someone else seems like a good place to start our larger discussion about art, and the theft thereof. This week we'll discuss where the inspiration for isoChronal Panic!'s art style came from, and why we did it that way.

Now to clarify that bit about stealing up above, I'm not claiming to have plagiarized any other works of art for our game; my personal mark is on every single element of the game and it's all original, in the sense that anything can be considered original these days. While I can honestly claim that I didn't go in and literally trace any pictures directly into the art folder of the game, I can't say I didn't get some inspiration from other sources. Ideas for drawings don't just come out of the ether, and as such I've looked at possibly thousands of images for inspiration of what to draw.

To give a good example of just this sort of thing, we recently decided that we wanted to give the laboratory that Dan Guymore is stealing the Timetanium from the look and feel of a nuclear waste storage facility in order to imply that the Timetanium was somewhat dangerous, and say something about Dan's character that he didn't seem to care about the risks presented by the dangerous material he was about to handle. Okay, great, that's a good direction, but real quick art test for you guys at home: Without looking, draw me a room consisting of walls and floor that conveys the feel of a nuclear science. With only things like the wall and floor to go by it's pretty tricky.

To help you out, try a google image search for Nuclear Waste Facility. You'll start to see a lot of industrial concrete and safety railings, and upon looking at them you get a real sense of what these kinds of places look like. Specific knowledge into these sorts of facilities helps too, you could see some of the more famous nuclear science facilities, like Oak Ridge and Los Alamos; modeling the art in the game after these sites in particular makes the location seem more fully realized and less generic.

Once you have some inspiration for the art, then you need a specific style. In the game, the art style has a lot of crisp clean lines, with a few parabolic curves thrown in. Color is handled with overlapping simple geometric planes, or if we want to add a sense of texture, gradient meshes. All the shapes have a strong outline to help them stand out on the screen. Every object in the scene is viewed from an exaggerated top down perspective, the perspective is looking down from above, but all of the objects are themselves slightly skewed so that their tops are visible to the camera.

In the next art blog post, we will run through this entire process with one particular asset, so stay tuned.

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: