What is the future of Slate?

We’ve been discussing Slate a lot recently in our studio. It seems completely code-driven rather than data-driven at this point, and while it makes some things easy, it makes other things more difficult. In particular, we’re looking at having a lot of animated elements to our front end and our HUD, and Slate seems to make that a bit more difficult than we’d like.

Additionally, we’d really like a graphical layout editor, especially for handling different HUD layouts at different screen resolutions, and we’ve been considering writing this ourselves.

Is there a plan to overhaul Slate at some point, or add Slate editors that would support that kind of functionality?

The plan is first to extend the Slate runtime such that it supports more robust rendering, richer cursor picking geometry, arbitrary visual transformations and more. Once the API-affecting changes have been made, we hope to build a visual editor for Slate content. The current expectation is that the code-driven Slate workflow would continue to be supported as it is by far the preferred approach in many usage scenarios.

Thanks, Nicholas. That’s very helpful.

I definitely think an editor for overall layout would be extremely useful – particularly, I’d love to get rid of the huge block of


and such that I have to put in my master HUD widget’s Construct().

I agree that code is preferable in terms of how I handle interactions with my UI, but I’d definitely prefer a visual editor for this kind of layout work.

I’ve heard the pitch a few times regarding Slate, stating that it was great because it was code driven. But, I think this is an area where it is great for the engineers who made the api, and not so great for anyone actually having to create HUDS and Menu’s. I was unaware that engineers were the users who generally made user interfaces.

As well, I was under the impression that for UI, data driven is much better. It’s an area that needs to get lots of changes and things getting moved around by someone with a real Artists eye. Needing to recompile the code for this seems kind of crazy honestly.

Was Slate ever tested to see if it met the needs of intended users?

It’s a big step back from scaleform. I understand there are problems with Scaleform, and Flash, but it’s a tool most UI guys know how to use allready.

WPF is probably a better example of a good UI system. It’s data driven, easy to bind elements to code, and has a great visual editor.

I have to agree on this. While after grasping how the declaring layout work, it’s that big of an issue (although it’s still issue because I have to recompile every time to see changes), the real issue for me is data.

I have done my deal of UIs. In WinForms, WPF (not that much), ASP .NET MVC (quite a bit) and tried some Qt4/5
Thing that all these frameworks have in common is easy way to bind and display data.
It’s usually easy in one direction (receive data to display), or in case of WPF two-way data binding (receiving and sending data between user and model).

Slate depends on delegates to receive and update data. I don’t know it might be easy. Severe lack of documentation, is really hurting, when it come to display more complex information that updating character health for example.

What I would welcome is more documentation effort focused on Slate. I’m pretty sure it’s not bad UI system, the issue is there is zero explanation on how to actually use it, and existing samples are just bunch of code without explanation why some decisions were made.

I would love documentation especially on topic of how to bind various types of data and display it.

I’ve recently thinking about implementing floating damage text, for my small sample game (damage text is attached to pawn that is actually taking damage). I honestly can’t even start planning it exactly because I don’t really understand, how Slate is handling data, and by extension I don’t really know where is optimal place to receive it from (as the system is quite complex it should take into account damage types, durations of damage currently affecting pawn).

As for designing UI. It would be really nice to hae some external languague to describe ui. XML, or something like QML from Qt.

I agree with you about all this, Lukasz, except

It would be really nice to hae some
external languague to describe ui.
XML, or something like QML from Qt.

Personally, I don’t see much of a point in external languages; those aren’t really significantly different from (or better than) the “domain-specific subset of C++ that can be used to readily express a UI declaration” currently used in Slate, as Nicholas puts it below.

I think what’s really needed is a good 2D layout editor to let you interactively specify positioning, margins, and so on, which shouldn’t be hard to do.

Most developers will have very art-heavy UIs, and Slate doesn’t currently handle this well at all.

