Handling multiple applications with the same code.

[reepblue]

I was poking around in the engine headers and noticed that headers for the Hub (Client) and Editor are in the include folder with the rest of the engine. It got me thinking if there was a better way of handling multiple applications within the same project. 

For Cyclone, I use premake to build everything and have it set up like Source. Every product has it's own folder minus the public folder which has shared headers and code.

This works in the Cyclone repo, as only the game links with Leadwerks, and I use UAK for the action mapper application since I needed a Win32 binary.  The rest rely on the standard library and WinAPI. However, when I translated this workflow to with Ultra Engine in-mind, everything was going great until Ultra Engine was introduced. 

It became hard to decipher what was using the engine library and what wasn't. I also wanted to create functions and classes that can be used by multiple applications without it being hpp files and preprocessor locks to prevent code from compiling if it's ever built by a non-Ultra application. There's now a lot more of redundant code with my core library and the engine having the same quality of life methods as the engine, plus I no longer need to build ZipLib as the engine has it already.

The only thing I would need to merge is my input library to be compatible with the Engine's enum values. but that should be really easy to do. Plus, the code will be more C++ friendly as it'll not be a dynamic library, 

What I'm asking is if there's a good workflow (Such has how the Hub and Editor co-exist) to have multiple applications share one Ultra Engine Project. I don't want to have multiple projects to keep up to date, nor I want to copy and paste code across. 

I know I could just copy the Visual Studio project but that's a pain in the butt and my root directory will just be filled with IDE Projects. Maybe we should go back to dedicated Projects directories like how we had it in Leadwerks? 

[reepblue]

Ok, this is what I came up with fitting the existing mold. 

I created a new directory called "Premake" in the Project root's folder. This holds Premake and the lua scripts for each project. While each script is literally the same thing minus the name of the code project due to limitations, I guess it's good if you want to add custom defines to one project. 

Premake builds the Visual Studio projects and solution under "Projects" like Leadwerks had it set up. I didn't divide project types by platform as that would take more code and I don't think it's necessary. The build objects and the hidden .vs folder will also be created under the Projects directory making it really easy to omit when committing to git and svn repositories. 

All source code will still remain under "Source". I'm still thinking about how to arrange shared files and project specific ones. Right now, I have it so files like the cpp needed for the precompiled header and the needed for macOS under the root directory and each separate project will have its own private folder.

I didn't battle test this yet, but it looks promising so far.  

[Josh]

I also use Ultra App Kit for simple programs that don't need 3D.

[Josh]

Another thing you can do is just make a program act different based on command line params. I think I am going to make the editor call launch its own executable to generate thumbnail images. This saves me from having to include two large EXEs.

[reepblue]

8 hours ago, Josh said:

I also use Ultra App Kit for simple programs that don't need 3D.

While this will cut compile times down, it'll go against the idea of the applications using the same cpp files. UAK changed some functions and has several old bugs that have been fixed in the engine. I'm also sure UAK will not load the most recent plugins. 

8 hours ago, Josh said:

Another thing you can do is just make a program act different based on command line params. I think I am going to make the editor call launch its own executable to generate thumbnail images. This saves me from having to include two large EXEs.

Thought of that, but I can see it becoming a mess if you wish to build more than a few applications. I also have a remote console that sends commands to the game application with enet and I'd like that to be its own application. 

I guess what I can do is make any tool that is just a simple main.cpp (Like an image converter) a default Ultra Project. Anything that has to interact or needs to reference a system (Like the input system) will be code shared in the game project made with premake. I can probably get away with the action mapper application being the same application as the game, but the remote console needs to be a standalone application. I'll just put it in the engine's "Tools" folder instead of my game's folder. 

My input library will just be merged into the game code using the engine's polling for input. For sound, I might not continue using FMOD unless I can get events and raw sounds to play correctly together without calling OpenAL. Although having a daw interface for games was really nice, the sound implementation is much better in Ultra so I don't think I need a replacement. Also, the less decencies, the better.