Jump to content
  • Advertisement
Sign in to follow this  
ITGER

Unity UI design with Lua

This topic is 4645 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been using Lua lately, and I've found it to be pretty nice. I got the idea of designing the UI for my game in Lua - I would write some widget classes in C++, and use a script file to specify where on the screen they go. For example, right now I can do something like:
createTextLabel(frameName, "New Game", 0.5, 0.35, 1)
createTextLabel(frameName, "Load Game", 0.5, 0.45, 1)
createTextLabel(frameName, "Options", 0.5, 0.55, 1)
createTextLabel(frameName, "Credits", 0.5, 0.65, 1)
createTextLabel(frameName, "Quit", 0.5, 0.75, 1)
Where the two floats after the string are the relative X and Y positions, and the 1 is a flag saying that the text label should be centered at that X coordinate, as opposed to being left aligned. However, I seem to have run into a problem. It's nice that I can specify the layout of my widgets without having to recompile, but I can't figure out a clean way of specifying arbitrary behavior when a widget gets clicked. For example, if you click on any of the text labels, (text labels kind of double as buttons here) then you will get switched to another screen, or quit the game. When you are in the options menu, there will be some radio buttons and listboxes, and it will have an "OK" and a "Cancel" label, which will of course save changes and leave or discard changes and leave. In the UI for my previous game, (which I pretty much just hacked up at the last minute before our showcase) I wrote a bunch of "WidgetAction" classes, which just had a virtual function called "activate" that got called when the action's containing widget got clicked. Since C++ does not have anonymous classes like Java, I ended up with a few (not too many) classes for seemingly arbitrary actions, such as "ConnectToServerAction", "StartSinglePlayerAction". The entire UI was hard-coded, with all of the widgets placed and their actions bound in some setup function. Here are some options that I considered taking. Could someone please make some suggestions as to which way is best? 1) As an extra argument for all createXXXXWidget glue functions, specify an event that gets raised when the widget gets clicked. This seems simple, but the problem is that I would probably have to write a bunch of subclasses for events, and perhaps have them all be able to be constructed at runtime by a string containing their constructor arguments. Then again, I will probably be making a lot of event subclasses for other purposes anyway. 2) Instead of an event type as the extra argument, specify an anonymous Lua function that serves as a callback for when the widget gets clicked. To be honest, I'm not really sure how this would work out in terms of argument passing. Also, the contents of the anonymous functions would probably be more glue function calls, which means more glue functions would have to be written. 3) Write some WidgetAction classes, and add glue functions to allow constructing them from the script file. This doesn't seem too horrible I guess, although I would like some more flexibility in specifying behavior. 4) Write WidgetAction classes, and hard-code the entire UI, including screen placement. I'd rather not, but it does seem the simplest. (And statically typed, but whatever.) I guess there isn't necessarily a magic bullet for this problem, but I would appreciate some advice so that I can at least make an informed decision. Thanks! --EDIT-- Damn, I should really read the other posts in this forum. This looks like a good approach: http://www.gamedev.net/community/forums/topic.asp?topic_id=366651

Share this post


Link to post
Share on other sites
Advertisement
The problem seems to be that your internal actions are not properly exposed to Lua.

Could you, today, write a Lua script which does whatever needs to be done in response to a button, but manually?

If not, then you need to beef up the interface between your application and Lua, in some way.

If you can, then all you need to do is pass a Lua function as argument to the create function, and have the button instance call it when activating the button.

Share this post


Link to post
Share on other sites
Quote:

The problem seems to be that your internal actions are not properly exposed to Lua.

Could you, today, write a Lua script which does whatever needs to be done in response to a button, but manually?

If not, then you need to beef up the interface between your application and Lua, in some way.

If you can, then all you need to do is pass a Lua function as argument to the create function, and have the button instance call it when activating the button.


So do you mean that I should just add more glue functions, i.e. some functions to create WidgetActions? Just wanted to make sure.

Share this post


Link to post
Share on other sites
In my project (also using Lua, though I use tolua++ to generate the glue functions), I have a Signal/Slot mechanism to handle widget events. For instance, if I want to activate, say, a new screen when the user presses a button I do something like this:
 
Cpp
---

class MyScreen: public Screen {
public:
Slot slot_activate;

MyScreen() {
slot_activate.set_callback(&MyScreen::onActivate);
}

void onActivate() {
// activate screen
}

};

Lua
---

-- Connect event to my_screen class
my_button.signal_activate:connectTo(my_screen.slot_activate);

-- Connect event to lua function
my_button.signal_activate:connectLuaFunction("FunctionName");


You can read about signals and slots here: http://www.codeproject.com/cpp/ElmueSignalsandSlots.asp

This is just how I do it, there are many other ways. Hope this gives you some ideas.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!