Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411274 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 04:04:36 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Code reuse
Pages: [1] 2 3
Print
Author Topic: Code reuse  (Read 9711 times)
synapse
Level 1
*



View Profile
« on: July 31, 2008, 03:26:56 PM »

How many people reuse significant portions of code over multiple projects?  And what kind of systems generally lend themselves well to reuse?

I ask because I'm trying to plan a bit ahead in game development because I'm hoping to leverage large parts of my codebase.  Specifically, I'm hoping that by developing simple games early on, I'll have a solid base of code from which to build on for later, more ambitious projects.  My current project is heavy on the user-interface code (which should be very reusable) and economic simulation code (which will be unlikely to be reused for anything other than a sequel).  My guess is that general game framework, user interface, AI, and graphics code are the most commonly reused modules.
Logged
muku
Level 10
*****


View Profile
« Reply #1 on: July 31, 2008, 04:11:21 PM »

Basically, anything that doesn't rely on the specifics of your particular game can usually be reused. E.g. all the "plumbing" code that sets up a window and creates an OpenGL context (or whatever it is that you use), perhaps your main game loop with frame rate limiter and event handling, a matrix/vector library, a texture class... that kind of stuff. I usually also have a source file containing all those little utility functions that are at most a few lines long and don't really fit anywhere else; as long as you keep those generic, they can often be reused pretty nicely too, though not everything will be used in every project.

There are really two ways to reuse your code. One is the "formal" and "correct" way, where you pull all those bits you want to reuse into a library of their own and just import that when you want to reuse it. The other is what I have heard somebody call "code salvaging" instead of code reuse, where you just rip source files or even just individual chunks of code out of an old project and drop it into a new one. To be honest, I recently use the latter, "dirty" method much more often than the first one; it feels much simpler, there's less overhead, and you don't have to try and accommodate every imaginable future situation in your code right now.

This last point is also the reason I wouldn't recommend specifically planning ahead with respect to reuse in a later project. Sure, try to keep unnecessary dependencies to a minimum (so if your vector class includes some game-specific code, there's probably something wrong), but apart from that, I'd recommend sticking to the YAGNI principle: You Ain't Gonna Need It. Don't try to make your code so general that it can handle everything and the kitchen sink if it's not required for your current project; if new needs arise, you can always refactor, and the actual use cases probably look different than the "general" case you envisioned earlier anyway. That's one of the big lessons I learned about programming the hard way, namely by experience.
Logged
Wilson Saunders
Level 5
*****


Nobody suspects the hamster


View Profile WWW
« Reply #2 on: July 31, 2008, 04:39:36 PM »

I try my best to follow good OOD principles for the code reuse benefits down the line. Every project I make these days has the same Point class. This object just contains an x, y, and z values. However I have written a lot of member functions into this class that do my 3d math. On a higher level I also have a 2d tile map class that I have reused on a few occasions. I also keep a starting template project lying around from which I make a copy to start a new game. I find having a working base from which to add stuff to makes life easier than starting from a blank slate. Also with the complexity of windows initiation, having some code I know works is a great comfort when debugging. You don't want to worry about you timed update function getting called regularly when you are trying to implement AI.

In summery: Encapsulate your code into small independent chunks. It may take longer to add the proper header and footer code than it would if you just slopped everything in one file. However you will thank yourself later when you can reuse that code without stripping out the app specific bits.
Logged

Play my games at http://monkeydev.com/
moi
Level 10
*****


DILF SANTA


View Profile WWW
« Reply #3 on: July 31, 2008, 05:28:25 PM »

Of course why would someone NOT reuse code?

Anyway here is how I do it : I generally make two files (or more depending on the language).
Traditionally one of the source files is the "engine" and deals with everything low level (sometimes there are separate source files for really low level stuff) and with all the general case code. There must be nothing specific to the game being develloped in this source.
If I'm coding in oop, then I define a bunch of reusable OOP classes there (for example: sprite, point, enemy, timer,scrollmap,etc...)

the other source file is the "interface" , it's a bunch of functions that are called by the "engine" code, and in these functions I define everything that is specific to the game being develloped (object spawning, objects ticks, timer code, screen dressing, etc...).
I can also use an additional data file when necessary (for example XML).
The goal is to separate general case from what is specific to one game.
So the second source is different for every game while the first one evolves very slowly.
And when I start a new project, I just need to edit the second source file (which becomes very easy as the engine becomes more solid with time)
Capishe?
« Last Edit: July 31, 2008, 05:36:06 PM by moi » Logged

subsystems   subsystems   subsystems
ravuya
Level 7
**


Yip yip yip yip yip


View Profile WWW
« Reply #4 on: July 31, 2008, 06:45:00 PM »

I have a pretty thick codebase that I've built up by pulling chunks off of previous games, refactoring them a bit and standardizing them. It needs a few more steps of polish, but it's not bad. The important point here is that I build the library after I write the game. Developing for re-use in the first place is a good way to make your scope insane.

I've used the same basecode on my last four games.
Logged

Ryan
Level 1
*



View Profile
« Reply #5 on: July 31, 2008, 07:34:09 PM »

