Dry Spell

Not a whole heckuva lot to report. Progress on the code-front was suspended last week as a vital team member was away at a conference. I've been focusing on the game's rapidly dwindling list of art assets that need to be created or tweaked. And if you've ever watched someone make art, you realize that while the finished product can be cool, the process is, well, a process. It sort of moves at it's own pace, and if you're not actualy doing the art yourself, it's not that exciting (unless you're very invested in how the image will turn out, like if you've been implicated in a crime, and the sole witness is describing what the assailent looked like).
So that's it for this week. It's been cold here in Oklahoma City, but it's been cold most places in the US, so why am I suprised? Take care, and we'll see you next week!

More Documentation Work

Something I took away from my short stint in the professional video-game world was my feeling of shock over the sheer amount of documentation that was developed in order for one team to relay it's needs to another. I've been going nuts with documentation for the past few days, creating a complete game walkthrough from the code-perspective. More later today...
I'm back. Turned out the City of Oklahoma City (surprisingly that's not as redundant as it sounds) shut off the water at the popular Coffee and Sandwich shop I was visiting, thus forcing it's closing for the day. Oklahoma City is kind of like that; every time you think you've located someplace to sit down and work for awhile, you find out that either they close at 4pm, or that the city has decided to take the cap's off all the fire hydrants and allow 50,000 gallons of water to run into the street's. Odd place.
Anyway - back to what I was talking about 5 hours ago. This code-perspective walk through I put together is a monster, but should be very useful in the overall development of the game's back-end. As a frequent reader of this web-log would know, I'm very new to any sorts of code, but am increasingly placed in code-grunt role for this project. As the artist I've found it useful to spell out what I want the code to do in the document in question, because it allows me to direct the game's movements, or chapters if you prefer. The cliche that artists can be fussy and controlling of their work apparently does not fall to far off the mark in my case. Here's an example of what I wrote up;

- GREENHOUSE DOOR: LOCKED (greenhouse_door_locked.html)
o USE: THE MAGNET
• ROOM SWAP (greenhouse_door.html)
• TRIGGER: EMAIL - CHALLENGE 11
- GREENHOUSE DOOR (greenhouse_door.html)
- GREENHOUSE (greenhouse.html)
o EMAIL: CHALLENGE 5 (free Gustava Challenge) (greenhouse_challenge5.html)
• POP-UP: YOU WIN! (greenhouse_challenge5_win.html)
• ROOM SWAP (greenhouse_empty.html)
o POP-UP: PICKUP CODE WORD “SHERBET” (inv_code_word.html)

Phew! The thing has a glossary of terms, for Pete's sake. More next week.

Inventory Matters

When I say that I make online training games, I kind of feel like I'm lying, or at least exaggerating. This is because I, like many people, have a lot of preconceived notions as to what an online game looks and feels like, and what a training game looks and feels like. Here are mine (feel free to compare);

Online Games
- Web-based, low graphic puzzles or 'action' games intended as a brief distraction from your work. Often mimicking popular styles of "bigger" games (like First Person Shooters or Role Playing Games). Usually feature little or no story lines.
- OR Massively full blown action/adventure install-based games with an online "virtual world" component, featuring fancy graphics, story lines, ect.

Training Games
- Simulation based environments or virtual scenarios intended to mimic real-world skills or situations.
- OR Childrens games using likable characters and puzzles to teach basic skills in a wide range of topics.

So that's what pops to mind when I hear either 'online game' or 'training game'. I know that leaves out a heck of a lot, but those are the definitions that crowd to the front of my brain when I think in those terms. The odd thing is that the CITES Help Desk games don't fall under any of those 4 catagories. Here's how I would describe the current Help Desk Game;
- Web based 2D exploration environment featuring a fiction-based story line with integrated learning content.
That doesn't sound very 'game like' to me. To remedy that, a while back the team decided to invest some time and develop a more linear series of steps which revolve around an item inventory (which was mentioned in a previous post). This isn't the first time we've done this - our first slightly big production (a Halloween adventure aptly titled Escape From Bloodridge Manor) featured a similiar inventory-driven experience. Why did we stray away from an inventory in our proceeding games? Well we were trying to allow our players to have a more 'open world' feel to the game, which nobody was realy impressed by. That, and inventories are really tough to make.
Why do I bring all this up? Well cause while we don't have a functioning inventory just yet, we do have all the art assets in place as of late last week. I'm excited as heck - here's an example image for your viewing pleasure.

Technical Difficulties...

It's Wednesday! Update time! I haven't made a whole heckuva lotta progress in the last few days - this is largely due to the technical difficulties. Since I work from the road, everything I do is on a laptop. Turns out that my laptop is experiencing some sort of power issue; occasionaly it'll turn off when it has a full battery, or even when it's plugged in. Sometimes it wil be plugged in, but the battery will drain anyway, and it will shut down once the battery is dead. It's all very confusing. I looked up the issue online and it my be related to a bad motherboard component. So the computer's usable to a degree, but not at all reliable. I've spent the past few days re-creating my work environment on my fiancee's laptop. Now that I'm up and running on a new machine, I can get back to work.
This is one of the hazards of working from the road; you're very dependent on what you have with you. Last year the computer I'm on now had a hard-drive failure, and I spent the next two weeks without a machine. This was a pain, but I was at the stage in the process where drawing mattered more then anything else, so it turned out okay. If I had been without this backup machine this go round, I would have been in pretty bad shape.

Java-foo

I'm not much of a do-it-yourself kind of guy, but from time to time over the course of this project I've jumped online and attempted to figure out how to improve the game with javascript. In the past these efforts have been fruitless, but late last week I gave it another shot and things just worked out. I've discovered a way to randomly call up animated gif's everytime the game's player moves their mouse over a hotspot. And just yesterday I got a 'page loading' gif working (sort of - currently it cancels out other parts of the onLoad event, so it's kind of like taking one step forward and two steps back).
I bring all this up because I'm not a code guy. I have no real idea what I'm doing, and by all rights should not be allowed anywhere near HTML. But eventualy, with enough tinkering, things just started working. 'Code people' reading this are likely to be rolling their eyes, because yes, it's not that hard once you understand what you're doing. And while I have a much better understanding of how it all works now, I can clearly remember two weeks ago when I didn't have the foggiest idea of how an array functioned. For me the experience has reminded me why I love making these training games; if you set your sights high there will always be new hurdles to jump over, and getting over those hurdles can be a hell of a lot of fun.