Mark Sibly is a reasonably well bug tested computer programmer who would love to be working on creating Avant-garde video games but lacks the necessary creative bent so will forever be resigned to messing around with programming languages and graphics and algorithms and data structures instead, which are also heaps of fun so it’s all good.

A Brief History of Mark Sibly

…(switching deftly to first person…) featuring a tasty selection of my greatest hits (and a few misses) from the 80’s, 90’s, 00’s and beyond!

The Awesome 80’s

I spent the late 70’s and early 80’s learning to program in BASIC and Z80/6502 assembly code on the brand new TRS-80 in Dad’s office and, later, the Apple ][s at Selwyn College in Auckland.

This lead to me attempting to forge a career as a game developer in the late 80’s with mixed results. I did manage to write a bunch of not too shabby games for the 8 bit machines of the day, some of which were even commercially published, but alas none of which turned out to be particularly financially successful.

These games included such sadly neglected classics as ‘Dinky Kong’ and ‘Zeron’ for the Vic-20, ‘Starwarp’ for the C-64 and ‘Leapin’ Louie’ and ‘Tomb of Tarrabash’ for the C-16/Plus-4 (greatly underrated machines!).

My proudest achievement of this era was probably working with Commodore Computer NZ Ltd to help create the ‘Triple Jump’ game cartridge for the C-16 which included 2 of my own games. This was the first time I’d really had to deal with the hardware side of programming at all, although only in a very minor way, ie: working out where to put the ‘magic bytes’ in the e-prom.

More information on this interesting time in New Zealand’s game development history can be found here:

www.ourdigitalheritage.org/archive/playitagain/

Hola, I even have a page there!

www.ourdigitalheritage.org/archive/playitagain/creators/mark-sibly/

The Nervous 90’s

I started the 90’s writing the Blitz Basic 1 & 2 compilers for the Amiga computer, but reverted to game development again by the end of the decade.

Blitz Blitz 1 was plagued by HW problems as it was sold with a dongle (not my choice!) that never really worked, but Blitz Blitz 2 was pretty successful and quite a few Amiga games were written in it. It still has a loyal following these days including an active FB community etc.
 
 My efforts at writing games were somewhat less successful. The games industry had grown into a behemoth by the late 90’s and I was obliviously well out of my depth. I was still working more or less on my own (albeit with the help of similarly self-employed graphics artists and musicians), which can work for the ‘auteur’ style game developers out there, of which I am sadly not one.

Still, ‘Gloom’ and ‘Guardian’ were both minor hits on the Amiga, Guardian even collecting number 3 in Amiga Power’s ‘top 100 games of 1996’ list! And Gloom was apparently so good the publisher saw fit to ‘reuse’ the graphics engine (completely without my/our permission) to produce a stream of Doom-ish clones for the Amiga…

The Nasty Noughties

By about the year 2000, I decided to give the programming language thing another shot, but this time on the by-now ubiquitous Windows PC. In retrospect, my timing here turned out to be flukily spot on, as 3d graphics hardware was just starting to go mainstream in the form of the new cheapish 3dfx voodoo and nvidia geforce graphics cards (amongst many others) which allowed me to create an easy to use ‘beginners’ style language with some pretty cool (for the time) 3d graphics support which turned out to be a minor hit back in the day.

Thus Blitz Basic 3D was born, which is probably the most successful thing I’ve done to date, and the thing I’m probably most proud of. In fact, it still turns up occasionally in ‘best of’ lists 20+ years later, eg:

www.slant.co/topics/8080/~3d-game-engines-for-beginners

After Blitz3D I started work on a sequel of sorts, BlitzMax. BlitzMax featured a more complex language with object-oriented elements, and ran on ‘the big 3’ platforms: Windows, Linux and MacOS. However, I never managed to add the ‘killer feature’ that would have really made it super successful – 3D! I did get the basic ‘bones’ of a fairly good 3D engine written, but I underestimated how hard writing a 3D engine for 3 APIs would be. If I’d had more business sense, I might have considered employing someone to help.

Still, BlitzMax went on to be pretty successful without 3D and eventually found it’s own following amongst 2D game developers and the more ‘systems programming’ types.

To infinity and beyond – the Monkey years!

My most recent stab at programming language design was the ‘Monkey’ range of languages. The original Monkey came about in the late 00’s, largely as a result of the appearance of the next-gen cellphones (ie: the iPhone, later ripped off by Android) and handheld gaming devices (Vita, 3DS etc) which were becoming far more open to ‘hobbyist’ developers in that you could plonk down a hundred bucks or so for the ‘right’ to develop for these devices, as opposed to the hundreds of thousands and phalanx’s of lawyers required to develop for consoles at the time.

I decided I couldn’t just retool Blitz3D or BlitzMax if I wanted to make a language that could target a wide range of these devices, as they were designed around producing ‘native’ code. Instead, I set about writing a ‘translator’ that would take Monkey source code and covert it to C/C++/ObjectiveC/Java source code which would get compiled by the appropriate native tools. This was still a considerable amount of work, but writing backends that produced high level source code was still a lot easier than writing backends that produced low level assembly or machine code.

It actually worked reasonably well, and Monkey did fairly (not spectacularly) well for a while. However, the game dev scene was changing and I was too slow to keep up – and sort of reluctant to, truth be told. In particular, the emphasis had moved away from ‘how do I write cool games/effects etc?’ to ‘how do I market my games effectively/suck as much money from players as possible’. No doubt an entirely predictable side effect of the mainstreaming of games which had (and still has) been ongoing, but also due to the shift to ‘pay as you play’ gaming that kind of got kicked off by the iPhone and ‘in app purchases’ etc. And even though I hated and still hate this approach to making money from games, I realistically had to support the APIs that made them work in Monkey, something I didn’t always do with as much grace or precision as I may have done. Monkey was turning into ‘work’.

Anyway, by this stage there was a *lot* of competition around for Monkey. By the late 00’s, tools similar to Monkey like Unity, XNA, Cocos2d etc were popping up everywhere, but were maintained by much larger and generally more professional teams than yours truly, and that had a much better handle on the new ‘pay as you play’ zeitgeist than I did. Monkey eventually got left behind, and despite a belated attempt to catch up via a crowd funded Monkey2, the writing was very much on the wall by 2018 and I decided that, at the age of 51, it was probably time to start looking for a *real* job! Which was a very interesting experience but perhaps a story for a different time…

Recent projects: Orkland

(Trying clicking the image: if the server hasn’t crashed and you have a grunty enough machine you may just get taken to a playable app!)

“Orkland” is a simple web app written in C++/Emscripten and WebGL that lets you fly over various NZ locations – use arrow keys/A/Z to control the incredibly physically incorrect aircraft. It was inspired by some work a friend was doing on preprocessing various GIS maps of New Zealand, and my own recent work on a modern terrain rendering engine that was sitting there doing nothing.

It was also a good chance to experiment with Emscripten’s multithreading capabilities which turned out to be pretty impressive IMO. There are actually 3 threads running: the main thread which is doing the rendering, and 2 background threads that are continuously loading, decompressing and mipmapping height maps and aerial image maps as you move around. If you hit the ‘1’ key, you can see the progress of the aerial image loading thread: red tiles contain ‘wrong’ data so need to be refreshed. Dark red/green tiles are hidden from view by distance fog, but bright tiles are in view so should *never* be red! Ditto the ‘2’ key shows the height map loading thread.

I am very pleased with the terrain engine: The terrain mesh is a simple static mesh that requires no runtime updating (height data is read from a texture in the vertex shader) so is very efficient to render, and there should be no noticeable ‘pop-in’ – although if you look carefully you may notice a few vertices ‘warping’ into position here and there.

I would like to take this further by allowing the view distance to be greatly increased so you can fly much higher, but this would require some pretty significant changes to the algorithm as far as I can see. Still, I have a vague idea of how it could work which I might explore one day.