next »

[Ivan]

I think the best approach is to work on a game, but write the technical parts as a separate library, so that you're still working towards a certain concrete goal, but in the meantime build up your own API.

[Garthy]

My experiences in code reuse (and I've been doing software dev an awfully long time):

- It takes longer to engineer a general solution to a problem than a specific one. Choose which bits to generalise/reuse carefully. Don't generalise everything- you will regret it.
- A general solution lends itself better to testing as a component, and with test cases, will often be a much more stable component than a specific one. It'll take far longer to get to that stage though.
- Until you've worked on a similar problem before, you're not going to be able to tell which bits are worthwhile to generalise. You will often have to guess. You will often guess wrong. It will hurt.
- Smaller non-dependent components are much more useful when building up a new project than large monolithic generic constructions. The smaller one is more likely to fit the problem. The larger ones, less so, and they are so much more work.
- More than half of the general-purpose components you carefully engineer you will never use again. Half of the ones remaining you might use once or twice. Many of the rest will be useful, but nothing amazing. A small portion of the general-purpose components will be absolute God-sends in the future and you will be eternally thankful that you decided to make them, so much so that you won't care about the wasted time on other components.
- It is always worthwhile to build up a general library of general-purpose components. Whether you put one new thing into it a year or one a week, it is always worthwhile to have. You can then use it in your next project, small or large.
- If you develop a general component you plan to reuse, also develop some automated test cases to go with it. That way, when you tweak it, you can retest it in seconds, not hours. If you don't want to make the tests, check why you decided to generalise this particular component.
- You will throw away the first general-purpose engine or large component that you develop in any particular area. Your second attempt will be good. Don't start unless you're doing it for the learning experience or you have a lot of time- both of which are valid reasons, of course.

Please also note that I am focusing on code-reuse from the point of developing generalised components, not reusing code from an existing project in a new one. I'm not touching the latter case for now.

Do take this all with a grain of salt though. The best thing to do is to determine what works for you. Experimenting helps, and you can always change your mind later if you made the wrong guess.

[moi]

- Smaller non-dependent components are much more useful when building up a new project than large monolithic generic constructions. The smaller one is more likely to fit the problem. The larger ones, less so, and they are so much more work.
- More than half of the general-purpose components you carefully engineer you will never use again. Half of the ones remaining you might use once or twice. Many of the rest will be useful, but nothing amazing. A small portion of the general-purpose components will be absolute God-sends in the future and you will be eternally thankful that you decided to make them, so much so that you won't care about the wasted time on other components.

YES , this is the gist of code reuse.
For example I spent several weeks coding a general case enemy behaviour routine in my engine, trying to cope with all possibilities by adding variables.
Then a few months later I happily deleted everything, just calling a function for each enemy and using specific code when needed. Which sped up everything and removed tons of bug issues.
It made me waste time and ressources, but when I finally got rid of it, it made me happy because at least I knew where I was coming from.
My code wouldn't have been as good if I hadn't made the mistake in the first place.

[Garthy]

For example I spent several weeks coding a general case enemy behaviour routine in my engine, trying to cope with all possibilities by adding variables.

A tip if it helps- and I've been there with this one when developing the AI for the bad guys in E.V.E. Paradox: Arena (Robotron-like game). I created a generic set of AIs with certain responses and parameters, all written in C++ in a switch statement. For each creature, I specify which to use, and parameters for each. Many creatures share the same AI code, but with different parameters. Each boss had its own custom AI code and value that only it used.

This gives you the flexibility to give every creature its own personal AI whilst having the power to directly code any needed custom behaviour, plus the nice end result of seemingly entirely customised behaviour for each, even though you've only written a small handful of AI behaviours.

It's a compromise between the master general one-size-fits-all behaviour, and the work required to write them all individually.

[muku]

A tip if it helps- and I've been there with this one when developing the AI for the bad guys in E.V.E. Paradox: Arena (Robotron-like game). I created a generic set of AIs with certain responses and parameters, all written in C++ in a switch statement.

Hm, a switch statement doesn't seem very idiomatic for C++. What were the reasons you decided against a polymorphic design with an abstract AIBehavior class from which specific behaviors were derived?

[Garthy]

Hm, a switch statement doesn't seem very idiomatic for C++. What were the reasons you decided against a polymorphic design with an abstract AIBehavior class from which specific behaviors were derived?

Heh heh, I was waiting for a comment on the switch statement.

In answer: A desire to use the tools, rather than let the tools use me. It simply suited the surrounding code better, and was a more elegant solution in that particular context. There would no doubt be a situation where a more OO-style approach would have been warranted.

[moi]

For example I spent several weeks coding a general case enemy behaviour routine in my engine, trying to cope with all possibilities by adding variables.

A tip if it helps- and I've been there with this one when developing the AI for the bad guys in E.V.E. Paradox: Arena (Robotron-like game). I created a generic set of AIs with certain responses and parameters, all written in C++ in a switch statement. For each creature, I specify which to use, and parameters for each. Many creatures share the same AI code, but with different parameters. Each boss had its own custom AI code and value that only it used.

This gives you the flexibility to give every creature its own personal AI whilst having the power to directly code any needed custom behaviour, plus the nice end result of seemingly entirely customised behaviour for each, even though you've only written a small handful of AI behaviours.

It's a compromise between the master general one-size-fits-all behaviour, and the work required to write them all individually.

Actually I did something very similar. I check a variable in my nme class to see which case applies in a switch statement. The negative values are basic general cases and when needed I apply a positive value for customized management.

[bateleur]

How many titles have you finished using this method/philosophy of yours?

I could say 14, but whilst true, that would be very misleading.

The fairer answer would be two (!).

The reason for both figures is that I've changed platforms a lot over the past ten years and of course every time I change platform the opportunity for code reuse drops dramatically. I still miss the days of the Amiga where everyone has identical machines and platform wasn't the nightmare question it later became.

[Michelle Disraeli]

You can't engineer fun 

As an engineer, I must respectfully disagree The core idea that is to become fun might not be something one can determine via engineering. However, I have seen far too many games in need of a little (or a lot of) engineering on their fun

As for the thread itself - don't stress about it! Mattias Gustavsson is right when he says that it is all to possible to get caught up in the complexities of reuseable code, and end up not getting onto the code that actually makes the program do what it was intended to do. If something obviously is going to be needed again, roll it out to a library. Otherwise, salvage away, and if you find you actually need to salvage the same thing again and again, put it in a library.

As for switch statements for AI states, were the behaviour is known to be fixed and generic, they work quite nicely Although I am actually sold on the idea of behaviour classes now, even if the coupling needed for this to work in complex AI systems scares me...

*goes back to lurking*

[ஒழுக்கின்மை (Paul Eres)]

I'm not sure if the Game Maker Language counts as a real language (although it probably does, it's just interpreted & slow), but I rarely reuse code between different games for that engine. I'd say 5% at most, usually basic functions like "create a random color" or "wrap text in a box word by word as it scrolls in" and such.

