PDA

View Full Version : Strategy for Architecting a more efficient UI



John J
11-03-2010, 02:39 PM
I have completed the majority of the technical side of my UI protoype and am now starting to put a plan together to make it more efficient and less bulky code wise. For the initial version I just wanted to get it all up and running so I made one swf file that had a keyframe on the timeline for each "screen"..... 12 in all.

Then, I just used the gotoandplay command to move around as needed. This actually works just fine as my menu screens are not that intensive. However, the UScript file for this thing is getting a bit unwieldy and I still need to add a fair amount of functionality per screen. I looked at the UDK system and honestly, got confused on how it all worked because it was so split up and used external AS files. So I guess I am looking for an easier way to have a swf/UC file for screen and load/unload or hide/unhide each screen as I movethrough the UI.

Any ideas?

Matt Doyle
11-03-2010, 05:27 PM
You'll do best with a 'model-view-controller' design pattern. Your UnrealScript should load and unload Flash files on demand, and most of the heavy lifting should be done in UnrealScript. Each main screen should probably be a separate Flash file - example: Pause menu, Main Menu, Options Screen, Server Browser, etc.

John J
11-04-2010, 11:22 AM
So is that pretty much what the UDK setup is doing? Have a base "view controller" screen that then loads/unloads screens based on user input?

If so then what is a clean way to load/unload the swf's and how are the uc files connected to the swf's? I am loading the current swf in Kismet so that allows me to specify my uc class as the movieplayer, but I'm confused to how I would connect things up with the separate flash file approach.

Matt Doyle
11-04-2010, 01:14 PM
That is a complicated subject. I am not an engineer, nor did I write the UDK menu code, so I'll try to explain it the best I can, but I do not understand the entire setup.

Here are some of the things I know:

1. The level UDKFrontEnd is loaded via DefaultEngine.ini at startup.
2. Kismet uses Open GFx Movie to open udk_manager.swf using GFxUDKFrontEnd.uc as the movie class.
3. udk_manager.swf sets its doc class to MenuManager.as
4. GFxUDKFrontEnd.uc sets up each view as a variable (ex: GFxUDKFrontEnd_MainMenu = MainMenuView)
5. The view data is stored in the ini file DefaultUI.ini (ex: ViewData=(ViewName="MainMenu",SWFName="udk_main_menu.swf")

You'll want to follow the code in GFxUDKFrontEnd.uc line by line to try to understand what is happening, but essentially, you push and pop views off of the stack.

Also be sure to examine MenuManager.as to understand what it does.