Platypotamus

Much has been said of the developer's perennial quest to create an immersive world--the cliched "living, breathing world".  Of course, one item on that agenda includes the NPCs that populate said world, and presumably are doing the living and breathing.  In this series, I take time out of playing a game to follow around a single NPC, observing the actions of that character for a single in-game day.  The character is chosen randomly from those that populate the environment but do not directly tie into the quest or narrative experience.   The idea is to see how well crafted the illusion is.  Does it hold up under scrutiny?

I'm approaching the end game of Fable 2, doing the side quests before the final mission or two.  Taking a break for this experiment, I reached the city of Bloodstone at just about midnight, so I headed to The Leper's Arms, which is the name of the bar in the town.  Since it's near the end of the game, my character is quite famous, and since I've been playing as a good guy, he's generally quite well liked.  This means that in pretty much any city but Bloodstone, the NPCs follow him around singing his praises.  This would make it difficult to observe without interfering, and I don't want to kill any quantum kitties.  Fortunately, my character is not as well liked in Bloodstone, and right there in the bar he found a specimen that would pay little attention to him

Mandy the Thug

She's an aggressive, straight, tough, unfriendly chick who absolutely hates me.  She likes the Furniture Graveyard (apparently a building in town), she likes the Bloodstone Tombs, and she likes Pretty Necklaces.  She dislikes the Bloodlust Roar.  All this info comes directly from her profile in game.  My character takes up a position at a respectable distance, from where he will observe her actions creepily for the next 24 hours.

• Midnight - 2 AM - Mandy paces around the interior of the bar.  She occasionally stops in positions (observation reveals them to be at least partially non-random).  She doesn't take any particular actions in those places, even when she stops directly at the bar, facing the bartender.
• 2ish AM - Mandy walks outside, and generally continues the same sort of behavior on the patio.    At some point, she talks to Kyle the Thug, telling him something like "Every Friday night without fail you'll find me at the pub.  Unless I stay home."  He responds by taunting her: "What kind of a beast are you? Surely not a lady!"
• 4ish AM - After pacing about randomly for awhile, Mandy stops on the edge of the waterfront staring out over the harbor.  She appears to be watching the moon set.
• 6ish AM - I thought for a moment that Mandy was going to leave the area of the bar, as she was heading up a path to the next level of the town.  Perhaps she was going to go home after a night of not-really-drinking.  She fooled me though, and just paused a bit up the path before returning to the bar's patio.  Around this time she also exchanged inaudible taunts/insults with Leyla the Thug (I could tell it was an unfriendly exchange due to the animations that played).  She also chats with Dave the Thug, but I am too far away to hear that exchange either.
• 8ish AM - She's back on the edge of the waterfront, this time watching the sunrise.  This is among the most convincing of her behaviors, particularly since it has been timed with great views of the moon and sun so far.  Also, it just made me realize that I'm pretty sure the moon set on the same side of the sky that the sun rose on.
• 9ish AM - She tells Kyle the Thug that he can find her at the pub every Friday night (again).  He responds by telling Mandy to get back in the kitchen.  This isn't the first time that I wonder if the two are married in the game, but the only way I can think of to verify that involves having my character try to sleep with Mandy right in front of Kyle, which would interfere with the experiment.
• 11ish AM - She's wandered back inside the bar.  She stands at the counter, right in front of the barman, but doesn't speak or play any animation.  Honestly, this would creep me out if I were the barman.
• 1ish PM - Chris the Traveler enters the bar, encounters Mandy, and uses the same insult that Kyle used previously.  She doesn't dignify it with a response.
• 3ish PM - Leyla the Thug is back.  No insults this time, instead Leyla says "The Reaver can have me as often as he likes, and he does!"  Mandy responds with "Very Mysterious..."  Personally, I didn't find much mystery in the comment.
• 4ish PM - Cathy the Traveler is staggering around drunk and bumps into Mandy.  Mandy screams after her "What's the matter?  Scared?!"
• 5ish PM - She exchanges inaudible taunts with Vikki the Thug.
• 6ish PM - Mandy wanders back into the bar for just a few minutes before wandering back outside.
• 8ish PM - She returns to her spot on the edge of the waterfront staring out over the harbor.  No celestial bodies doing anything interesting this time.
• 10ish PM - Ted the Stone Cutter mentions to her that he should get his mother a present.  Mandy helpfully points out that there is a "shop in that sells that in town."  I think she's referring to the stall that is pretty much right next to them (closed at the moment).
• Near to midnight - After nearly 24 hours of avoiding direct interaction with Mandy, she finally spots my character and starts Boo-ing.  I look at this as a decent time to call the 24 hours of observation over.

