Why you won’t get a Linux installer for the Windows version

August 9th, 2009 by Michael Simms (CEO and head of Development)

We probably get this question at least once or twice a week, ‘I already bought this game for Windows, can I just get an installer for Linux for free’.

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!

  • Share/Bookmark

PPC support officially being discontinued for all LGP titles

August 5th, 2009 by Michael Simms (CEO and head of Development)

I am sorry to have to announce that as of today, we are officially discontinuing support for all PPC versions of LGP games.

The decision is not one I am happy with, and I know that a lot of people will be equally unhappy, but unfortunately, practicalities must win out. The demand for PPC versions of LGP games has been almost non existant, with just a few players buying for this platform. The decision was reached recently, when we looked at the costs for bringing the new Majesty updates to PPC. The cost would have been well in excess of any possible revenue we would gain from new PPC sales, and with most people who have already bought Majesty for PPC also having access to x86 machines, well, it just seemed for the best. I seriously doubt if any players will actually be left behind because of this (though I expect several people to post comments here saying that they will be). While we would love to keep supporting ppc, and any other platform you can think of, we have to be practical, and throwing money into a project we know will never even come close to recovering its costs is not going to keep LGP making games into the future.

For the forseeable future, we will concentrate on the x86 platform, 32 bit, and when appropriate 64 bit (although all of our games will continue to run on 64 bit using the 32 bit compatibility libraries).

  • Share/Bookmark

The case of the missing Majesty

July 17th, 2009 by Michael Simms (CEO and head of Development)

A few people are asking where is Majesty, howcome everywhere is running out of stock?

Well, Majesty is actually out of stock. We ran out during the May sales, and it is still not reprinted yet.

We have been holding off on the reprint, as we are working heavily on updating it. The first version of Majesty is a little dated now, it uses some old libraries (we were using SDL 1.2.5, which is just a little out of date!), and it uses some systems we have since stopped using (such as the old static/dynamic release system to satisfy the LGPL).

We are also removing the old OpenPlay library used for multiplayer games up to now, and replacing it with Grapple, and integrating it with the PenguinPlay server for lobby and scoring systems (as you can see below).

majesty

This does mean network compatibility between versions will be lost, but it means that you now get all the advantages of PenguinPlay, and Grapple, which is a more advanced networking system than OpenPlay. Saved game compatibility will not be lost, luckily!

Unfortunately this all takes time, and we were not expecting to sell out so soon. We sold more Majesty than we were expecting to in the sale, and so we were out in our time estimates by a few months, as to how long the remaining stock would last. The updates were about half way through when the stock finally ran out, and not in any position where we could simply release a new version.

Luckily the changes are almost finished…maj_manual

So, in a few more weeks, you can expect that new Majesty will be coming your way! If you don’t have it already, you probably should get it. If you already have it, well, the new version also has a colour manual instead of the old black and white one, uses the new setup tool, and the disc looks better.

I know some people may ask, why didn’t we make the colour manual and better layouts before? Well back when Majesty was first printed back in 2003, the cost of colour manuals was so high that it was just not possible. Now, colour manuals are much more affordable. As for the rest, well, LGP was just learning its trade back then, and now, we know what we are doing and can do a better job!

So, new player or old, whether you buy the new version, or just patch your existing disc, I hope you enjoy the new version of Majesty. All in all, it is a new lease of life for one of our most popular games!

  • Share/Bookmark

Customer Services Update for June 2009

July 8th, 2009 by Melissa Kealey-Bennett (Customer Services Manager)

Welcome to a issue 3 of the LGP customer services monthly report for the LGP Blog.

We didn’t have an update in May, as very few issues seemed to be similar, and we simply dealt with them on an individual basis.

This month we have a couple of new issues to discuss.

X3: Hanging or Crashing

This issue has been affecting a small number of people, where X3 seems to be leaking memory. We are in the process of assigning a new staff member to look for this issue, as a matter of priority. The problem does not seem to affect everyone, as many players play for long periods of time with no problem, where some can hit the problem in five minutes of play.

While we acknowledge that the bug does indeed seem to be there, it may be some time until a fix can be provided, as it may take some time to locate such an elusive bug.

Sacred Networking Bug

The networking bug in Sacred that we have talked about previously seems to be more widespread than first suspected. We have found what could possibly be a solution, and we are hoping to have a patch out soon. However we are still working on a few other issues to resolve before the Sacred patch is ready.

  • Share/Bookmark

IP MASQ shortcuts causing Grapple to fail

July 4th, 2009 by Michael Simms (CEO and head of Development)

