At that point, fresh from our completion of Majesty, we were convinced world domination was just around the corner and we would all have our ferraris quite soon. We had a number of copies of Majesty printed (no, I’m not saying how many), and expected to have to get a reprint within 2 months, judging by the number of applications for the beta test, and the enthusiasm shown by people.

Over the next few months, reality, and a certain level of depression set in. We didn’t need to reprint Majesty. In fact in the first 3 months we didn’t even sell a quarter of the copies we had produced, and after the first few months, sales begin to slow down, so it didn’t look likely that we would suddenly see a huge rush of orders. The optimism pretty much evaporated.

So, realising it wouldn’t all be parties and glamour and free money by the bucketload, we settled down to some real work. We had more projects going on, with NingPo, Soul Ride and HDB, and we had new ideas. One of the new ideas that we went with was to open a physical shop.

Not a lot of people know we did that. We opened a shop in Nottingham, that was selling games. I admit we didn’t just sell Linux games, we sold all kinds of games, but the idea was to get a bit of local publicity for Linux games, while raising money using sales of other games, to fund the development of Linux games. It also didn’t feel horrible to see a shop where Linux games were on the same shelves as Windows games.

To be honest it didn’t do that great. The shop was small, and the people we rented the premises from made vastly inflated claims of how busy the mall we rented in was. Oh they didn’t lie, but they neglected to mention that the figures for mall visitors also included people walking in one side and straight out of the other side, as it was the only direct route from the city centre to the train station… However we sold a few Linux games, and increased company turnover (which always looks good on the books). In the end though, it was fairly obvious it wasn’t going to be the cash cow we had hoped for, in fact it was more a cash sink. So we closed it down after a few months.

Shortly after, I had been invited to talk at LinuxWorld Expo in San Francisco, and on my return to the UK, found we had had a disaster. Overnight on the day I returned, our stock room (also our server room) flooded. Our premesis is on a hill, and a severe rainstorm caused a building uphill from ours to flood, and the flooding cascaded downhill until reaching our stockroom, which seemed to be waterproof on the downhill side and not on the uphill side. End result was that the water pooled there, causing thousands of pounds of damage, and days of downtime. 6 inches of water took several days and a quite elaborate pumping system to remove, and obviously while half of the electrical system was underwater, we couldn’t fire up the servers!

Luckily, the damage wasn’t catastrophic. while hundreds of games had been destroyed, and computers had been submerged, no game was completely wiped out of stock, so we had no mad rush to reprint, and no orders were delayed. Backups ensured no data had been lost, but it was a bit of a scare! We spent a good few days raising everything in the room up by 6 inches, so that if it ever happened again we wouldn’t have a big problem, and we even installed a pumping system just in case!

Following one disaster, it is only appropriate that we mention another company disaster at this point. Disciples, a great game, but unfortunately LGP’s DNF. It was around this point that Disciples caused the first of many resignations from LGP. Mike Phillips left the company after one too many late nights trying to beat the game into submission. It isn’t that there is anything wrong with Disciples, it is simply that you need a developer with just the right development style to be able to port it, and they have proven hard to find over the years. And so over those years, Disciples has been part-ported several times, leading to belief it will never be released. I can say for sure it will be released, I just cannot, still to this day, say for sure when!

Despite the downsides, the flooding, the game that refused to be ported, and the staff that left, we had successes. Postal 2 became the fastest selling game in its first month, and when we looked back at the accounts we found that we had, in many ways done it right. The company had proven itself sustainable. Where Loki had come in in a blaze of glory and burned out just as quickly, we had been around for as long as Loki, and we were still here. We were not as high profile, the games we ported were not the ones you see advertised on TV, but they were all undoubtedly as good as the games produced by Loki. Just because a game is high profile doesn’t make it good, and just because a game is less well known doesn’t make it bad.

So, we were stable, we were ready for the future, and we now had to make some decisions. How could we grow. What could we do to drag Linux gaming into the mainstream. And how could we do it without the blaze of glory ending…

Recently, we came across an issue with PulseAudio (I will rant about Pulse in some other post). It became almost impossible, due to the architecture of alsa, and the combination of our build environment, and our higher level sound libraries, to make sound work - pretty much at all, in Linux games. Those of you with older games will know that for a while they all stopped having sound. Some of them we still haven’t released patches for yet (they will be forthcoming).

Now, one of the big problems was that sound libraries (such as OpenAL or SDL) go through their own motions of opening sound. We have no way of directly controlling what they do or how they do it. This is a common feature with many libraries, they will load their own dependencies in a way we cannot control.

