I'm a master computer programmer, specialising in interesting projects. For me, that's a bit backward - computer games are work and for entertainment I play with file systems.
At the moment (May 2020), I'm wrapping up a few things for Haiku OS Release 1 Beta 2 and some radio automation supporting software (new TuneTracker release coming soon). I expect to spend the summer of 2020 working on the cottage, supporting my elderly mom (lots of driving to doctors' appointments and worrying about COVID-19), and working on my less evil social media reputation system (uses Ruby on Rails) for the résumé. Hopefully that will lead to a job, or if that doesn't pan out then at least a really odd web site for my photos and blog.
I thought I'd have the summer of 2012 for a relaxing break after Artech, but no, we had an opportunity to take over the family cottage. Since I was the unemployed co-owner, that meant a lot of work over the next few years, after the paperwork there was a lot of planning and contractor herding to fix up our old 1930s house on an island. It now has new windows with much improved air flow, a new front porch wall and windows (stuck my screwdriver in much too far into a structural beam while painting it), a new metal roof (was raining inside, right over the bookcase), assorted painting by me and friends, and some plumbing (digging up cracked drainage pipe surrounded by roots, making the trench actually smoothly sloped), a new bathroom (old shower tap had leaked for 20 years, into a drain which leaked, floor joists had rotted right through), and foundation repairs (more cross beams, larger concrete foot pads) and related levelling (I had to map it out myself with a water hose level to discover one corner was 6 inches down). Anyway, it was a joy to close the French doors and have them latch for the first time in probably half a century.
My second game programming career at Artech Studios / Artech Digital Entertainments started in fall 2003 when they needed some help with a project. Of course, I actually ended up working on a different more urgent project and stuck around for another career segment.
All of that finished in 2012 when they shut down the company in an orderly fashion due to too many cancelled contracts and the directors getting close to retirement age. The last few months were firehose hectic (quick - learn about the shader compiler system so you can fix it), taking over other people's tasks to get that one last game out (Cloudship Traders for iPad).
I should really write up all the nifty Artech work I did; the most innovative was the database (MySQL) centered DVD building system that included art asset management (with automatic composition of elements and text via Adobe After Effects to make video clips), game flow logic (interconnected module templates, each one a DVD video clip or still and related code), internationalization (web page for text entry, text and audio variations composited), an HTML front end that could emulate the DVD playback for testing, and a Scenarist DVD project code generator that a few steps later yielded an actual DVD. We used it for for DVD based games like Time Troopers, the Scholastic Read With Me series (pumping out one whole game DVD every 9 weeks, admitedly we had 3 or 4 animation studios feeding us) and Monopoly Tropical Tycoon. Amazing what you can do with a puny (32 bytes of RAM) computing capacity of a DVD player to run game code, when you have 4GB of space for code and data. Even got a patent out of it (USPTO #20060089193 - search for "DVD Game Architechture").
Besides game programming, I was also doing tech support at Artech. Most of the routine stuff (assembling new PCs, running network cables) was handled by the full time tech staff, but I got roped in for the complex stuff, and the urgent ordinary stuff when nobody else was around. Everything from researching network equipment (we settled on gigabit ethernet earlier than most companies due to the need to move around piles of artwork and lots of 4GB DVD images), looking into licensing Flash animation players for use in games, checking out Android for use as a game platform, setting up Mac minis and running the servers.
I set up and ran our Linux Fedora-14 server, which did everything except bulk data storage. It was the internal web server (with various applications), e-mail server, subversion version control server, newsgroup server (subversion code changes were posted to newsgroups for each project), a RedMine project tracking server (again integrated with subversion), DHCP server, MySQL database server (for our DVD authoring system, time sheets, etc) and a few other things. I think we even had a pizza voting system somewhere in there.
For bulk data we had three storage servers running Windows Server, using a RAID5 3COM SATA card with a 12 bay hard drive enclosure and a stack of 250GB drives. I don't know how many hard drives we went through, but quite often one would fail during a backup. Losing a drive wasn't too bad; it just slowed things down during the rebuild with a new drive, and sometimes broke a backup. Each bay had many fans, so we also went through many of those until we figured out that ball bearing fans lasted much longer than the original equipment sleeve bearing ones. Still, we managed to keep the active projects going, though I can't say the same for the old game archives - no budget or spare hard drives for saving them.
One of these days, I'll finish the Virtual File System, after many years of delay. Yes, you will be able to have files of any length, up to files with sizes represented as a megabit number. Well, maybe I'll use XML for storage and let you have an arbitrarily long string of digits for numbers. Anyway, while buying BeOS 5 Pro, I came across an enjoyable book entitled Practical File System Design with the Be File System that got me enthused about writing a file system again. I'll start with a RAM disk for BeOS (got that mostly done). Then I'll try getting fancy with the virtual file stuff (migration of data, security and so on, the sorts of things ZFS has).
Still playing Space Hulk in 2020, though now it's the online turn based version. I seem to have collected several versions of it over time. Still have the PS3, good for Little Big Planet, Star Ocean, YouTube and playing blu-ray discs. The Windows PC is now mostly running Fedora Linux, and is used for a bit of photo processing (ok, lots of photos) though it does get rebooted back to Windows for the latest TrainZ train simulator. I'm also on the computer doing a lot of work for the communications committee of the local community assocation, doing most of the editing and posting on http://champlainpark.org/.
Once in a while I take a break from all this computer activity and spend some time reading science fiction, watching plays (the Fringe Theatre Festival is the big two week event of the year for me, well except this COVID-19 year), playing odd games (Unstable Unicorns anyone?) with friends, taking care of an elderly mom, and walking on the SJAM Winter Trail and around town doing errands (a good way to get both exercise and some thinking done).
The current 2020 computing machinery is the best of 2013 (bought in 2014), an Intel 4820K i7 CPU on an older LGA2011 motherboard (ASUS P9X79) which has a serial port and PCI slot for older hardware connectivity (could even connect the Apple II to it!), and lots of RAM for running virtual machines. It primarily runs Fedora Linux, with virtual machines to run other operating systems (very useful for building code for multiple versions of the Haiku OS). There's also a continuously running utility VM for the Web/BeShare/Tracker/FTP server and other online experiments like FFVSO.
Before that (2000-2012) I had a dual CPU Pentium-III/550Mhz system with an ASUS P2B-D motherboard (Intel 440BX chipset at 100Mhz). It ran BeOS 5.0, Fedora 9 GNU/Linux, Windows 98SE and Windows 2000. OS/2 is on the shelf, uninstalled. As well, it uses WinUAE to emulate my old 1987 model Amiga A2000, which can then emulate an Apple II or Macintosh.
Long before that was the Amiga 2000 (1987), Atari 1040 ST (1985), Commodore 64 (1983), Apple II+ (1979), TI-58 (1978), KIM-1 (1977), a friend's Commodore PR-100 calculator (1976) and various discrete electronics and Radio Shack kits.
I've paid my dues in the distant past: University of Waterloo Bachelor of Math in 1986 with a major in Computer Science and later a Carleton University Master of Computer Science in 1991. My master's thesis and related animated cartoon are available here. It was on distributed Smalltalk and animation, implemented as Handyman, the multiprocessor, multiuser networked computer graphics puppeteering system - I guess you would call it distributed motion capture nowadays. Bell Canada, BNR (Bell Northern Research - now part of Nortel Networks), SHL System House (COBOL!), Dypix and some freelance family tree chart graphing (that combinatorial optimization class on graph theory actually came in useful) software for Quinsept are also in my past.
Some of the Amiga programs I have written in the distant and near past are available on the various AmiNet FTP sites (these links are to the readme files, e-mail me if you want source code):
In more recent history, I've finished a couple of 8 year careers with a
sabbatical in-between helping write these games for Artech Digital Entertainments:
Lancer
Three-Sixty Pacific | Programmer, researcher in early 1992. This was to be a flight simulator successor to Megafortress, starring something like the B1B bomber. I went through piles of airplane books and technical descriptions, and even saw one at the air force base (just from the outside). The story was going to be about fighting drug smugglers using a "borrowed" B1B, which means lots of flying low to hid from radar across the US and South America. I got as far as writing an nifty adventure game plot simulator and started an object oriented aircraft component simulator (so we could do more accurate damage modelling than in Megafortress) before the project was scrapped. |
Theater of War
Three-Sixty Pacific | Programmer in summer of 1992. Developed the computer players. They were done as nice simple state machines. For example, a unit in the foot-soldier-attack state would go towards the globally picked on enemy unit and attack when it got near. There were also some formation rules so that several units all in the same state didn't go to the same square (flying wedge and other shapes). If a unit got hit too badly, it would switch to the sick state, which had the goal of going to the hospital area and healing up. Simple, eh? Unfortunately the player could only control one unit at a time, unlike the squad controlling computer, so the computer could always beat the player. |
Patriot
Three-Sixty Pacific | Programmer, late 1992. I got called in to do the weather and air strikes and to fix up the movement border code in this Gulf War coffee table book which became a boringly realistic military simulator. I don't want to talk about this one. |
Outlaw Sprint Cars
Sega | Project leader and researcher, most of 1993. Developed
the physics simulation for cars driving and skidding on a mud track.
Pushed the Sega Genesis to do an oval track in 3D (walls, cars,
grandstand, puddles) rendered with texture mapped polygons using some,
ah, interesting tricks. It actually worked too, at about 7 frames per
second. Pity the 3D goggles never got released. Oh, if Carl reads
this, we still have your Sprint Car video tapes at Artech. Lesson
learned: dump the 512 prerendered low-res car pictures from all angles
for fewer higher resolution pictures.
There's also a page with the longer story and video clips. |
32X Motocross Championship
Sega | Software design and programming in 1994. The fake physics,
inspired by Sprint Cars, actually plays very nicely. The rendering
technology uses simple scaled-by-distance sprites. The road is 2D with
left/right offsets to simulate curves as it shrinks into the distance
(so no curves more than 90 degrees). I remember doing a test on the PC
with some scanned in dirt and running to the boss, saying that I had
found the "Mars look" - something that would take advantage of the
Mars' (32X) 16 bit colour mode.
This was probably my most fun project. Our team leader (Chris Chan) took care of the dirty details of getting the prototype hardware and a working compiler so I didn't get distracted from the fun of programming. Chris also had some fun trying to parallelize the rendering to use the dual processors. Due to bus limitiations, and our code not fitting in the cache, that didn't work. The second processor ended up just making engine noises. One fun day was spent trying to prove that you could beat the game on expert level. Interestingly enough, this game was mentioned in an article about the history of the 32X, written by Nicholas Thorpe in Retro Gamer magazine "Load 133". My 2014 interview answers are here. |
Corel Chess for Windows
Corel | Project leader, 1995 and a bit of 1996. This game turned out
fairly well, maybe because it had over a year of development time due
to delays for updating to Windows 95 and for adding networking.
I did the animation player; it spools sound and video off the CD-ROM and draws it in the 3D world, all using the Windows regular GDI and our off-screen bitmap drawing code. It even works in 24 bit colour. The trick is that only a small part of the display is changing while the rest is static and cached. The compressor worked by looking at the next few bitmaps in the series and deciding which pixels were background (not changing) and which were foreground. Foreground ones were specified for each frame (RLE compressed too), background ones were specified once and drawn into the background of full screen animations. Since analysing multiple full screen bitmaps was kind of slow, the compression utility (written by one of our co-op students) could be run on several computers on a network, all reading and writing to common shared network directories. My other big part was the network code, which handles local communications using DDE and AppleEvents, and remote using modems, DirectPlay and Winsock. I also had a hand in bits of everything else, except the actual chess engine, helped by two other programmers. Lesson learned: don't rush for an unimportant milestone, which made the Mac version fall behind and get dropped. A few neat features didn't make it into the final CD-ROM, one was the lack of an install program (Corel added one of their own) - originally you just inserted the CD-ROM and it asked you if you wanted to play chess. If you said yes, it started up the game right away (you can do that manually by running the PLAYER.EXE, I think). The other neat dropped feature was a utility and tutorial for making your own chess sets from a series of bitmaps and a sound file. There's also an out-take chess set which Michael Copeland didn't like, understandably since the burnished metal Terminator style chess pieces were difficult to tell apart (but the rocket powered flying Knight was really cool). |
Corel Super Putt
Corel | Firefighter. The game had to be finished by the end of October 1996, and network play wasn't working. I was called in from sabbatical leave two weeks before the deadline. After looking at the original spaghetti code (due to a year of creeping featuritis), I saw that network play couldn't be added successfully. The only hope was for a complete rewrite. After lots of long days and nights, I and my two trusty compadres finished it at 17:00 on the last day of October. Instead of scattered game logic, mixed with physics and graphics, we broke it up into separate modules for each of those, with a side order of network communications code. A nice state machine runs everything now, at 30 frames per second. Slave computers display images and play sounds on command from the master computer (previously the slaves were running the physics and trying to be exactly the same as the master - and not succeeding). When you switch turns, the master makes sure the slave is up to date and then hands over control (fast enough to not be a bother in multiplayer games). Yup, that was a fun project - pure programming and not too much bogging down in code research or waiting for artwork. |
Monopoly Star Wars
Hasbro Interactive | This one was a bit of a surprise. Hasbro had come out with a
Monopoly board game that used characters from the Star Wars universe as
tokens, pictures of Star Wars places for board squares, Imperial
Credits for money, chance and community chest cards using Star Wars
events, and several other adaptations. It sold astonishingly well.
Since 1997 was the year of the Special Edition (the remastered,
enhanced trilogy of movies was released in the spring), this would also
be a good year to do a computer game version for Christmas.
Our contact boss was able to get the job for doing a future version of Monopoly, due a couple of years down the road. I started doing the software design for the rules engine on March 22. The pressure of time and money brought up the possibility of doing Monopoly Star Wars (or Star Wars Monopoly if you are from LucasFilm; they are supposed to be equal) for Christmas. Our 3D crew spent a really long hot week doing the Sizzler video to show the Hasbro people what the Star Wars version of the game would be like (you can see the video in the credits sequence of the game). They decided to give us the go-ahead, even though we couldn't say if we could finish it in such a short time. In fact, until the very last day, it was a cliff-hanger. Of course, this didn't mean as much for me since the rules are the same for regular and Star Wars Monopoly. After an initial week of agonizing effort, I hit upon the idea of a state stack with a message queue (you need to stack up debts when someone owes money, and then do arbitrary other stuff, and then come back to paying the debt). A couple of months later, we had a working version of Monopoly running as a plain Windows application, with the scanned in board and cards from the paper game. In the subsequent months, the simple but effective dialog boxes and 2D board were replaced by fancy animations, sound effects, and speech. I kept around the old user interface for testing the AI code, which could play a typical four player game in 7 seconds on a Pentium-II/200. Our AI programmer and boy genius had gone through the Monopoly strategy books and come up with a statistical approach to evaluating trades and other options (expected value of trade items calculated and compared to cost to acquire). Things got rushed in the end, so the user interface for trading immunities and futures was left out, the Japanese version got postponed, and there are several other obvious rough spots. Still, we finished it on October 18, just in time for the Christmas season. |
My Little Pony
Hasbro Interactive | After spending the spring of 1998 working on the animation engine rewrite, mostly splitting the time manipulation part from the drawing part, I helped out a bit with My Little Pony. It's a game for little girls, part electronic pet (feed your pony and train it to jump) and part activities (simple games, printing stuff, Pony activites, hair play). I helped get things working, like the scrolling system (hardware scrolling so it is good on P90s with a reasonable video board), and other system stuff (birds in stereo!). I also did the screen transitions (secret magical key for Pony friends: type Shift-ScrollLock to turn on the transitions rejected as being too slow on P90s, and to turn on random transition colours rather than official Pony colours). |
Star Wars Playset
Hasbro Interactive | This is a TRUE video game. As you play with the toys on the deck of the Millenium Falcon, they press plungers which hit keys on the keyboard underneath. This triggers different parts of the video, jumping to alternate parts if you react or fail to react to things happening on screen. I helped a bit with the testing and answering questions but it was written by others. Still, I picked up some ideas for the new library's video player, such as alpha channels and better performance when seeking in the video. |
Jeopardy!
Hasbro Interactive | I didn't have much to do with this, other than library support. In particular, they needed compressed sound (4000 questions asked, plus 4000 right answers by each of the two computer opponents, plus 4000 wrong answers too). The new sound system in the library uses DirectSound and the ACM (using experience from previous audio compression code done by various people) and has support for fancy video sound tracks. This is one of the more fun games to play, because you learn something new from the questions. |
Wheel of Fortune
Hasbro Interactive | Again, more library support. I also helped with fixing performance problems (playing compressed sound uses more CPU than expected, which can make animations run too slowly, and if the game is always slow then Windows will gradually slow down as internal queues fill up). The one thing which impresses me about Wheel is the great graphics, and use of multiple camera shots while playing, just like the real thing. This is the best looking computer game show yet! By the way, I had absolutely nothing to do with the PSX versions of Wheel and Jeopardy, instead I was busy getting yet more library stuff (memory and data system rewrite for one thing) ready for next year's games. |
Guess Who
Hasbro Interactive | I helped out a little bit, with support for the previous year's code library, but this nicely animated 2D game was mostly routine and unusually smooth in development. |
Monopoly 2000
Hasbro Interactive | Again, more library support and writing the Dope Sheet '99
animation tool. 3D is now in the library, and since the new dope sheet
uses it, the artists can make 3D animations too. Because of good game
design, this update to Monopoly can even work on slower computers in a
special 2D mode, or if you have hardware 3D then the camera can move,
moving spotlights can shine on the board and so on. The trick for fast
3D on slow computers is to have nice pre-rendered 800x600 bitmaps for
the background from a dozen fixed camera positions, and only draw the
moving tokens. Actually, the prerendered bitmaps look better than true
3D.
There are a few nifty undocumented features, the best one being voice chat. First, get your microphone working with Window's SoundRecorder by adjusting volumes in the mixer (double click the volume icon in the taskbar), turn on microphone boost in the advanced recording controls if needed. You can activate voice chat by manually editing the Monopoly.ini file with NotePad and setting the voice chat parameter to 1. The next time you run the game, a whole new set of Monopoly.ini parameters will appear, which let you customise herald noises, sound levels etc. To use it, merely speak into the microphone (best during a network game :-). Unfortunately some sound cards don't work if recording is activated before playing, and others don't work if playing is started first, so there's a voice chat parameter to choose this - change it if voice chat doesn't work. |
The Director's Chair 2003 | This was an in-house tool to improve on the existing SceneGen tool. The
idea is to let you set up animated scenes more quickly than an artist can
do. After analysing existing software and the actual needs, I came up with
a nice design that integrated artificial intelligence with a time line and
an event based simulation. Rather than fiddling with keyframes, you'd
place the actors and tell the AI to do things, like "walk over there", and
"have a drink at the bar". Amittedly, under the hood there are keys. The
AIs could interact through the event system so that the bartender could
chat with the customer, give him a beer and so on. It also had some
sophisticated facilities for going back and changing things in the middle
of the scene, so after previewing it, you could tell the bartender not to
serve that customer and the related changes would propogate backwards and
forwards in time.
Unfortunately all that I had time to implement was the framework for the whole system, using a nice XML schema for keeping track of everything, and allowing undo, redo and cut/paste of actors and their behaviours as a nice side effect. I hope that whomever takes up the job will have a look at my design document before starting to reinvent yet another key frame system. |
Time Troopers
B-Equal's Time Troopers Page | After studying up on the DVD format in December 2003, we launched into a trivia game on DVD. This one is unusual in that it uses the DVD player's menu logic to run a whole game. We finished it in June 2004, a short time when compared to regular game development. In an odd twist of fate, several years later they were bought out by a Canadian company! But unlike computer games with a two week shelf life, it's still on sale. |
Show Me The Wild
B-Equal's Show Me The Wild Page | After finishing Time Troopers, we started on the sequel in the summer and fall of 2004. This time the topic is animals, with 194 gorgeous animal video clips from National Geographic. Here we perfected the generation of graphics, making for a nice consistent game. The writing was also better - this time there was a much better match between the videos and the questions. |
Read with Me DVD Scholastic Store | A series of DVD books for Scholastic to go with Fisher Price's gigantic kid-friendly remote control. We cranked out almost a dozen DVDs in 2005, refining our new artwork management and production automation system. Unusually the animation drawing was outsourced to at least three New York studios, if not more. I was impressed by the excellent graphic style for waves in Where the Wild Things Are by MaGiK studio. |
Cluedo One of these days I'll find some pictures and document these better... | A DVD to go with the Clue/Cluedo board game. Nice art deco stylings by the animators. Tricky menus that disable items until they become available as the game progresses. This stretched from 2005 to 2006, while international versions trickled out. The USA version is special in several ways; for one it's dual layer so we could bump up the video quality. This project helped our animators get more experience with doing, well, 3D acting. Though we had to keep it down to just the inspector and butler. |
Twister Dance | A DVD to go with the dance mats done in 2006, or was it 2005? I've done so many DVDs that I'm losing track! The production system can now compile multilingual content onto one disc, though that only got used to make an English/Spanish version. The two musicians were kept busy writing 40 tunes, each around two and a half minutes long. They didn't have to worry about the beat - for animation consistency it's always eight beats per measure, which means each movement sequence has eight steps. Of course, that meant that the animators had to generate a corresponding quantity of video. I don't know how much time they saved by leaving the necks off the characters :-) |
Yet more DVDs | I've likely missed a few. Yes, I forgot the Wendys series in spring
2006 to go with their kid's meals. Rather than a plastic toy, they tried
simple games on DVD. We came up with several ideas and made four games for
them. I-Spy, Goosebumps, Maya and Miguel, and Clifford the Big Red Dog
(jigsaw puzzle). I helped with the DVD coding and automated production for
Clifford. Oddly the tough level is actually simpler from the code point of
view, where you just pick the right piece from 4 spots, rather than picking
the right spot to place a piece from 16 locations. I also did the
Foodinator (a simulation of Wendy's web pages letting you build meals).
They produced them in Hong Kong using the cheap dead times between priority pressings and gradually shipped containers full of them to North America in time for the fall promotion. So you could say I have worked on games with sales in the millions, but they were giving them away. The one cool part was going over DVD specifications with their manufacturing guy - we had to look up the minimum storage temperature in DVD Demystified to make sure that they could survive storage in the freezer. Yes, the cold room, because it's lockable and the pile of games won't be underfoot in the restaurant! |
Monopoly Tropical Tycoon | This project was to make a DVD to go with the board game, finished in
2007, I finally bought a copy in Canada in 2008. This project is notable for
the large amount of animation, more than an hour.
We have a news team covering stories in the Monopoly world, with events affecting the players in the game. Originally it was just one news announcer, but extra time to work on it vastly improved the writing by having two news anchors (one smart girl, one dumb guy) with lots of interpersonal friction to make it vastly more entertaining. On the coding side, it wasn't too hard, just a matter of randomly picking stories for the appropriate part of the game. The big part was automating After Effects to crank out the videos with different text variations on the background video. The sound mixing was also generalised, both using the concept of a database feeding templates to generate Javascript or batch files. Watch out for the 1.0 kHz audio tone when the station goes off the air! It used to be a full amplitude signal which would drive people from the room, now it's just annoying :-) |
A Year of Demos | I spent around a year doing lots of little demo programs, which we'd shop
around to potential customers.
There was the ball game I helped flesh out - it used 3D physics to have marbles falling down chutes with flippers and gates you could manipulate to try to get the right colour marble into the right bin. It had dynamically generated sound effects too, with rolling or colliding sounds driven by the physics. Unfortunately lots of other people did marble games that year, so it didn't get picked up. Then there was the rubber ducky one, using Verlet integration to have 3D ducks move around on a pond with a water flow velocity field to move them around. It looked quite pretty with a water ripple shader effect our graphics crew created. It was kind of fun trying to get ducks of the same colour into a row, as any duck that bumped into another would start a conga line. You had to use the mouse to drag the ducks to the right conga lines, which when completed, would enable the ducks fly off the screen. Then there was a 2D platformer sort of like the old Aztec game on the Apple II, using our 3D engine, fancy state machines and blocks of 3D world templates to stamp down the platforms. Running, jumping, climbing ladders and all the usual platformer things were implemented. Again the artists provided graphics which made it look way better than it should for just a demo. Then there was the Cloud Ships game (the name varied), my favourite. It involved flying your ship around in 3D, through the clouds, around and over mountainous islands with castles, bridges and other interesting architecture. It was notable for having 3D parts - you stuck together the appropriate things (balloons, engines, guns) to a ship hull to make your ship. A strong enough hit would knock parts off. Or if they took enough damage, they'd get destroyed. All the parts affected the physics. Losing balloons would make your ship plummet. Adding weight made you lose altitude. Losing the left engine would make your ship turn due to the unbalanced force from the remaining engine on the right. Losing the rudder meant you couldn't steer. Having a cannon knocked off the deck meant you couldn't fire shots from it. Though we were thinking of having a grappling hook to retrieve parts which had fallen to the ground (we even got as far as making chains, though they kept on getting stuck on the landscape). Firing a shot physically threw the cannon ball at the other ship, making your ship recoil with the force of the throw. Similarly a ship taking a hit would sway from the impact. Besides the clouds, the fantastic was enhanced by streams of flying fish. And nets on the ship to catch them and harness them so you could go faster (each one actually flapped on command and pulled the ship, until it managed to escape or got knocked lose). All very cool, with great smoke and explosion particle effects and wonderful world and ship graphics from the artists. Unfortunately the 3D action was too much for the casual game market; just bumping into a wall or firing the heavy cannon would mean losing control as your ship rocked and wobbled around. Perhaps too realistic, but then that also gives you incentive to not bump into the landscape and be careful when shooting. There would also have been the hassle of getting a 3D physics engine through game console certification (though I hear Havoc has been made available for the PS3 by Sony, and that would likely have been better quality than the open source one we were using for the demos). Ah well, I'll have to content myself with sticking things together in the upcoming Little Big Planet. But it won't be the same. Future ideas, if I ever have time and money to recreate this game:
|
Littlest Pet Shop | I helped in 2008 with some of the minigames here, Skee-ball and a Dance game a bit like Dance-dance-revolution. Pity we had to simplify things on the Wii, going from a general flick of the Wiimote to throw the ball to a sideways position timing game where you only control the vertical throw. Had fun adding dual mice to the Windows build for testing two player mode without having to run it on the Wii. Lots of gesture recognition needed, which helped a bit later for the Xbox Kinect games. |
Naval Assault: The Killing Tide | Originally a deck gun shooter demo by Tim Sandwell, this turned into a full submarine game in a world filled with ships and aircraft. My specialty was doing the particle effects for splashing water, wake, bow waves and that sort of thing. Didn't get as far as making the hull wet from individual waves, though I had some ideas for using writeable textures to store the wetness factor (affecting the shader that draws the shininess of the hull) and updating it as individual waves hit the hull. Of course I did lots more, from the automatic build system to alpha channel masked video playback (for a big explosion at the end) to a revamped animated menu system (which got used in several other games, rather than Flash animation which would need licensing fees). |
Monopoly 2010 | This was a really beautiful version of Monopoly put out by EA. My task was to do the AIs for the computer players, with personalities. Since they were using all new game code from a different Monopoly (which unfortunately couldn't support the full set of rules), we couldn't use our old rules-engine AIs. I just redid them from basic principles (projected values for each square's income, etc; dug up a used copy of Kaz Darzinskis' Winning Monopoly). The personality part was essentially adding flaws, such as the railroad magnate who overvalued the railway properties and would frantically bid high or trade lots for them. |
Motion Explosion | Trying to cash in on the brain training game craze, Artech came up with Left Brain / Right Brain, a collection of minigames that mostly train for ambidexterity, using the XBox 360 Kinect device. Kinect uses depth camera technology to sense the positions of a couple of Humans, giving the game 3D skeletons of the player's positions. From that, we can move around in-game avatars and see if the player is pointing at things on the screen (like menu items!) or colliding with moving walls that have a player shaped hole in them. I did a lot of the support stuff, like menus and player enrollment (used in taking turns), though in the end we used the simpler for players to understand anonymous skeletons (wave to start your turn, don't bother with biometrics). Joshua Brodie did the best set of games IMHO, which started out as a robot cannon that launched the ball at you for you to juggle. The juggling was great, easier than the real thing due to the ball going in the right direction when being hit (unlike a real ball). But what made it extra fun was when the thing turned into dodge-ball, with multiple cannons rolling around and firing at you, and you hitting the balls back to knock them over. |
Cloud Ship Traders | The final game was one which repurposed our in-house game engine (PC, XBox, PS3, Wii) to run on the iPad2. I did a chunk of the porting (threads, data files, touchable menus, etc) and Dave Eccleston did the glue to our OpenGL code. Embarassingly, I also did the in-game purchases and advertising. Things got extra busy near the end when most of the staff had been laid off, so I had to fix shader compilation and delve into other parts of the engine and the game code. The final game wasn't as full fleshed as you'd want, ending up as a nice spinable globe where you could draw islands with your finger and populate them with fanciful objects while flying over them in your cloud ship, harvesting crystals from the clouds and occasionally fighting a pirate ship. |
Back in 2000 I started working on BeOS utilities and file systems (and wasting time reading mailing lists and Usenet). The BeOS stuff is stored in this directory and the Windows stuff is in this directory, which you can scrounge around in for the latest versions of the programs I've written. In more detail, here are some of the BeOS programs (and a few Windows ones) I've written so far:
FastCounter 1.0 is example code for fast animation using a backing storage
bitmap, a separate thread for high resolution timing, and alpha blending for a
nice time-lapse fade-out effect. For fun, try resizing the window while it is
running. The readme file is here. You can
download FastCounter.zip from here, it's also
available through BeBits.
AGMSDeviceTest 1.0 is a graphical utility for testing device
driver operations. You can download AGMSDeviceTest.zip from here, it's
also available through BeBits.
The readme file is here.
AGMSRAMDiskDevice 1.1 is a device driver for simulating a
removable disk drive using your computer's memory. The big feature is that it
uses a compressed disk image to preserve the contents across reboots. See the
readme for a list of other great features. You can download
AGMSRAMDiskDevice.zip from here, it's
also available through BeBits and
Computer
Channel (Germany). The readme file is here.
AVLDupTree 1.0
is a set of C subroutines (not C++, so you can use it in drivers) that is
useful for indexing a set of key/value pairs, using the key to find a matching
value. The standard AVL balanced binary tree algorithm is enhanced to support
multiple values for the same key. It is designed for future use in a file
system to support fast attribute indexing and queries, but you can use it for
other things. See the readme for more. You can download AVLDupTree.zip from
here, it's also
available through BeBits and Computer
Channel (Germany). The readme file is here.
CreateManyPartitions is a small C program which creates many partitions, all
the same size, on the disk device you specify. It can optionally format them
with the BFS file system. It also mounts the partitions for you after creating
them. It could be useful if you want to have a separate disk volume with
associated index files to avoid cluttering up one volume with many different
indices. Or have one per user in a multiuser system, so that individual users
don't hog all the disk space. You can download CreateManyParitions.c from here.
After that you will have to compile it yourself (its audience is too small for
the full BeBits treatment). A couple of days later, I finished
ManyApplePartitions which is similar, but writes out an Apple Macintosh style
partition table so that BeOS can find the partitions automatically on bootup,
even when using an Intel computer rather than a Mac. You can download
ManyApplePartitions.c from here.
AGMSWordWrapper is a BeIDE text editor add-on which wraps the selected text
to fit in a width of 79 characters. It also understands UTF-8 character
encoding, tabs, block comments, C style comments, and adds extra space between
sentences. You can download AGMSWordWrapper1.2.zip from here. The
readme file is here.
MailboxFileToBeMail is a utility
program that converts Unix mailbox files (the kind that Pine uses) into e-mail
files for use with BeOS. It also handles news files from rn and trn, which
have messages very similar to mail messages but with a different separator
line. You can download MailboxFileToBeMailV1.9.zip from here,
it's also available through BeBits. The readme file is here.
BeMailToMBox is a utility program (requested by Frank
Zschockelt) that converts BeOS e-mail files into Unix mailbox files (the kind
that Pine uses). All the files in the input directory are concatenated with
the appropriate mbox header lines added between them, and trailing blank lines
reduced. The resulting text is written to standard output. You can download
BeMailToMBox1.0.zip from here, it's
also available through BeBits.
The readme file is here.
MatchUTF8 is a subroutine for doing simple pattern matching, much like you
would do for file names under Unix or queries in BeOS (I'm rewriting it since I
need it for implementing queries in an experimental file system). It's an
enhancement of John Kercheval's old match.c code, improved so that it handles
UTF-8 characters, which are represented by multiple bytes in a string. You can
download MatchUTF8v1.4.zip from here, it's also
available through BeBits. The
readme file is here.
AGMSBayesianSpam is a set of programs for classifying e-mail
messages and other text as either spam or genuine, based on the words they
contain and previous messages which have been identified by the user as spam or
genuine. It's implemented as a server program (AGMSBayesianSpamServer) which
keeps track of the word list and a Mail Daemon Replacement add-on
(AGMSBayesianSpamFilter) which uses the server to classify incoming messages.
Theoretically other programs, such as a news reader, could also use the word
database using the scripting interface. There's also a command line interface
and a graphical user interface. You can download AGMSBayesianSpam1.74.zip from
here,
it's also available through BeBits. Because I kept on finding
bugs in the MDR mail parsing library, I was encouraged by the Zoidberg team to
help fix it, so I got involved. My spam software is now included in the e-mail
package known as "Mail Daemon Replacement" which is on BeBits and SourceForge (where the
most current version of the source code is now kept). The illustrated readme
file is here.
AGMSRAMFileSystem stores files in RAM rather than on disk. This
makes it a bit faster than a real disk, more memory efficient than a RAM disk
that simulates disk sectors (like AGMSRAMDiskDevice), but also means it forgets its
contents as soon as you turn off the computer or reboot. There are also a few
experimental features you won't find in regular file systems (see the readme
for Nifty Features, like AGMS links and indices visible as directories). It
works, even down to the complexity of live update notification and BeOS query
parsing, evaluation and optimisation, but is still unfinished due to a lack of
time (got a job, cutting off the sabbatical early). You can download
AGMSRAMFileSystem20040403.zip from here,
it's also available through BeBits. The readme file is here.
VNCServer lets you use your BeOS or Haiku computer from anywhere there is an Internet connection. You can think of it as a really long keyboard, mouse and video cable. A VNC client (available elsewhere for Windows, Mac, Linux, others) shows you the BeOS screen and sends keystrokes and mouse actions to your BeOS system over the Internet. The VNCServer software running on BeOS/Haiku takes that data from the client, and simulates button presses on a fake keyboard and movements of an imaginary mouse. In the opposite direction, it scans your BeOS screen for changes, compresses the resulting graphics data and transmits it to the client.
This is a port of VNC using RealVNC's version 4.0 final source code (which has an extremely well designed class structure, making it easy to do this port). There are lots of VNC clients out there, but I can recommend the RealVNC ones as working very well under Windows. You can get their clients, servers and source code at http://www.realvnc.com/.
You can download VNCServer-4.0-BeOS-AGMS-1.34.zip (includes source, and
executables for PowerPC BeOS R5, Intel BeOS R5, Haiku OS R1 Intel 32 and 64 bit
packages) from here, it's
also available in Fat Elk's repositories
(Haiku 32 and 64 bit) and more versions are in my BeOS
directory. You can also see the source code on
GitHub. The readme file is here.
There's also a commercially available graphical user interface for VNCServer
which you can get from Tune
Tracker Systems. They call it TTAnywhere. It just drives the
same command line server using buttons and text boxes rather than a command
line. But it isn't as scary and it looks nicer! As well, it can doctor the
system boot files to automatically start the server, and pipe the output to a
log file.
PartitionManualOverride is a command line program for getting and setting the partition size and offset of a device file that represents a partition on a disk, thus letting you mount that partition without relying on the standard partition table loading system.
I wrote this to help with my new 320GB hard drive. BeOS R5 only recognises up to 128GB of space. So I partitioned the drive with the BFS partition taking up the the first 128GB, which worked well enough until I added a efs2 partition for the rest of the space for Linux. The BeOS partition loader balked at that - claming the partititon table had a partition going past the end of the disk, and thus didn't load any of the partitions. So now I'm writing this little program to replace the BeOS partition loader's functionality manually.
You can download PartitionManualOverrideV1.4.zip from here.
PhotoRedater is a Microsoft Windows program which renames the input files you specify (presumably photos and videos) with new names that include their "modified" time (plus a camera clock correction factor) as part of the name. Who would ever want to do that? Just people trying to combine photos into chronological order from several cameras all shooting the same event.
You can download PhotoRedaterV1.zip from here. The readme file is here.
AGMSScriptOCron is a BeOS / Haiku OS program for maintaining a list of templated commands and running them at scheduled times (inspired by cron). Fetchit! is a graphical user interface built on it, optimized to do scheduled downloads for radio stations.
A specialist makes Model Commands, for doing things such as downloading a file, converting audio levels in recorded sounds, displaying a message, or anything else you can imagine and do from the command line. After specifying the template command line and marking out key Fields within it for end-user modification, the Model Command is ready for the user to copy and customize with their own Field details (such as file name and web site for a download, message text to be displayed, etc). Some Models come built-in, and you can create your own.
If you don't have the GUI version, AGMSScriptOCron is controlled by using the BeOS inter-application scripting language. In the eat your own dog food school of thought, Fetchit! uses that scripting to do all its manipulations and display of Commands.
Here is a screen shot of Fetchit! version 1 with the list of Commands on
the right, colour codes and progress bars show the state of each command. The
command for displaying an alert box is currently running (greenish) and the
rest of the window shows the details of a download Command. The mouse pointer
is over the file name ending input area, so the context sensitive help along
the bottom describes that.
This screen shot shows a resized window (it also adjusts for font changes -
useful for larger text). An advanced mode tab showing the log of one Command
is visible, along with the advanced mode control buttons.
As of version 2, Commands can be arranged in a tree of serial and parallel
tasks, with datatypes of input and output to restrict the user in adding only
valid sub-Commands. Now you can combine a file download Command, with
sub-Commands to do audio levelling, extract MP3 metadata into file attributes,
rename the file, all sorts of other things, and finally copy the result to a
destination directory.
One processing step of note is the Rename command. The difficult part of
renaming was to come up with a user interface that was understandable to radio
station operators. We have simple renaming where you insert text or just flat
out provide a new name, then we have this mode where you assemble fragments of
the new name from bits of the old one and text and the current date. There's
also an advanced mode for SED (stream editor) and regular expression fans.
You can download AGMSScriptOCron-2.91.zip (includes BeOS & Haiku versions, source code, docs) from here. The help documentation is here. Fetchit! is available commercially from Tune Tracker Systems, see their product page for details.
With the October 2018 release of Haiku Release 1 Beta 1, there suddenly were more people interested in using the Haiku computer operating system, people looking to online chat to answer their questions. That spurred me into action, to make a bridge between the busy #haiku channel of FreeNode's Internet Relay Chat (IRC, clients available for many computer operating systems) to the BeShare chat program (more Haiku specific, does chat and also supports BeOS/Haiku files with attributes and live updates).
This is one of those quick and dirty hackathon type of projects, supposedly a day's work to copy discussion text on the #haiku channel to the BeShare chat program. The basic idea is to run the Vision IRC client and BeShare simultaneously and have a shell script copy the text from the Vision log file to BeShare, as it comes in.
BeOS / Haiku programs respond to scripting messages and I planned to use that to stuff the chat text into the BeShare graphical user interface, simulating someone typing it in. However, after reading the source code, I discovered that BeShare uses scripting messages internally and even had one that does the posting action. That's much better than trying to hack the GUI. A few days later, after several more problems (such as avoiding buffering delays while extracting the chat from the log file), my program was mature enough to have version numbers. The audience seemed to like it, though I had to mention the "/ignore #haiku" command for people who didn't want the sudden flood of text in the normally quiet BeShare chat.
Going in the other direction was similar, though Vision has a very complex GUI structure of nested panes, swapping in and out as different channels are displayed in the main window frame. But it too used scripting and there was an operation for posting text, if you could just find the correct window pane to apply it to. After some frustration using Hey, I was able to find the path through the BView tree by using the debugger and tracing parent BView pointers up to the visible window. Things went smoothly after that, and BeShare2IRC was soon online. Though experiments with sending multiline text did ban me from IRC; apparently they are fussy about sending only a few lines of text per second. Anyway, with the help of a #haiku operator, I was able to get unbanned, added throttling to the code and BeShare2IRC-Tycom (B2IT) was made an official 'bot on the #haiku channel. I even had a feature request for coloured text to highlight the BeShare user name, guess that makes it a mature program, so I'll have to add it to my resume...
BeShare2IRC.sh and IRC2BeShare.sh are available in my BeShare shared files. I'm currently running it on my home server, so you can see it if you visit the #haiku IRC channel or use BeShare when connected to the beshare.tycomsystems.com server.
That's enough stuff for now. If you want to read more, check those weekend reports for more of my ultra mega verbose verbiage, or visit the top level of this web site.
- Alex
Please send e-mail to agmsmith@ncf.ca. I'm also @AGMS00 on Twitter and usually "agmsmith" on various other social media services.
Get my PGP key here.
Here's My Resume Sound.
Copyright © 1997 by Alexander G. M. Smith.
Last updated $Date: 2022/04/13 18:40:54 $