Pivots

It’s been a very long time since I posted.  It’s a different world now.

Ten years ago, I was contacted through Meetup by Matt, an entrepreneur and developer who had previously started a successful online test administration company.  He had cashed out and just secured seed funding for his next idea: an “Uber for Doctors.”  I signed on as an iOS developer, employee #1.  A few weeks later he hired Brandon, an Android dev, as #2 and we started working out of a literal garage in the Baldwin Park neighborhood of Orlando.

Over time, we made a few strategic pivots.  We became a SaaS focusing on telehealth, patient notifications and forms.  Instead of just mobile development, we built the whole stack.  Covid came in 2020 and truly tested us.  It was a tremendous amount of work but today our company is a multimillion-dollar-a-year patient engagement platform.

It’s been an interesting road for me.

The iPhone

In February 2007, I was doing console game development at Electronic Arts, and they sent some of us to the Game Developer’s Conference in San Francisco.

In a diner on Market Street, a colleague of mine pulled out his brand-new iPhone, typed in en.wikipedia.org and showed it to me. It was the full desktop version. I was transfixed.

Later I met another developer at EA who was writing games for the iPhone on the side.  Apple was not yet distributing apps from third party developers, but they had released the SDK beta and he was preparing his games for release as soon as the App Store opened in summer 2008.  They were straightforward 2D arcade games.  Once the store opened, he started pulling in huge amounts of money on a monthly basis.

The iPhone, in my mind, was the dream device for the individual game developer.  It brought back all the promise and joy of the days before and around the time of Doom and Quake and Unreal when a single developer could still make a game that would be a success on their own.

The first device I bought was an iPod Touch — which was an iPhone without the phone.  I still remember the elation of having my own full 3D game running on a device I could hold in my hand.

Indigo Ocho

I released my first iOS game, Indigo Ocho, in early 2009 to poor sales, but great reviews.   I was late, and my game landed among many others in a deluge of new entries in the store, many of them backed by sophisticated marketing.

My successful friend had chastised me for building a 3D game.  “It takes too long, you have to strike while the iron is hot.”  He was right, of course, and he had seen his sales dwindle significantly as time passed.

I was approached by another small studio to collaborate on an updated version of the game that they would market.  They helped improving the art and we produced a better looking version.  We released that to poor sales as well.  When we temporarily made it free, it was downloaded twenty times more frequently than when it was priced at $.99.

It caught the attention of a company called Chillingo.  They were not interested in trying to remarket Indigo Ocho but they were impressed by it and wanted to collaborate on a multiplayer Gauntlet/Diablo style game.  That initial idea would eventually become The Relic.  My relationship with Chillingo became a little tricky because at the time they were acquired by EA, I was still working at EA, and I wasn't supposed to be moonlighting...

Eventually I struck out on my own and started Axolotl Studios for my games and other contract apps.  During that time I built a couple other games for clients.  I also built white-label banking apps, sports apps and apps for security checks. I even built a few for Android and BlackBerry.

It was at the end of this time that I saw Matt’s message in the Orlando iOS Developer’s Meetup board and my life moved away from games and apps.

LPT: How to Convert °C to °F in Your Head

These are quick math tricks to make certain day-to-day calculations much easier.  Sometimes you need to convert temperatures in Celsius (centigrade) into Fahrenheit.

The formula I learned in elementary school was °C * 9/5 + 32, which is not particularly amenable to calculating in your head.  Here's how to figure that in your head without multiplying.

Let's say the temperature is 7°C.

• Calculate 1/10th (10%) of that.  Ten percent of a number is simply that number with the decimal place shifted left one spot.  So ten percent of 7 is 0.7
• Subtract 0.7 (1/10th) from 7 = 6.3
• Double 6.3 = 12.6
• Add 32 = 44.6
• 7°C is 44.6°F

How does this work?

In the original formula 9/5 = 1.8.  Half of 1.8 is 0.9

If you subtract 1/10th of the original number from itself, you get 0.9 * °C.  Then when you double that, you get 1.8 * °C.

After that, you merely need to add 32 to get the Fahrenheit equivalent.  Going the other way (°F to °C) is a little more complicated, and I will get to that in a subsequent post.

LPT: How to Calculate a Tip in Your Head

These are quick math tricks to make certain day-to-day calculations much easier.  When you eat at a restaurant, you'll typically tip your server.  Here's how to figure that in your head without multiplying.

Let's say the bill is $12.34.

Calculating an Exact Tip

• Calculate 10% of the bill.  Ten percent of a number is simply that number with the decimal place shifted left one spot.  So ten percent of 12.34 is just 1.234 (round to 1.23).

10% tip:

• Tip is $1.23

15% tip:

• Start with the 10% of $12.34: 1.23.
• Now cut that number in half to make 0.615 (rounded to 0.62).  This is 5% of the bill.
• Add 1.23 and 0.62 together to make 15%:
• Tip is $1.85

20% tip:

• Double the ten percent: 1.23 * 2
• Tip is $2.46

Easier Approximate Tip

That said, I typically approximate using only the dollar value, because it's easier.

• Round up to $13.  Calculate 10% of 13.  Ten percent of a number is simply that number with the decimal place shifted left one spot.  10% of 13 is 1.30

