How do I leverage code and experience across alternate platforms?

Question

I continually build complex engines and libraries within a single platform and technology, to allow me to build increasingly bigger and better games. How do I continue this when development crosses into different platforms? If I switch platforms, how do I leverage past code and experiences?

---

Games are hard to build. Big games are even harder to build. I've decided that to be able to make big games, I need to start building smaller games, and building up an asset base of code, assets such as graphics and sounds, tools, and most importantly, game engines. I can eventually get there, one game at a time.

Let me give an analogy. To build an MMO 3D RPG, I would approach this by building and releasing small games with increasingly more features. This could entail, for example:

• A simple 2D game
• A tile-based game
• A game with RPG elements (items, equipment, monsters, battle)
• A full-fledged RPG
• A 3D RPG

The problem now is if I have to change platforms or tools; I don't know how to leverage past code-bases and experience to start with a mature product.

---

Right now, I'm writing Silverlight (FlatRedBall) games. Let's say I stick with this for ten years, and then suddenly decide to write a PlayStation 6 game, which is in an entirely different programming language.

Granted, I have ten years of game-development experience, and ten years of professional software development experience from my day job, to back me up. I would still like some way to transplant that 2D RPG engine into the new programming language, or else leverage it, somehow.

Is this even possible? What are my options?

Answer 1

If you look at how you do business systems I don't think there's much difference in this regard.

Abstract and layer everything as cleanly as possible so you can reuse interfaces and libraries later on, making the games as modular as possible. Write your game code against an engine layer that isn't hardwired to run on a specific platform.

Use scripting languages as much as possible and just write or add the script interpreter to each new platform, reusing script logic.

Design your tools to be as generic as possible and with flexible content formats. Reuse the tools and content pipelines and only re-implement the platform specific parts.

Answer 2

You could try to use an interpreted language combined with some small native components for hardware specific bits. By using Python, for example, you only need to recode native language extensions that interact with the hardware directly, while sticking to the same API on the Python side. This allows you to code your game logic, asset loading and rendering once in Python and reuse them as long as you manage to get the Python interpreter and your extensions operational on the new system.

All-in-all, I think that a game engine should be very hardware and language specific so it can pull off cpu or gpu intensive feats. I would want to build or buy a new engine when migrating to another language or system, so you can benefit from the optimizations they offer.

You do have good options for your other systems, though:

• Game logic can be written in an interpreted language that is supported by or built into the new engine
• Assets are already pretty portable, again, as long as the engine supports them or you have converters for them
• Tools do not need to be written in the same language as the engine is written in as long as they communicate or export in way understandable by the engine (again converters can solve this problem)

The bottom line is that you will never be able to fully transplant an engine 'as-is' to a different platform or language. You always need some kind of layer or wrapper that translates the platform/language calls into engine calls and vice versa.

Answer 3

So, first, please stop saying 'leverage'. Say exactly what you want to do with it ("I want to run the bytecode across platforms.", "I want to use my old .cs files in ten years.", "I want to...", etc.). Buzzwords aren't helpful for us here.

First, let me try to see if I understand your underlying questions:

1. I wrote a game or engine to do X on Y platform. How do I use this (without modification) on platform Z?
2. I wrote a bunch of code in language X. How do I convert it to language Y?
3. I want to rerelease my game or engine X for platform Z 10 years later. How does this work?

All of which boils down to a better question; we'll get there in a bit.

I wrote a game or engine to do X on Y platform. How do I use this (without modification) on platform Z?

So, there are two parts to this: "doing X on Z", and "using on Z".

You want to make sure that you are bringing something worthwhile onto the platform ("doing X on Z"): why port a text adventure game onto a PS6? Is there an opportunity to update the technology and game to make better use of available resources (i.e., "I've got pixel shaders now, so I can move away from statically-calculated per-sector lighting in my Doom clone.", "I've got hardware T&L and rasterization now, so no reason to use an engine limited to raycasting wall segments")? If you are porting over code limited by old hardware, might as well ditch those limitations and start anew.

"But," you say,"Zork is still awesome, and would be great on the PS6!".

Okay, no worries, agreed. So, now the problem is how to make Zork run unchanged on a PS6 ("using on Z"). To run old programs, you either need to adapt the code to its new operating environment, or adapt its new operating environment to it. You made a decision writing your code, and this is what is going to be important: did you write your code to be interpreted?

Why yes, all of my game logic is in a custom, well-specified bytecode format running on a custom virtual machine.