I basically just make prototypes and things, not full games, so I sort of picked an API I liked and then implemented it using SDL and OpenGL. I like the way BlitzMax handles things, so i have a Graphics() function, KeyHit(), LoadImage(), etc, etc. I even have the main() function defined in my Bmax API source file so I just have to do things like this:

Code:
#include <MyLibrary.h>

void Main()
{
    AppTitle("Wee!");
    Graphics(640, 480);

    while (!KeyHit(KEY_ESCAPE))
    {
        /* stuff here */
        Cls();
        Flip();
    }
}
(No int main(int argc, char *argv[]) stuff).

The source file is somewhat large because it has everything not related to game-specific code within. If you prefer a more modular approach, I've done something like this in the past too:

Code:
Namespace: Input
  Classes:
  - Keyboard
  - GamePad
  - Mouse

Namespace: Display
  Classes:
  - Display
  - Primitive [ utils for drawing circles, lines, rectangles, triangles, etc in GL ]

Namespace: Resources
  Classes:
  - Texture (png, bmp, jpeg)
  - Sound (wav)
  - Music (mp3)

Namespace Math.h
  Classes:
  - Vector2
  - Vector3
  - Matrix... and so on.

Er... yeah. So basically the idea is to separate anything that is not your-current-game-specific, and just reuse that whenever you try out something new. That was a long winded post for pretty simple and obvious advice. Sorry.
Beer!

Logged
ColossusEntertainment
Level 1
*

Royal Leamington Spa, UK


View Profile
« Reply #6 on: August 01, 2008, 12:50:15 AM »

code reuse == overrated

The supporting stuff like drawing, input, sound etc are of course good to reuse when you can, but beyond that, it's more programmers indulgence and attempts to avoid the real work  Wink
Logged
muku
Level 10
*****


View Profile
« Reply #7 on: August 01, 2008, 02:03:38 AM »

it's more programmers indulgence and attempts to avoid the real work  Wink

I don't really get what you're saying. So you think rewriting the same code over and over for every game is a good use of my time? And if I don't do it I'm lazy? Shocked
Logged
goshki
Level 4
****



View Profile WWW
« Reply #8 on: August 01, 2008, 02:17:46 AM »

it's more programmers indulgence and attempts to avoid the real work  Wink

I don't really get what you're saying. So you think rewriting the same code over and over for every game is a good use of my time? And if I don't do it I'm lazy? Shocked

Oh, c'mon... there's a wink at the end of muku'sMattias' sentence. MukuMattias, you wouldn't mean it for real, would you? Smiley
« Last Edit: August 01, 2008, 03:57:04 AM by goshki » Logged

ColossusEntertainment
Level 1
*

Royal Leamington Spa, UK


View Profile
« Reply #9 on: August 01, 2008, 02:24:53 AM »

The thing is, apart from the basic stuff (drawing, input, sound), there's not much that should be reused between different games.

Sure you might be writing similar stuff, but not identical. And if you reuse game code, you're likely to end up with the same game, more or less.

My point though, is that it is much easier to bury yourself in the "engine" side of things, polishing your framework and making your code flexible enough to be reused, than it is to tackle the real problem: making a fun game.

What we need to realize, I think, is that we are game creators, not programmers. And most of the tools in the programmers toolbox are not useful for the game creator.

You can't engineer fun  Tongue
Logged
muku
Level 10
*****


View Profile
« Reply #10 on: August 01, 2008, 02:39:17 AM »

Sure you might be writing similar stuff, but not identical.
That's why I advocated the "salvaging" kind of code reuse in my first post: rip stuff out and adapt it to fit into the new project. That doesn't mean that you have to rewrite it from scratch.

Quote
My point though, is that it is much easier to bury yourself in the "engine" side of things, polishing your framework and making your code flexible enough to be reused, than it is to tackle the real problem: making a fun game.
Looking at it that way, we seem to have the same opinion: I warned against over-generalization too.

Quote
What we need to realize, I think, is that we are game creators, not programmers. And most of the tools in the programmers toolbox are not useful for the game creator.
I'll respectfully disagree here, but that's another discussion entirely.
Logged
_Tommo_
Level 8
***


frn frn frn


View Profile WWW
« Reply #11 on: August 01, 2008, 02:46:15 AM »

Well, I started creating a common framework, before starting to make actual games... while some decisions in it have been proven wrong by experience, I can say that it was surely worth it...
Now i have all the codebase ready, so i can get a game running with 3d graphics, shaders, physics, 3d audio and other things in no time!

IMHO writing the base code IS the real work: all the game code should be the more possibile simple and separated from technical topics: in fact, all the "bigs", are more and more scripting their game logic in simpler languages... so to separate the "engineer" and the "game creator"  Wink
Logged

bateleur
Level 10
*****



View Profile
« Reply #12 on: August 01, 2008, 03:52:38 AM »

I have basically the opposite perspective to Mattias. When I'm writing a game, I don't even put most of the code in the game's namespace. I think about what I need to be able to do, write reusable libraries to do those things (properly modular, having no knowledge of the game logic at all) and then build the game from those parts with as little custom code as possible.

