Friday, August 13, 2010

Chuck Close: Artist

I was watching The Colbert Report tonight, and his interview guest was portrait artist, Chuck Close.  First impression, some artist in a wheelchair. I was waiting until the shoe dropped and Stephen was able to make a pre-approved joke about his handicap, to spice up the boring talk of his drawrings.  I didn't think much of him until they flashed his self portrait.

309923848_3d52c4fdc7[1]

That picture triggered a well-ensconced memory in me.

Oh so many years ago, as a kid on a high school field trip in Minnesota, I saw this self portrait hanging before the beginning of a tour of the Walker Art Center. I remember being enthralled by this incredible piece. It was placed a story above the entrance into the main exhibits, but it still felt so huge… larger than life, as the hacks would say. I could tell that the guides were proud of it, but I was the only one in our group memorized by its depth, its detail, its humanity. It's not much to see from a picture on teh internets, but to see this towering visage made my cynical teenage mind pause and appreciate the craftsmanship, the vision, the raw beauty. I remember everybody entering the hall while I reluctantly followed, staring up all the way in.

I picked up some fun tidbits about him tonight, from the origins of his most obvious handicap (what he calls “The Event”), to a gift from the Gods of Irony, his inability to recognize faces, known as Prosopagnosia.  He even threw in a disparaging joke or two about Bush, revealing his personal politics.

I’ve learned two lessons tonight.

First, I went 15 or so years without knowing anything about the artist, even though that one piece has always stuck with me. And, that’s fine. In a week where Steven Slater is really a just a drunken dick, and Jenny didn't really quit her job, even my most cynical self must appreciate the art they created and the visceral emotions evoked in me.

Second, he’s been a man stubbornly, and respectably, in love with the idea of limitations.

Via Wikipedia

As he explained in a 2009 interview with the Cleveland Ohio Plain Dealer, he made a choice in 1967 to make art hard for himself and force a personal artistic breakthrough by abandoning the paintbrush. "I threw away my tools", Close said. "I chose to do things I had no facility with. The choice not to do something is in a funny way more positive than the choice to do something. If you impose a limit to not do something you've done before, it will push you to where you've never gone before."

I think that’s something that appeals to the wanderlust in me, and speaks generally about the rugged, American spirit. To choose the hard path is the most unnatural thing we can do. But, those folks are the people I respect the most.

The episode

I looked back on that painting all the way out of the museum, even after seeing all the incredible productions inside. Nothing on display inside hit me so bluntly in the chest as that piece.

Friday, July 2, 2010

Oh, that makes it better, Apple

Apple has posted an open letter explaining the precipitous drop in signal strength when their new iPhone 4 is manhandled inappropriately. Jobs’ advice to the “Doctor, it hurts when I do this” has been, of course, to “don’t do this”.

Upon investigation, we were stunned to find that the formula we use to calculate how many bars of signal strength to display is totally wrong. Our formula, in many instances, mistakenly displays 2 more bars than it should for a given signal strength. For example, we sometimes display 4 bars when we should be displaying as few as 2 bars. Users observing a drop of several bars when they grip their iPhone in a certain way are most likely in an area with very weak signal strength, but they don’t know it because we are erroneously displaying 4 or 5 bars. Their big drop in bars is because their high bars were never real in the first place.

Yup. Seems the same reason that one Mars-bound robot mission augured into a planet, or the reason the stock market dropped 1000 points in a minute, made it past Apple quality control and into the market this release. Added to that is a tinge of “it’s your fault”.

We will issue a free software update within a few weeks that incorporates the corrected formula. Since this mistake has been present since the original iPhone, this software update will also be available for the iPhone 3GS and iPhone 3G.

Wait, make that ALL releases… for the last couple of years. Well, thanks for fixing that now.

So what does Apple’s explanation tell us?

