Sharing classes between game and tools
Members - Reputation: 124
Posted 21 April 2012 - 07:36 AM
by superficial, i mean collision boxes, textures but not code
my thoughts would be have one main header file, which includes headers for each class, which contain the class, texture paths and bounding box paths/or data, then include the main header in each program
my main concern is being able to actually access said header from each project, i'm using visual studio ultimate and i want to know, is it possible to share a set of headers in a project, or perhaps choose a folder, and have the project automatically display everything in said folder, so i can change classes from either program?
thanks, any suggestions to improve this would be appreciated also
Crossbones+ - Reputation: 5187
Posted 21 April 2012 - 07:59 AM
Game project links to the output engine.lib and its Microsoft® Visual Studio® project settings has a header path set to the directory where the engine header files are. Game header and source files go to its own Src\ directory.
Outputs the game .exe.
Same organization applies to tools.
You need to be aware that when you say “game” in this thread, you are actually talking about the game engine, which is a separate entity. There is no reason tools need to know what “CAliceAI” is or what “CCreditsScreen” is. They need to know what vectors, matrices, 3D models, terrain, etc.
All of those generic classes belong in the engine. The game is where you define which terrain, models, and buildings to use. Tools are a way of defining which terrain, models, and buildings to use, but that doesn’t mean it needs to know how you coded the AI for the the raptor01 character (assuming you don’t have script support, you will be using C++ classes).
And yes you do mean code. You want to share a box. A box is more than a group of members. There is code in the .CPP file for bounding boxes around a given set of points. An AABB will have code in the .CPP to create another AABB that represents the original AABB transformed by a given matrix.
But your tools only have access to the .H files, where I will assume you did not also put the code, because I am sure you know better than to inline functions that don’t need to be inlined.
Hence libraries enter the picture.
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums
Members - Reputation: 383
Posted 21 April 2012 - 02:39 PM
For instance I have a common library full of things like 2d 3d geometry classes, debugging tools etc, file libraries full of file handling code for parsing, munging etc, memory manager libraries for overriding new and delete, libraries for a particular game level format, libraries for model handling code, networking, sound, etc etc. Essentially everything is a component that can be picked and chosen from. Everything is also encapsulated, no spaghetti code .. code within a common library for instance won't have a dependency on some game specific code.
When it comes to writing your tool, you can either just directly add the library project to your solution, or have a separate tools version of the project (referencing the same source files) with different build options.
Members - Reputation: 124
Posted 24 April 2012 - 10:37 PM
so basically i need to share the entity types between two programs
Members - Reputation: 1257
Posted 25 April 2012 - 03:26 AM
Sometimes they are the same program (an "edit mode" within the game); sometimes (in particularly data-oriented architectures) the game is a pruned and locked down variant of the editor that only runs the content it is given, sometimes the whole game is embedded inside the editor in order to try out changes.
Members - Reputation: 402
Posted 25 April 2012 - 12:47 PM
Code sharing between the "main" application and any tools related to it, such as an editor etc, is obviously good in many ways.
A few posetive effects is that changes affects all applications in the same manner and you know that if something works in either application will work in the rest of them as well.
About intergrating the actual game and editor in one application, I guess it depends on the nature of the application.
Maybe there is a reason for having the editor as astand alone application? Maybe you want to re-use it for another project?
One big thing about being able to swiftly switch between game and editor-mode is that level-designing should be much easier as you can do small changes and switch to see the effects then swtich back to keep working on the level, and so on.
If you think it will mess up your code or structure.. Well there is always a risk but with solid design of your project it shouldn't add to much to the complexity as the actual editor and game could be two separate parts of the application which you could then simply switch between.
Having said that, I went the same rout as it sounds like you are thinking about, having one game and one editor and I can say that I regret that choice looking back at it.
I think having the editor and main application within the same executionable would have made my life a bit easier atleast ;)
Members - Reputation: 1245
Posted 25 April 2012 - 02:35 PM
That solves all problems of trying to reuse code, makes complicated linking crap go away, and makes it as easy as possible.
For example, have the game check for a command-line option or environment variable, and if set, starts the editor instead of the game (bypassing menus and other game interface elements).
One binary - game and editor(s). Simple.
If you care about not shipping the editor, you can #ifdef the editor-mode out for release binaries.