After watching her for a day, I actually wonder if random chance might have gotten me a very boring NPC, or if any of them would have been so dull under this intense scrutiny.  Of the various characters she interacted with, both Kyle and Leyla were also in the vicinity the entire time.  On the other hand,  Chris, Cathy, and Ted definitely came through from elsewhere and then moved on after a time.  Ted was presumably working at his stone cutting stall at some point.  While there were a few interesting interactions between Mandy and other townsfolk, I never saw her doing anything else beyond walk around and pause.  For someone who spent all day in the vicinity of the bar, she never drank or ate anything (I did see one NPC sitting at a table with a drink).    I've seen NPCs entering/leaving their houses, and I've seen or heard them in their houses sleeping or eating or talking to family members.  Mandy did none of this.

I guess that gets to the point of this series though.  As I do this with other games, I pretty much expect that none of the NPCs are interesting when watched this closely, and the moments of entertainment they provide during normal gameplay exist only because they are in the background.  On the other hand, I think there's something to be said for creating a strong enough simulation that it remains compelling when brought to the forefront.   In any case, the next game I'll cover will probably end up being Red Dead Redemption.

Gamasutra - Features - Making Games On The Side: Development In The Real World.

Great article that profiles a couple of folks working on game projects in their spare time.  A pretty inspiring read, particularly if you are trying to do the same sort of thing.  Good advice from the developers too.  Read it.

"I guess my main thing is I try never to force it, I don't try to stress myself out doing it," he says. "If I feel like I have something to say or a game that I really want to make, I'll take the steps to do it, but I'm not 20 anymore so I don't really feel like spending 24 hours of my weekend jamming on a game so much. I do have a wife, so she wouldn't be too happy with that.

Bad Pitch/Good Pitch is a recurring feature in which I take some sort of creative work, and pretend that I am pitching it to the executives.  One pitch is terrible, and would never get the project greenlit, and the other is presumably better.

Bad Pitch

It's a story about an archaeologist on a dig for a religious relic in the desert.

Good pitch

Did I mention that the relic has incredible power, and he's racing against the Nazis who want to use it to help them conquer the world?  Also, the movie will feature incredibly meaty sound effects when he punches guys, which he will do frequently.

Show ▼

Recently, I played a game called Doodle God.

It's a simple game, and playable in your browser (assuming you've got a Flash plugin installed), so click the link if you want to check it out.  I think you should, but it took me some thought to figure out why I think you should.

Doodle god is a simple game, with a simple (but not unattractive) presentation.  Pretty much the whole game looks like this:

What's going on here?  You begin with four elements, each in its own group.  Here I've selected the air group, with the short tutorial indicating that I should click on the fire group.  Doing so would make the left side of the screen look a lot like the right side, but with fire instead of air.  I could then select individual elements within the two groups (at this point, I have little choice, fire + air).  If they combine (they do), I get a new element (energy), which I can then use in further combinations.

And that's it.

You start with the four base elements, and through combination and experimentation, you reach the end of the game with over 100.  Each time you succeed at combining elements, you're greeted with something like this:

You get your new element(s) and a delightful little quote related to the process, or the result.  Some slight fanfare that isn't adequately captured via screenshot occurs, but it isn't anything worth writing about in detail.

The question is then, why is this game worth writing about in detail? It does a great job of tackling a key tool in the designer's toolbox:  experimentation.  Allowing the player to experiment in a controlled way is an excellent way to allow the player to feel as if they have freedom, and then to feel clever when they figure something out.   At the same time, the experimental process is rife with setbacks.  A quote attributed to Thomas Edison that gets bandied around often is  "I have not failed.  I've just found 10000 ways that won't work".   What this means for designers is that experimentation offers a built in ego crutch:  failure is less punishing than success is rewarding, which means that if the experimentation is implemented well, the frustration of failure won't drive players away.