Maybe Apple is poor at engineering, testing and quality control.  They didn’t realize for 3 years that the phone function of their phone wasn’t performing as the screen proclaimed. I spent the last year cursing Apple, AT&T, Jesus, nature, myself, my cat for walking too close, the wind, the lack of wind… any pattern I could find that would explain why I would go from 5 bars to dropped call every minute during a conversation. Turns out I lived in a fallout shelter, but the imagineers who imagineered the # of bars display were giving me shotty data.

So, was Apple really just grossly negligent in its assessment of signal strength, or was it protecting its ill-advised exclusivity deal with AT&T when the carrier was unable to support the heavy load?

Never ascribe to malice that which is adequately explained by incompetence.

- Napolean, 1800… or so

I’d like to believe that Apple didn’t deliberately doctor the bars to make me feel like AT&T was doing a better job than it really was upholding their end of an exclusive data contract. But, the corollary to this quote, in this case, should probably be:

Never underestimate the willingness of the vested to overlook incompetence when it works to their advantage.

- Brett, just now

I’m not sure if I can take the “Whoops, we got the algorithm wrong… it’s very complicated and technical, don’t worry we fixed it now” excuse as full forgiveness. It’s well played spin, probably to be eaten up by most of their existing and potential customers. They make compelling products; quite pretty and well loved.

I’ve had a bit of a love-hate relationship with Apple over the last year. I have an iPhone 3G and a used MacBook Pro (which you’re experiencing right now). They have their awesome points, and their glaring pitfalls.

The aesthetic part is pretty on the outside, but on closer inspection, it’s typically a jumble of hastily-wrapped parts basically performing their function long enough to make the user happy. I could cite several examples of this in specificity, ranging from attempting to do iPhone programming in Objective C, to the impenetrable iTunes interface, to watching my friend attempt to replace a drive in an MacBook, to repeatedly trying to make a phone call to my parents, to the ever-slowening of the iPhone OS, to the computer I’m typing on right now…

IMG_0605

Those lines on the screen are always there, but move every time I type a letter. It’s apparently one of many known issues with the MacBook Pro laptops of that generation. There are sites and forums dedicated to cataloging these kinds of problems. Even though it’s on a heat-dissipating pad, it’s burning my hands and creating artifacts from the heat-fatigued GPU. Worse, my iPhone 3G suddenly refuses to join any WiFi network, thus forcing me to burden AT&T’s already stretched 3G antennas beyond their abilities.

I’m not sure where I land here. From a design standpoint, they make a really nice box. It basically does what I need it to do most of the time. Stray one bit from that, or just wait long enough for the components to fall apart, and you’re just boned.

ron-burgundy-3717

60% of the time it works, every time.

Full disclosure: I’m a Microsoft employee, currently doing some work in the mobile space, though my thoughts here are completely divorced from any and all Microsoft activities, statements, positions, gambles, Kins, cats, or bacons. I’m paid by them for my engineering expertise, though not endorsed to opine on the state of the industry.

Thursday, March 18, 2010

It’s St. Patrick’s!

Can’t beat that.

75999010[1]

Thank you, Nathan Fillion

Wednesday, March 17, 2010

Get off my lawn!

SON, I AM DISAPPOINT.

Well, more to the point, radio! I'm disappointed in you. Please see me after class.

It wasn't until I was listening to the local hips hops station that I realized how bad things had gotten. Birthday Sex still comes on the radio at least once an hour. And, have you heard this? Have you seen this?

Birthday Sex is an actual, honest to goodness, produced, legitimate, for-serious-reals version of "Dick in a Box." Seriously. Listen to the lyrics, and come back! I'll wait. This post will still be waiting for you, and the extra advertising impression is always a welcome guest in these halls!

Dick in a Box is satire, but is frustratingly close to reality! Every song is some Usher-sound-a-like singing about banging teh hoez. Well, not even hoez at this point! It's even worse than that. I wanna make love in this club!

Another fun game I like to play on teh hips hops station is "seconds until autotune." It's usually zero.