10% tip:

• Tip is $1.30

15% tip:

• Cut 1.30 in half to make 0.65.  This makes 5% of the bill.
• Add 1.30 and 0.65 together to make 15%: (1.30 + 0.65)
• Tip is $1.95

20% tip:

• Double the ten percent: 1.30 * 2
• Tip is $2.60

Fibonacci Code Golf

The other day, one of my colleagues said he'd once been asked to code a function to produce the nth fibonacci number for a job interview.  We got talking about the shortest possible function to do this.

A fibonacci number is the sum of the two previous fibonacci numbers.  The first and second fibonacci numbers are defined to be 1.  That makes the third 2 (1 + 1), the fourth, 3 (2 + 1) and the fifth, 5 (3 + 2).  Cake.

1, 1, 2, 3, 5, 8, 13, 21, ..

Beautiful, Recursive and Horribly Inefficient

A clean and simple implementation in C might look like this:

int fibonacci(int n)
{
    if (n == 0) 
        return 0;
    else if (n == 1 || n == 2) 
        return 1;
    return fibonacci(n - 1) + fibonacci(n - 2);
}

Since I'm not a golfer, and code golf and mini golf are the only kinds of golf I play, I came up with the following in (bad) C.

f(n){return n<3?1:f(n-1)+f(n-2);}

Now, this one isn't correct for 0, which should return 0, so let's revise it at the expense of four more characters.

f(n){return n<3?n?1:0:f(n-1)+f(n-2);}

That works.  Kind of.  The highest n you can pass it is 46 (returning 1,836,311,903), because after that it overflows the 32 bit signed int (which holds a maximum value of 2³¹-1 = 2,147,483,647).

Okay, but the real problem with these functions is how phenomenally slow they are.  You wouldn't be able to get much past 46 anyway without rendering your machine absolutely useless.  This is a classic recursive function, that is, a function that calls itself.  This fibonacci function itself is often used to demonstrate the elegance of many functional languages.  For example, here it is in OCaml:

let rec fib = function
  | 0 -> 0
  | 1 -> 1
  | n -> fib (n-1) + fib (n-2)

As it turns out, to calculate f(46), you end up calling f() 3,672,623,805 times!  f(47) makes 5.9 billion and f(50) makes nearly 20 billion calls.  The recursive fibonacci sequence grows in number of calls on the order of 2ⁿ, which makes it roughly equivalent to the rice and chessboard puzzle.

Ugly Lookup Table

So we need to rework it and make the shortest version that isn't super inefficient.  Since 46 in the maximum n that fits in a signed 32-bit int (and 47 unsigned), we could just make a precomputed look-up table.

int fib(int n)
{
    static int fibs[] =
      { 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 
        610, 987, 1597, 2584, 4181, 6765, 10946, 17711, 28657, 
        46368, 75025, 121393, 196418, 317811, 514229, 832040, 
        1346269, 2178309, 3524578, 5702887, 9227465, 14930352, 
        24157817, 39088169, 63245986, 102334155, 165580141, 
        267914296, 433494437, 701408733, 1134903170, 1836311903 };
    return fibs[n];
}

That's as fast as you're probably going to get, but it's ugly and not particularly short.

Iterative and Fast

You can also do it iteratively, without any recursion at all:

int fib(int n)
{
    if (!n) return 0;
    int p = 0, q = 1;
    for (int i = 2; i < n; i++)
      { int t = p; p = q; q = t + p; }
    return p + q;
}

It's starting to get a little longer, though, so I don't bother to shove it on one line or abbreviate int fib(int n) into f(n) like with the shortest ones above.  This function can be literally billions of times faster that the first ones.

Returning to Recursion, with Memoization

But..  I've got a short recursive version that outperforms this one on the whole, especially when called more than once, because it builds up a look-up table dynamically, with a simple technique broadly called memoization.

f(n){static int m[64]={0,1,1,0};return !n||m[n]?m[n]:(m[n]=f(n-1)+f(n-2));}

Fast and short.

No Recursion, No Iteration, Just a Formula

Let's do one more.

There is a closed form calculation of the fibonacci number that requires neither iteration nor recursion.  You just calculate it and there you go.  Here is my shortest implementation of that:

f(n){double A=sqrt(5),B=A/2;return(pow(0.5+B,n)-pow(0.5-B,n))/A;}

Short.  No iteration, no recursion.  Over several calls, I figure this will be slower than the previous function, but it's way slicker.

The Book of Sand

Argentine literary genius Jorge Luis Borges ('magic realist') is one of my favorite writers. Borges unravels the many human uses of information within a universe that is mystical and mathematical at once. His work illuminates the way we, as human beings, struggle to capture meaning - any meaning - from infinite quanities of data. Borges explores ideas such as the recursivity of mirrors, points in space containing all the universe (The Aleph) and man's struggle to find meaning in endless information (The Library of Babel & The Book of Sand).

