Would it be possible to compile the Unreal Engine into linkable libraries instead of an executable? I know the Unreal Way is to develop any other features of your game as plugins to the Unreal Engine, but what I’m thinking about is the opposite, Unreal Engine would be a plugin to my game.
The reason I am asking is because my team has invested quite some time and work in building a game, most work being in game logic and subsystems. We’ve also invested some time in the 3d engine but we are at a point that we realize that the Unreal Engine graphics engine + content pipeline + animation systems etc can’t be beat.
Unfortunately our codebase/build system isn’t compatible with the UE4 one as it is. So if we’re going to be using UE4 for its graphics engine, there’s two options:
Invest a lot of time in porting all of our code to Unreal style C++ and use its build system and launcher. We anticipate this will be a lot of work and possibly a bit demotivating.
Somehow compile Unreal Engine as a library. We would simply link against it, and call some wrapping functions for starting it, configuring its view port and other settings, and some functions to load game modes, spawn actors and such.
Is option 2 a possibility? Has anyone ever done it before? What’s in the way? I’ve done some googling and searching the forums but haven’t found anything, perhaps I’m using the wrong jargon.
I know there’s a bunch of ways to make option 1 more attractive and I don’t mind it if you’d make suggestions, but I’d love it if we could talk about option 2 because it seems to me that if it’s just some configuration it could be very useful to us.
Unless that was changed, you cannot use engine code/tools in your projects.
I remember a post where this came up when someone wnated to use one of the editors “in game”…
I read that thread, and I think they specifically meant the editors. The license does only cover the Unreal Engine runtime, which is what I need. My final product will still be a game that’s a single executable that runs the unreal engine, no different from any other game. It’s just that the build process would be different, perhaps only the final step, where my game is linked to a precompiled unreal engine.
Just a small update, I found out that the entry point of the game is in the Launch project. I think if I’m going to find a way to build this, it’s going to be useful for finding out how to bootstrap the engine. Also I found in the binaries folder a bunch of .lib files, including a 500mb engine.lib. Perhaps I can get away with just including the engine headers I need, and linking to some or all of those .lib files.
Maybe it was just worded wrong, but you don’t write your gamecode as plug-ins to the engine, plug-ins are another thing entirely. Option one is easily the most sensible method, by a long shot. Nobody has done Option 2 before, and if they have it’s certainly not documented because they either:
A) Went clinically insane during the process, or more likely:
B) Didn’t pull it off
You’re more likely to face de-motivation taking the second option, because you’ll be the first and only folks doing it, and you won’t get much help from those who made the tools because they’ll encourage you to take option 1 as well. There’s a lot to be said for using the tools the way they were intended to be made, and you’ll probably run into many more benefits along the way too!
EDIT: I would also be extremely surprised if this didn’t bring up legality issues.
EDIT #2: There’s also no reason why you can’t use the code you’ve written as it is, and write a wrapper or callbacks of some kind for Unreal. A few folks I work with are writing a lot of their code outside of the engine, and linking it in small engine classes. This allows them to run simulations on their code without having to worry about engine overhead for testing and debugging, among other things.
While technically feasible and from what I am reading in compliance with the EULA, I would strongly advise not going down that road as “there be dragons”. IMO the two sweet spots are you staying with your current tech or going with ours; we’ve never seen the hybrid approach work out in practice.
Thanks Daniel. We’ll be sure to explore other options first. I’d like to say that it sure would’ve been handy if there was a build configuration for compiling Unreal Engine into an easily embeddable dll, as Unreal certainly isn’t the only C++ project out there that tells its users that it’s easier to wrap other projects into their way of things than it is to embed it in something else.
It would be a shame if there’s many projects out there that can’t use the world’s most advanced graphics engine and content pipeline, only because it’s not possible to build it in a modular way.
Of course I understand you’re focusing on the 100% Unreal people first, just a little outside perspective
I’m looking for the same thing. A way to wrap the engine as a dll. We have an executable and our application does a whole host of things beyond just 3D. 3D is one part of our solution, and it would be nice if unreal just were loaded in our 3D window operating on a canvas. Otherwise, it seems we’d have to launch a separate EXE and communicate with it via pipes or sockets? Seems like a lot of extra work to come up with that protocol.
Also, looking for a more traditional api. I’ve downloaded the unreal engine, I think, and started a “project” but it’d be nice to get more low level than what a artist or designer would use.
Before I asked this questions we were working on a system to communicate with the Unreal project via pipes, it was going to work but felt really fragile and it had a very large amount of boilerplate.
You should check out the guides in the documentation and on the wiki’s. There’s lots of API available and you’ll get totally lost if you don’t, it’s nothing like a ‘normal’ C++ project.
“By staying with your current tech”, do you really mean “don’t use the Unreal engine” because it can’t definitively really work with our application? I work for a simulation company that develop his own software since years but is planning to update the technology toward his kernel. So if i I understand well, the simulation software have to be totally rewritten using the UE tech…No way to bind this latter to our .exe via some dll files for instance ?
I felt like looking into this again for a couple of evenings, which turned into a couple of days. I now have found out what is necessary for this to work. I think in a couple of days it’ll be good enough for me to start working on integrating UE4 into my existing game. In its current form it’s really hacky though. I’ve been modifying UnrealBuildTool and random build scripts and makefiles all over the place, as you said there were some dragons there. What I want to ask is: If I’d commit a bunch of evenings to add some features to UnrealBuildTool and fixing up the (mostly Third Party) build scripts the nice way, would Epic consider accepting that as a pull request? The feature would mainly be to enable a Target to be a Monolithic DynamicLinkLibrary (it would be a new TargetType). It has repercussions throughout the build scripts though not super severe ones and I think it would be backwards compatible except for that existing modules might not build in the new target type without some extra work.
If you think that really is not something Epic feels like spending any time whatsoever on (i.e. people might actually start using it and run into other problems, need documentation etc.) or is counter to your strategy, I will leave it in its hacky state in my own fork and don’t spend more time on it than is necessary for getting my game to work.
Cheers,
tldr; if I build a new TargetType for UBT, would EPIC accept the PR?
Alright, I just re-read the EULA. A DLL actually doesn’t seem to be allowed, the game needs to be statically linked to it, at least to the point that it can no longer be considered to be seperable from the product. I’ll rethink my approach to this.
@
I assume that your current engine is a separate application. Like most applications it should have typical stages like initialization, main loop and shutdown. UE also has these stages: they can be found in the Launch module. This could be a good place to insert your own code. In this way you could replace UE code with yours step-by-step without need to load whole engine as a DLL and (probably) without need to modify the build system. By the way, UBT is very flexible, I suggest exploring existing modules: I am sure you will find out how to setup your build process with it.
I’m in a similar position. The 3d game world is a small piece of my project. When I started, I envisioned potentially multiple instances (or viewports) which may (or may not) be shown at any point after program initialization. I was thinking of going with an open source base application with a commercial (closed source) plugin utilizing the engine. The idea was to encourage users to contribute to the base app freely with the income coming from plugins. I thought this model was compatible with the eula, am I misinterpreting this?
Do you know about what Blue-Hole Studios did? why was it a hybrid, did they port their existing game-engine to UE3?