So, I'll just change the station! I'll listen to some award winning rock/alternative station, even though "alternative" means "every station ever" now.

Wow. Is that... is that Alice and Chains? On the hour, every hour? That is so two thousand and late. I mean, nineteen ninety late. I mean, 1986. Am I getting this right? The go-to station for new, relevant music is playing the top hits from (at least) fifteen years ago? Fifteen? Fifteen years ago? This is award-winning music relevant to this generation? And, was that seriously followed by Red Hot Chili Peppers?

Are you kidding me?

Friday, January 29, 2010

Arcade Tower Defense Dev Log: New Age Music Might Be Bullshit

Hello, everyone!

This is my game. It's a work in progress, and I'm hoping to have it up on XNA Indie Games sometime before July.

The audio that you hear today is not the audio that the game started with. As part of my effort to avoid spending too much time on The Small Things, I initially generated sound effects using SFXR. SFXR is a sound generation tool that produces effects that are very reminiscent of 8-bit games of old.

A Flash version of SFXR can be found at http://www.superflashbros.net/as3sfxr/

So, the first revision of sounds used by ATD were generated by SFXR. And it was great! My ship made little sounds, and the game started to feel somewhat legitimate!

Throughout development, I added more features that made use of these sounds. The most profound of these features was turrets, which would fire relentlessly at nearby enemies. Enemies would blow up, and life was grand!

But then, something happened.

I'm not sure exactly when, but somewhere along the 100th time I launched my game to check something out, my generated sounds turned against me. No longer were they pleasing to the ear! No, they were the opposite of that. They were little stabby things that produced pain to all who heard them!

Something had to be done. But what? I'm too cheap to buy sounds, and don't really have the know-how to produce my own.

Dejected, and sick of listening to my generated audio, I sauntered off to the back room to practice guitar.

Several days prior, I had played with Brian Eno's Trope and Bloom. Generated audio would certainly play nicely with the skills I have. That's hard, though, and I'm not terribly bright.

So, as I'm practicing guitar, I'm mulling over this generated music stuff. I started playing with note combinations that worked well together. I played natural harmonics along the 7th and 12th fret of the guitar, and no matter what combination of things I had, it appeared to sound good. So, what if my turrets, which are a good random seed, had those same sounds?

I set forth into the recording studio with a new-found purpose! I was going to record audio for my game. I ran my guitar through my Spider III 120 with some echo, ran the amplifier output through an Mbox Mini and started recording each individual natural harmonic along the 7th and 12th frets of the guitar in ProTools LE.

I armed a track, recorded a note, armed the next track, recorded the next note, and so on. Each track was recorded independently and sounded pretty good on its own.

When I was done and had 12 tracks staring at me, I thought, hey! What the hell. What does 12 channels of unplanned audio sound like?

Pretty good, actually.





Doesn't that sound awfully familiar? I'm pretty sure I've heard this track before!

tl;dr I hated my audio, was inspired by procedurally generated audio and recorded some sounds, and they sounded good when played together.

Wednesday, December 9, 2009

Representing a mutable game state using continuation-passing and aspect-oriented concepts.

I've been a fan of the World of Warcraft Trading Card Game for a while now. As a geek that somehow missed the Magic: The Gathering rush, I feel like I'm retroactively patching up some holes in my nerd-dom defense.

The game makes me cringe when I look at it through developer eyes. It has an interesting hook; while there are basic rules associated with the game, the printed card text always trumps the rules. And new cards are coming out all the time. As I play and watch absurd card after absurd card completely change up the game, I think... can this be implemented in a sane way?

The game state is completely mutable. No rules are truly set in stone. For example, cards have class restrictions, but class restrictions can be circumvented. Players take one turn, but might be able to play a card to take another turn. Cards can bring in cards that don't even exist in the concept of a game. I've read horror stories of games where a player's deck is crafted in such a way that the player can eventually swap their deck out with a raid deck.

