Canvas-based GUI Framework in UnrealScript [Community Code Project]

[Crusha K. Rool]

Greetings, fellow coders!

I've been working on a UScript-based GUI for some time now to work around the need of Scaleform in order to create menus and eventually managed to create an ingame menu that is summoned with the Esc key and has a button in it with a nice texture that can be pressed with the mouse cursor and call a function to shut down the game. At this point I'd like to thank Solid Snake for the UDK gem on how to get the mouse cursor work.

I hope that's enough of a start to motivate you to contribute to this project because I now planned to continue this as a project for and with the entire community.


For this purpose did I create a SVN repository on Google Code, which can be found here:
https://code.google.com/p/unrealscript-gui-framework/

Everyone can check out the repository and files anonymously but hopefully will there be enough around here who actually want to contribute to it.

Gettings started contributing is easy, all you need is a Google Account and download an SVN client like TortoiseSVN for Windows.
With this tutorial will you have the stuff configured at the drop of a hat.

In order for you to contribute do I need to give you access rights, so just shoot me a PM with your Google Account if you are interested.


The GUIFramework folder and it's classes are all the core elements of this project.
GUIFrameworkExample is a separate folder that comes with usage examples to quickly show you what is needed to make a simple menu with this project.

All menu elements support full localization. In the MenuScene can you reference the name of the localization file and inside that file is the [Group] simply the name of your MenuScene class and the keys relate to the strings you enter for the buttons, which will then get localized to the values.

Check the Wiki at the project side for some basic info about the GUI components.


Happy coding!

[Carsten]

Well that sounds REALLY cool

We did this in my previous project. It just added so much to the game.

And good idea to involve the entire community

[_h2o_]

gays, maybe better to make PUBLIC UDK COMMUNITY SOURCES REPOSITORY? i will do another thread

also, why people still making something like own GUI..
Because there was a truly good system: http://forums.epicgames.com/threads/...small-UIEngine
Why to reinvent a wheel.. or maybe just for fun ^_^

[Crusha K. Rool]

Well, what other community projects are there? Because you can't just put any project into a repository that was released here.

About the other GUI system. Well, I never tried it. Because nobody ever mentioned it again in the numerous threads about GUI systems here before.

[Crusha K. Rool]

Well, according to himself are most of the classes in his system placeholders for now and don't really have much functionality yet.

I am currently discussing with him to join forces between our GUI systems and uploading his stuff to this repository as well and then sort things out.

[Carsten]

Good, i wonder what comes out of it

[Crusha K. Rool]

Ok, we had a nice extensive talk and came to the conclusion that our approaches are too different. He has a very complex system with styles and lots of code that is really hard to keep track of manually and that looks quite bloated since he derived from a Qt Framework. It would probably take weeks to fully dive into that stuff for me.

I started my approach from scratch without ever having worked with a UI system before and payed attention to keep the code as straight-forward and readable as possible while still not sacrificing functionality. Much is handled by a stack-like draw system and the whole system can basically be set up from the default properties of your HUD class.
This would be the code that is needed to get a working exit button with an ingame menu in my system:
http://pastebin.com/RQa6mXMU


So I will stick to my version and he to his, although he says that he doesn't have time to work on it anyway.



Back to the topic of this thread: Still looking for contributors. I am honestly not keen on doing this all on my own if the community I am doing that for is for the most part in a take-but-don't-give-back mentality.

[tegleg]

yes ill help out, though i havnt gone too far into canvas stuff yet.
ill have a quick look at your exit button to start with

[Crusha K. Rool]

yes ill help out, though i havnt gone too far into canvas stuff yet.
ill have a quick look at your exit button to start with

Nice, was counting on you already.

A work on the PostBeginPlay of the pastebin stuff I posted: While I would prefer to assign the delegate already in the DefaultProperties, this would for some reason crash the engine (possibly because some static reference or something like that), so I have to assign it at runtime.

[tegleg]

blimey you have put some work into that.
please could you give a very breif overview of how it all works, what the different classes do and such, and any important vars or whatever.

just so were not diving into it cold.

[Crusha K. Rool]

Sure, it's easy:
The HUD class is basically the originator for everything, I provided a GUICompatibleHUD.uc from which other HUDs can be derived, though I plan to refactor the code a bit so that you basically just need to add three lines to your HUD's PostRender to get everything working.