Doodle God gets this right; it makes the player feel clever upon finding a neat combo, and provides a hint system that nudges players in the right direction for discoveries without actually doing the discovering automatically.  It has a nice feedback loop, in that each success creates more gameplay for the player (in the form of new elements to play with).

That said, it misses out on a key opportunity to combine that experimentation with a more rewarding learning experience.  That is, a successful (or failed!) combination doesn't actually provide any new information to the player that can be useful in future interactions.  Imagine the situation of a young child playing Pokemon for the first time.  They come across a fire Pokemon, like Charmander, and are having a rough time defeating him.  So they start swapping their monsters around until they use some sort of water Pokemon (Squirtle), and get the message that the attack was super effective.   The child learns that water attacks are strong against fire (which is basically a given to experienced gamers or firefighters, assuming it isn't an electrical fire).  Her experimentation with a variety of Pokemon lead to not only a positive result, but tactical information that can be useful in future battles against fire Pokemon (and indeed, inversely, against water Pokemon).   This is what Doodle God is missing.  There isn't any player-knowledge gained from a success, only new gameplay items.  While the player learns a particular combination doesn't work in the case of a failure, this provides no additional information beyond "don't bother doing that again", and after playing awhile, it's easy to forget what combinations have been attempted.

Since it generated some interest on Twitter, and since I find it pretty mysterious overall, I thought I'd post some more info on the broken car window that greeted me this morning.  First, some preliminary details:

1. The car was parked down around the corner, because parking is at a premium on my street.
2. I hadn't driven it in a week.
3. I didn't actually notice the broken window until I was already driving and (presumably) a piece of glass falling made enough noise that I turned around to see it.

This is the (slightly later) view that greeted me at that point: 

A couple thoughts immediately struck:

1. WTF
2. Should I pull over, or keep driving?
   1. Eh, keep driving, what's stopping going to do for me?
   2. To clarify, I didn't take the picture until later, when I did stop.
3. Shouldn't that window be the most structurally sound of all non-windshield windows?

Further visual analysis of the image tells us:  well, nothing really.  The window broke inward rather than outward.  That non-window stuff you see is just trash (a cap for some sort of bottled water or something).
Here, let's post another image for no particular reason.

Here you can see the enticing view from the outside.  If this was broken by a potential thief, he didn't want my squeegee.  Actually, he didn't want anything.  Didn't take my stereo or... well, I guess the stereo and squeegee are pretty much it.

This leads to the conclusion that whatever happened was an accident.  I was parked next to a ditch, so the passenger side of my car wasn't really accessible to pedestrians or vehicles.  I didn't see any thing inside of my car that might have broke the window (I was thinking may fireworks, or some other celebratory projectiles from the fourth of July hit the really low probability shot).

The only other option seems to be the old "temperature change window explosion" thing.  This has some merit, as it got up to near 90 yesterday, and had only been in the 60s last time I drove it, so all my windows were sealed.  However, I would imagine the window would explode outward if that was the case.  On the other hand, I'd think this would be the hardest window to break on the car (with the exception of the reinforced windshield), due to the small surface area giving it more stability.   I'm leaving this filed as a mystery for now, unless someone out there has a good theory.  Now to get some estimates on repairs.

This homework assignment will have you updating HW2. If you did not get that homework completed adequately, please reference the solution in my outbox on the network. This assignment is due week 9, the week after thanksgiving.

Basically, we are rewriting this homework to take advantage of objects.

1. Turn the player into a single object. Obviously, his three stats should be properties of the object. Convert choices the player can make into functions (behaviors) of the player object.

2. At least one of the choices the player can make from the menu must have him interacting with other objects (extra credit if all 3 do). This other object can be an enemy, environment, whatever, so long as it has its own definition, properties/constructor/behavior.

3. Let's do that extra credit from the previous assignment. There must be at least one item that players can buy/find, that heals the player. It should, of course, be its own object with its own definition.