In fact, there are cards that turn resource cards into ally cards while still providing the benefits of a resource card.

So, how do I model that?

I was knee-deep in implementation on something that sort of kind of worked. I had the idea of "firm" rules with cards that were somewhat dynamic. This worked up to a point. I had a good majority of my common cases working, but as the less-common cases rolled in, I realized that the most intuitive, charge-in-ask-questions-later approach wouldn't work. Ever. In a million years. I was way off.

I bounced ideas off of my own personal design committee for hours. I'd highly recommend throwing one of these together if you haven't already, by the way. They're really great about reminding me that my designs are awful and I'm almost completely inept.

What we came up with was pretty spectacular. I didn't know it at the time, but we implemented a continuation-passing style design pattern in the context of modeling a card game. And, we threw a dash of aspect oriented programming in there, too!

Consider an object graph that contains several nodes. Each node on the graph contains several lists of functions (pre-, default or mask, and post-functions). Pre-functions evaluate, followed by either default or mask functions, followed by post-functions. That's our aspect-oriented flavor and allows us to do cool things like, "Before a player draws a card, make them take a billionty damage." More AOP goodness can be found here: http://en.wikipedia.org/wiki/Aspect_oriented_programming

The default functions associated with each node on the graph are responsible for doing something and then putting another node on the queue of nodes to evaluate. For example, let's say we have a set of rules for picking a player. Once we've evaluated those rules, we want to move on to the "Play the game" part of our code. This is where we get our continuation-passing style influences from. For more information on CPS, check out this informative Wiki: http://en.wikipedia.org/wiki/Continuation_passing_style

