Good examples of 'transferable game logic' across genres?

Question

Do any of you have any good examples from two or more games that share some of the same game logic, but are of entirely different genres? Could very well be one of your own games. Take Warcraft 3 and World of Warcraft for instance. Entirely different games, but they could have some game logic in common without us knowing.

Answer 1

Game logic re-use can be a wonderful thing! Here's where and how we've used much of ours from project to project. About 75% of our 2004 title exists throughout the games we've created in the subsequent six years, even though they are all quite different:

• 2004 - Inago Rage, our first 3D title, an FPS
• 2005 - Epidemic Groove, an early tower defense style game
• 2008 - The Wonderful End of the World, a casual action game
• 2009 - AaaaaAAaaaAAAaaAAAAaAAAAA!!!, a BASE jumping title
• 2010 - ooo! ooO! oOO! OOO!, where you fly and fight through levels created procedurally from your own music library

Here are a few places where we've re-used modules:

• Tools: The level editor for Inago Rage exists as part of Aaaaa! and Ooo!, but it also formed the basis for gameplay for Epidemic Groove (the player's interface for building defenses is an augmented version of the map editor from the previous game).
• Libraries: The audio wrapper for our sound library of choice is shared between all five titles. We've improved this with each iteration.
• Game Logic: Elements such as player movement logic were/are re-used where appropriate. No need to re-invent the wheel.
• Utility: Certain elements such as text display/HUD are re-used and (ideally) augmented each time.

Pluses: Over these titles, we've learned the following positive things:

• Re-use reduces the time required to prototype new ideas.
• It can also reduce time-to-market once we're past the prototype stage.
• Elements that seem outdated can serve as a basis for more polished future work. For example, if the UI that displays the score is ugly and aliased, no matter -- we can use it during development, and polish when we're ready.

Minuses: And the following negative things:

• Re-use can sometimes constrain what we do when we prototype. For example, we never considered an RTS-style game because it was too far from what we'd done before.
• Sometimes we neglect to refactor, so we end up with the code equivalent of junk DNA. There are routines that handle weapons upgrades from our 2004 FPS in our 2009 title whose gameplay does not involve combat.
• If the code sits atop one engine, porting it all to another engine can be difficult. (For example, we want to move to Unity for cross-platform compatibility, but that requires a certain time investment we didn't want to make just yet.)

Still, I think our inclination to re-use has kept us in business thus far, and would recommend the practice. Hope that helps!

Answer 2

I believe this deals with logic like "making the player jump". I've heard that question from inexperienced developers a couple times. What you're looking for is more algorithmic in nature. For example, the code to make an actor jump in a game could be uniformly used in any engine and any game that supports jumping characters.

It needs: - a velocity vector for the actor - a force modifying the velocity (jump) - changing actor position based on velocity every frame - reducing velocity every frame based on gravity - certain minima and maxima, like min/max speed

This works in a 2D Jump 'n Run, a 3rd person action-adventure or a 1st person shooter in any engine. Only the parameters (force, gravity, coordinate system) change.

But sharing this kind of code across games of different genres is unlikely simply because developers:

1. change engines (sometimes depending on game genre)
2. stick to a certain genre anyway
3. simply re-write the code because it's so simple or requires significant architectural changes because of the game genre or game engine
4. love to reinvent the wheel (some do)

Answer 3

The easiest examples of this are two games that use the same engine, or one game that is a "mod" of another game (which is just a special case of "same game engine" really).

And yes, of course you can do that. One of the Warcraft mods took away the concept of destroying the opponent and essentially created what is now known as the "Tower Defense" genre, which is a bit different from the Realtime Strategy genre. Portal and Half-Life 2 share their game engine in common; I'm not sure exactly what genre to call Portal, maybe a physics-based puzzle game, but I'd be hesitant to call it a pure first-person shooter.

If you want to get technical, all games using, say, Game Maker are built using the same tools, and therefore share some of the same objects and behaviors. Or even games using C++ that are all using if statements, for loops and pointers, whether they be RPGs or FPSs or retro-arcade games. So it all depends on how loosely you define things.

From the question title, I'm guessing that what you're REALLY looking for here is a general list of "game programming" tasks that are used in a variety of games, beyond just "normal" programming -- in other words, what functionality should be common to every "game engine"? And yes, there are a few things: random number generation; displaying sprites (for 2d games) or polygons (for 3d games) to the screen; ability to accept and respond to player input in real-time; collision detection; pathfinding; playing sound effects and background music.