Unreal Engine as a Service for Developers
If we were to run Unreal Engine as a service on developer machines (workstations) it would allow us to focus on specific tasks rather than have to deal with the inconsistencies of the unreal editor interface.
OS integration
Unreal Engine already running similar to a virtual machine as like Java would allow many possibilities and enhance workflow.
Tabbed browsing in Sub-Editor windows
It is my experience that Unreal Editor suffers from the “too many windows syndrome”. While people who work with the editor might commonly have more than a single monitor, screen space is a commodity in this industry.
Not only is productivity an issue but so is the time factor for poor navigation method through windows and sub-editors. The goal here is to enhance workflow so that what people really want to use is right there with minimal “digging” around required.
IDE access to the Service
The ability to compile whilst the editor is open is a much sought out feature for many, having Unreal Engine running as a service opens up more possibilities than this simple ability.
There is so much to be gained from this simple idea, it all came from seeing the main window get continuously stuck on the bottom and the other windows getting stuck inside it even on multiple monitors. Not only that but with the discussion of multiple IDE’s being developed for Unreal Script and what they can provide over Visual Studio sparked my thought on the topic.
Materials as Sub-Expressions
The idea here is to allow people to use materials within materials so tasks like creating custom lighting modes or shading techniques across a whole project is easier.
The sub-expressions would mirror normal materials and exposed options could be set within the material allowing connections to only nodes that allow it.
I realize the magnitude of this task in terms of a redesign and that people might be partial to the old methods because they have just learnt it or it’s what they know. Looking towards the future I only see good things for Unreal Engine and I would like to be part of that future.
There’s a lot more that could be done with this and this is just the tip of the iceberg, a couple that quickly come to mind is closer integration with the Swarm sub-system. Since Unreal Engine would be run as a service this turns each client running the service into a potential render node. Or the ability to run command line scripts through the service much as you can type into the command line box in the lower left of Unreal Editor.
Thank you to everyone who has helped me over these years, to the guys on #unrealscript irc, to all of you here on the forums and most importantly Epic Games.
If we were to run Unreal Engine as a service on developer machines (workstations) it would allow us to focus on specific tasks rather than have to deal with the inconsistencies of the unreal editor interface.
OS integration
Unreal Engine already running similar to a virtual machine as like Java would allow many possibilities and enhance workflow.
An example is that someone who boots the editor now, just to work with the content browser, has to deal with the main editor window for no reason. This must waste resources when it’s sitting underneath many other sub-editor windows.
If this were implemented there could be a toolbar and the popup on the taskbar item for opening each of the sub-system’s editors, of which, the level editor window would become one, like kismet and generic browser.
It would also function better with the taskbar in the OS because each sub-editor's window could be stacked on top rather than being hidden from the taskbar inside of the main editor window.Tabbed browsing in Sub-Editor windows
It is my experience that Unreal Editor suffers from the “too many windows syndrome”. While people who work with the editor might commonly have more than a single monitor, screen space is a commodity in this industry.
As an example, not only could we save on the cost of multiple monitor setups if they aren’t required, we can also save screen space which means people can be more productive on the space we’ve saved.
This could also save resources because we can deactivate rendering in tabs that aren’t visible currently, such as multiple static meshes being open at once in the associated sub-editor.
The recommendation is that each sub-editor automatically supports tabbing with the ability to drag tabs out to windows if required. This way, materials would always be stacked under the material editor window, static meshes under the static mesh viewer window and so on.Not only is productivity an issue but so is the time factor for poor navigation method through windows and sub-editors. The goal here is to enhance workflow so that what people really want to use is right there with minimal “digging” around required.
IDE access to the Service
The ability to compile whilst the editor is open is a much sought out feature for many, having Unreal Engine running as a service opens up more possibilities than this simple ability.
If the packages are cached for the service and the service can unlink them for compilation, then an IDE can be run alongside the Unreal Editor. Caching of materials and the content browser could be done at intervals rather than on boot.
IDE’s with access to the service could use the package cache for auto-completion not only of keywords, modifiers, enumerators and the like but also for assets in package groups. This would greatly enhance efficiency by allowing people to link to their assets from within Unreal Script.
The ability to compile while the service is available only compounds the benefits to this solution, allowing people to work with both the art pipeline and programming pipelines alongside each other almost un-interrupted. Unlike the current system which you have to open the editor, check the asset path, put it into your Unreal Script, remember to close the editor and then recompile.
There is so much to be gained from this simple idea, it all came from seeing the main window get continuously stuck on the bottom and the other windows getting stuck inside it even on multiple monitors. Not only that but with the discussion of multiple IDE’s being developed for Unreal Script and what they can provide over Visual Studio sparked my thought on the topic.
Materials as Sub-Expressions
The idea here is to allow people to use materials within materials so tasks like creating custom lighting modes or shading techniques across a whole project is easier.
Any changes to the Sub-Material would cascade through all materials using this so global changes to lighting would be much quicker.
The sub-expressions would mirror normal materials and exposed options could be set within the material allowing connections to only nodes that allow it.
A benefit to this would be something similar to the already implemented Material Instances if you pull in a material and only modify acouple of nodes with exposed nodes defaulting to preset values.
Output nodes for channels like diffuse could be labelled as such and modified before being plugged into the channel of the super-material.
I realize the magnitude of this task in terms of a redesign and that people might be partial to the old methods because they have just learnt it or it’s what they know. Looking towards the future I only see good things for Unreal Engine and I would like to be part of that future.
There’s a lot more that could be done with this and this is just the tip of the iceberg, a couple that quickly come to mind is closer integration with the Swarm sub-system. Since Unreal Engine would be run as a service this turns each client running the service into a potential render node. Or the ability to run command line scripts through the service much as you can type into the command line box in the lower left of Unreal Editor.
Thank you to everyone who has helped me over these years, to the guys on #unrealscript irc, to all of you here on the forums and most importantly Epic Games.
the game, the compiler and the editor will all boot multitudes quicker, not that its slow (it can be at times) but itd certainly be worth the extra resources in the long term.
Comment