NOTE: Each line item in this homework should be its own function, but we won't talk about functions until week 4. So you should start this assignment and do each line item separately in the program as you are working, so that you can easily move them into functions.

1. Create an Array with 100 numbers in it. Each number should be randomly generated, and somewhere between 100 and 200.
2. Make a function that tells us the total of the array.
3. Make a function that returns true if the array's total is prime.
4. Calculate the average of the array.
5. Generate a new array (using the same parameters as above) 100 times, and then return the average TOTAL of each array.
6. Trace out the "word form" of each number in the array. That is, if the first three numbers in the array are 15, 90, and 22, you should trace out "fifteen, ninety, twenty two".
7. Set each value in the array to it's negative version.
8. Make a function that takes in an integer (this can be randomly generated, or entered by the user). This function returns true if the array contains the specified int.
9. Sort the array (by hand, DO NOT USE the built in sort() function). We will discuss a method for doing this in class.
10. Tell me the median of the array.
11. Extra credit: Tell me the mode of the array.

I've decided to keep this as the HW assignment. You should be able to do all of it except for the entering of the character name, which we'll cover next week.

Text adventure time!

1. Allow the user to enter a character name.
1a. Once they do, automatically call a function that generates three stats for their character (you can make up whatever stats you want (let's say the range for each is 1-10).
2. Present them with a menu with Several options options. Selecting any option should call a function specific to that option, each of which is described below.
3. First option: Check status. This should print out their character's name, their 3 stats, and how much health they have left (all characters should start at 100 health), how much experience they have (and what level they are), and how much gold they have (useless for now).
4-6. The nextthree options are yours to make up. Each one should be focused on one (or more) of the character's stats. Each one should feature at least one possible success, and one possible failure, and the results should be random (modified by the appropriate stat, of course). For example, I could have an encounter that involved a hot dog eating contest against Kobayashi. Fortunately, my belly stat is 10. So some random generation happens, if I win, I gain 10xp, 50 gold. If I lose, I vomit, and lose 5 health.
7. 4th option: Use an item. The character has an inventory (array) with five ints in it. Each int represents how many of each item they have. Item[0] is a healing item. Item[1]-[3] are buff items, they should add a random amount to a specific stat for the next encounter. Item[4] is a loot item, that the user can sell for money. Remember, the array just contains integers telling the user how many of each item they have!
8. Last option: Shop. The user can sell any items they have, and buy new ones. This should have its own menu.
9. After any encounter, your program should automatically call a function that checks for leveling up. If the character has 100+ xp, they gain a level, (and lose 100 xp). When they gain a level, one stat randomly goes up by one point.
10. Make it so that the stat-using options above, in some successful cases, drop loot and money.

There's a good chance if you are at my site today, and you aren't one of my students, that you followed a link from Cory Doctorow's (of Boing Boing) twitter account. Admittedly, you'll find that there's not too much up here interesting to non-students beyond the Title Generator that he linked, as I've use this page primarily for my classes. I do have some projects that will be launched here sooner or later though, so really, you're just ahead of the curve and beating the crowd. Expect a flash game as well as sporadic other updates over the next few months, sooner or later depending on how my schedule changes.

Since I have a number of students who have took GAD225 elsewhere, in another programming language, etc, I have created this helpful little guide as far as what I expect you to know and be able to do already, before you really take GAD235. That is, this is what I covered (and graded on) in my GAD225: Principles of Programming class.  This list is in roughly chronological order as far as the GAD225 class goes...

• Actionscript syntax for basic programming constructs:  variable declarations, if/else blocks, while/for loops
• The use of functions, including parameters and returning data
• The use of arrays.  How to construct one, how to fill it with data, and how to move data about in it.
• Using keyboard events/listeners to get input from the user, and how Actionscript's event system works in a general sort of way.
• Object Oriented Programming.  The creation of an object's definition file, its data, constructor, and behaviors.   The concept of data hiding, getters/setters.
• Inheritance/Polymorphism, how to use these concepts, and what their benefit is.

Also, another reminder:  We have agreed to begin class at 5PM rather than 5:45 PM, so don't be late this week.