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.