A somewhat pleasant experience

A somewhat pleasant experience


The pleasant experience I’ve mentioned in the title of this entry is that of writing a program. It took me less than a week, and it’s an example of the sort of thing I do as a break from my normal coding and so I don’t take life too seriously. The program is a 3D maze puzzle and can be found here. The reason it was such a pleasure to write I’ll expand on further.

I’ve been programming professionally now for well in excess of 20 years; and I can say that, to me, the writing of software is a somewhat interesting and strange process. This is probably why I find most programmers interesting while “normal” people (whoever they are) find programmers strange. I’ve always found that the best way to produce effective solutions is to take existing programs and build upon them, whether it’s a scripting language, development environment or functional libraries accessed through an API. As these tools are constantly being developed and re-developed, computer-language skills also have to be re-learned on a continuous basis, which in turn creates a real challenge for programmers over time.

A problem with this occurs in the proprietary world when a library or tool is created, or some other advancement is made, and the vendor wants to restrict the deployment. The prime reason for this is money. Not necessarily greed you understand, just what they feel is the ability to earn a living, feed the dog and put the kids in kennels for the holiday break (or the other way around in some cases). Tool kits and libraries are often jealously guarded secrets that shouldn’t ever leave the building in case the competition get hold of them and make money from your hard earned investment and sweat. I’ve been involved in the creation of many such libraries for proprietary companies in my time and all of them were grossly underused. They were deployed in only a few applications for those companies and, as they could never be used elsewhere, that was it. Needless to say the competition also created similar tools with similar results. Now, should the two competing companies settle their differences and join together in a holy partnership, the new union would be disadvantaged in the expense of maintaining two different and incompatible libraries for similar applications.

Naturally, what also occurs is that some software companies specialise in producing these tools. They then license them to other companies at a fraction of the cost the licensees would normally encounter if they were to develop and maintain the software themselves. The disadvantage with being a licensee is that you lose some control over your destiny. What if you need to port to a new platform? What if you need extended functionality of the library, toolkit or whatever? What if the software company you’re licensing from goes bust? What if you discover that the CEO of the software company you are licensing from is sleeping with your wife? Well, you get the idea. You are stuck.

This brings me (of course) to free software. Here the toolkits are both available and controllable. Proprietary software advocates would argue that you lose out when you use software not made by a profit-oriented company with vested interest in supporting the software. But, any increase in cost due to this is offset by not having to pay license fees. Also the licensing and attitude behind free software means that improvements, fixes and enhancements that anyone makes to the software is made available to all, including yourself. We are seeing this model functioning beyond all expectations in another sphere: the GNU/Linux operating system—where competing companies like IBM and HP are working together to improve a common free product.

However, a problem with free software is that when building it you need to write-off the value of the initial development. Value in free software is in the use, deployment and support of it, there is no profit in license fees. This means that initially the creation of these libraries can be a slow process. There is also an advantage though: unlike the alternatives free software, once created, will not become lost to the depths of some company’s dungeon, never to see light of day due to the monetary concerns of a particular entity—once written it exists forever. It is accumulative.

The result of this is that although toolkits exist in the free world, it takes time for them to become as polished as the proprietary counterparts. Nobody wants to (even if they can afford it) put enough investment into a product to bring it up to standard only to write that investment off. On the other hand though, the small investments (personal or company oriented) that are actually going into the toolkits is accumulative, and the shine is beginning to show. An example of this is WXWidgets, which has numerous cross-platform applications written with it. For GNU/Linux there’s the continuing maturity of GTK and QT. Perl, Python and that crowd have been around for years, especially Perl, and their scripting languages are now difficult to beat.

The other aspect to point out is that the rise of free solutions puts market pressure on the proprietary ones and this is having a undesireable effect (depending on your point of view) as to the amounts that can be charged in licensing.

Now comes the crunch. Simon Tatham, who is most famous for ceating the MS-Windows SSH client PuTTY, has also created a Portable Puzzle Environment and has written a whole lot of puzzles in it. After examining it, I have come to the conclusion that the man is a genius. There is nothing new in the concept of a portable graphics interface of course (which is what that includes), but Simon has taken the concept a stage further. To understand why I think it’s so clever I need to get technical, so please forgive me.

What Simon has done is to create a tripple layer concept in this sphere. The main meat of this is the middle layer while the top is the graphics interface and on the bottom the “back-end”. The way it is designed is that to implement another platform, or front end (being the top layer) all a programmer has to do is to create a pre-set API to draw things (like lines, rectangles and text) on the screen and accept inputs from the mouse and keyboard. This front-end interfaces to the middle layer. Should another puzzle need to be written, all that a programmer needs to do is write a back-end that accesses another set of middle layer APIs that handle many of the games functions such as what is displayed, animations required and what to expect from the user input (not how—that’s handled by the front end). There is in fact more to it than that: the middle layer is designed to be resilient and to automatically handle things like undo and redo, save and load functions and the such with minimal to no work required by the programmer. All in all a pretty cool piece of work.

OK—that’s the end of the technical bit.

In the olden days this sort of library would have been created by a company in a proprietary manner; and a number of games may have been produced with it. But, the restrictive licensing the company would have forced upon it would have meant that either it would’ve been too expensive or too impracticable for anyone else to use. Only one company would have enjoyed the use of it, and when it became unprofitable it would be assigned to the trash. It would have been a brilliant invention that would have eventually headed nowhere.

Now, because Simon chose to release what he did using a free license, I can employ it to my own benefit and hopefully the world’s too. I have long been fascinated by mazes, especially virtual ones, and I’ve always found the mechanics of simple three dimensional mazes enjoyable to sort out (I’m just that sort of person). Simon’s routines have meant that I could take some code I previously wrote that handled 3D maze generation and movement mechanics, port it to C, and easily interface it to the Portable Puzzles’ back end. This resulted in a 3D Maze Puzzle or Game that I know runs on at least two flavors of MS-Windows and three flavors of GNU/Linux and, according to Simon’s documentation, there is a simple recompile for it to run on a Mac.

In less than a week I’ve created a 3D Maze Puzzle that probably runs on more than 99% of the desktops in the world. This tells me that the free libraries, in some respects, have not only caught up with the proprietary ones, they have overtaken them. For those who have not guessed yet, Maze3d is free. The link, for those who missed it at the top, is here.

It was pleasurable to write. If you like mazes... Enjoy!

Category: 

Author information

Edward Macnaghten's picture

Biography

Edward Macnaghten has been a professional programmer, analyst and consultant for in excess of 20 years. His experiences include manufacturing commercially based software for a number of industries in a variety of different technical environments in Europe, Asia and the USA. He is currently running an IT consultancy specialising in free software solutions based in Cambridge UK. He also maintains his own web site.