Of course, games still end up with massive amounts of non-reusable work required, but most of it ends up being data, not code. By which I mean art, level designs and that sort of thing.

The one big downside of this approach is that it's slow for your first project. You'll be two or three completed projects in before the benefits start to be worth it.
Logged

december
Level 1
*



View Profile
« Reply #13 on: August 01, 2008, 04:26:11 AM »

You can't engineer fun
are you saying my degree in fungineering is useless?
Logged

Signature:
Signatures are displayed at the bottom of each post or personal message. BBC code and smileys may be used in your signature.
moi
Level 10
*****


DILF SANTA


View Profile WWW
« Reply #14 on: August 01, 2008, 09:36:04 AM »

The thing is, apart from the basic stuff (drawing, input, sound), there's not much that should be reused between different games.

Sure you might be writing similar stuff, but not identical. And if you reuse game code, you're likely to end up with the same game, more or less.

My point though, is that it is much easier to bury yourself in the "engine" side of things, polishing your framework and making your code flexible enough to be reused, than it is to tackle the real problem: making a fun game.

What we need to realize, I think, is that we are game creators, not programmers. And most of the tools in the programmers toolbox are not useful for the game creator.

You can't engineer fun  Tongue
Yeah you end up coding very similar looking game, but you become much more productive and it's the only way to release well polished games.
If you have to redo the engine for every game you end up with artsy games with two colours or something.

All the big game companies reuse their codebase and it's been like that for ages (end of the 70s).
That's why for example, SEGA released so many fake-3D games in the late 80s (outrun, hang-on, power drift, etc... all were based on the "space harrier" engine).
Then they created the virtua cop engine and went on to release more games like this (house of the dead, etc...).
Same for Capcom and SNK with their platformer and fighting games engines.

But having a codebase doesn't restrict you to doing always the same thing. Actually having a solid base to build upon is IMO one of the best ways to create innovation.
Logged

subsystems   subsystems   subsystems
ColossusEntertainment
Level 1
*

Royal Leamington Spa, UK


View Profile
« Reply #15 on: August 01, 2008, 10:28:45 AM »

I have basically the opposite perspective to Mattias. When I'm writing a game, I don't even put most of the code in the game's namespace. I think about what I need to be able to do, write reusable libraries to do those things (properly modular, having no knowledge of the game logic at all) and then build the game from those parts with as little custom code as possible.

The one big downside of this approach is that it's slow for your first project. You'll be two or three completed projects in before the benefits start to be worth it.

Interestingly, I used to hold the same opinion many years ago, before completing a lot of titles (but I had been tinkering with games for a long time even back then).

Now, don't take this the wrong way, I'm not trying to knock you, I'm honestly interested:
How many titles have you finished using this method/philosophy of yours? It's true that it takes longer, for sure, but I think it even makes it unlikely that you ever finish anything at all (for most people).
Logged
moi
Level 10
*****


DILF SANTA


View Profile WWW
« Reply #16 on: August 01, 2008, 10:41:40 AM »

I was not the one asked, but using this method I have finished several engines and about a dozen games, although most of them weren't released publicly.
Now let's not turn this into a pissing contest, this isn't indiegamer.com.
Logged

subsystems   subsystems   subsystems
Alevice
Level 10
*****



View Profile WWW
« Reply #17 on: August 01, 2008, 11:02:01 AM »

On large scale projects, engines are a blessing, and not necesarily lead to a similar game (although it'd still be within the similar genre). Evidence: HL2/GMod/Portal and Homeworld/DawnOfWar
Logged

synapse
Level 1
*



View Profile
« Reply #18 on: August 01, 2008, 11:12:51 AM »

There's no reason that code reuse would lead to a similar game.  In my experience, game-specific code takes up less than half of the overall codebase, and common infrastructural stuff is the majority.  The only reason I've rewritten a lot of stuff over the past several years is that I've improved significantly as a programmer, and I'm finally starting to build things that are genuinely modular.

Specificially, I've been using the observer pattern a whole lot lately.  For anyone who doesn't know what it is, it's just the formal name for creating observer interfaces so that dependencies on a particular class don't have to be known ahead of time.  For example, I have a Scheduler class that manages the updates for large numbers of objects by spreading out big updates over several seconds, rather than updating all the objects a little bit every frame.  This is totally necessary for my current project, which simulates thousands of buildings, planets, and corporations at a time.  But there's nothing game-specific about this functionality, and I'm using the exact same code for all the different types of entities.  So I just create a listener class I_SchedulerListener, and any entity that must be managed in such a way is derived from this.  It's then added to a Scheduler, and it's ready to go.

I'm definitely finding that the more I develop, the more modules I'm finding to be very general.
Logged
ColossusEntertainment
Level 1
*

Royal Leamington Spa, UK


View Profile
« Reply #19 on: August 01, 2008, 12:09:25 PM »

Now let's not turn this into a pissing contest

Wasn't my intention  Wink

But from my own experience, I struggled to finish things when focusing on making reuseable code, and what I did come close to finish wasn't any good. When I started writing very game specific code, it got easier, and got better.
Logged
Pages: [1] 2 3
Print
Jump to:  

Theme orange-lt created by panic