Good for you, Mr. Fancypants. You saw this day coming, and you wisely wrote your language to run completely on a virtual machine (emulator). You are following in the footsteps of Carmack, Lucent/Bell Labs, or Berez and Blank. All you have to do to run a port is to rewrite/recompile your interpreting environment, and now you can rest assured that as long as people can write VMs for the new platform, you're tech will persist. Java or C# is a decent way of going about this as well.

Er, that's rather silly... I just wrote everything in portable C/C++, complying to all the standards and abstracting away all of the platform-specific stuff.

Alright, cool! Your diligence in proper systems engineering and abstraction is going to pay off. You just have to rewrite the platform-specific stuff, tweak the build process, and away you'll go! Sure, writing a Direct3D backend to replace your OpenGL renderer might take a month, but hey, at least it isn't the whole stack!

Um... I... uh... well, it was a lot simpler to let objects make Direct3D calls directly. I mean, it wasn't supposed to turn into this big app.

Congratulations! You're screwed!

...more seriously, this is something that can be unavoidable. If you wrote your text game in QBasic, and here we are on Windows 7, you probably can't do anything to salvage it. At this point, you can't possibly adapt your application to run correctly on the new architecture/machine/operating system.

So, you'll need to adapt the environment to your application (if Mohamed won't come to the mountain...). Consider: if you've got the binaries, and the assets, and you know the configuration of the machine they ran on successfully, then all you have to do is use some emulator for that environment. This has been done before. As long as you don't need to communicate with it, or reuse its routines, you'll be fine.

But... but... but what about my A-star implementation in 68000 assembler? I don't want to rewrite that!

Tough luck. That's the cost of not thinking about what you are going to do with your code later in life. This is why we call it software engineering, not software kludging--at least not in public.

I wrote a bunch of code in language X. How do I convert it to language Y?

One character at a time? Outsource it? sed and regex?

More productively, if you wrote it in C or something similar, you might have it compiled into a library you can link with. It's okay to have something written in Fortran that you can still call from other code whose build environment knows how to digest libraries. COM objects and .dlls and all that let Visual Basic apps interact with C# code.

If you have to rewrite it, and don't care about code quality, sometimes you can find a tool to do the work for you. This might not even work, but hey, you don't have to write the code yourself.

If you don't mind, rewriting it in another language is a great opportunity to learn the new language, remove dead code, and rethink old algorithms that might not be optimal anymore. And because you wrote good unit-tests (right?), testing that the new code is at most as buggy as the old should be easy.

I want to rerelease my game or engine X for platform Z 10 years later. How does this work?

After reading the above, it should be obvious: write modular, well-specified code for a virtual machine, and/or properly abstract away implementation-specific functionality. If that doesn't work, ship it with an emulator.

*

The real question you want to ask, though, is:

How do I design software that I can keep using throughout my career?

You've got to plan out, ahead of time, what it is going to do, and how it is going to do it. You've got to hide or isolate anything that doesn't directly deal with the logic of the algorithms being implemented (no direct API calls), or decide where you stop caring about portability. You've got to be willing to remove and rewrite deficient code. Mostly, though, it's the same as the way you get to Carnegie Hall:

Practice, man. Practice.

Answer 4

The idea that you won't be able to take libraries of code and use them again, or use them on multiple projects because the language doesn't match, or the design is partially within the implementation is consistently misjudged in games development.

While developing projects across different languages, the inability to reuse source code is significant, but also inappropriate when considering the true meaning of reusability.

Reusability is not concerned in reusing source files, not even in particular languages, but the ability to maintain an invenstment in information. A wealth of knowledge for the entity that owns the development IP.

Copyright law has made it hard to see what resources have value in reuse, as it maintains the source as the object of it's discussion rather than the intellectual property represented by the source. The reason for this is that ideas cannot be copyrighted, so by maintaining this stance, the copyrighter keeps hold of this tenuous link to a right to withold information. Reusability across the language gap comes from being aware of the information contained within the medium it is stored. In our case, it is normally stored as source code, but the information is not the source code.

With same-language ports, the source can be adapted to any project we wish to venture. However, the source is not the information. The information is the order and existence of tasks that can and will be performed on data. This view of information leads to an understanding that any reusability is an adaptation from one set of temporally coupled tasks into a new framework.

So, even though you want to move from one language to another, or one platform to another, and the code doesn't appear resuable on the outside, the fact is that it contains a wealth of information in a readable form. In fact, porting between languages can often show up bugs that have been present for years.

The method by which you port the code from one language to another varies with the languages involved, but a good starting point is to load the old code into the new language as comments then, treating the old code as pseudo code, begin writing in the new language. This way, all the old bug fixes are maintained while any new ones can be quickly ported back to the old codebase if wanted/necessary.