The Carbon Accounting Group at Natural Resources Canada was publishing a paper on measuring the recovery of forest floors after disturbances. They wanted to create a companion app for the paper to more easily apply the techniques presented in the paper in the field, and I took on the job. The app needed to:

• Present the example images and descriptions from the paper in a quickly accessible manner so that someone working in the field can use them as a reference.
• Provide a data entry interface to allow collection of the data required to apply the techniques described in the paper, including recording pictures and measurements of samples taken in the field.
• Provide export functionality to export the collected data in commonly used formats for further processing and aggregation.

I completed an initial version of the app in March 2017, and made further tweaks after user feedback in November 2017. An up to date version is available here on Google Play Store.

COMTESA is a taxonomic classification program "COMputer Taxonomy and Ecology of Soil Animals" (accompanying paper) written using the Hypercard RAD platform for classic 1980's era Macintosh systems.

The original developers of COMTESA wanted to revive the software and make use of it again. Despite being a fairly old piece of software, it contains a lot of valuable information, including hundreds of hand drawn taxonomic diagrams. However Hypercard is a long dead software, and its associated file format is complex and poorly documented.

I was tasked with evaluating reviving the software in some way was possible, and doing a conversion to some more modern format if possible.

1. The first step of simply getting a copy of the program to work with was not so simple. The only known extant copy of the program was on an old SCSI hard drive in one of the original developer's basements. We set up a ~1990 Macintosh system from storage to read it and move the files onto 3.5" floppy disk than we could then read from a Modern system using a USB floppy disk reader.
2. Once we had the original Hypercard stack files, I tried using a couple of commercial programs that claimed to have some Hypercard stack import functionality on them. Unfortunately, neither program was able to read the files.
3. I then looked at some dated open source library code for decoding the highly complex compressed stack files (A lot of the complexity stemming from the need of the system to effeciently operate on stacks spanning multiple floppy disks) into a more understandable XML format. Unfortunately, that library also failed to decode the files.
4. At that point, I took a deep dive into the library code and spotty reverse-engineered specs on the stack file format, which has no official documentation. I debugged what exactly was going wrong and in the process restructured some of the library to work better for our needs. This took quite some effort, as the so called "Wrath of Bill Atkinson" format used for encoding the images is piece of work.
5. Once I had the converter working, we now had a workable copy of the data about the application to use. I developed an Android app emulator for the stack file format, including its internal scripting language, using the converted XML stacks as input. This was not too much work as I only implemented the features of Hypercard actually used by the COMTESA stacks, and COMTESA only used the simpler core features of Hypercard.
6. I also developed a Javascript/HTML version of the emulator, so that COMTESA could be served as a website and/or browser app.

In addition to my work on XMage, I have implemented a full clone of Magic the Gathering of my own on the Roblox platform.

It includes full rules enforcement, card rendering, deck editor, matchmaking, etc. It also has a robust client-server architecture which minimizes round trips to the server for that snappy feel, but still hides any private information so that even a compromised client would not be able to know information such as what cards the opponent has in their hand.

I never got around to adding trading and statistics for players or promoting it into a popular game on the platform, but it's basically a full engine and I may pick it up again at some point in the future.

Total project size is about 30,000 lines of Lua scripts, in addition to some Python tools that I used locally for sprite sheet packing and other tasks.

I've published many popluar building plugins on the Roblox platform, the most popular one having more than 40,000 installs. The core tools provided by Roblox in their IDE work very well for common cases and support 3D-modeling in ways that are easily usable by non-skilled users, as is necessary given that the userbase of the program is mostly teenagers. For more advanced tasks, skilled users turn to plugins like the ones that I have made. Here are a couple of interesting ones:

• Model Reflect (12,000 installs) — A plugin to reflect a model over a given axis. That would seem to be easy, if you were working with a vertex/mesh based system, however that is not how Roblox works. Roblox is based on "virtual Lego", and models are built out of Lego like parts. When you have complex or sloped parts, with textures applied to them etc, and you can't simply reflect their verticies or apply a reflection matrix, it is surprisingly non-obvious how to properly do the reflection.
• Gap Fill (40,000 installs) — Again, since we're talking about a platfrom where you're expected to build using Lego-like parts rather than meshes, this brings up some difficulties. For instance, if you have two parts sitting at arbitrary rotations in space, and you want to add new parts to "fill in the gap" between them, it would be fairly arduous to do by hand and there may be artifacts because you haven't placed the parts quite right. This plugin solves that problem by automagically generating the filling given selected parts.

For a long time XMage had simply used plain raster images to display cards, sourced from scans of the real paper versions of the cards. This was not ideal, as the most important information on the cards may not be very readable with just a scaled down image of a scan. Also, many cards in the game change other cards, and the static image scans will not reflect those changes even though the game engine is aware of them.

To improve the situation I developed a vector graphics based renderer to render the cards based on the characteristics that the game engine knew about them. It also dynamically increases the size of some parts of the card at small sizes. This provides clear readable text even when there are a lot of cards on the screen at once and each is quite small.

The deck editor is the part of XMage that allows you to choose which cards you want to play with, how many of them, what versions of them, etc. Historically it was a pain-point in the program because making a quality deck editor that is easy to use takes a lot of UI dirtywork that not many people want to do.

I created a full drag and drop based deck editor that allows you to box-select, ctrl/shift select, etc cards in the editor, and then drag / drop the selection in a dynamic grid of rows / columns. I also include show / hide functionality and many other extras.

An older version of the library can also be found here

I have written some minification tools for the Lua scripting language. At the time I first wrote the original version of the tool there was no Lua minifier available, so I created one.

The current version of the tool has full semantic / scope awareness and tries to optimize its choice of which variables get minified to one character variable names in order to squeeze down the code size. It also does some tricks like restructuring assignment statements / where variables are declared in order to reduce necessary whitespace if those changes can provably be made without changing the program's meaning.

Roblox uses a proprietary compressed binary file format for its content. I wrote an efficient decoding library for that format in C, so that other programs can work with and export to Roblox place/model files.

I modeled the library off of similar libraries for block-based file formats like libpng, trying to avoid any unnecessary dynamic memory allocation.

I'm looking for work! If you have an opportunity in Edmonton Alberta and are interested please contact me. Resume and contact info are available on that contact page.

I'm currently working on creating a new better game view for XMage. The existing one had it's last significant changes over 5 years ago, and it could use a lot of improvement. Main goals:

• Make all information windows dockable. Currently you often have a mess of internal windows open in the program with various information that you need. Making them dockable when desired would be help things immensely.
• Generally improve the layout to waste less space. The current layout has quite a lot of wasted space that could be used better. For example, by turning some of the elements that are currently always shown into floating elements overtop of other UI that are not shown when not needed, and moving to a slightly more complex layout to not waste space.
• Make the code more modular. Right now the main game view is a fairly horrible 5000 line god class. No matter how it's done, it has to be a fairly large class, but it can still be much more modular and smaller than it currently is.