Slate in its current form is not a replacement for Flash. It is a replacement for something like WPF when it comes to building the editor. Nobody is implying that it’s fun to lay out something art-heavy via code; that would be ludicrous! However, there are many scenarios (e.g. most of the unreal editor) where the view/controller logic dominates the workflow. For those scenarios it is very useful to have a domain-specific subset of C++ that can be used to readily express a UI declaration. The editor code certainly shies away from any hard-coded margins as in the example above. I’ve written code like that, and it wasn’t exactly pleasant.

We do feel that the Slate runtime is a solid foundation that is worth building up. There is more than one authoring use-case; we’ve got one covered and it isn’t going anywhere. The more art-heavy use-case is not well supported, but hopefully that will change.

Not to be a jerk and jump on the bandwagon here but the use-case that’s covered… Are you referring to the one involving coding it in C++ and macros? Or is there some other use-case that I’m not seeing?

I think the issue is that Scaleform isn’t hooked up to Rocket, so there are no GUI tools for gameplay.

Slate makes sense for Editor additions, but the Editor is a framework and the needs of adding features to it are very different than the needs of adding GUI features to a game.

Well said, Mike.

Looking at our own schedule, UI is the largest risk for us by far right now, simply because of Slate. There are too many things that we need to do that we just don’t know if we can do at all at this point. It may not be intended as a replacement for Flash, but the things Flash (or Scaleform) do are what we actually need from an integrated UI development system.

II think Slate is perfectly viable for use as in game GUI system. I have seen stranger things (at first glance), like WPF based in game gui.

On high level rendering GUI in game is no different than rendering editor GUI in modern systems. It’s all going trough GPU and it’s made of polygons.
Windows in Windows (pun intended), are made out of triangles, and re actually rendered by GPU.

The issue is, it is hardly explained how to use Slate as in game GUI system, and how it works in that context.
At this stage I really don’t need any fancing graphics. I just need to display and manipulate information in game.

