Ways to Port Other Company's Games

To explain the title a bit more, this post will be specifically focused on a Bad, Good, and an Interesting way (that is also good) that I've experienced when porting other company's games. I have also found it hard to find information online about this topic and that has always frustrated me.

Let me first give you a bit of background. Just about every year my company gets another company's popular game(s) onto our bar-top touchscreens. The game team (the team I'm on and used to be the lead for) were the ones that got to port these games. I will be explaining two real life examples of ways we did it and the pros and cons of both approaches. The final approach is one I would like to try in the future. Another thing to note is that in all cases these are ports from Windows/Mac to Linux.

Approach 1: (the Badish one)
I say "Badish" because this approach (if executed properly) could be good, and I will explain that more in the pros/cons. To explain this approach I will go through the scenario of my company porting the games Luxor and Chains 2 (developed by MumboJumbo). So the companies have had the talks, the licenses have been approved, and we've just received everything we need to start.

What we have:

1. All source code, including game, engine, and some tools
2. All art assets, raw and in-game
3. Some game tools (like a particle editor)

So great, we actually have all the code and everything.

STOP!
Before I go any further, in the case of these 2 games I started at the company after they were pretty much done. I am writing from coming in after the fact, helping fix bugs and porting the puzzle mode for Chainz 2.
GO!

The method chosen for porting this game was pretty brute force. Make the game use the OpenGL rendering and copy the MacOS specific code, rename the files BlahLinuxBlah.h/cpp and change things to use X, etc. etc. Since both games used the same engine, we would basically be killing two birds with one stone right? WRONG! A better analogy would be that the momma bird mated with a monster and now you had two crazy monster birds to handle.

Long story short it was about 3 months (which to me is absurd) until you could see something on screen and about 6 months after that of misc. obscure bugs coming up from testing under certain hardware with certain conditions. This is probably due to poor foresight and lack of experience doing such a port on the part of the developers. Lets check out the pros and cons.

Pros:

1. Once it is done, all games that use the engine should (keyword "should") be fine
2. Assuming you know exactly what to do it should not take that long.

Cons:

1. There are lots of variables, game engines are usually different from game to game
2. Some games do not properly abstract things out and OS specific code can be in the game
3. Most games are not ready to be ported to Linux and were never intended to
4. There is a lot of time needed for code archeology

• figuring out the best way to plug into the engine if possible
• Tweaking existing features in the game to match intended audience and hardware (touch screen)

Okay, so I came up with more cons than pros. I may be a bit jaded. It may be because there are bugs that got "resovled as wontfix" or still linger on our trac to this date (the games shipped 2 years ago). Anyway, lets move on before I cry us a river.

Approach 2: (the Goodish one)
The only reason I put "Goodish" is because I have still not seen this completely run its course, but at the moment it looks good. This example was used on a few games that are not yet released. Let us call them Game A and Game B. I am currently developing Game B which seems to be going just as smoothly as Game A. Again lets look at what we got from the nameless company.

What we have:

1. SOME source code, which includes all game code and very little engine code
2. All art assets, raw and in-game

Okay so this is a slightly different situation. Things that are different this time around are: No useful engine code, and knowledge of the previous game ports. I was also the lead at the time :-). This time we wanted to try a different method which some may think is radical. Instead of pushing on the developer to give us their engine code, which we could then go on and make the same mistake with, we decided to rewrite the game.

Let me explain a bit in detail. We would use the provided assets (visible assets as well as object placement script files and other misc. data) with our in house engine. We would use there game code as reference for specifics with game logic. But wait Aaron, doesn't this mean you are wasting a bunch of time recreating that wheel? Yeah, but the benefit is it would become OUR wheel and it would be attached to OUR car which we know in and out. This means maintenance and parts that fit are readily available.

Game A began development about 3 months ago and finished development the end of last month. We expect some bugs and tweaks to come from beta feedback, but we KNOW there will not be anything crazy (and that helps me sleep). Game B is expected to take a similar amount of time. Check out the pros and cons.

Pros:

1. Bug fixes and issues that come up require less research time
2. We don't need to port an engine, we already have a working one
3. It does not require in depth knowledge of how to properly port Window/Mac -> Linux
4. There isn't much high risk code being developed

Cons:

1. If we ever get another game from them that uses the same rev of the engine (not likely) we have to also rewrite that game.
2. Dev time is variable depending on the complexity of the game.

Now keep in mind, this works great for the type of games we port (casual). I imagine if this kind of model was being used with a AAA title it may have a bit more cons. Anyway we found this model to work great for us, and will be remembered as the way that worked Good.

Appoach 3: (the Awesome/Interesting one)
Okay now this approach is one that I have not done first hand, but really interests me. This one has to do with going in under the game code, under the engine code, under the APIs the engine uses. I am talking about going in and emulating the platform the game already works on in between the OS and the Game. You may have heard of Wine or Cedega (http://www.transgameing.com). I actually got a chance to talk with Gavriel State at the the recent GDC Khronos Session and they are doing some awesome stuff in this area.

Pros:

1. All games made now work
2. Ideally all dev time would be spent on making specific gameplay changes for your platform

Cons:

1. I have no experience doing this method so I don't feel comfortable putting a con

This method is already being used for many AAA titles so they run on the Mac. I hope to learn more about this topic in the future, but if anyone has any more insight into it I would love to hear it.

If you found this informative, you are welcome :-). If you knew this already, great. If you think I have no clue what I am talking about, I would love to hear more about this subject from you.