Wow...Really!?

I'm now seeing that it has been quite some time I've written. And here I was hoping that I would write at least once every other week. Who knew that it take time to actually write?

Here's the long and short of it. Seth and I were working diligently on getting those finally elements into Oh! Gnomes!. In fact, Seth had parachutes and the dynamically difficulty working pretty well. And then something tragic happened. Seth updated the Unity package to include my work regarding bushes and his weeks of work disappeared. Ok. So it's not the most tragic event in the world. But I'm sure anybody that has lost that amount of work can attest to, it certainly does take the wind out of one's sails. But we're back and running. I think we're all looking forward to polishing the final bits on Oh! Gnomes! (especially when Unity 3.5 releases).

In the mean time, Karl has been working through the cards for Ghost. They progressively get better and better with each card. I keep joking with him that he'll have to go back and revisit the first couple cards now that he found the art style. But then those cards will be better than the later cards and he'll have to revisit those cards...and he'll be trapped in an infinite loop of making it better. Seriously though, he's only got about 3 more cards to make and then he's onto modeling the players and ghosts.

While he's been doing that, I've been continuing on making the board game solid. I got it to a pretty solid working state and played it with various folk. And the more I played it, the more I realized that it wasn't quite the game that I was intending to design. It played alright, yet it was horribly chaotic (the same way Ghost Stories is chaotic). This forced the lot of us to sit down and reevaluate the player-loop. Needless to say, it received a massive restructuring. We went from an action-point system (different actions had different costs) to a phase-based system. This made the game far more accessible, requiring the player to only think about 1 action at a time. Additionally we introduced room effects making some rooms more or less desirable than others. There are still a few wrinkles that need to be ironed out, but even in its horribly broken state, it already feels significantly better. Of course, all of the restructuring code have been avoided if I would have just made a paper prototype to start with...sigh...I should know better.

Alright. I think that's it.

And The Gnomes Continue

