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:
- All source code, including game, engine, and some tools
- All art assets, raw and in-game
- Some game tools (like a particle editor)
So great, we actually have all the code and everything.
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.
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.
- Once it is done, all games that use the engine should (keyword "should") be fine
- Assuming you know exactly what to do it should not take that long.
- There are lots of variables, game engines are usually different from game to game
- Some games do not properly abstract things out and OS specific code can be in the game
- Most games are not ready to be ported to Linux and were never intended to
- 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)
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:
- SOME source code, which includes all game code and very little engine code
- All art assets, raw and in-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.
- Bug fixes and issues that come up require less research time
- We don't need to port an engine, we already have a working one
- It does not require in depth knowledge of how to properly port Window/Mac -> Linux
- There isn't much high risk code being developed
- 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.
- Dev time is variable depending on the complexity of the game.
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.
- All games made now work
- Ideally all dev time would be spent on making specific gameplay changes for your platform
- I have no experience doing this method so I don't feel comfortable putting a con
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.