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.
Paul Senzee on iOS/Android App and Game Development, Technology and sometimes Life
Showing posts with label Senzee. Show all posts
Showing posts with label Senzee. Show all posts
Saturday, January 31, 2015
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. ;)
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. ;)
Friday, January 31, 2014
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.
Tuesday, May 24, 2011
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.
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.
Wednesday, March 16, 2011
The Relic
In the App Store April 14, 2011!
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.
Friday, March 11, 2011
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]
Labels:
Axolotl Studios,
Indigo Ocho,
Senzee,
The Impossible Dream
Saturday, November 29, 2008
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 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.
Sunday, November 16, 2008
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.
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.
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 |
Saturday, November 15, 2008
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.
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
Monday, November 03, 2008
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.
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
Saturday, September 13, 2008
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.
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.
Monday, September 08, 2008
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.
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.
Tuesday, August 05, 2008
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.
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?
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?
Wednesday, July 30, 2008
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.
Friday, July 18, 2008
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 ;) )..
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 ;) )..
Wednesday, July 16, 2008
Wednesday, July 09, 2008
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.
Solutions
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.. !
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.
- The photocell was clearly visible on the front of the adapter and that made it look suspicious.
- 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.
- 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.
- It only emitted one single type of noise. Although deliciously annoying, it didn't offer as much flexibility as we'd like.
Solutions
- 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. - 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.
- 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.
- 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.. !
Tuesday, July 08, 2008
What the @#$*! is that Noise?
The Art of Pranking at EA
Video. Fine moments in pranking at EA Tiburon. You'll see narration by my former manager, Rob Hyder, who pulled off perhaps the finest prank ever here - The Disappearing Door.
Our prank may not be as cool as some of those, but we're still refining it. The target? Fazeel Gareeboo, my manager.
1. Misdirection
Fazeel was out for two weeks, so he was likely expecting some sort of prank. So we had to do something obvious. There's a certain report that Fazeel hates, so of course we papered his cube with it.

2. The Idea
The real idea was to set up an annoying noise that went off whenever the target scooted his chair in to work. Fortunately, Fazeel sits next to the window. So I made a detector that set off a sound whenever a shadow is cast on it. Camouflaged the detector by hollowing out an electrical adapter and used the wire from the adapter to connect with the control circuitry and the buzzer.


Then we taped the buzzer box (yes, made from a Wal-Mart soapdish) to the back of Ryan Burkett's monitor. The box sported a switch so that Ryan could flip it on and off at will.

We got three solid days of torture out of that baby! Yeah!
So, of course, I built a bigger, badder, wireless version with voice playback that I'll post about later.
Video. Fine moments in pranking at EA Tiburon. You'll see narration by my former manager, Rob Hyder, who pulled off perhaps the finest prank ever here - The Disappearing Door.
Our prank may not be as cool as some of those, but we're still refining it. The target? Fazeel Gareeboo, my manager.
1. Misdirection
Fazeel was out for two weeks, so he was likely expecting some sort of prank. So we had to do something obvious. There's a certain report that Fazeel hates, so of course we papered his cube with it.
2. The Idea
The real idea was to set up an annoying noise that went off whenever the target scooted his chair in to work. Fortunately, Fazeel sits next to the window. So I made a detector that set off a sound whenever a shadow is cast on it. Camouflaged the detector by hollowing out an electrical adapter and used the wire from the adapter to connect with the control circuitry and the buzzer.
Then we taped the buzzer box (yes, made from a Wal-Mart soapdish) to the back of Ryan Burkett's monitor. The box sported a switch so that Ryan could flip it on and off at will.
We got three solid days of torture out of that baby! Yeah!
So, of course, I built a bigger, badder, wireless version with voice playback that I'll post about later.
Subscribe to:
Posts (Atom)



