The biggest problem is that OpenAL and SDL try to dlopen libasound, and on some machines, libasound doesn’t work with our binaries. On others, it can actually crash the whole game due to incompatibilities. This is a common issue when dealing with unknown system configurations when sending out a binary-only product into the world. You never know just what peoples systems will have installed, and just how they may confuse the situation. But you cannot just say ‘well, bad luck, it crashes on your machine’, people will be understandably upset.

We came up with a rather horrible system to make this work, and one that I hope may be of use to those of you who come here for our technical insights. This system is deliberately designed to work with libraries that have the potential to actually crash a program. As a simple example that many here will follow, I am using SDL’s audio system as the target, and using it to test whether ALSA works or crashes the program.

 static int system_asound_ok=-1;
if (system_asound_ok==-1)
{
forkval=fork();
switch (forkval)
{
case -1:
//This is an error, we couldnt fork() so we just say no to
//system openal working
system_asound_ok=0;
case 0:
//This is the child, try and run the open, and then close and exit
{
//Your code here to remove whichever signal handlers you have set up
}
fail=SDL_InitSubSystem(SDL_INIT_AUDIO);
if (!fail)
SDL_QuitSubSystem(SDL_INIT_AUDIO);
//MUST use _exit here not exit
_exit(0);
break;
default:
//This is the parent, wait for the child to exit somehow
waitpid(forkval,&fail,0);
//The child has now exited somehow, check how
if (WIFEXITED(fail))
{
//The child exited ok, we can try and use the system library
system_asound_ok=1;
}
else
{
//The child probably crashed, dont try and use the system library
system_asound_ok=0;
}
}
}

At this point you know whether the system asound (ALSA) library is safe to use.

This is a truly truly horrible system, when you actually have to allow an application to crash, you know something is wrong, but sometimes there is no option.

As a technical note, note the use of _exit() instead of exit(). This ensures that when the program ends, no atexit() functions are called. Using exit() could mean things like SDL’s cleanup being called, or who knows what else!

Signal handlers should be removed at the point in the code indicated. They interfere with the proper signaled exit of the program and will prevent WIFEXITED from detecting a crash properly. Bear in mind the signal removing only happens in the child process and will not affect signals in the parent.

So, what can you do knowing that the system works or doesn’t work?

Well, knowing that it works, you can simply run the initialisation as it stands and enjoy the working library.

If you know it fails, you can either skip this system altogether (in this case run without sound) or you can switch to another library. If you setenv an LD_LIBRARY_PATH this will influence the path that dlopen looks for libraries. LD_LIBRARY_PATH is searched before any other directories, and so will override the default location of the library. This means, in this instance, that SDL_InitSubSystem will dlopen the libasound.so in the location you have set the LD_LIBRARY_PATH to.

I hope this will relieve some headaches for some developers out there. It is always difficult making any application when you do not know what the target system will have installed on it. Of course, we can always say ’sorry, you need a specific version of this or that library’ but when you have just bought a game, that is the last thing you want to hear, and so - we have to jump through some hoops to stop that happening.

In some ways it is a fair question, you bought a license to play the game, but in reality it is not going to happen. Let me explain why.

When LGP ports a game, it takes time and money. We only get revenue back from people buying the Linux version. This means that if we were to say ’sure’ to that question, we would then suddenly get no revenue, as buying the windows version will earn us nothing.

We license games from companies who make the Windows version, and we do not get paid for making the games, and so selling them is the only revenue we receive. If, for example, you bought a game for Windows, you wouldn’t expect to be able to get a free copy of the same game for the Playstation. This is pretty standard for any industry. If you go pay to see a film at the cinema, you wouldn’t expect to get free pay-per-view access of the film on TV later on just because you paid money to the cinema.

We have had many people try and justify why they should have a free installer. We even had one bright spark take the demo for X2, hack the Windows datafiles into it, and then came asking for help wondering why he couldn’t save the game. The answer of course being ‘its a demo, its meant to not save the game’. Our demos are all written in such a way that they will not run the full version of the game.

Some Linux games, for example Quake 4, you get a downloadable installer because the same people who made the Windows version made the Linux version. They went to the expense and they recoup the money by selling the Windows boxed version. Other times, such as Unreal Tournament, where Loki released a downloadable installer for the Windows boxed version, the company who made the Linux version were paid to do so, and so the revenue is generated in that way. This is not the case with LGP games, and is unlikely to become so.

Of course, to leave things on an optimistic note, when Linux finally becomes the ruler of the desktop, then of course, Linux versions will be released first, and Windows gamers will end up in the shoes we Linux gamers currently wear. However, that will be a while coming, so until then, the answer is no. No installer!

A contradiction? Probably.

Now I am writing this from a personal perspective, on how I, as the CEO of the company, feels about this. If you don’t like what I say, don’t shun my poor devteam, who may often think differently.

