Jump to content
  • Advertisement
Sign in to follow this  
T4ng10r

Build with specified features

This topic is 1410 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

Let's assume that I have big project with lots of components (GUI with Multimap, Widgets, etc, Data  with loading, texture mangers, etc).
Now I want to create SECOND build - ie demo - with only part of functionality (GUI without minimap, data with fixed textures, etc). I could easily achieve that with preprocessor defines, but it will be ugly. Still achievable.

Ok, now something difficult. My boss tell me to create build to create GameEditor. Again - I could place multiple defines to separate functionality/features specific for each of those 3 build configuration. But it will populate code with more trash/gibberish.

How can I create make system to generate build based of some kind of features lists to contain in given build.

Other solution is to make special care to separate features so one FILE/CLASS would contain only one feature (possible but not so easy to achieve). Then in some file I could place list of files or feature tag, so make during file gathering would take only files matching features ID.

 

Share this post


Link to post
Share on other sites
Advertisement
Several build system generators (like for example CMake) should be up to the job but introducing them retroactively will probably be an uphill battle. Edited by BitMaster

Share this post


Link to post
Share on other sites
If your modularize your code then your #ifdefs will be much fewer and rarer.

For instance, in my home project, I can do this:

void initialize() {
  CreateService<IGraphics, GLGraphics>();
  CreateService<IAudio, ALAudio>();
  CreateService<IInput, SDLInput>();

#if !defined(NDEBUG)
  CreateService<IDebug, AntTweakBarDebug>();
  CreateService<IProfiler, TelemetryProfiler>();
#endif
}
And that's it. The linker will deal with stripping out the unused service implementations. No other code has to change. It's just these few lines in the app initialization code that have to be removed.

Share this post


Link to post
Share on other sites

@SeanMiddleditch - this will work quite well for selection of bigger components.

What about application with different versions? I mean trial (with blocked most of higher functionality), common, professional or ultimate versions? And we're not talking about simple code/serial unlock, but separate version for each. Yes, with proper architecture design I could hide those specific behaviors behind interface and use plugin approach. Situation became more complicated where in one file/class few functionalities crosses

You have - for example - only one file reading format, only one net protocol, only one configuration, etc. I would like to have situation where I can create build (with help of CI/Jenkins) which will always create all possible versions.

@BitMaster - building engine/tool isn't a problem. It doesn't matter if I use make/CMake or whatever else. Problem with selection files for different releases is the same. Do it manually, semi automatic or fully automatic.

Edited by T4ng10r

Share this post


Link to post
Share on other sites

Unfortunately, given how often the requirements for these "special" kinds of builds (public demo, trial version, alpha, beta, standard, expansion, editor, etc.) can be completely arbitrary and determined by the developer/publisher at later points in the project, if often does become a matter of sprinkling #ifdef's around the code (or runtime checks if appropriate) to disable/enable/tweak functionality. On the content side, it makes a lot of sense to have a filesystem that allows you to separate your data into multiple physical files, so you only need to distribute the right content for each build, and allow content from one package be able to "override" content from another package. This also allows you to easily patch content for bug fixes, expansions, DLC, whatever. On the code side, you can always try to plan ahead and split subsystems apart such that they can be turned on and off wholesale, but it's often not going to be enough if the game's functionality isn't fundamentally different for each build.

 

The editor build is usually more straightforward because it's often just the game with an additional editor interface on top, whether that be in-game or done as a separate application. However what you need to do in order to get this work, will depend on the specifics of your project.

Share this post


Link to post
Share on other sites

Yes. Even further - when during development I receive this kind of requirements I imagine whole lot of ifdef polluting my code.
Seperate approach would be to use strategy design pattern or separate functionality in files stored in folders with recognizable name  (demos, dlc, etc) which later on will be taken by build mechanism.

Share this post


Link to post
Share on other sites

It's typically not too bad. In my experience, most of the differences between builds boil down to data, or can otherwise be data-driven (which is where a robust asset and file management system comes in handy). Only in special cases where the developer absolutely needs/wants code excluded from the build are #ifdef's deployed.

Share this post


Link to post
Share on other sites

In my team we discussed few approaches.

Dynamically selected features - activated during run-time by configuration files or detected system values. Rejected - we can't allow our binary to grow for one of possible releases due to memory constraints (embedded system with low memory).

Statically selected features - by file locations (folder name) or if_defs. Second one - we want to avoid introducing ifdefs (in code we have almost none of them) because developers will easily overuse them. First approach is used right know and is candidate to be used further.

Is there ANY possible framework which uses marks or tags (i.e. @REL1/2/3/4 in files to select files (or part of file) for compile? I mean - some kind of extra pre-configuration step in buildchain which will provide list of files?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!