This is a technical article that goes to some depth into networking protocols. Reading this article, you will need some overall knowledge of how UDP networking works, and a basic idea about what NAT and IP MASQ is.

We’ve just spent quite a while investigating issues with a small number of games failing to make connections to perfectly good servers. Grapple, the LGP networking layer, is designed to work around the presence of firewalls, NAT, and all that good stuff, so that users can host a game from any machine on their network, whether it be exposed to the outside world or not.

So, when we found out that some people couldn’t connect to games, we were a bit concerned. After all, our code should be just fine for this. It has worked in all of our test scenarios.

Unfortunately we assumed that all networking at the kernel level worked. This was a mistake.

So, take a scenario, lets say host A (lets call it gateway) is the gateway server, running IP MASQ to NAT all servers on its local network. Host B (call it laptop) is a machine on the internal network.

Now, as we run through this article I will run you through some aspects of NAT, STUN, TURN, and other nice things about firewall and NAT handling. I wont be going through the exact protocols, but I’ll give you a bit of an idea how it works.

So, Laptop is the machine I want to use to start up a game server. I start a server and bind a UDP socket to port 2000 on all interfaces. I then use STUN to find out what kind of connection I am on. The method for STUN is shown below.stun

STUN tells me that the server is on a symmetric NAT. This means that the only things that can communicate with the server, are things that the server has talked to itself first.

This is the most restrictive type of NAT, under usual circumstances it will mean that it is effectively impossible to make connections to this laptop game server without making manual traffic routes through your NAT routing table on the gateway machine for each client. Any client connecting to the server will try and connect to the laptop, but any routing will be rejected because the laptop has not first connected to the client.

However, Grapple can handle this, as I will demonstrate.

So, on the gateway machine (it is important for later on to note that the gateway machine is also the client trying to connect to the laptop server to play the game), I start up a client. The client tries to directly connect to the server, sending a number of UDP connection requests. The server does not receive them.

This is not unexpected, as demonstrated earlier, the server is behind a symmetric NAT and the server hasn’t sent any data to the client, and so the servers routing will reject anything being sent to it from the client.

So, at this point it looks fairly hopeless, how can the server magically know the client is connecting to it.

Well, the answer lies in the STUN server. The laptop server has already talked to the STUN server and so the NAT routing tables allow the STUN server to send more data to the laptop.

So, the client gateway knows about the same STUN server, and so sends a request to the STUN server to ask the laptop server to connect to it.

The laptop receives this request, and connects to the address that the STUN server requests. The client should then, we hope, be able to communicate.

Now at this point this can go two ways.

1) Client is not behind a symmetric NAT or firewall

In this case, the client receives the data packet, and communication can start. We’re pretty much done handshaking, the client and server can talk to each other.

2) Client IS behind a symmetric NAT or firewall

The client will never receive the packet from the server. No communication is possible.

Now, in the instance in question, we discover the situation is an impossible one. The client receives the packet from the server, but then is unable to reply.

This is completely impossible, the routing table to the client has seen a packet to from the laptop to the gateway, and so should allow 2 way communication between the two machines (on the same ports). But for some reason – it wasn’t!

This was the sticking point. How could this be possible. We knew that the laptop worked this way because we had communicated with the STUN server successfully, and this relies on the fact that an outbound packet creates a tunnel back to the server. This is vitally important for all networking, or you would just send out data and never get anything back, rendering NAT pretty much useless.

The issue turned out to be the IP MASQ NAT on the gateway.

The laptop sent a packet to the external IP address of the client. This means that it should have gone out to the NAT layer, and been NAT’d to the external IP and port of the server socket communicating to the client. The client would have received a request that external IP 123.123.123.123 was trying to talk, and would respond to that address. The response would have gone through the same IP MASQ layer, and the server would get back a response from the location it expected.

HOWEVER

IP MASQ has decided in its infinite wisdom to take a short cut. It spots a packet will be routed to the gateway, and decides that, hey, they are on the same internal network. They can talk directly! And so, the packet presented to the client is not showing as coming from the outside internet, it is shown as coming from 10.2.2.13 (the internal IP address of the laptop). And so, when it gets this reply, it sends a response back. As the response never passes through the IP MASQ because it is going over the internal network, then the response to the server comes from 10.2.1.1 and as the server sent its data to 123.123.123.123 the servers own firewall (independent of the NAT) says ‘hey, I don’t know you’ and rejects the packet.

All because IP MASQ takes a short cut.

