So i'm currently working on a level editor for a game, and in order to do it i need to share the superficial contents of each class between two programs (game and editor)
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
Sharing classes between game and tools
Core game engine project outputs a library and contains all source/header files in a very shallow tree of sub-folders (I never go more than one below the main directory, so “Src\Vector\LSMVector3.h” is valid but “Src\Vector\Vector3\LSMVector3.h” is not.
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.
L. Spiro
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.
L. Spiro
Sharing classes between game and tools (and other projects) is a great idea. A lot of the code you need for a game will be usable in tools and lots of other projects. If you try and structure your libraries into modules of similar code this makes things nice and easy for you to pick and choose which libraries to include in your tools.
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.
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.
Author
I just realised, i should have clarified this, but i mainly want to share subclasse, for entity types, for example, say i have a tree base class, then several sub-classes, each with different textures and bounding boxes, not information classes, such as 2d/3d vectors
so basically i need to share the entity types between two programs
so basically i need to share the entity types between two programs
In many cases, rather than being independent programs sharing "the superficial contents of each class" (i.e. as little as possible), game and editor use the exact same game engine and share as much as possible to improve consistency and avoid code duplication.
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.
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.
Author
thats what i thought might work also, simply have ifdef's causing the program to compile differently for editor/game, though it sounded like it could get messy really quickly
Hi!
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 ;)
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 ;)
I would suggest, that if possible, you build the editor into the same binary as the game itself.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