Now, I love open source. I think it is vital, I think its is the best thing that has happened to computing since the invention of the silicon chip, but, it doesn’t answer all of the questions. I think that closed and open source have a place in the world.

My personal belief is that operating systems and file formats need to be open source. NEED to be. After that, looking logically, the rest of the computing world becomes a level playing field, and you can only become a dominant product by being best. You cannot lock people in if file formats are open, and operating systems are open.

Another fact is that programmers need to eat. Some very few developers are lucky enough to be able to make a living making open source software. But for most, that isn’t going to work. Programmers need to eat, need to support families and pay rent and occasionally buy a luxury or two. To do that they need to make money on their core skill, making software. This can be done in one of three ways:

1. Open Source Beg-ware. Spend ages making software, and hope to hell that people that use it feel generous enough, or guilty enough, to give you some money.
2. Open Source Supportware. Make great open source products and make money on supporting it.
3. Closed source, pay for it.

Looking at those options, well, beg-ware may make some people enough to live off of, but really, people as a whole just aren’t that nice. The natural instinct of a human is to get the most benefit for the least money. Some people will pay, not many though. Supportware is the common way of making money in open source. People pay for extra features or for support. Great. But hold on. This means that it is financially better for a developer to make a product that is hard to use, or lacking in features. Do we REALLY want that? Closed source makes you money, no doubt about it, but who knows what is going on. Really, any piece of closed source airline or medical equipment is always one semicolon away from crashing and killing whoever depends on it, and you would never know.

So by this example, there is no good option. Nothing works perfectly.

A lot of people these days refuse to use the closed source Nvidia and ATI graphics drivers, because they are closed source. I wonder, if the instructions were all hidden by hardwiring them into a ROM chip on the card, and the only part of the driver was some kind of instruction pipeline to the ROM, but that pipeline was open source, would that be any better? Fact is, it would be exactly the same situation as now, closed and hidden blobs of instructions, but without even the ability of the manufacturers to fix problems without a flash upgrade of some kind.

Because of course this is exactly what the open source drivers do, they talk to closed hardware. You are still dealing with proprietary systems. I expect that even RMS, in his infinite dedication to open sourcing (sorry, free-ing) everything, uses a computer that has hardware that has closed and hidden instructions. Is it any better that the instructions are hard wired into a chip? I doubt that a single modern computer in the world has a completely open specification with no hidden bits.

But this doesn’t really matter, I am not answering the question, I am just muddying the waters a little. Showing that the question is not as clear as it seems.

For most software, Open Source seems to be the way to go. In games however, it seems to be failing us. Why have so few open source games been created. I don’t mean one of several hundred tetris or breakout clones, I mean big games, of the scale of X3, or Cold War. I think the problem is creative goals. Open source, to attract volunteers, needs to be something that a developer WANTS to work on. And so a game must be the game that that developer has always wanted to play. And the problem with games, where making a game is mostly a creative process, is that everyone wants something different. And so most open source game projects fall apart, or just fade away.

You can see large numbers of small games for Linux. Games made by one or maybe two people. You can find a large number of clones of commercial games. These are all easy to find developers for, they all want to play the game they used to play, but on Linux.

But original, new, high quality games on Linux, well, there are less than a handful, and none of them would get shelf space in a commercial store They may be technically great, they may be a marvel of collaboration, but they probably wouldn’t sell copies to the random public, and those are the people that Linux needs to target to become more mainstream.

One idea is that commercial companies would make a game and release it with the source. That may be something for the future. People could fix the bugs, but to distribute it you must only distribute the official boxed copy. That way the game is open, maintainable, but the company still gets its money. Put it under a license that restricts use or modification for any other reason. Unfortunately, in reality I doubt it would work. People would abuse the license terms. Call me a cynic, but, I just don’t believe people would respect the license.

In the end, I believe in the best tool for the job, as long as the playing field is level. Firefox is doing a good job of getting to the top, by being better, assisted greatly by open standards. OpenOffice is making inroads by doing the same job as MS Office without charging. It would be doing a better job if all of the file formats used by MS office were open, and that is the biggest thing that is holding it back. A clear example of an un-level playing field preventing the better product winning because of lock-in.

As for games, I started in this industry cos I love Linux and I love gaming. I believe in open source (I’ve been writing and contributing to open source software since 1993), I just do not have confidence it can solve every problem. If open source obsoletes commercial gaming, I’ll be happy as anything cos I’ll get all my games for free, and I’ll be able to go get a job and earn money. Until then, commercial gaming is a vital thing for Linux, and does nothing but help push the platform forwards. Even if it is in a way that RMS doesn’t approve of {:-)