In the end, the problem is solved that if the client doesn’t receive further communication from the server, then it falls back to its final communication option, TURN. We have already demonstrated that the STUN server can talk to both sides, as both sides initiated communication with the server. This means that the STUN server can act as a relay between the client and the server, sending any and all data via this third party. However to be honest, we don’t like doing that as obviously it will increase latency of games, and also it means that any and all game traffic that has to resort to TURN has to be passed via our servers. A few games running at once, no problem, but more and more games means more and more bandwidth used, and we’d like to avoid that!

So in the end, the problem is solved, but really, if not for IP MASQ making a shortcut for efficiency, there would never have been a problem in the first place.

[Edit: I am adding the layout of the network below, to explain a little better]

network

  • Share/Bookmark

A closed source company’s CEO’s view on open source

June 29th, 2009 by Michael Simms (CEO and head of Development)

It is no secret that LGP makes closed source software. We also create games that only work on closed source 3D drivers. And yet we work to make games for an open source platform, and we consider ourselves as part of the open source community.

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 {:-)

  • Share/Bookmark

LGP History pt 2: The Early Days

June 23rd, 2009 by Michael Simms (CEO and head of Development)

Thanks to everyone that posted and emailed about part one of this history. I’m glad you enjoyed it, and here is part 2…

So, there I was, back in the tail end of 2001, with a contract to do Creatures and Majesty, and really, no idea how. Creatures wasn’t much of a problem, as Creature Labs had done the port already, and just needed a publisher. I pretty much winged that, I got the game made up, but made the mistake of doing it in parts. To this day, each copy of creatures that is shipped has to be hand assembled with each of its 4 parts. It may not sound like much, but over the years, it’s been a real pain. All other games we had made since then, we had made ready to ship.

At around this time I got the news that we had all been expecting. Loki was going out of business. I immediately contacted Loki, and asked them if LGP could obtain the rights to carry on producing the games they had made. This would have been a great boost to the new company, and would have allowed us to keep on making the games that were still in great demand by Linux gamers. Unfortunately Scott, the CEO of Loki at the time, was asking for such a ludicrous amount of money for the licenses (way more than they were possibly worth, and probably more money than the games had made by selling for the entire history of Loki) that I had to let the idea go. We made a second attempt at the liquidation of Loki to acquire the rights, but the company handling the liquidation was so unprofessional, that they made it impossible to do so. With their policy being that the only way for me to officially state our interest being to fax them, and their only fax machine being broken for over 2 months (they kept telling us it would be fixed any day), we didn’t really have a hope. The liquidation hearing came and went before they contacted me, several months later, and acknowledged LGP’s interest in the liquidation. Not a lot of use really.

So then there was Majesty. I had the porting rights, but I had no idea what to do with it. I mean, I pride myself in being a very good programmer, but porting was something I had no real experience in.

Sam saved the day. Sam Lantinga, previously one of the Loki developers, pointed me at a number of ex-Loki staff who were still interested in doing more porting work. Of those, Mike Phillips was the one that ended up joining us, and even though he left the company some years ago, his influence shapes the way we do porting development to this day.

Mike spent quite a while pushing me in the right direction. I had a number of preconceptions that he had to beat out of me, but I also had to push back on some of his ideas, and I think, in the end, we got the right mix of decisions. Mike set up the idea for the LGP build environment, one that we still use a derivative of, as it has proven to be a build system that is very very portable, and enables us to make games that run on all distros. He also introduced me to the idea of IRC, which has enabled the company to have a real interaction with our customers.

Before Majesty work could start, Mike spent a number of months sorting out the LGP build system, and building some of the basic building blocks that LGP uses to make porting easier. He wrote wrapper functions for file handling and other common tasks, and established the tools we would use for our games. SDL for input and graphics, smpeg for video, SDL Mixer for sound, and openplay for networking, were the main choices.

Majesty work started in earnest. Mike spent a lot of hours on the project, while I carried on trying to find resellers and distributors for our games, and at the same time finding new games for the company. I ended up making an agreement for a couple of smaller games by Pyrogon, and also managed to pick up the rights to Mindrover, one of the Loki games we had missed out on earlier.

Majesty porting finally came to an end, and then we had a decision to make, that has influenced how we do business from that moment, and a decision I am very happy that we made right. After the beta test, we had one bug left, where network games occasionally went out of sync. Mike wanted to go gold, and ignore the bug. I wanted to find the bug, despite the fact that the bug happened in the Windows version too. I put my foot down and insisted, and that was a turning point for the company. From then on, LGP’s policy was always to delay release as long as it takes, to get a good release, not an almost right game, but one that we can be proud of. So Mike spent a good few weeks hunting for the bug. In the end, I joined him in the hunt when his resolve started to waiver, and between us, we found the bug after a hunt that lasted for over 8 weeks. It was a simple 1 line change, and the multiplayer game was fixed.