I wonder if it would be possible to integrate something like Awesomium into rocket ? Probably yes, but it is beyond my skill set for now (;.

II think Slate is perfectly viable for use as in game GUI system.

It really depends on your GUI’s needs, doesn’t it? It can work for some GUIs, but please don’t think all game GUIs have the same needs. In our case, we’re building a strategy game with a very complex, art-heavy user interface, and it has much, much more demanding needs around UI than your typical shooter or platformer game.

The issue is, it is hardly explained
how to use Slate as in game GUI
system, and how it works in that

Yes, that’s another issue, for sure.

I should say art is not my concern yet, as I’m still at stage of setting up basic functionality. My really big issue is, I haven never done any UI work with unreal. Not even using Canvas. Hopefully by the time I’m have all things working, skinning of UI will be in place.

I have planned how my drag&drop spell book <> action bar ability assignment system should work (and it doesn’t involve any input interaction beyond mouse, just sending data back and forth), IDK, just how to setup it using currently available unreal GUI solutions.

“Once the API-affecting changes have been made, we hope to build a visual editor for Slate content.”

I do not see Slate ever becoming popular until you do this!

Then once the framework is laid out for people in editor and they can see the resulting code, THEN people can begin modding the code to get the effect they want, and more advanced programming at that point will be feasible because the basics have been clearly shown via the automatically generated code from the visual editor :slight_smile:

#Slate Code vs AHUD Code Familiarity

I have a very featured GUI in my game, including

  • animated text with programmatic multiple layers of outlines

  • “panels” that show 5 entries at a time and have scroll bars on the side to scroll through infinite entries

  • lists of important data where each entry has a tool tip that appears by the mouse cursor and the text responds to mouse hover events by glowing

  • an entire in-game internal file system with folders and files that can be moved around freely, to reorginize actual contents of project.

  • Right-click context menus that appear when the user right clicks, and have color schemes of their own and respond to the mouse cursor hovering

  • Every part of my HUD is interfacing directly with my AI system, displaying and modifying USTRUCT data of the AI creatures directly without any intermediary.

I have achieved everything I could ever want with my GUI system

#using just the AHUD class and C++


I balked at the very sight of Slate because I knew I would be able to do what I wanted,

especially my Scroll-able Panels that display 5 entries at a time,

much FASTER,

by just using C++ and HUD class :slight_smile:

So until there is sufficient documentation I do not even consider Slate viable for programmers,

Because I have only achieved the fullness of my GUI wishes using AHUD + C++, because I know structure of HUD and Canvas and there is not a lot of code bloat such as Mothership mentioned.

#Mind → Code

Because I know the language of the AHUD and Canvas, I can take the ideas for my GUI in my mind and turn them into code very quickly!

I cannot even begin to comprehend how I would do some of the fancier things I do with my HUD using Slate.

by just using C++ and HUD class :slight_smile:

I’d love to see a tutorial on that :smiley:

any particular part?

I cant feasibly do a tutorial on all of it

but I can explain core concepts of your specific interest fairly speedily :slight_smile:

What are your main questions / concepts of interest?

You are the tutorial master :wink:

Basically, I’d like to learn how to get rid of Slate completely.

The best would be a tutorial that could show how to make a simple button without going through Slate:

  • How to render text in a given font at a given screen coord
  • How to render images at an arbitrary size and alpha level at a given screen position, either using the size of the texture or a custom 2D scale

and then it’s trivial to do mouse hit-detection with that.

At this point, I am pretty much ready to give up on Slate entirely; it doesn’t sound like Epic is really putting a lot of resources into building it into the kind of robust UI development system that licensees like us are looking for, so it would be less risky to do it ourselves.

what you are asking for should not take me long to put together,

one question though:

“How to render images at an arbitrary size and alpha level at a given screen position, either using the size of the texture or a custom 2D scale”

when you say images, do you mean materials / textures, or actual images like a .bmp from your harddrive? I’ve done all of these I just want to know exactly what you mean.

You can put a specific button image into a material and the specify everything about how the material is read and put into the HUD, see this function definition and description! It’s amazing!

* Draws a material-textured quad on the HUD.
* @param Material Material to use
* @param ScreenX Screen-space X coordinate of upper left corner of the quad.
* @param ScreenY Screen-space Y coordinate of upper left corner of the quad.
* @param ScreenW Screen-space width of the quad (in pixels).
* @param ScreenH Screen-space height of the quad (in pixels).
* @param MaterialU Texture-space U coordinate of upper left corner of the quad
* @param MaterialV Texture-space V coordinate of upper left corner of the quad.
* @param MaterialUWidth Texture-space width of the quad (in normalized UV distance).
* @param MaterialVHeight Texture-space height of the quad (in normalized UV distance).
* @param Scale Amount to scale the entire texture (horizontally and vertically)
* @param bScalePosition Whether the “Scale” parameter should also scale the position of this draw call.
* @param Rotation Amount to rotate this quad
* @param RotPivot Location (as proportion of quad, 0-1) to rotate about
UFUNCTION(BlueprintCallable, Category=HUD, meta=(Scale = “1”, bScalePosition = “false”, AdvancedDisplay = “9”))
void DrawMaterial(UMaterialInterface
Material, float ScreenX, float ScreenY, float ScreenW, float ScreenH, float MaterialU, float MaterialV, float MaterialUWidth, float MaterialVHeight, float Scale=1.f, bool bScalePosition=false, float Rotation=0.f, FVector2D RotPivot=FVector2D::ZeroVector);

#New Thread - Buttons With HUD C++

Dear Mothership, could you make a new thread something like "How to Make Custom Textured Buttons Using HUD C++ ?

I can then answer that with my tutorial I am about to write, so that people searching the UDN in future can easily find my tutorial and get answer to this type of question.

Reason I request new topic for this is because this thread should never be marked as resolved for looong time till Epic actually resolves all of these Slate concerns.



Of course. I’ll open it shortly.