To see if this approach would fly, I decided to implement The Game of War (http://en.wikipedia.org/wiki/War_(card_game) ). The Game of War is one of the easiest card games to implement, and I figured this would be a great test bed for introducing the kinds of game-changing rules I would expect from more complex card games.

When we consider The Game of War in the context of our object graph, we end up with something like this:

    0. Shuffle the deck.

    1. Determine the active player.

    2. Draw a card for the active player.

    3. Compare card values with the opposing player. If the opposing player doesn't have a card, GOTO 1. If there's a tie, make each player draw three cards and GOTO 1.

    4. Declare a winner.

    5. GOTO 1.

This flow represents the "ideal" state of the game; that is, the default rules. And hey, this worked out pretty well! Not bad for implementing one of the simplest card games in the world within a series of obscure design patterns.

So now, with epic Game of War in place, I decided to add a slight twist. Each player would have a deck of standard playing cards. However, each player would also have a side deck of ability cards. In step 0, each player's side deck of abilities gets shuffled into the deck of standard playing cards.

I want ability cards to be able to mutate the state of the game. When an ability card is drawn, I want functions associated with the card to evaluate and cause weird stuff to happen. Weird stuff is good! They make games interesting.

The ability cards I decided to implement were:

Gain 1 Point: "Immediately gain one point and draw another card."

Fortune: "Immediately draw until you have 5 standard cards. Choose the card with the highest value and add the remaining cards to the pot."

"Gain 1 Point" isn't terribly interesting, but does throw an interesting wrench into our standard game flow. In step 2, we draw a card and move to step 3. However, in this case, we draw a card and go back to draw a card. The card has manipulated the flow of the game, and this is exactly what I want to enable.

The "Gain 1 Point" card does this by... well, I'm one of the unfortunate types that can't explain anything without a whiteboard, so let's take a look at the code instead.

new AbilityCard

{

    Name =

"Gain 1 Point",

    Description =

"Upon drawing this card, immediately gain one point and draw another card.",

    Action = () =>

    {

        testGame.GameState.ActivePlayer.Points++;

        testGame.GameWorkflow.ExecutionQueue.Add(testGame.DrawCardNode);

    }

}

Okay, so a card has an Action. The Action is evaluated when the card is drawn. In this case, the action of the card is to grant the active player (determined by step 1) a point. And then, we take the execution queue and add a "DrawCardNode" to it. A DrawCardNode is just the typed representation of Step 2. So, we drew a card (we were in the draw card node!) and added another draw card node to the queue of stuff to evaluate. We went from step 2 right back to step 2 again, and in a convoluted way! Joy!

Don't worry about GameWorkflow or ExecutionQueue just yet. Suffice to say, the execution queue is responsible for evaluating each node in the object graph I described above.

So, Fortune is a bit trickier. We have to draw 5 cards, and then pick the high card, and then use that for comparison. We also have to add all the cards we drew to the pot. Our game isn't conducive to this at all! It has no notion of the absurd stuff this card is trying to do. Luckily, it doesn't have to!

Let's take a look at the Fortune card code. Apologies in advance! There's a lot going here:

 

new AbilityCard

{

    Name =

"Fortune!",

    Description =

"Upon drawing this card, draw until you have 5 standard cards. Choose the highest card and add the remaining cards to the pot.",

    Action = () =>

    {

        List<Card> cards = new List<Card>();

        while((from card in cards where card is StandardCard select card).Count() < 5)

        {

            Card cardToAdd = testGame.GameState.ActivePlayer.Deck.Draw();

            cards.Add(cardToAdd);

}

        StandardCard highCard = (from StandardCard card in cards where card is StandardCard orderby card.Value descending select card).First();

        testGame.GameState.ActivePlayer.HighCard = highCard;

        int potValue = cards.Count;

        testGame.CompareCardNode.PreRules.Add(

"fortune", () =>

        {

            if (testGame.GameState.Player1.HighCard != null && testGame.GameState.Player2.HighCard != null)

{

                if (testGame.GameState.Player1.HighCard.Value > testGame.GameState.Player2.HighCard.Value)

{

testGame.GameState.Player1.Points = testGame.GameState.Player1.Points + potValue;

}

                else if (testGame.GameState.Player2.HighCard.Value > testGame.GameState.Player1.HighCard.Value)

{

testGame.GameState.Player2.Points = testGame.GameState.Player2.Points + potValue;

}

}

}

testGame.GameWorkflow.ExecutionQueue.Add(testGame.CompareCardNode);

}

Okay, the Fortune card looks scary. It manipulates quite a bit of game state. It's also responsible for quite a bit. The first 10 lines or so of the action are dedicated to drawing up to 5 standard cards and picking the highest card. This process also determines the pot value. Can you tell that I love LINQ? So far, so good?

Immediately after that, we add a pre-rule to the "Compare Card" node in which we determine that, if both players have drawn cards, give the winning player the pot determined by the fortune card. This means that, the next time we evaluate Step 3, run this arbitrary function that our Fortune card has just created.

Okay, so there's a nuance here! You might be wondering why this is a pre-condition of comparing cards. Consider that, in The Game Of War, when a tie happens, each player draws three cards. Those cards get added to the pot.

So, we might have a particularly crazy Game of War With A Twist (GOWWAT?) in which a player draws a fortune card, picks the high card, but ties with the other player! And has to go back and draw three more cards, and then do a comparison again.

Here's the output of such a game, with these game rules hooked up to a test harness:

 

Player 1 drew a Fortune card!

Player 1 drew 2 of Hearts

Player 1 drew 1 of Clubs

Player 1 drew 11 of Clubs

Player 1 drew 0 of Hearts

Player 1 drew 7 of Hearts

Player 2 drew a 11 of Clubs

Draw! Drawing three cards...

Player 2 drew a 1 of Clubs

Player 1 drew a 12 of Spades

Player 1 wins the Fortune pot!

Player 1 wins with 12 points!

So, we have a somewhat tricky design that allows us to deal with some rather tricky cards. In this implementation, the gameplay is almost entirely mutable. We can take a rather mundane concept and mutate it to add flare.

Thursday, October 29, 2009

Three Wolf Pumpkin

I'm pretty proud of my Halloween pumpkin :)