Majesty was finished, and our first game, ported from scratch, was done!

  • Share/Bookmark

The sale, and the results

June 8th, 2009 by Michael Simms (CEO and head of Development)

Now that some time has gone by, and the numbers have been looked at, we have reached a conclusion about the sale.

The thing is, a one day sale can never give us useful information. The one day sale was a HUGE success. We turned over more stock in one day than we usually do in 6 months. The problem is, we made less than we would usually make in a month.

But that sale was never part of the calculations. The real test came after.

We looked at the sales figures from resellers. These sales figures spanned a number of weeks, and gave us a much better idea of how sales long term would go, when prices were lower.

The first week of sales was, as expected, higher than usual. Week two, sales dropped back to the same sales levels as we were getting before the sale was announced. Week three, sales levels stayed flat, at around the level of before the sale was announced.

This was the important test. What happens over an extended period of time, and the result was, the same number of sales, less profit per sale.

And so, I think we can say that we gave it a shot, we gave a fair ear to the people that demanded lower prices, and the result was, it is not economical for us to do so. Sales spike, obviously, but then go back to normal. A person coming to the site seems no more or less likely to make a purchase based on the lower prices.

On the plus side for those that wanted lower prices, we now have the rental scheme in place and at least one reseller implementing it, and so, some games are now available at the lowest prices ever!

  • Share/Bookmark

Downloadable and rental games now available

June 1st, 2009 by Michael Simms (CEO and head of Development)

A lot of you asked for the ability to download games.

We have listened and created the reseller download system.

From today all resellers will be able to sell downloadable copies of LGP games, and these will be cheaper than boxed copies. LGP is not selling downloadable versions directly, as to do so would seriously damage the ability of the reseller chain to compete meaningfully.

When buying a downloadable game you are guaranteed the following:

  1. All LGP games will be re-downloadable from LGP itself for as long as we are in business
  2. All full downloadable games, while keylocked, will always work, even if LGP shuts down
  3. In the unlikely event of LGP going out of business, all downloaded games will be placed onto the bittorrent network (in a keylocked state obviously) so that they will remain in circulation for as long as people demand them.

Rental Option

We have also listened to those who wanted ridiculously low prices on their games. We have created the LGP Rental system. Any downloadable game is now available for rental. This means you can pay just a fraction of the price, and have the game for a week, or for a month. The rental games DO require internet access to start up, but apart from that are exactly the same as the full game. I know some of you will dislike this, but really, it is rental, we have to have stronger security on it. The downloadable purchased game does NOT require internet access to start the game.

Right now, the only games we have that are available for download or rental are the three newest games that have the LGP Key System, X3, Jets’n'Guns, and Sacred. Other games will follow as we get time to add them into the system.

I hope that this will be what you all wanted, and will give everyone, even those that want their games for next to nothing, the ability to play LGP games. If you can think of other things we can do with downloads, please do comment here and let us know. I wont promise that LGP will do everything that people ask, but I can say, and I think we have now proved this, we DO listen {:-)

  • Share/Bookmark

Variable length C macros

May 30th, 2009 by Michael Simms (CEO and head of Development)

Something that came up in porting X2 and X3 is that Visual Studio in Windows handles variable length macros, and as far as we could see, GCC didnt.

This means that in gcc, if you wanted to create a define that would do a job and report where it was called from, you would need to do something like:

void mydebug(const char *file,int line,const char *fmt,...)

#define DEBUGOUT1(x) mydebug(__FILE__,__LINE__,x)
#define DEBUGOUT2(x,y) mydebug(__FILE__,__LINE__,x,y)
#define DEBUGOUT3(x,y,z) mydebug(__FILE__,__LINE__,x,y,z)

and so on…

However, there is a solution which does the job, which we found after a fair amount of investigation. The recommended method would be

#define DEBUGOUT(x,y...) mydebug(__FILE__,__LINE__,x,y)

Which will work, but only if you actually add a second parameter to the DEBUGOUT call. Without, it will expand

DEBUGOUT(x)

to

mydebug(__FILE__,__LINE__,x,)

which will obviously fail to compile. To fix this, simply bear in mind that … in the macro just means everything else, so you can do

#define DEBUGOUT(x...) mydebug(__FILE__,__LINE__,x)

which then works with single and multiple values in macros, x becomes the fmt AND the … for the mydebug .

  • Share/Bookmark