Another thing to take note of is the GUICompatiblePlayerController. It intercepts all mouse buttons by exec functions (some of them need to be bound in the INI first, others like StartFire check if the HUD's bCaptureMouseInput is True and then either route the stuff to the HUD or process the StartFire as usual).
And the GUICompatiblePlayerInput reads out the mouse movement values and updates the cursor coordinates in the HUD accordingly.

Pressed mouse buttons cause the matching pending booleans in the HUD to be set to true, for instance bPendingLeftPressed and bPendingLeftReleased.
Then does the PostRender update the location of the mouse according to the PlayerInput and the calls UpdateHoverSelection to recursively find the GUIComponent that is currently below the mouse cursor and tells the Component that it's now focused and tells the old one that it's no longer focused. After that does it process the pending booleans for the mouse buttons and tells the currently selected GUIComponent that it got clicked, scrolled or whatever. (It's easy to enhance it at this point to also allow clicking on ingame 3D objects by implementing the interface of the MouseInterface UDK Gem.)


GUIComponents are stored in a dynamic array in the HUD and added via DefaultProperties as you saw in the PastBin example. The PostRender() then goes through this array and calls each GUIComponent's DrawComponent() function, to which it passes the Canvas. So each GUIComponent gets a chance to draw itself and gets also ticked (the time since the last render can be read from the HUD class).

GUIContainerComponents hold an array of several other GUIComponents themselves and when they are drawn, they will tell each of their child components to draw as well.
This way can you create occluding layers. You could put all components that belong to a page, let's say an option screen, into a single container and then the whole page is only drawn if the container is drawn, thus preventing unnecessary draw calls on components that are not visible anyway.

GUICursorComponent is a static class that holds information about the cursor texture and handles drawing of tooltips and so on. It's set as class reference in the HUD as well.

GUIVisualComponent is the base class of all components that use textures, like buttons, background images and so on. (This might be refactored to comply more with the system of GUIMultiComponents, which is something I saw in the UT2k4 code and which makes sense. Basically it's simply a component that is made of several sub components, for instance a button out of a component that handles the "collision", one that handles the visuals and another one that handles the text label.)

GUIComponent is the very base class, it defines such basics like helping the HUD to find out which of overlapping components take precedence for mouse cursor selection or calculating the actual screen position. Components can be set to have a position in absolute values, in relative values, with HUDResolutionScaling or without and can have fixed distances relative to other components.


The way textures can be stretched in the Canvas allows for some nice lossless scaling, btw, if the textures are correctly made for that approach. It simply repeats the pixels that are in the middle of the texture, so you always have the same edges at high resolution and don't lose any detail if your middle part is equally colored anyway. http://udn.epicgames.com/Two/CanvasR...wTileStretched

[rquester]

FLCT already had this functionality. Canvas menu etc. and more (Save/Load system, Pawns/AI/Weapont generator, editor). Or some imrovements are there?

[Crusha K. Rool]

The thing that you posted seems to have nothing to do with a GUI Framework. And it also doesn't seem like anything you would use for serious games.

[rquester]

Menu in FLCT is professionally looking and working like in 90% commercial games.
Weapon, Pawn, AI generators are good start point to development. Editor is created for fast development of the level base. Then you can edit it by any editor (UDK, Blender,3Dmax...). But first version of the game will be ready very very fast.

[tegleg]

rquester was spamming that on my ai thread saying it creates custom ai too, sounds an amazing peice of software, it does everything lol.
with only a cheap dodgy looking site to go by its hard to say what it is exactly.

[rquester]

Site is cheap looking because I'm working on the program, not on site. Time spent for site design kills free time for FLCT development... If you want, you can see www.bludnikov.ru - it had normal design, but it in russian, because previous version of my programs (and other content) are for Russians.

[Crusha K. Rool]

Anyway, not interested. We are working on a real framework here that suits coder's needs, not something for some UDK newbie who expects everything to be done for him the easy way.

And that other side that you posted doesn't have any more serious design and it's nothing I'd call "normal". With such a nasty green color, icons from Windows 98 and four promotion graphics with half-naked RPG girls that look like Barbie would I do everything but even consider to click on a PayPal link there. Just as a tip for the future.

[rquester]

We are working on a real framework here that suits coder's needs, not something for some UDK newbie who expects everything to be done for him the easy way.
FLCT not only for newbie. Professional programmers will found it very useful too, because it saves many time. FLCT works like Wizards in Visual C++ (and many other developer programs).
Which are features in your project more suits for coders? I think it is interesting for other this page visitors too...

[Crusha K. Rool]

I don't have much trust in wizards. When I type everything myself I can be sure that I know afterwards how every line works and why I handled it that way and can easily make adjustments. It's just a matter of flexibility to me, especially since I usually upgrade to every or every second new UDK release.
I also think, without having tried your approach, that it's easier to directly integrate this into your own classes.

Anyway, I am not here to discuss which approach is the better one, I just want to offer another one that might suit people who prefer my style of doing things (easy to use and extend but never sacrificing functionality). Maybe there are better ones, maybe not. Diversity is always good, so I wonder why all responses here so far, except Tegleg's, have been "It has been done already" or "Look at this one, unless you do something much better you shouldn't be doing it at all".


So if you don't actually want to contribute something to the project, please don't derail the thread.
(This was not directed to you in particular)

[thommie]

sounds really interesting Crusha.
though i'm currently really busy with other things, i will have to give it a try some time.
mostly because i never could get into the whole scaleform process.
hopefully you can expect me to join this in a short while

[Carsten]

Site is cheap looking because I'm working on the program, not on site. Time spent for site design kills free time for FLCT development... If you want, you can see www.bludnikov.ru - it had normal design, but it in russian, because previous version of my programs (and other content) are for Russians.

The porn ads on that website really make it professional....

I don't think you get the point of this thread

[Crusha K. Rool]

A quick note on how it gets easier to test and set up things with this system:
We are of course lacking some visual interface that shows us the effects of variable changes in realtime, but we can get a provisory one easily in the game.
In case of my PasteBin example above, just type
editactor class=SiegeHUD
in console, where SiegeHUD is the name of the class that extends the GUICompatibleHUD and that is used by your gametype.

This will pause the game and bring up a typical UDK editor property window with all variables and their values to be altered at runtime.
Under the property group "None" should you find an array "GUIComponents" which will hold in the case of the above example a GUIButtonComponent from which you can alter values like screen position and so on in realtime and see the effects immediately.


I will see if I can apply the editinline modifier so we can even create new components at runtime for testing purposes.

[Crusha K. Rool]

I committed some changes to the repository, the code has been refactored a lot to make things more straight forward.

All mouse and component logic is now moved to GUIMenuScene, an Object-derived class that is created in the HUD and get's the PostRender passed to it. It serves as a base layer in which every new component is created now instead of the HUD.
It will also prevent GUIComponents from being destroyed in case the HUD should get switched midgame for some reason.
GUIMenuScene is "within" GUICompatibleHUD, that means all variables of the HUD
are directly accessible for it, just in case you are wondering. This is to prevent having to refactor and overcomplicating a lot of GUIComponent-related code.

Didn't test yet if everything still works, but it compiles fine, so I am carefully optimistic.


And the GUICursorComponent has been removed since that system was overcomplicating things and it has now been incorporated into the new GUIMenuScene.
I also added a check for widescreen aspect ratio to the GUICompatibleHUD class, thanks to TheAgent.


But there are still no active contributors.

[Wormbo]

rquester: A pure UnrealScript GUI framework needs to be a thin layer, like the SWT framework for Java, not a thick layer like Java Swing or Microsoft's WPF. Thick layers create too much overhead and UnrealScript is quite slow. UT and UT200x had reasonably thin GUI layers, with UT's UWindow being implemented entirely in UnrealScript and UT200x's XInterface using lots of native code support. UWindow wasn't exactly the fastest way to go, both on the developer and the performance side, but that's probably related to the amount of management code involved and the many linked lists. XInterface on the other hand took advantage of subobjects and other new UE2 features, so it was relatively easy to use even without wizards.

[rquester]

Thick layers create too much overhead and UnrealScript is quite slow.
Because many games (90%-99%) have identical main menu, load/save functionality, options, inventory etc. it will not slowdown games (programmers must write code for identical functionality). Besides when a game is running, most of code usually doesn't run - menu, inventory etc. pauses game first. FLCT uses this method at least. In multiplayer or other rare cases when menu doesn't pauses games, it is not important too, because framerate in menu mode may be lower (although FLCT code doesn't use too much resources).
Wizards allow to concentrate on a gameplay, not on standard functionality.

[Wormbo]

You obviously never tested UWindow. Like I said, that one is a relatively thin layer, compared to e.g. Swing, but already puts pressure on the CPU. Keep in mind that most GUI work will be on a single CPU thread, the one executing UnrealScript. Pausing the game in menu is not a reason to ignore execution time. In fact, the main menu in today's games is displayed on top of unpaused background levels. And since you never tried UWindow, you don't know how much CPU power a UScript-only GUI requires even on top of a paused level.

Standard functionality should not be implemented by wizards, it should be there in the base classes. Buttons could be dropped in via a subobject, special functionality added by means of delegates. Crusha is taking this in the right direction. Sure, wizards will make implementation a lot easier, but at the expense of providing much less flexibility than doing it yourself. And besides, if anyone is determined enough, it should be no problem writing a wizard for a known existing GUI framework. By concentrating on the wizards already you are taking development time away from optimizing the actual framework. And if you over-engineer it, it will be slow because UnrealScript is an entirely unoptimized language. UnrealScript byte code is an exact binary representation of the source code.

And uhh, if I may point that out, linking "FLCT" every time you write it, no matter how often you write it, seems a bit childish, especially since you already linked it in this thread before.

[rquester]

You obviously never tested UWindow.
What is UWindow? I didn't found it in internet.

Keep in mind that most GUI work will be on a single CPU thread, the one executing UnrealScript.
Yes. But in most applications GUI doesn't take many time. HUD functionality in non-paused mode is drawing 5-20 icons and 1-5 lines of text.
In menu mode most programs draws approximately 10 lines of text.

Pausing the game in menu is not a reason to ignore execution time.
This is the reason, because you don't needed 60FPS in menu mode, even 10 FPS is enough for menu.

In fact, the main menu in today's games is displayed on top of unpaused background levels.
Background level is approximately empty and in this case no problem with speed at all.

And since you never tried UWindow, you don't know how much CPU power a UScript-only GUI requires even on top of a paused level.
I know how much CPU power need FLCT.... Even 100 times drawing a HUD works OK (I had tested it).

Standard functionality should not be implemented by wizards, it should be there in the base classes.
Only base classes is not good idea for many tasks. You must subclass and define many properties. In some cases too many properties. If you have many classes, problems became larger. This is a good place for many errors.

Buttons could be dropped in via a subobject, special functionality added by means of delegates.
This not always best decision. Sometimes additional programming for adding these buttons is worse than realizing it manually.

Sure, wizards will make implementation a lot easier, but at the expense of providing much less flexibility than doing it yourself.
With wizards you can change all generated files, if you need it. But in most cases you don't need it.

And besides, if anyone is determined enough, it should be no problem writing a wizard for a known existing GUI framework.
You must understand GUI, read many documentation before use them, write many code. And you will receive functionality that in FLCT generated for seconds.

By concentrating on the wizards already you are taking development time away from optimizing the actual framework.
Don't optimize tasks, which don't need to much CPU/GPU/Memory etc. It unnecessary and sometimes cause unsupported code.

And if you over-engineer it, it will be slow because UnrealScript is an entirely unoptimized language. UnrealScript byte code is an exact binary representation of the source code.
Yes, but this is right for all Unreal Script code...

[tegleg]

rquester
it is admirable that you have created flct and that you give it away free, but please stop spamming it on every thread.
i did actually try it but the hugely bloated code it produced had too many errors to try and fix.
there are no wizards for menu, hud creation, ai and other things like you have suggested.
it takes over the udk installation entirely overwriting the ini's and everything without warning. it will not let you put it in a non udk installation folder like you said it would.
maybe over time you will improve it and it might be usefull to someone and i wish you good luck with it.

Crusha
sorry i said i would help and havnt yet. i just need to find the time to have a propper play around with it.
it does make it complicated to work with someone elses code. ill get the update and have another look.
the ideal outcome of this system would be something you can do most of the work in the editor, and/or a very very simple way or extending/using the code base without having to write too many lines to get it working.

edit:
just to expand a bit on what im thinking.
for instance, the exit button example you posted.
so that everyone can use this system and not just programmers it would be good to have 'standard button classes' that you can easily impliment.
so the exit button has default properties (position, texture and whatever) that you can overwrite if neccesary.
all you would have to do is declare in the 'hud wrapper' or somewhere that you want an exit button.
either adding it in the editor or by a single line of code. like New class'exitbutton' or maybe a button array in defaultproperties.
BtnArray[0]='ExitBtn'
BtnArray[1]='PlayBtn'
and that kind of thing.

what say you?

[Crusha K. Rool]

Crusha
sorry i said i would help and havnt yet. i just need to find the time to have a propper play around with it.
it does make it complicated to work with someone elses code. ill get the update and have another look.
the ideal outcome of this system would be something you can do most of the work in the editor, and/or a very very simple way or extending/using the code base without having to write too many lines to get it working.

edit:
just to expand a bit on what im thinking.
for instance, the exit button example you posted.
so that everyone can use this system and not just programmers it would be good to have 'standard button classes' that you can easily impliment.
so the exit button has default properties (position, texture and whatever) that you can overwrite if neccesary.
all you would have to do is declare in the 'hud wrapper' or somewhere that you want an exit button.
either adding it in the editor or by a single line of code. like New class'exitbutton' or maybe a button array in defaultproperties.
BtnArray[0]='ExitBtn'
BtnArray[1]='PlayBtn'
and that kind of thing.

what say you?

No problem, but you could already send me the name of your Google Account in a PM so I can already add you to the project's member list so you can add stuff if you feel like doing so.

About the basic functionality: I could make a separate folder GUIFrameworkExt, which is what I already had offline for the button example I posted. It is supposed to contain more specialized stuff. But the button needs a bugfix first because currently I didn't manage to have it display text, but it's probably just about some variable having stored an unfitting value.

[rquester]

but please stop spamming it on every thread.
In this thread was the message to me and I answer to it.

i did actually try it but the hugely bloated code it produced had too many errors to try and fix.
No errors at all. All generated code is compiled without errors and warnings. If you have an error, please type it somewhere and I try to fix it.

there are no wizards for menu, hud creation, ai and other things like you have suggested.
There is. Menu and hud creates when you select "New game". AI creates when you select "Create Enemy AI". You can view video: http://www.youtube.com/watch?v=GJlKRsphNJU

it takes over the udk installation entirely overwriting the ini's and everything without warning.
It is not overwriting, it changes some important parts (add package name to DefaultEngine and adds keys to DefaultInput).

it will not let you put it in a non udk installation folder like you said it would.
FLCT may be setup in any folder. For generating files UDK directory need of course. But if you want you can copy only Developer/Src and Config folders (with right place in directory tree) in temporary folder and run FLCT.

[Crusha K. Rool]

Added yet another small change to the GUIMenuScene.uc:
The RenderScene() function was made more assessable by moving the button handling functionality into a separate function. I currently aim a lot at making the code easier to understand for new guys.

[tegleg]

is SeigeHUD still working?
just updated the codebase, copied SeigeHUD and i get errors with bDrawGUIComponents and FindComponentByName.

[Crusha K. Rool]

Nope, since most stuff has been moved into the MenuScene now.
So the DefaultProperties of SiegeHUD need to be in a subclass of GUIMenuScene (and then let that thing be spawned by the GUICompatibleHUD as MenuScene -memo to myself: let the GUIMenuScene class to use be specified in the DefaultProperties-) and the content of PostBeginPlay() needs to be moved into InitMenuScene().
And in TogglePauseMenu() does it need to be MenuScene.bDrawGUIComponents and MenuScene.bCaptureMouseInput now.

[sv13]

just out of the curiosity, what is siegehud ?

[Crusha K. Rool]

It's just example code of how to get a simple Exit button in the game that is shown in the pause menu when pressing the Esc key. It's the PastBin file on the previous page.

[tegleg]

could you do an update for seigehud just so i can see it all in action?

also maybe it needs to be more accessable for people who are just curious, it might encourage them to participate in its development.
something like all the base classes and a very simple example menu hud, should be small enough to attach a zip on here.

[Crusha K. Rool]

Sure, later this evening.

[Crusha K. Rool]

Committed. You will need to set a texture for the button in the DefaultProperties yourself and it will probably not show any text on it yet (I also didn't test the code yet, but it compiles fine). But other than that should it get you going by just using the GUIExampleGameInfo as gametype in the map.

[thommie]

starts out with a scriptwarning Object ExampleMenuScene None created in Package instead of GUICompatibleHUD
in the GUICompatibleHUD postbeginplay()

and after that accessed None 'MenuScene' whenever i press escape, but that's hardly surprising.

tested it on DM-deck, but i think i just did something wrong. will look into it when i have time again

[Crusha K. Rool]

Hmm, will have to look into that. I haven't really used the new() operator before, so I might not be aware of all it's limitations and requirements.