For many software developers, creation of software, while frequently mundane, is still very much an aesthetic pursuit - an art. When a piece of software is 'beautiful' it is so in the same way that a Borges short story is beautiful, and in a very different way than a Dostoevsky short story is beautiful (which is the gut-wrenching, depth-of-human-suffering-and-existential-torment sort of way) or in the way a Hemingway story (the depth-of-human-suffering-but-don't-actually-ever-say-it sort of way) is.

A Prediction from 2007

In 2007, I wrote a post called --

Xbox 360, PS3 Games Unplayable on Future Hardware?

Where I concluded that, due to technical reasons detailed in that post --

.. I suspect that far more Xbox 360 and PlayStation 3 games will be unplayable on future hardware than Xbox and PS2 games on the 360 and PS3.

Unfortunately, I was right, as we've known since before the new hardware was released nearly a year and a half ago.  The Xbox One and PS4 are capable of playing exactly zero binaries built for their predecessors.

But just because we saw it coming doesn't make it any less painful.  Once our older machines die, how will we play those games we love?

Java-Style Properties Files in C++

(Originally posted Feb 28, 2008)

Need to handle Java-style properties files in C++? I've decided to post some of my own personal library of code on this blog. This is one of those occasionally useful things.

javaproperties on github

If you fix any bugs, extend the code or anything else, send back your changes if you don't mind. ;)

Core Plot Tutorials

Handy references for Core Plot, which I use for making charts in iOS apps.

• Core Plot Tutorial
• Pie Chart at Ray Wenderlich
• Comparing charting/graphing libraries
• Core Plot itself on github

Surge of Video Game Nostalgia

When I was a wee lad in the mid 1980s, Compute! magazine would run ads like this.  Box cover art is what sold it back then, I'm telling you.

My Apps

Ideas Are Cheap

Ideas Are Cheap, Execution is Worth Millions

This has been on my mind lately regarding mobile app ideas.  Or as Thomas Edison most famously put it,

"Genius is one percent inspiration, ninety-nine percent perspiration."  

These days it seems like 99.999% perspiration.

Rapunzel's Tower

 Made a game for my kids, based on Indigo Ocho.  It's called Rapunzel's Tower.  It's basically a reskin. 

I Was An Atomic Mutant

(Originally posted 2006)

I bought this PC game a few years ago at a Wal-Mart in Lee's Summit, Missouri for $3. The gameplay is repetitive and the in-game graphics are unimpressive - but it hooks me. It's a ValuSoft title developed on a shoe-string. A single developer is credited for the engine. Its redeeming strength is that its atmosphere totally captures the 50's and 60's era sci-fi and monster movies it imitates.

Thematically the game resembles Destroy All Humans! and Destroy All Humans! 2, which are far better games but don't quite nail the atmosphere of old sci-fi flicks like this does. The Destroy All Humans! are too self aware to fully capture those movies. Another game with a similar feel is Godzilla: Save the Earth which, while clearly much more polished, scores one point below Atomic Mutant on Metacritic (64 vs. 63). And I Was An Atomic Mutant scores a full thirteen points above our own vastly ambitious but ultimately underwheming Superman Returns.

So what does this mean? It would be irresponsible to draw any conclusions from this example, but it is interesting.

JSON Parser for Objective-C

Building on the string code in the previous post, here is a simple Objective-C JSON parser that I use a lot.

Json.h, Json.m at GitHub.

C String Library for C++ and Objective-C

In the last couple of years I've shifted professionally to iOS development.  In doing so, I adapted some of my previous code for use with Objective-C.

I converted my super minimal C++ string library, consisting of basic string manipulation and parsing functions, back into pure C so that I could use it more conveniently with Objective-C as well as C++.

You can find strs_c.c, strs_c.h at GitHub.

It is intended to be very basic and small, so there's no regex or anything like that.  There are string splitting and list handling functions, searching functions, trimming, parsing, etc.  I have further libraries building on top of this for more sophisticated tasks.  For example, an Objective-C JSON parsing library that I'll post right after this.

Cholera

People talked of the days of cholera, of Xochitlán's baptism in a great flood of diarrhea and vomit.  In those days there were wives and husbands, children, mothers and fathers just gone.  The water was unclean and there is no deliverance from water. 

They said one-in-four perished.  I didn't believe in the 1990s a medieval epidemic wiped out a town like this with no peep heard elsewhere.  The government underreports outbreaks and it was an unbearable tragedy here whether one in four or one in forty.  Xochitlán's torment was in the still dirt streets, the ramshackle homes at the periphery, the dust-blown open market and in the church of broken walls that stood as the headpiece of the town square called the zócalo.

It was three years after the epidemic.  Sweat soaked our shirts as we raced again in the sun past men with straw hats plowing and harrowing new milpas and breaking up dark soil beneath the pale dust.  We slowed to saunter at a reverent pace as we walked those streets near the graveyards where from time to time other men with straw hats, muscled from years of labor, would stand quietly with calloused hands and infected nails clutching their deep-lined faces or kneel at wooden crosses and weep.

The Relic

In the App Store April 14, 2011!

The Relic is a 3D Gauntlet- or Diablo-style arcade RPG developed by Axolotl Studios (aka me) and published by Chillingo. It runs on iPhone and iPad. It's taken too long to develop but it is currently in submission with Apple and will be released within the next few weeks. I'm proud of it. There are those projects that you create that turn out far better that you had hoped and this is one of them - for the most part. Like all your creations that you know intimately, you know its flaws. One big disappointment was having to cut multiplayer.

Multiplayer is not in this release. I spent months working on it and got it working reasonably well but the architecture was a mess and it was hard to fit the rest of the game around it at that time and it was getting later and later. I was starting to believe myself that the game would never be released, so I cut it. I intend to get it in in a future update. 

And Death Shall Have No Dominion

Life is about attachment and detachment.  We're born; we love; we die.  Yet science in our age hints that even death itself may yield to the relentless advance of technology. The Relic explores the concept of immortality and of mastery of the biological in an unexpected, though admittedly minimalistic way. I'd like to add more depth and nuance to the story in future updates.

The Art of The Relic

Mark Jones created the character art and most of the animations. Some of the environment art (the tents and market area) was stock 3D art and well worth what I paid for it.  In the future I will use stock art more, it's more cost effective that creating my own art or paying for custom art.  I created the dungeons themselves and props such as the crates and barrels and the items that can be dropped, some of the animations, the UI art and the logos. Much of the scene art, the intro, etc. uses art adapted from public domain art sources - that is, famous, old works of art.  I used Blender for the 3D art.

The Music of The Relic

Most of the music in The Relic is stock music, however, The Relic includes two songs by indie songwriter and musician Andy Livingston, "Indigo Winter" and "Heavy."

The Code of The Relic

One of the most successful parts of The Relic's engine is the sheer number of animated 3D enemies that it can handle. The Relic engine uses Lua heavily for game-side scripting, but it is organized in a way that does not interfere with The Relic's ability to manage so many enemies.

I'll write more about coding concerns later, but with 438 source files (not including the Lua files), this is certainly the largest software project I've written entirely by myself. It's written primarily in C++ and I did most of the development on Windows PC with Visual Studio and occasionally testing with the iPhone with platform-specific pieces written in C++ on the Windows side and Objective-C on the iPhone/iPad side. As with Indigo Ocho, near the final stages of development, development shifted completely over to the Mac/iPhone.

The Relic (iPhone 4 screens) [on facebook]

Indigo Ocho

Indigo Ocho has been out of the App Store for some time now, and now that The Relic is done, I'll try to get Indigo Ocho back up there.

Indigo Ocho on the App Store.

Join in the adventures of Indigo Ocho, the eight ball on a quest to destroy a labyrinthine tower threatening to wreak havoc on the human world.

I'd like to write more about Indigo Ocho, and hope to get around to it in some future post.

Indigo Ocho [facebook]

Industry Broadcast: Podcasts of Senzee 5 Articles

A Senzee 5 podcast (Audio Article #34: Concurrency in Game Design + Why Use C++?) is now available at Industry Broadcast (http://www.industrybroadcast.com/) read aloud by Ryan Wiancko. There's a lot of really great stuff there, so get over there and check it out!

The audio article posted combines my entries Concurrency in Game Development and Why Do We Use C++?

Industry Broadcast is the result of Ryan's great idea to offer insight from game developers in audio format. He says -

I was toiling over one disappointing aspect of almost every one of my days: That being that I have so little time outside of my 16-20 hour work day to be a human being that I never am able to sit down and read enough of the articles being published online about the games industry. Occasionally my RSS feeder throws something at me that I just have to make time for but for the most part I see the headlines of features and articles and have to regretfully click away and focus on the 65 new emails sitting in my mail box. I thought ‘God, if I could just have an LCD in the shower with me I might actually have the ability to digest the plethora of useful information regularly being shared by the top minds in our industry.” And then an even better idea struck me: If all of this material was available in Audio Format then I, as well as fellow developers, could be listening to these amazing articles whilst working out or doing the dishes, or or or.

Ryan also maintains a personal blog here.

The Tandy Graphics Adapter (TGA)

 When I was a kid, we had a Tandy 1000SX.

I was obsessed with RPGs, particularly games like Ultima, and I wanted to recreate those kinds of worlds myself. That meant learning how to draw tile maps, scroll viewports, and animate sprites. I wanted to do them in “full” 16-color graphics, not the underwhelming four colors offered by the stock PC-compatible CGA. And I wanted them fast.

The Tandy Graphics Adapter was essentially an enhanced version of IBM’s earlier CGA standard. More specifically, it was the IBM PCjr’s graphics standard later adopted by Tandy. CGA was the baseline graphics hardware for early IBM PCs, but it was limited: in its most practical graphics mode you got 320x200 resolution with only four colors. The Tandy extended this to 16 colors at the same resolution, which at the time was a tremendous improvement.

The Tandy graphics mode was fairly approachable. The screen memory layout was unusual by modern standards, but not difficult. Where the CGA’s framebuffer was interleaved into two banks, the TGA’s 320x200 framebuffer was divided into four interleaved scanline banks, meaning line 0 would be followed in memory by line 4, then 8, and so on, while line 1 lived elsewhere with 5, 9, etc. Pixels were packed two to a byte instead of four as in CGA. It sounds strange, but after writing the offset math a few times it became second nature. Before long I was blitting tiles and drawing maps to the screen.

One thing I miss about that era of programming is that drawing a sprite to the screen required understanding, at least a little, how the machine itself actually worked.

Underengineering Undead

It's a well-known platitude that we learn more from our failures than from our successes. In A Developer's Life Stages, the first stage is The Underengineer, in part inspired by this poignant failure.

As a college freshman in late 1992, I started making an Ultima VI/Times of Lore-like role-playing game.

In researching this post, I went through my journals from that time period to try to figure out exactly how Undead failed. One glaring issue is that ~75% of the journal was about girls, with the remainder divided among writing music, painting classes and working on the game. While totally expected for a distractible teen, given the difficulty of the task and a rapidly approaching deadline (discussed later) it's not a good indicator of eventual success of the project. Nevertheless, software development is a human activity and must coexist with other human activities. Initially, I was more interested in producing an Ultima-esque demo that would get me a job at Origin Systems.

I met a classmate in my speech class at school named Alex Kapadia. Alex had some experience with sound programming and was a game fanatic. I showed him what I'd built, he was thrilled and we began collaborating. At the time, we were playing a game called Solar Winds distributed by a small shareware company called Epic MegaGames before it shortened its name and became known as the world-class developer of Unreal and Gears of War. Each time the game ended, up popped an ad by Epic requesting developers to send in their games for publishing. We sent Undead to Epic and awaited a response. We didn't have to wait long. In early summer 1993 we knew that we would be working with Epic. We sent several versions to Epic over the following year. As it started to gel a bit, we began working more closely with them.

JOURNAL 12/06/93: Talked to Tim Sweeney (president of Epic MegaGames) today. Wow, he knows games. He gave me a lot of good suggestions. He's looking into an artist and musician for the game. He was talking some intense MONEY!!!!!!!!!!

Tim estimated that the game would make us $40,000, which was an unfathomable amount of money for me as a 19-year old.

JOURNAL 12/08/93: Today Dan Froelich, musician and composer for Epic called me. He lives in Kansas City (that's crazy!) and works for Informix. He told me a lot about how the game publishing thing works. After finals week, we'll get together.

We did end up getting together, Dan, Alex and I, at Manny's, the finest Mexican restaurant in Kansas City. He told us a lot about Epic and the business of developing shareware games. He also brought beta copies of Epic's Xargon and Ken's Labyrinth, developed by wunderkind Ken Silverman.

Rewrite of Undead from 2000

  

Undead: The Tibovian Era, 1993

JOURNAL 12/15/93:

From Tim Sweeney (via E-mail):
Date: Wed, 15 Dec 1993 04:28:24 -0500 (EST)
From: Tim Sweeney <70451 .633=".633" compuserve.com="compuserve.com">
Subject: RE: Undead & Pinball
To: PSENZEE@VAX1.UMKC.EDU
Message-id: <931215092823_70451 .633_fhg40-1=".633_fhg40-1" compuserve.com="compuserve.com">
Content-transfer-encoding: 7BIT
--
Thanks! It's great that you and Dan live in the same town. I hope you'll be interested in working with Dan - he's been with us on Jill, Kiloblaster, Brix, Solar Winds, Adventure Math, and Xargon and his experience working with these projects would be helpful in addition to his music! I'm looking forward to seeing more of Undead! It's the best "first" game any author has shown us. Judging by your coding and artwork, your game has great potential and you have tremendous potential as an author. Undead still has a long way to go in developing a story, creating all the artwork, and turning it into a fun, unique, and successful shareware game, but it looks like you have the perserverence to see it through to the end. Keep up the great work!

-Tim, Epic MegaGames
(3:22 AM - normal business hours for we game developers) :-)

A House of Cards

In late 1993, we believed Undead was going to be an enormous hit. The possibilities appeared endless. Even so, I was starting to deeply fear that I wouldn't be able to finish it. Undead had grown in complexity so much that modifying it was becoming difficult. It was approaching 20,000 lines of C and assembly and because it had no higher level architecture to speak of, I was losing my ability to understand it. Disparate pieces were tightly coupled. There was no layering of subsystems. Significant numerical values were hard-coded everywhere. Every line of code I added made it harder to work with. It was like going from troweling wet concrete to chiseling hardened concrete. This was a classic case of underengineering and I was unequipped to fix it. I was scared. Instead of confronting that issue, I began obsessing over the art - most of the development time was now spent in DeluxePaint getting the art just right.

JOURNAL 03/02/94: Undead is gaining bugs as I try to fix it! Argh. And it's having memory problems -- specifically, not enough static memory.

Worse yet, I had a deadline that I hadn't yet shared with Epic. In a year, more or less, I'd be leaving the country for two years without access to a computer. Now, I suspect I could have fixed Undead's woes given enough time, but I didn't have that time.

Man on a Mission

I grew up in the Mormon (LDS) church. Although I left the church many years ago now, at the time I was devout and determined (and expected) to become a missionary (I'll write sometime later about why this was the right choice, despite my eventual leaving). Around March 1994, I called Tim and told him that I had committed to leave for a two-year mission to central Mexico sometime around September. Understandably, he wasn't happy. I'd naively assumed (wishful thinking) that I would be able to get everything done before leaving in the fall. He knew better.

JOURNAL 03/26/94: BAD NEWS. Tim Sweeney got the copy of Undead. He told me he thought it was fantastic, but that there was no way on earth I was going to get it done before August. In addition, he said it would be absolutely obsolete when I got back. 03/27/94: I didn't realize how upset I was about what Tim said about Undead not being done until I woke this morning and I had been having nightmares about it all night. Of course he's right and I knew it anyway.

Obsolescence was always on our tail and we felt its pressure even during development. The style of game that Undead represented was an Ultima VI class game when the RPG state of the art was Ultima VII and in 1993, Doom (as shareware no less!) splayed the writing on the wall for all 2D games.

Perhaps, as a project, this was doomed from the outset for many reasons. The most obvious was my leaving before it was done. Compared to what I build today, though, the game was not at all complex. It should have been straightforward to build it in a year-and-a-half. It's been said that programming ability manifests at a young age, while skill in software architecture comes much later. In the end, I knew the dark secret. It wasn't merely unfinished, it was unfinishable.

Undead rewrite 2000

Geek History #1

Circa 1987-1991

Connecting with old friends on Facebook lately led me to remember those early days as a teenager writing video games. It's incredible how much has changed since then. It was nearly impossible to get any information on how to program a computer, much less on how to write games. The library books were typically user and application-oriented. C and assembly books could only be had at the bookstore at ~$60 a piece. In the days before bookstores came with sitting/reading furniture, being a kid without a lot of cash, I'd go to Waldenbooks in the mall and stand there reading, absorbing as much as possible before I had to leave. Today, on the other hand, there's rarely a need to buy technical books because whatever I need can be found on the web faster and for free. Today is definitely better.

With a tiny bit of programming in school (Applesoft and Commodore BASIC) when we got our first computer (a Tandy 1000SX), I naturally started with GW-BASIC. It was too slow for the kinds of games I wanted to make - games like Ultima V and Times of Lore.

For Christmas, I asked my parents for a BASIC Compiler (a what?, they asked). It was what I'd circled for them in a magazine - Turbo Basic. I expected to drop my games in and have them run like crazy. There was a hitch, however. The Tandy 1000SX shipped with an OEM version of Microsoft's GW-BASIC that natively supported the Tandy's enhanced CGA video adapter (essentially the same as the the IBM PCjr's with the 16-color 320x200 mode). Turbo Basic didn't. So, as long as the games could be confined to the horrible four-color plain CGA, they'd compile just fine and run pretty fast. I wrote a paint program (Paint!, image below) and a couple of plain (and simple) CGA games (Alien Invasion and BreakOut!, below) in Turbo Basic. In the end, Turbo Basic was still not fast enough and four colors weren't sufficient.

More importantly, there was one specific technical issue that simply could not be solved with any sort of BASIC. I wanted a four-way scrolling world, like those in nearly every commercial game of the time. I was so desperate to make this sort of game that I spent what little money I had on a commercial library (for BASIC) that supported scrolling through assembly-language routines. It turned out that the scrolling supported by the library was simple text scrolling through the BIOS routines, wholly inadequate for what I wanted. I was extremely disappointed and called the (apparently) single-person company for a refund. He refused. There was only possible solution - to learn C.

C had (and still has) a reputation of being extremely difficult, yet it was the language most commercial games were written in. I bought Mix C - a command line compiler/linker and nothing else - for $20. Coming from BASIC, it was a difficult environment. After floundering with that for months and maybe a year, I finally broke down and bought the Turbo C compiler for $150 and spent the next two weeks trying to build a working piece of software in C. Although I didn't fully understand pointers at the end of the two weeks, I wasn't far off from a basic working knowledge of C. Good tools can make all the difference. I still couldn't figure out scrolling until I received a letter from Herman Miller that brought everything together. From that Legacy I (shown above and below) in C finally came to be. It was a collaboration between Eric Lambert (who did the maps and much of the game design) and I. In truth, it wasn't a game in the end - the player is merely able to roam the world in full 16-color Tandy splendor. That was good enough for me because we now had a new computer with 256 (!) colors. It was time to start all over.

[Programming the Tandy Graphics Adapter (TGA]

Games in Turbo Basic - CGA (4 color)

Games in C - Tandy/PCjr (16 color) Graphics

Stages of An Entertainment Medium

Some thoughts about the lifecycle stages that entertainment media seem to have in common. Let me know your feedback and (please!) counterexamples.

Novelty

The medium is brand new and typically reliant on new, immature and disruptive technologies. The cost of content creation is almost nil and, accordingly, poor quality. Content creation is the domain of individuals rather than companies. The new medium itself is revolutionary enough to sell what little content exists. Content is expensive to the consumers and margins for content creators can be large. Whatever stylistic conventions exist for content here are borrowed from other media (as film borrowed from stage, the novel borrowed from the romance). (However, because of early technical limitations, video games now look more like movies than they did in their infancy.) The conventions of the new medium begin to establish themselves and innovation is high, although craft is low.

Specialty

Content quality increases somewhat and innovation is on the rise. No mechanisms are in place for quality evaluation besides word-of-mouth. Technology is still immature and further developments in technology change content. The cost of content creation is still low and corporations are displacing auteurs as the primary producers/creators of content. Much more content is sold and price remains high. Margins are large.

Vanguard

Highly influential quality content appears. The underlying technology matures and content form innovation wanes replaced by quality craftsmanship. Evaluation of content becomes important to consumers because of an explosion of choice. Critics, a concept of literacy and a vocabulary of criticism appear. The medium becomes mainstream and its influential content becomes a part of pop culture. References to the new medium become common in older media. Margins are enormous. An 'arms race' of craftsmanship appears and as a result, dominant content creators (corporations) competitively establish enormous barriers to entry for new participants.

Maturation & Refinement

Vast quantities of content flood the market. Content drops tremendously in price. Evaluation is absolutely crucial to weed out all but the best. Poor quality content is effectively ignored by consumers. The time it takes to consume the content is more valuable to the consumer than the price paid for the content. Margins decline as the cost of content creation spirals upward. Because of enormous cost and risk, innovation is confined to craft and polish. The medium is no longer 'new' and is vulnerable to disruptive technologies.

Eventually, there is a vast landscape of low-to-zero cost content. Only the best is ever consumed. Cost of creation is enormous and margins are slim. Related services, merchandising, advertising, product placement, endorsement employed to increase profits. Core innovation is low, craft is very high. The technology is mature and is vulnerable to disruptive technologies. More and more is spent against diminishing (though differentiating) improvements in quality.

Convergence

The medium becomes a component of a more expressive and newer medium, while continuing to exist on its own.

• Recorded audio becomes a part of movies


• Radio (audio) - a component of television


• Movies and recorded audio - a component of video games

The Consultant's Law

I spent about half of my career working for Kansas City's Metro Information Services, then Keane (when they acquired MIS) as a consultant. As a consultant, I eventually learned a crucial truth which applies to consultants and employees alike. It's just that employees have the luxury of forgetting this from time to time.

The Consultant's Law

As directly as possible, ensure that your efforts make money for your clients.

That's the secret to really long contracts and an high level of control over your career. There's a well known evil doppelganger of this law that I'll call The Law of Job Security.

The Law of Job Security

As directly as possible, ensure that your absence will cost your clients money.

A lot of people seem to live by this law. It's subtly different from The Consultant's Law, but The Law of Job Security breeds resentment and comes across as unprofessional and opportunistic. It's also dangerous, because as irrational as it is in some cases, people tend to punish those who take advantage of them - even when it costs them and their company.

Poker Revisited + ESPN

I hadn't given much thought to poker hand evaluators lately when I received a comment today on the post 7 pointing me to this absolutely fantastic roundup of open hand evaluators at Coding the Wheel.

James Devlin clearly put an enormous amount of work into this analysis of currently available evaluators. As part of that work, he finished up my 7 card evaluator I posted here a year-and-a-half ago! He offers it as a library with a number of other evaluators including the phenomenal 2+2 evaluator.

And of course, I also really appreciate James' comments :) -

Paul Senzee is well known, in poker-programming circles, for his perfect hash optimization to the original Cactus Kev evaluator and for being an all-around programming BAMF.

Honestly, after that great post and the 2+2 evaluator, I'm not sure if there's any more I could possibly add to the problem of poker hand evaluation.

Although In Other Projects..

Something I've done a little work on recently - At ESPN, Play-by-Play Goes Virtual.

OpenCV + Self-Organizing Maps

A little on self-organizing maps and the machine vision library OpenCV..

Self-Organizing Maps

Excellent tutorials on Self-Organizing Map theory -
The Self-Organized Gene (Part 1)
The Self-Organized Gene (Part 2)

OpenCV

Intel's Open Computer Vision Library
Recently took a vacation and spent some time in Key West, which was awesome. When we got home I did a little yard work and played around with OpenCV, trivially writing a program to automatically rotate photos by detecting faces and their orientation. Now I'm hooked.

If NetFlix Rents Games?

I really love NetFlix. So much that I've considered ditching many of the DVDs I own. And since starting NetFlix, I have bought very few.

NetFlix renting games has been rumored since its inception. Other services, such as GameFly have stepped in to try to become the NetFlix of games. But while NetFlix is mainstream, I suspect that GameFly's subscriber base is far from it - and it is an additional charge and an additional service if you already have NetFlix. Unlike movie makers, game makers don't have an equivalent to a 'box office' take. So if NetFlix were to ever decide to rent games, while initially great for the consumer, I believe it would profoundly impact game developer's revenue. Which would, in the end, be bad for the consumer given the skyrocketing cost of game development.

So how do we, as game developers, develop a NetFlix-proof business model? Is it all MMOG's from here on out?

Pair #1

Finally, I'm putting up what I have for Pair, my script language intended for homebrew game projects. Pair is designed to be a small, embedded, acceptably fast (probably not yet the case) script language that will ultimately allow multiple concurrent VM (and not OS-based) threadlets, generators and continuations.

I don't have a lot of time on my hands, so stuff like this takes quite a long while. Now, there's some messed up stuff going on here. You'll have to forgive me that or wait until it's refined more. For example, scoping isn't right at all. The (let ..) expression isn't how it's supposed to be in a lisp-type language. It defines a variable for the rest of the outer scope which isn't right. I'll fix that. Continuations aren't currently supported, but the underlying machinery is mostly there as well as the mechanism for running multiple lightweight VM threads although this is not accessible from the command line program. Which is probably good, since I'm not sure how well that works with the garbage collector at this point. Also, there's a lot of just general messiness going on. There are a bunch of warnings at compile time and comments are sparse. These things will be fixed eventually. I've compiled these with Visual C++ .NET 2003. There are two parts here.

Version 0.01.00

The Pair Compiler & VM

See the Code Use Policy if you are interested in using any of this for your own purposes.

Code Use Policy

If you use code from this blog for non-commercial use please credit Paul D. Senzee and include a link to senzee.blogspot.com. If you make changes, please send them back. If you'd like to use code from this blog for commercial purposes, contact me so that we can work something out.

Edge of Ability

Some of the most successful projects are at the bleeding edge of their implementor's ability. Absolutely as simple as possible out of sheer terror of complexity.

The sequel to this phenomenon is the universal second system effect.

Intellectual discovery can be a powerful motivator in design decisions. Take care when tasking a developer with a mundane or boring task. People have a way of making uninteresting problems interesting!

I have more to say about this, including a crazy idea about the SR71 Blackbird, Lisp and the Apollo Missions all somehow appearing before their time (like from the future ;) )..

Infinite Flexibility

= Infinite Complexity

Think about that and weep.

 

The Ghost Box

The Art of Pranking Part II

The bigger, badder wireless pranking device that evolved from Part I of our pranking bonanza. This is a somewhat technical post. A following post will detail our exploits with it.

The completed device

Learning from the Past

There were a few issues with the first model.

1. The photocell was clearly visible on the front of the adapter and that made it look suspicious.


2. High maintenance. The contraption didn't work well when it was dark outside. In the interest of simplicity, it was designed to sound when it got too dark. That is, in the normal case, when a shadow fell across it. How dark was too dark was adjustible with a screwdriver. Of course, that meant that Ryan had to turn it off each night or if it rained out. This also made it high maintenance, because it didn't turn off automatically - it would keep sounding as long as the target was casting a shadow over the photocell. This drove Ryan crazy, since he had to listen to it and turn it on and off all the time.


3. It was not wireless. Fazeel was eventually able to follow the cord back to the noise box when he figured it out. Then the jig was up.


4. It only emitted one single type of noise. Although deliciously annoying, it didn't offer as much flexibility as we'd like.

Solutions

1. The photocell should be better concealed. Bought a Nortel adapter at Skycraft Surplus for $5 apiece. Using a cordless saw, opened it up, removed the internals. Cut the transformer from the prongs that go into the wall socket, leaving enough plastic around them to keep them solid, and taped the terminals up to insulate them thoroughly from each other and the rest of the electronics I was stuffing in the box. Took one of the detectors from the toy (see below), pulled out the electronics and put them in.
   
   
   Cut off the antenna and hooked up the adapter's cord as the new antenna. Added a battery holder and two AAA batteries. Drilled out a hole for the sensor, slipped it through. Still pretty conspicuous.
   
   
   
   
   To obscure the photocell, cut clear contact paper into a rounded-rectangle shape consistent with the types of stickers you might find on these things. Then, colored over the contact paper with black dry erase marker.
   
   
   
   Because this adapter now has batteries (the adapter from the previous prank didn't since it was powered from the box it was attached to), I had to install some sort of switch to keep the batteries alive. Otherwise, I'd have to tear that thing back open all the time to replace them. I really didn't have a way to solidly mount a tiny switch, so I slipped a tiny reed (magnetic) switch in the seam. It's powered on by sticking a really tiny rare-earth magnet on the switch.


2. The device should roughly detect motion, specifically a rapid change in light intensity as opposed to merely detecting dark. This was nailed with the solution to the wireless problem described next.


3. Wireless would be ideal. This appeared to be beyond my skills and/or experience in electronics, but I found a toy at Toys 'R' Us that, appropriately modified, was wireless and sensed motion. It's called a SpyGear Wireless Tracker. This also had some issues when used in this way. For example, when triggered, it had a blinking red light (LED) that continued to blink until manually reset. That made my job with the glue circuitry a lot more complex.
   
   


4. Plays back a recorded message. This appeared to be the easiest to accomplish. Radio Shack, in fact, sells a voice recording/playback module for about $10 (above). This device was almost perfect. The difficult thing about it was that it had a rubber plunger switch to playback with no leads or any apparent way to hook into and trigger it from other circuitry. So I had to take the switch apart, drill tiny holes in the PCB for the wires and solder them directly onto the traces underneath. Not ideal. Sound quality is not great, but then I didn't really expect that much.

Finishing Up

The receiver mess (with voice record/playback unit) in nearly completed form.

Getting the glue circuitry working correctly was a pain, in the end I went for an inefficient but dead simple approach that made all the pieces work together. Maybe in the future I'll refine it. Anyhow, for now, I'm pretty happy with it.

More to come on the fun we've had.. !