Sales are happening on Oh! Gnomes!...we are all very excited to see any sales. And we are even more excited because we got a some feedback from fans (primarily friends but if they like it...they're fans). With that feedback we decided that there are certain features that are indeed missing. So here's the major features we are planning to address.

1. Bushes that gnomes spawn under. You have to squish the bush before you squish or fling the gnome.
   
2. Parachutes for when gnomes spawn from the sky. If you want to squish the gnome in the sky, you have to squish the gnome and not the parachute.
   
3. Magic Pixie that you earn after surviving so many gnome waves. You can send her out to retrieve stolen coins in the field and return them to the Groundling.
   
4. Augmented Reality...yes...it's just that awesome. But unfortunately, it will be released for Android before iPhone. The iPhone library isn't released yet (I'm sad too).
5. Psuedo-dynamic Difficulty that tries to maintain player-flow.
6. Various bugs. Yeah. We found some.

We want to hear your ideas for how to improve our game. Thanks for your input thus far.

Heroes Who Hunt Ghosts

Artist's Log: Net date 0611.5

After being impounded for what seemed like ages, we have finally gotten our clearance from the iOS council. I admit that after spending all those weeks stuck on the ipod-3 station, watching as our applications were rejected one after another, tensions were running high. We'd certainly expected some hardships along the way, but the particulars of this setback had been especially frustrating. We are free and clear to continue our mission though, and I've been preparing for this for days now.

Our next destination is the Ghost system, only a couple of genres away from the Gnome world. I'm relieved that for the first portion of our survey, I won't be needing to wrangle with our 3d workflow, cobbled together from little more than free ware and string. No, the first part of the survey is being handled almost exclusively by the 2d workflow that, while old and outdated, at least doesn't give us many surprises.

I've already managed to produce these images of some of their greatest heroes.

These proved particularly difficult, and while I am very pleased with the results, I do wonder what they might have looked like if I had gotten them in a different setting. I made several attempts to capture some images while they were in town, but all of the abstract artwork, heraldry and symbolic carvings in the background proved too cumbersome. In the end I was forced to settle for some images in their natural habitats, but I think they turned out just fine regardless.

I look forward to tomorrow, when I return to my studies of the planet's native life forms. Spooks, ghosts, things-that-go-bump-in-the-night is what I believe they are called by the locals.

They're Here...Again!

Oh! Gnomes! is officially at the iStore (here). Thanks for your patience.

Augmented Reality is Just Plain Cool

We're continuing to go back-and-forth with Apple. Gotta love when you can play the game on our devices but nobody else can. Well...while we've been waiting, we decided to bring back augmented reality (AR) for Oh! Gnomes! For those of you that aren't familiar with AR, it is the idea of virtual images being superimposed on actual reality. With Oh! Gnomes!, the player points his Android at an image on the table and instead of the camera being constrained to a fixed orbit around the Groundling, the player can move the camera upwards-and-downwards, and inwards-and-outwards, and sidewards. It's kinda like a Wonka-vator. Anyway, we're hoping to have something here shortly for our Android enabled users.

And while we aren't adding new features to Oh! Gnomes!, we are continuing our work on Ghost. There is something strangely satisfying about rolling dice. Even if they are virtual dice. Karl is creating some beautiful cards for the ghosts and players. Once we get our final player cards, I'll post them and share the pretty.

Xcode > Devil

First, the good news: Oh! Gnomes! has been submitted to iTunes Connect for approval.

The bad news: it took a week to get it to that point, and will probably find out if we've been approved or not early next week. Hopefully we'll be approved this first time because I don't want to have to jump through all of those hoops again.

It all started when Xcode version 3.x we were running, and a old version of iOS on the iPod we were using to test were not compatible. To be able to push a build to the device to test, I had to update the iPod to the latest version of iOS (v 4.3.2). That updated it too far ahead of the version of Xcode we were running and we still couldn't push a test build to the device. So, we updated Xcode to version 4.0.2, but our project didn't update correctly. We had to go through all the pain of resetting up our project again, with the added difficulty of a completely new and unfamiliar Xcode interface. We got the build onto the device, tested it out and found that everything was running smoothly. Hooray! Now we can submit to Apple! The hard part is over! Right? . . .  WRONG!!

Apple provides documentation with the steps needed to build a distribution build, unfortunately they have not been updated to reflect the major changes they made to the user interface for the latest version of  Xcode. First, we had to generate a new Certificate Signing Request so we could create and download a new iOS Distribution Certificate. Next, we had to create and download a new iOS Distribution Provisioning Profile. Now we can make a build, right? Well, almost. We still needed to set up Xcode to do the distribution build, and that's where things got a lot more difficult. Turns out, you also need an App ID, so we had to go back and set that up and do a new Unity build to incorporate it. The directions didn't match the current interface, we couldn't find anything making it almost impossible to set up to build for distribution. After asking the all mighty Google, we got it all set up and built.

YAY! Almost done! We logged into iTunes Connect, filled out all the tax and banking info, the app info, uploaded screen shots for iPhone/iPod and iPad, set the price. All done, now lets upload! Er... where/how do you upload your app? Re-read all the instructions, nothing. Look over the app info page looking for an upload button, nothing. Back to the all mighty Google. Turns out we needed to download the App Loader program so we could upload our app. Of course you need a special program to upload your app to iTunes Connect for approval. It's so obvious. Why didn't we think of that?

After much pulling of hair, gnashing of teeth, and most of a Saturday, we finished the submission process. Now, our app is in limbo, waiting for approval. Hopefully we'll hear back in a few days.

In the mean time, here are a couple of teasers.

 

UPDATE: Because of a new issue with Unity for iOS and the latest iOS SDK 4.3, we may be automatically bounced. Lets hope that doesn't happen.

Dear Unity iOS Developers,

Unfortunately, many (and probably all) Unity iOS applications built with iOS SDK 4.3 are crashing during the App Store Review process while still running successfully on developer's devices. We have contacted Apple regarding this issue and received confirmation that this is of highest priority to them. Our iOS team is working on a solution as well, but due to complex nature of the problem it will take longer than expected to properly resolve. A currently known workaround is to keep using iOS SDK 4.2.

Many users reported that applications built with Xcode 3.2.5 + iOS SDK 4.2 successfully pass the Apple App Store review process currently. OS SDK 4.2  is not publicly available on the iOS Developer site anymore, but it still can be downloaded via direct link. We want to assure you that building final applications with iOS SDK 4.2 provides all the features the Unity iOS run-time supports and is proven to work fine with devices running older generation iOS (3.x-4.2.x) as well as the newer devices running iOS 4.3.x (like iPad 2).

Please feel free to contact us if you have issues releasing your application to the App Store.

Regards,

The Unity Team

Xcode = Devil

To all that bought the Android version of the game, thank you very much. And please, send us your feedback, we want to make the game better for you. In fact, we pushed a new build to Marketplace today because of a couple requests; and it's a lot better because of them.

To all that are waiting for the iOS release, again, we are working on it. We are working on it despite Xcode's hatred of us. We had Unity and Facebook integrated beautifully once upon a time. But because we decided we Xcode didn't hate us enough, we upgraded to Unity 3.3. Doing so broke our integration. Now we have to do it all again. So...you know, that's fun. Theoretically, we should be done by the end of the week. ...Then we can fight with App Store.

They're Here!

For those of you that are Android users, Oh! Gnomes! has been released to Android Marketplace! Go check it out here!

For those of you that are iPhone/iPod/iPad users, ...we're working on it.

Soon!

The gnomes are coming!

Three Guys, a Girl, and a Groundling Shop

It's been some time. Certainly far too long. I have no excuse other than laziness...and I've been distracted. Mostly laziness. ...No wait, I've actually been really busy. Between instructing courses in Game Studies/Development and working towards cert for a AAA title, I've been working on Gnome. Yes. Gnome. Actually, it is now known as ...

Oh! Gnomes!

I must say, Seth has been a life saver for this game. He has done all sorts of crazy things. Most importantly, he interfaced Unity (iOS and Android) with Facebook so that players will be able to post their scores to their walls. When he and I were developing it and we kept IMing scores back and forth to each other, it quickly became apparent that having such a feature would be absolutely necessary. He also made Gnome work via Augmented Reality. It is so much fun to play. Absolutely amazing. Unfortunately, we (meaning he) could never get the FPS to an appropriate level. The best I heard was anywhere between 20-25 FPS, which just isn't good enough. And to top it all off, he performed several user tests. We could figure out what worked and what didn't. In fact, we removed 2 gnomes from the list because of it. They just weren't fun.

And Karl stepped up to the plate for the team. He was busy working on Art assets for Ghost (splitting a small team is not recommended), but when I asked him for a little help, he modeled and animated the Groundling and environment. And in Blender no less. Invaluable.

Last but certainly not least, Denise, a programmer, looked at the team and said "We have enough programmers. I'll be an artist!" Ok. So maybe they weren't exactly those words, but the intent was certainly the same. She created the GUI assets, modeled and animated the gnomes, and had many valuable insights into Unity. This game could not have been made without her.

Why am I using the past tense for Gnome? Because the game is almost done. We are putting on the final touches and squashing those final bugs. In hindsight, I feel we should have written about the process while in the thick of it. But I guess that's the glory of hindsight. So yeah...

A Kind of Transaction

Some time ago, I wrote about Transactional Analysis from the book Scripts People Live (I read it thinking that it would give me a set of archetypes that I could use to make characters more real - not exactly what the book is about.) Well, I enjoy the idea and started reading Games People Play; and then lightning struck my brain. In order for you to understand my thought, I will have to explain Transactional Analysis. Bear with me.

Certainly the most commonplace, is that every individual has an ego. That part of the psyche that experiences and reacts to the outside world. The notion of self. And at any time, the ego may experience and manifest itself through a mixture of 3 unique sets of behaviors, thoughts, and feelings. These 3 psyches are:

Parent ("exteropsyche"): a state in which people behave, feel, and think in response to an unconscious mimicking of how their parents (or other parental figures) acted, or how they interpreted their parent's actions. For example, a person may shout at someone out of frustration because they learned from an influential figure in childhood the lesson that this seemed to be a way of relating that worked.

Adult ("neopsyche"): a state of the ego which is most like a computer processing information and making predictions absent of major emotions that could affect its operation. Learning to strengthen the Adult is a goal of Transactional Analysis. While a person is in the Adult ego state, he/she is directed towards an objective appraisal of reality.

Child ("archaeopsyche"): a state in which people behave, feel and think similarly to how they did in childhood. For example, a person who receives a poor evaluation at work may respond by looking at the floor, and crying or pouting, as they used to when scolded as a child. Conversely, a person who receives a good evaluation may respond with a broad smile and a joyful gesture of thanks. The Child is the source of emotions, creation, recreation, spontaneity and intimacy[1].

Alright…are you still with me? Now when any social interaction (or transaction) occurs, there is the transaction stimulus - where on individual acknowledges the presence of another - and transactional response - the action that in someway is related to that stimulus. The simplest transactions are those where both individuals egos manifest themselves as Adults.

The agent, estimating from the data before him that a scalpel is now the instrument of choice, holds out his hand. The respondent appraises this gesture correctly, estimates the forces and distances involved, and places the handle of the scalpel exactly where the surgeon excepts it[2].

In order for communication to proceed smoothly, complementary. Example. But if a crossed transaction occurs, then communications is effectively broken off. Example.

Well done. Not painful at all. Now for my lightning.

Now the typically RPG dialog, there is the obvious Good, Neutral, and Evil (or in some of the lesser RPGs, Neutral, Evil, and "I like to eat babies" Super Evil) responses. However, depending on the flow of the dialog, the Good response is somewhat more evil than the Evil response, or vice versa. And sometimes there really isn't a response that makes any sense at all. This problem can easily be attributed to poor writing. Additionally, I would attribute this to an ignorance in how people actually interact. People are not transparently Good, Neutral, or Evil. Consider if all dialogs always had 3 responses: Parent, Adult, and Child. Depending on the initial stimulus, the Good response (or most ideal) may be the Parent or Adult or Child. It completely depends on how the player previously choose to navigate the dialog. This structure may create more natural flowing stimuli-responses.

In order to create an even more engaging experience, the option to socially respond the stimulus in one manner while psychologically responding to the stimulus in another. That is, an NPC may socially acts towards the player as an Adult ("This one is better, but you can't afford it.") and the player reacts to the NPC as an Adult ("That's the one I'll take!"). But the psychological undertones of this exchange is truly that of the NPC's Adult and the PC's Child ("Regardless of the finical consequences, I'll show that arrogant fellow I'm as good as any of his customers.").

So Many Gnomes!

So many gnomes! Let me say that one more time...So many gnomes! We've been working on Gnome for quite some time now. There are 2 interactions: Touch and Throw. And there are 3 gnomes for each interaction. Touch has Squish (touch and it dies), Explode (touch and it dies - and it kills all other gnomes around it), and Spawn (touch and it dies - and it spawns 2 gnomes at its position). Throw has Fling (throw and it dies when it collides with the ground), Target (throw and it dies when it collides with the Groundling), and Chemical (throw and it dies when it collides with another Chemical gnome - it kills all other gnomes around it).

If anybody has any suggestions for additional interactions or gnomes, please post a comment. I am interested in hearing what people have to say.

Also for each interaction, there is an interaction icon around their feet. - And it works out really well. Before these "affordance" icons were added, when a new gnomes was added into the mix (gnomes are added incrementally - starting with the basic gnomes and adding a new type after the player has killed some many gnomes), players were confused about how to interact with the new type. However, with the "affordance" icons, the game communicates appropriate interactions. To help with this training, players can interact with the Squish and Fling gnomes during the menu screen. This feature was, of course, an accident. But is certainly the best accident Gnome has experienced. I had a play-tester play with the gnomes in the menu for about 2 minutes before starting the game. - He did quite well.

We are working on getting animations from Blender into Unity (if anybody has a better clue than me, please let me know). We are working on being able to post the player's high scores to their Facebook page - this feature is so that friends can compare scores. You know, adding social play element to the game. Yep...That's it. So many gnomes!

If anybody has any ideas for the name of the game, again I want to hear them.

I Ain't Afraid of No Ghost

First, I thought that I would share some of the ghost images...


Secondly, things are not going nearly as well as I wanted them to be going. Not because I don't want them to be but by the fact that I was one of the few individuals that recently got laid off at High Voltage Software. In a moment of absolute panic, another project was started. It was conceived by my wife (she is much better at "cute" games than I am). But from that initial spark of an idea, the design is a quick and simple game for the iPhone. Here's hoping Gnome is successful.

There are 4 degrees of difficulty, the game shows the groundling. For EASY, the groundling is wearing a diaper. For NORMAL, the groundling appears as normal. For HARD, the groundling is wearing chest plate mail. For INSANE, the groundling is shown wearing...something...I don't exactly know. If anybody has any suggestions for it, then I would love to hear your ideas.

...With any luck, the next post will be a plea for people to go purchase Gnome (And I'll even explain the game).

p.s. I did find a contract position as a technical designer at Day 1 Studios. I'll be working on FEAR3. - I'm excited.

Back from the Black

I know it has been some time since my last post. In fact, it has been far too long. Whenever I have a spare moment from the busies of life and work on my side projects I see 2 options: I can either blog about what I am doing or I can get more of what I am doing done. Unfortunately, I typically see the latter as being the more productive action.

That said, Robot is still going strong. Justin is diligently working on the script and hopes to have it completed within the next couple weeks. I am attempting to channel all of the mothers of the world and guilt Trevor into sketching the concepts for the characters. I recruited 3D artist to build those fantastic sketches and turn them into a virtual reality. ...And as for me, well...I still need to get a computer that can handle the new Chat Mapper. It doesn't completely freeze my computer. No. I just can't open the application. But of course, and I just realized this, I don't need to open the Chat Mapper to update the exporter. Just to test it.

Ghost is going along quite well. I have yet another buddy of mine, Karl, working on 2D images of the various ghosts. It was crazy. I asked him to create a set of ghosts for the game. I gave him the their various powers and toughnesses (Yes, I play Magic: The Gathering) and the next day he came back with names for all of them and several drafts of the first ghost. It's hard not to love this guy's passion.

(I really do have a lot of really creative and talented friends.)

And with all my various trips back and forth between Chicago and Minneapolis in the past few months, I have had plenty of time to think. And because I am thinking without the specific implementation of either of these 2 games, I came up with yet another game. I call it Martyr. It's based off of a thought experiment in recalled from my "Moral Theory and Practice" course in college. Nearly ten years later, one would think that I would eventually forget those lectures.

Initial iterations would be a zero-player "game" that plays as such:

Initially, a set of characters are created. Each character is defined by a personality. A personality is defined by the Five Factor Model. Each of the five factors is either POSITIVE, NEUTRAL, or NEGATIVE. For each factor, one of its dimensions is randomly selected. This dimension has the same value as its factor. This defines the character's personality. Each dimension carries with it positive and negative weights toward 8 basic emotions. The greatest 2 values in the character's emotional dyad, such as "Love" or "Morbidness". This dyad determines what action the character will perform towards another character. If the dyad is composed of 2 opposing emotions, then cognitive dissonance occurs resulting in no action.

Each character has 3 POSITIVE, NEUTRAL, or NEGATIVE "feelings" toward each character (including himself). This relationship is defined using the Triangular Theory of Love. Now whenever a character acts upon by another character, he has the possibility of influencing the target character's emotional dyad. The intensity and longevity is determined by the target character's relationship toward the acting character. For example, if Character A has an emotional dyad is "Love" and Character B has a consummate love relation toward A, then B's JOY and TRUST values increase permanently and SADNESS and DISGUST values decrease. However, if B were to have a consummate hate relation toward A, the opposite would occur. If B were to have a NEUTRAL commitment toward A, then the influence would last for 1 round. If B were to have a NEGATIVE commitment toward A, then the influence would last for 1 turn.

Each basic emotion has an opposite and resulting emotion. JOY results in more JOY. However, SURPRISE results in ANTICIPATION. This allows for "Dominate" personalities to create "Submissive" personalities, and "Curious" personalities to create "Fatalistic" personalities.

This would be the simulation. The "game" portion returns to the Trolley Problem and also why I call it Martyr. There would be X number of dying characters in play. The player would have Y amount of health (Y is less than X). The player can walk up to the various characters and few their personalities and relationships. Now the player can heal a character and return him to life. Doing so, causes the player to lose 1 point of life. Once the player has expended all of his life, he dies and the simulation occurs for a set number of rounds.

While this "game" may appear evil, we (you and me) as individuals do this sort of thing everyday of our lives. We chose to interact and influence certain people, while ignoring others. This project just brings that unpleasant reality to surface. It begs the question, or at least I hope it does: "How do you spend your life?"

Alright. Back to work on either Robot or Ghost.

Note: There is a certain emotional dyad that will heal other characters. And of course, there is also a dyad that will kill others.

The Writer of Things

I never know how to write introductory posts that aren't lame, so let me try to keep this short:

I am the Writer of Things. I've been brought onboard here at Groundling Games to script Robot.

Although I've done some spec dialogue work here and there, my primary background as a freelancer writer lies in the tabletop roleplaying industry. (You can check out my online Bibliography.)

If you're looking for a quick primer on how I think about interactive narrative structures, check out:

The Three Clue Rule
Don't Prep Plots
Getting the Players to Care
Remixing Keep on the Shadowfell

These essays were written for pen 'n paper gaming, so the methods of execution may be radically different when it comes to computer games. But I think the underlying philosophy remains fairly constant.

A final introductory thought: If I could only eliminate one flaw in modern game design it would be the presence of narrative dead space. Pauses of faux-poignancy. Droning repetition. Facile time-wasting. A lot of modern games are the narrative equivalent of a tight two-hour movie blown out into a six-hour waste of time -- they're artificially pumping up their play time by watering down the experience.

Robot is going to be pretty much the opposite of that. Expect intensity.

Trusting Talent

While I continue my implementation of Ghost, Justin (a extremely talented writer) continues his work with Robot, using the newly released Chat Mapper. Because of its new features, I will need to make time and modify the Yack Pack exporter *.DLL. I know, I know. If I were to focus on one project at a time, I could get that project do that much quicker. But by having multiple projects in different areas of development (in this case, pre-production and production), I am allowed to trust the talented people I surround myself. Besides, other than resolving the exporter issue, I would just impatiently annoying that talent.

Ghost is going well. Using a modified maze generation algorithm, I randomly create a path through a 5x5 tiled board (board size is arbitrary until tested completely). Along the sides of these floor tiles, there are wall tiles that are properly layered to create an illusion of depth. When character-tokens move across the board, their layer position moves up and down to add to that illusion. Ghosts spawn, die, and activate their powers at appropriate phases. Shrines and gates (teleporters) trigger, and appear and disappear based upon ghost population. Bosses spawn and die. The challenge I am running into now is restarting the level once the game has concluded without forcing the players to exit the application altogether. ...At least the game is winnable.

Marwwage

For those of you who aren't married, don't expect to have a great deal of free time months before your wedding. I've got about 2 weeks before the big day and I'm grateful that my bride doesn't want to kill me. Of course, this is only one reason for my prolonged silence. The other is that Robot took a brief break. A momentary break. It will be done; that is a promise. Trevor's priorities had a slight shift recently and Robot unfortunately had to shift down a few rungs. Chat Mapper had a rather critical bug, which prevented importing the existing dialog into the engine. Thankfully, things are beginning to calm down for both Trevor and me.

However, do not think that I have been doing nothing in the mean time. I've been working on a digital board game: Ghost. Inspired on the board game "Ghost Stories," Ghost is a 4-player hotseat where players must find and kill a necromancer on a randomly-generated board while battling various ghosts.

Like I said, there are 4 players (Red, Green, Blue, Yellow). Each player has a skill that changes their play style slightly. I tried to link their skills with Bartle's Players: Achiever, Explorer, Socializer, and Killer. By using these types, I think I can more easily accommodate a greater number of players on a psychological level. I will expand on this in a future entry. There are 6 ghosts colors (Red, Green, Blue, Yellow, Black, White). Ghosts can have 3 powers: on-spawn, on-play, and on-death. The "on-play" power can occur during at any phase during a player's turn. Ghosts also have a toughness from 1 to 4.

A player's turn goes a such:

1. Upkeep: If there are 3 or more ghosts of the player's color (whites count as all colors), then that player takes 1 point of damage and the next phase is skipped.
   
2. Draw: A random ghost is spawned onto an explored tile. When the ghost is spawned, its "on-spawn" power triggers, which could spawn an additional ghost or steal a combat dice from the players.
3. Action: The typically player has 3 Action Points during this phase: explore a new tile (2 AP); visit an explored tile (1 AP); active a Shrine's ability, such as teleport or gain life (1 AP); and engage combat (1 AP). When a player enters combat, he engages all of the ghosts in his room. He rolls typically rolls 3 combat dice. Each die has 1 of 6 colors on each face (associated with each ghost color; whites again are wild). In order to kill a ghost, the player must get number of hits equal to the ghost's toughness. If he cannot, the player can use tokens to purchase hits. Combat is very similar to "Ghost Stories." If a ghost is killed, its "on-death" power is triggered.

For the most part, I have a prototype working in Torque Game Builder with a few things to finish up. And it is all programmer art, so it looks absolutely horrible.

Sweet is the Scene

For those of you developing any project, videogame or otherwise, save yourself future pain and use some sort of version control. Groundling uses Subversion for the same reason we use Torque - we know it. ...Ok, that and my friend, Seth, has given us some server space and he uses Subversion. For that, I thank him.

I implemented level locking. Assuming Robot continues into future scenes, I don't want every scene as its own executable. Instead, I want scenes to be able to flow into each other relatively seamlessly. But if certain players don't start playing until Scene 3 arrives, I still want them to start at Scene 1 while still having Scenes 2 and 3 on their computers. After Scene 1 is completed, then Scene 2 unlocks. Easy enough.

The complexity is when players return to an earlier scene. For example, assume that you have played up to Scene 5. For some reason (e.g. experimentation), you want to replay Scene 1. Normally, this action wouldn't be inconsequential, but because reputation carries from scene-to-scene, some action needs to occur. Either the player can play through the scene again and reputation will or will not be saved. If the reputation is to be saved, then a certain question must be asked: "What happens to future scenes?" I could think of 2 options. (A) Future scenes are locked as if players are going through the story again; or (B) future scenes use their prior reputation saves until replayed. While (B) provides more freedom to the player, it also creates possibility of multiple story threads occurring simultaneously within the same save file. Because of that complexity, I implemented option (A). That said, I would like to know what people's thoughts are about the matter. Which option would you prefer I implement?

A play within a play

From an aesthetic viewpoint, building a theatrical set that depicts one fictional world, and placing that set within a theater that depicts a totally different fictional world presents a couple of challenges. Most importantly, each world must maintain its own unique identity without clashing with the other.

As Chad mentioned below, the play itself is set in a world that is somewhat less than cheery despite an impressive technological sheen. Layers of ethically questionable dictates have piled up and walled-in the society they were designed to liberate. Atmosphere: think Maltese Falcon with robots, most of which are little more than a subsidized source of bipedal horsepower. A smaller portion fill in as metallic playthings that for all of their bells and whistles are no less vacant than the stuffed animals and "Inflatable Ingrids" they replaced. But a handful, like Addison, have been bestowed with or otherwise acquired emotional awareness.

Addison's birthplace--Eva's lab--is nestled somewhere in the shadow of a vertical metropolis. My original concept was a single-level set with two exits, plenty of contraptions to keep the player amused, and far too much ambient light. Not very "film noir".

 

My second concept divided the set into two vertical levels, the second of which is accessed via a hidden stair. More light sources but less light create a more contemplative atmosphere, and multiple micro-environments--a balcony featuring a city vista, vertical windows overlooking a tiny alley garden, and a dedicated workstation area for Eva--help break up the action and create the potential for multiple distinct moods within a single set.

After having the layout approved, I drew a more detailed version to work out architectural motifs and other specifics.

We have since decided to move away from the rather pointy Victorian style and towards something closer resembling the massive, imposing Art Deco look realized in buildings of the 1920s-40s. Combine this with the muted colors, exaggerated fins, and sleek-blockish look of vacuum cleaners and Fords from the 1950s and you have a bizarre aesthetic.

Manifested by the Binary

I have successfully integrated Game Mechanics Kit into Torque3D. While playing around with my success, I realized that in order for players to know what objects are interactive, they must be physically near an object. If the interaction icon appears, then the object is interactive; if not, then it is not. This requirement seems to be unnecessary and cumbersome to the experience. Granted, the stage is a relatively confined play space, so looking at every object may not take a great deal of time. But having the player wander the stage looking at every object would interrupt the flow. To remedy this problem, I further added a Silhouette Shader to denote interactive objects. While a button (currently the right mouse button), all interactive objects are highlighted with a red outline, similar to how VATS worked in Fallout 3.

After integrated Yack Pack, I started implementing the Reputation System. When I completed it, I became acutely aware that my architecture was horrid. There was no sense of loading and saving values. There was no structure for character A to have reputation toward character B without character B having that same reputation toward character A. With all of that said, I rewrote it to resolve these flaws. And it shiny XML no less.

...Now I need to figure out how to lock levels until the previous level has been played.