[muku]

I'm not sure if the Game Maker Language counts as a real language (although it probably does, it's just interpreted & slow), but I rarely reuse code between different games for that engine. I'd say 5% at most, usually basic functions like "create a random color" or "wrap text in a box word by word as it scrolls in" and such.

I guess that's because Game Maker, by design, already provides a lot of the nuts and bolts you would otherwise want to reuse.

[Carnivac]

I guess that's because Game Maker, by design, already provides a lot of the nuts and bolts you would otherwise want to reuse.

Not as much as you might think which is why I certainly reuse large amounts of code.  I've gotten that way about my game making where I simply just make scripts that are easily copied and pasted to new projects to save me having to do the same thing over again.  All three games I'm working actually use the same core engine I made even though one of them is a top down shooter and the other two platformers (well, one of those isn't really a platformer since you fly rather than jump but still).

[Tobasco Panda]

You can't engineer fun

are you saying my degree in fungineering is useless?

Only if there are italian plumbers in the area.

AHEM. As far as reusing code.... anything tool chain related can and should be salvaged, assuming it isn't completely bunk-tacular to begin with. So if you made a custom level editor for example, definitely keep that and the code allowing your game to import and use those assets. Same usually goes for your rendering functions, though if you are switching to a different platform or visual engine (openGl, java, NDS or other console) you will likely only be able to reuse your framework.

As tempting as it may be, most people I've talked to prefer to ditch large amounts of their player code from one project to the next, as you usually think of better ways you could have done something later on down the road.

Fun, like food, is both a Science and an Art.

[Don Andy]

You can't engineer fun

are you saying my degree in fungineering is useless?

Fungineering Thundartainment

I think this is the secret formula for the best game ever.

[Will Vale]

Don't forget that pretty much everyone who *claims* not to reuse code is actually reusing lots of code via third party libraries, the operating system, and so on. Like the GameMaker/MMF example, if you use SDL or OpenGL or Direct3D that's a large chunk of the system code you would otherwise need to write.

Code-reuse can also be a good bootstrap for new projects - start with a working system, hack in the rough shape of your new game, and gradually replace the bits that don't fit so well with new code. You can get going much faster that way than starting with a blank slate each time.

This is especially important if you have a larger team with artists and designers as well as coders - as pointed out before, you need to re-use your toolchain as much as possible, so that artists can get creating content without waiting for programmers to recreate the engine from scratch on each title.

And finally, if you're doing a console title you won't want to write the TRC hotspot code more than once. Stuff like saving and loading games, profile management, and net play is incredibly hard to get right - witness the number of indie developers having a tough time in cert on their first title. Re-use here is going to save lots of pain and tears.

Will

[TheMeatyBall]

But if you put it that way, isn't ALL programming code reuse? Except actual machine language.

[Will Vale]

Exactly the point I wanted to make - yes. There's no escaping code reuse. Even machine language is building on top of all the code in the microarchitecture.

In general, the less code you have to reinvent (DRY FTW) the better because you can put more time into your new code, right? Provided that you don't get trapped into doing too much up-front design for reuse (maybe YAGNI) and you don't paint yourself into a corner design-wise because your engine code shapes your game.

[TheMeatyBall]

Yeah, good point.

[Kekskiller]

I'm reusing all the theroretical, write-it-once-and-touch-it-later-if-needed code like MuFu-parsers, color type templates, geometry data and so on. If I need more functionality for some components, I'm rewriting it. Rewriting can improve your code much more than writing new every of shit. You should care about the design of reusable code - a good design can be used over and over again with some minor modifications.

Templates and class derivation are cool features for reusable code. I love the fact that all my ressource handling can be done by an OOP/template-heavy code I just need to declare with another object/data type. Yay!

[synapse]

Templates and class derivation are cool features for reusable code.

Honestly, I've found class hierarchy-based stuff to be incredibly inflexible for code reuse.  Most of my code reuse success is based off of extensive use of interfaces (to borrow from Java terminology).  In C++, this is a sort of variation on inheritance.  If that's what you mean, then I agree.  To anyone familiar with OOP but not with this lingo - interfaces are basically class inheritance with function declarations but with out any derived implementation.

Maybe this brings up a more interesting question then - what kind of coding style do you find most flexible for code reuse?