本发明涉及计算机领域，尤其涉及一种UI自动布局的方法。
背景技术：
在MMO(Massively Multiplayer Online，大型多人在线)游戏中，不仅各种游戏系统多，而且复杂，需要展示给玩家看的信息也就会很多。一个典型的MMO游戏，各种界面会多达数百个，甚至上千。游戏内有各种界面元件(按钮图标、活动界面、对话框、提示信息等)，每个元件都希望有自己的动态布局方案，并且能够自适应游戏窗口大小和游戏分辨率。
在游戏窗口区域有限的条件下，如何合理地分配空间、合理地组织界面，既能够及时高效的把信息展示给玩家，又能够最大限度地不干扰到玩家游戏的乐趣，还能够最大化的减少重复工作；是非常迫切的需求。
MMO游戏对界面进行布局管理一般是默认设置几种简单的方案(比如按照九宫格进行定位)，有特殊需求界面再单独写逻辑控制。其中，典型的按照九宫格进行界面布局管理的方案如下，大致包括界面组织和界面定位：
界面组织：把游戏界面按照树形结构进行组织，树的根节点就是所有界面的祖先。祖先界面可以理解为铺满整个游戏窗口，也就是和游戏分辨率一样。子界面的坐标是相对其父界面，并且会伴随父界面一起移动和缩放；
界面定位步骤：
1)美术把界面的定位需求告诉程序；
2)程序在代码中实现界面的定位布局功能；
3)游戏运行中确定游戏窗口分辨率；
4)祖先界面按照九宫格点确定9个定位基准点；
5)其他子界面按照自己的定位规则，去相对某个基准点进行定位；
6)子界面的子界面，再根据自己的定位规则相对自己的父界面进行定位。
上述典型的按照九宫格进行界面布局管理的方案，每个界面的定位和布局是自己控制，也就是离散的。在需求简单、界面少时问题不大。在需求膨胀、界面繁多时，就容易带来以下问题：
(1)因为没有可视化，美术无法进行整体布局规划；
(2)难以统一管理，容易冲突：当多个界面同时显示时容易出现设计外的重叠；
(3)难以进行复杂的动态布局，比如B界面要根据A界面来进行相对定位，而A界面又会动态改变大小和坐标时，B界面则难以进行布局；
(4)难以维护：因为每个界面是自己进行定位和布局，当需求改变时，就需要去修改相应界面代码实现，维护成本大。
可见，为界面繁多的游戏提供一种合理、高效的界面布局方案是业界亟待解决的问题。
以上背景技术内容的公开仅用于辅助理解本发明的发明构思及技术方案，其并不必然属于本专利申请的现有技术，在没有明确的证据表明上述内容在本专利申请的申请日前已经公开的情况下，上述背景技术不应当用于评价本申请的新颖性和创造性。
技术实现要素：
本发明的主要目的在于提出一种UI自动布局的方法，以解决现有的界面布局方案已经无法满足界面繁多的游戏界面布局需求的问题。
为解决上述技术问题，本发明提出以下技术方案：
一种UI自动布局的方法，用于对游戏中的界面进行布局，包括以下步骤：
S1、于一编辑器中自定义代表待布局的界面的至少一个可视化布局组件，所述布局组件均包含多个属性；所述多个属性至少包括布局组件的大小、坐标以及布局参数；
S2、建立所述界面与所述布局组件之间的关联映射关系；
S3、对所述布局组件的各属性进行赋值，确定所述布局组件相应的定位规则；
S4、基于所述关联映射关系和所述定位规则，并根据布局组件的属性值和游戏分辨率，计算所述布局组件的关联界面在游戏主界面的实际坐标，实现界面在游戏主界面的布局。
本发明提供的上述技术方案，与现有技术相比最明显的优势在于：可以让专业的人做专业的事，即美术在他们精通的编辑器中进行熟悉的界面编辑工作，程序员只需在游戏代码中实现界面的功能而不用管布局，有效地解决了现有的界面布局方案中由非美术专业的程序员主导UI布局，而专业的美术无法最大程度发挥专业知识的弊端。美术在他们熟悉的编辑器中利用可视化的组件代替界面进行布局，不仅直观，也很简单；而程序员主要负责在程序中实现界面的功能，无需过多考虑布局需求，从而，可以减少程序员和美术的工作沟通成本，有效地提升了效率。另一方面，本发明的布局方法，具有较低的维护成本，表现在：当需要修改现有界面的布局时，只需美术在编辑器中对原先的布局组件文件中的相应布局组件进行定位规则的修改和关联映射关系的修改，在游戏程序运行时，调用修改后的布局组件文件以及关联映射关系，则游戏中就自动实现相应的布局修改；当增加新界面时，只需要程序员先在代码中实现新界面的功能，而后由美术在原先的布局组件文件中新增相应的布局组件并进行组件属性赋值，再在关联映射关系中加入新的映射，在游戏程序运行时(需要进行布局的计算时即可运行程序)，调用更新过的布局组件文件以及关联映射关系，则游戏中就自动增加了新的界面布局。
附图说明
图1是本发明一实施例在Adobe Flash中进行可视化布局的示意图；
图2是一布局组件的属性框示意图；
图3是一现有游戏的游戏窗口；
图4是对图3所示的游戏窗口中的三个示例界面采用本发明的方法在编辑器中进行可视化布局的示意图；
图5是关联于图3中状态栏的布局组件的属性框示意图；
图6是关联于图3中雷达地图的布局组件的属性框示意图；
图7是关联于图3中任务追踪界面的布局组件的属性框示意图；
图8是图4所示实施例所建立的布局组件与关联界面之间映射关系图；
图9是图3中的界面40的实际界面截图。
具体实施方式
下面结合附图和具体的实施方式对本发明作进一步说明。
本发明的具体实施提供一种UI自动布局的方法，用于对游戏中的界面进行布局，尤其是界面繁多的MMO游戏，该方法包括以下步骤：
S1、于一编辑器中自定义代表待布局的界面的至少一个可视化布局组件，各所述布局组件均包含多个属性；所述多个属性至少包括布局组件的大小、坐标以及布局参数；
S2、建立所述界面与所述布局组件之间的关联映射关系；
S3、对所述布局组件的各属性进行赋值，确定所述布局组件相应的定位规则；
S4、基于所述关联映射关系和所述定位规则，并根据布局组件的属性值和游戏分辨率，计算所述布局组件的关联界面在游戏主界面的实际坐标，实现界面在游戏主界面的布局。
本发明所用的编辑器优选地采用商业化的Adobe Flash，但也可采用其它编辑器，只要是有分层、可以自定义并可视化摆放控件并把所有信息都导出等功能的编辑器都可以。本发明的具体实施方式中以Adobe Flash编辑器为例进行说明。
基于本发明的方法，在游戏的程序(代码)中，程序员只需将游戏中的所有界面(包括主界面、状态栏、各种按钮、弹出窗口等，凡是显示了信息，可以和玩家进行交互的控件，都是本发明中所述的“界面”)的大小给定，并且界面功能都予以实现，而无需考虑界面的布局需求，关于布局，程序员主要是将步骤S4的算法过程在代码中实现即可，这样一来，美术在编辑器中实现可视化布局即完成步骤S1至S3之后，即可通过程序自动实现不同分辨率的游戏的界面布局。
美术在熟知当前需要进行界面布局的游戏中，相应界面的功能以及显示层次、显示时间等信息后，即可在编辑器中开始界面的可视化布局。如图1所示，在编辑器舞台上，通过拖曳的方式摆放可视化布局组件(简称“布局组件”)，优选地是矩形。摆放的布局组件的数量根据需要进行布局的界面来确定，一般而言，一个矩形对应一个界面，也不排除一个矩形可对应两个以上界面的特殊情况，该特殊情况下对应同一个布局组件的两个以上界面在游戏中具有相同的布局。本发明中以一个矩形对应一个界面的通常情况进行说明。每个布局组件的大小根据游戏程序中给定的界面大小来确定，摆放位置(即布局组件的坐标)则由美术自定义。优选地，一般游戏主界面的分辨率和编辑器舞台的分辨率完全相同(即编辑器舞台和游戏主界面具有同样的大小)，则布局组件在编辑器舞台上的位置即代表了关联界面在游戏主界面中的位置，布局组件的大小也和游戏程序中给定的关联界面大小一致。
其中，对于每一矩形，均可定义数个后述进行动态布局定位所需的特征点，少则一个，可以为两个、三个等，优选地以九宫格点的逻辑选定9个特征点，即矩形的四个顶点、四条边的中点和矩形的几何中心点。并将9个点统称为九宫格点，四个顶点分别命名为TOP_LEFT、TOP_RIGHT、BOTTOM_LEFT、BOTTOM_RIGHT，四条边中点分别命名为TOP、BOTTOM、LEFT、RIGHT，几何中心点CENTER。
如图1所示，编辑器舞台A区域上摆放了很多布局组件，每个布局组件都有各自的属性，呈现于舞台右侧的B区域，具体如图2所示的属性框中。每个属性都有其相应的值，对某一布局组件的属性进行赋值即可确定该布局组件相应的定位规则。例如图2中所示的布局组件属性框，该布局组件的具体名称为task_hud，HUD占位是task_hud及其同类型组件的统称；该布局组件的位置即坐标是(798,138)；大小是215×220(像素)；需要说明的是，布局组件的坐标是指布局组件在编辑器舞台上的坐标，以每个矩形的左上角顶点坐标代表该布局组件的坐标；而界面的坐标是指界面在游戏主界面中的坐标，也是将界面(均认为是矩形，涉及到有装饰物的不规则形状则采用程序中自定义的接口ufx_get_width()和ufx_get_height()来指定为一定大小的矩形)左上角顶点坐标作为该界面在游戏主界面中的坐标。
如图2，属性中的布局参数(等同于图2中的组件参数)至少包括锚点、锚定类型、锚定目标、目标锚点和忽略坐标偏移选项，通过对这些布局参数进行赋值，根据所述布局组件的布局参数的属性值建立所述布局组件与其锚定目标之间的锚定关系，以形成所述定位规则；所述锚定关系为所述布局组件的所述锚点和作为所述锚定目标的布局组件上的所述目标锚点之间的关联关系。这些布局参数的赋值例如是：忽略坐标偏移选项的赋值即是对图2中的“忽略坐标偏移”选项框进行选中或不选中的过程，选中即表示忽略坐标偏移，不选中(图2中所示的状态)则表示不忽略坐标偏移；锚点定义为位于所述布局组件上、用于与相对其它布局组件进行相对定位的定位基准点，可以选择矩形上的九宫格点之一，选择采用哪个点作为锚点就是对锚点进行属性赋值；锚定目标是指所述布局组件进行相对定位时的目标布局组件，赋值时不填写就代表所述布局组件是相对于编辑器舞台进行定位；相应地，目标锚点就是指所述布局组件进行相对定位时的目标布局组件上的相对定位点，也是可选择九宫格点之一。从图2的属性框中就可得出以下信息：所述布局组件task_hud用自己的左上角顶点(锚点TOP_LEFT)去和目标布局组件(锚定目标)map_hud的左下角顶点以按百分比锚定的方式(锚定类型PERCENT)进行关联，以相对于布局组件map_hud定位；同时也表征了所述布局组件task_hud的关联界面(简称“本界面”)在游戏中是以布局组件map_hud的关联界面(简称“目标界面”)为目标进行相对定位的，并且，也是用本界面的左上角顶点去和目标界面的左下角顶点进行关联。从而，建立起了所述布局组件task_hud与布局组件map_hud之间的锚定关系，进而也建立起了本界面与目标界面之间的相对定位关系。
如图1所示，在编辑器中进行可视化布局时，还对所有的布局组件按照其关联界面在游戏中的显示层次进行分层，把处于不同层次的界面所对应的布局组件分配到不同的层，图1中C区域即是分层管理区域。上层的界面会显示在下层界面的上面，在同一层中的不同界面，可以相互之间动态调整上下关系。编辑器舞台是最大也是最下层的布局组件，其所关联的是游戏主界面，在优选的实施例中将编辑器舞台的大小设置为1024×768，这是考虑到大部分游戏分辨率为1024×768，即与通常的游戏主界面保持一样的大小。游戏中定义为显示在主界面上层的界面，则其布局组件也相应地位于编辑器舞台的上层，而这些界面的弹出菜单等，又将显示于这些界面的上层，在编辑器中，这些弹出菜单等所对应的布局组件也相应地位于这些界面的上层，依此类推，来对所有的布局组件进行分层管理。
下面以一个具体的例子来对本发明的方法进行更加详细的说明。
如图3所示，是一现有游戏《镇魔曲网页版》的游戏窗口示意图，游戏主界面中最顶部横向占满的横条框为状态栏，定义为界面10；状态栏右下方的是雷达地图，定义为界面20；雷达地图下方的是任务追踪区域，定义为界面30。在本实施例中将阐述如何用本发明的方法来实现这三个界面如图中所示的布局。
首先，程序员在游戏程序中已经给出了界面10、20、30的大小以及实现了各自的功能。而进行可视化布局的美术也应当至少熟知这些界面的功能以及在游戏中显示在哪一层等界面相关信息。在此基础上，美术在Adobe Flash编辑器中自定义可视化布局组件(后述可简称“组件”)，如图4所示，在编辑器舞台(可简称“舞台”)上摆放三个矩形，即三个组件10’、20’、30’，分别代表需要布局的三个界面。每个组件的大小根据该游戏程序中定义的关联界面的大小一致，组件10’代表了界面10，大小为1024×30；组件20’代表了界面20，大小为225×160；组件30’代表了界面30，大小为215×220。而舞台的大小设置为1024×768，即舞台宽为1024像素，高为768像素。
其中，组件的大小可通过在属性框中编辑组件大小属性值而实现，也可以在舞台上对矩形的边进行横向或纵向等拖曳而实现矩形的放大、缩小来改变组件大小；组件的位置即由美术来定，也就是可视化布局，美术基于对游戏及其界面的功能等信息的充分了解，来对组件进行布局。在本例中，美术将组件10’置于编辑器舞台的顶部，由其大小可知，是横向占满，如图5所示，从而其在舞台上的位置(即左上角顶点坐标)就确定为(0,0)，组件名称为status_hud，锚点是左上角顶点，锚定类型是按百分比锚定，锚定目标没填写就代表是以舞台作为锚定目标，目标锚点为舞台的左上角顶点；如图4，组件20’置于组件10’的右下方，并与组件10’右对齐，其属性及值如图6所示；组件30’置于组件20’下方，并与组件20’左对齐，其属性及值如图7所示。
当各组件及其属性值都编辑好之后，可将该可视化布局的flash文件保存，保存的文件是flash源文件，为UIManager.fla；然后再发布，导出布局组件文件UIManager.swf，作为后续供游戏程序调用的文件；同时，建立各组件与其关联界面之间的关联映射关系，以游戏程序运行时可自动读取的数据文件形式呈现，例如是一Excel映射表，本实施例中所建立的Excel映射表参见图8。在游戏程序运行时，自动读取布局组件文件和Excel映射表，然后在游戏界面加载前，程序基于读取的布局组件文件的数据和Excel映射表中的关联关系，自动进行后续的界面实际坐标的计算，以使关联的界面具有编辑器中的布局。
在计算实际坐标以获知界面在游戏主界面中的位置时，程序会按照一定的优先级顺序，例如，对于某一组件，如果其锚定目标是舞台，即该组件的关联界面是相对于游戏主界面进行定位，则这样的组件及其关联界面具有第一优先级，在进行界面实际坐标计算时，优先计算；再将以第一优先级布局组件作为锚定目标的布局组件及其关联界面设为第二优先级，将以第二优先级布局组件作为锚定目标的布局组件及其关联界面设为第三优先级，依次类推；按照优先级递增的顺序依次进行计算。在本实施例中，组件10’和组件20’的锚定目标都是舞台，即界面10和界面20都被设置为相对于游戏主界面进行定位，程序中可同时计算二者的实际坐标，但也可不同时计算，也就是说，在同样的优先级别中，也可按照一定的顺序来计算，例如，根据组件在舞台中的坐标，可依照从上往下的顺序依次计算。在本实施例中，是先对组件10’的关联界面10进行实际坐标的计算，再对同样优先级的界面20进行计算，由于界面30是相对于界面20进行定位，因此只有在界面20的实际坐标计算出来之后才能计算界面30的实际坐标。
每个界面的实际坐标的计算方法都相同，只是数据不同，包括四个计算步骤：
①基于所述关联映射关系，并根据所述布局组件的关联界面的大小，计算在该关联界面中锚点相对于界面原点的坐标偏移off_x和off_y；
②根据所述布局组件的锚定目标所关联的界面的坐标和大小，计算所述布局组件的目标锚点在当前游戏主界面中的坐标(relativeX’,relativeY’)；
③根据属性赋值时所选择的锚定类型、所述布局组件相对于其锚定目标的相对坐标偏移、所述布局组件的目标锚点在当前游戏主界面中的坐标(relativeX’,relativeY’)以及当前游戏分辨率，计算所述布局组件的关联界面的锚点在当前游戏主界面中的坐标(tmp_x,tmp_y)；
④根据所述坐标偏移off_x和off_y，以及所述布局组件的关联界面的锚点在当前游戏主界面中的坐标(tmp_x,tmp_y)，计算所述布局组件的关联界面的原点坐标(_x,_y)；其中，_x＝tmp_x-off_x，_y＝tmp_y-off_y；界面的原点坐标即为界面的在游戏主界面中的实际坐标。
计算步骤③中，每一布局组件相对于其锚定目标的相对坐标偏移_offsetX和_offsetY通过如下方法计算：
当对所述忽略坐标偏移选项进行属性赋值时选择忽略坐标偏移，则所述相对坐标偏移_offsetX＝0和_offsetY＝0；
当对所述忽略坐标偏移选项进行属性赋值时选择不忽略坐标偏移，则所述相对坐标偏移按锚定类型分两种情况进行计算：
1)当属性赋值时锚定类型选择为按百分比锚定，则
_offsetX＝(anchorX-relativeX)/StageWidth；
_offsetY＝(anchorY-relativeY)/StageHeight；
其中，(anchorX,anchorY)为所述布局组件的锚点在编辑器舞台上的坐标，(relativeX,relativeY)为目标锚点在编辑器舞台上的坐标，StageWidth和StageHeight分别为编辑器舞台的宽和高；
2)当属性赋值时锚定类型选择为按像素锚定，则
_offsetX＝anchorX-relativeX；
_offsetY＝anchorY-relativeY。
上述计算步骤③具体包括：
当锚定类型选择为按百分比锚定时：
tmp_x＝relativeX’+_offsetX*screenWidth；
tmp_y＝relativeY’+_offsetY*screenHeight；
其中，screenWidth和screenHeight分别为当前游戏主界面的宽和高，相当于游戏分辨率，是在游戏程序运行时读取；
当锚定类型选择为按像素锚定时：
tmp_x＝relativeX’+_offsetX；
tmp_y＝relativeY’+_offsetY。
下面分别来说明每个界面的实际坐标计算过程，也就是定位计算过程。
1、界面10
1.1、由于本实施例中所有组件的“忽略坐标偏移选项”属性都是选择不忽略(属性框中未截出)，并且是按照百分比锚定，因此，计算组件10’相对于锚定目标“舞台”的相对坐标偏移_offsetX和_offsetY，如下：
_offsetX＝(anchorX-relativeX)/StageWidth＝(0-0)/1024＝0；
_offsetY＝(anchorY-relativeY)/StageHeight＝(0-0)/768＝0；
其中，从组件10’的属性框中可以看到，其锚点为左上角顶点(也就是自身的原点，其坐标代表了它在舞台上的位置)，坐标为(0,0)，而目标锚点是锚定目标的左上角顶点(也就是舞台的原点)，坐标也为(0,0)。对于舞台和游戏主界面而言，左上角顶点为原点，横坐标往右增大，纵坐标往下增大；
1.2、计算界面10的锚点相对于界面自身原点的坐标偏移off_x和off_y。由于界面10的锚点就是界面10的左上角顶点，因此off_x＝0，off_y＝0；
1.3、计算组件10’的目标锚点在游戏主界面中的坐标(relativeX’,relativeY’)，由于组件10’的目标锚点就是舞台的左上角顶点(原点)，因此此处要求的(relativeX’,relativeY’)就是舞台的坐标(0,0)；
1.4、计算界面10的锚点在游戏主界面中的坐标(tmp_x,tmp_y)，由于是按百分比锚定，则：
tmp_x＝relativeX’+_offsetX*screenWidth＝0+0＝0；
tmp_y＝relativeY’+_offsetY*screenHeight＝0+0＝0；
1.5、计算界面10的原点坐标(_x,_y)，也就是界面10在游戏主界面中的实际坐标，如下：
_x＝tmp_x-off_x＝0-0＝0；
_y＝tmp_y-off_y＝0-0＝0；
从而，在游戏程序运行过程中，自动计算出了界面10的位置，确定其在游戏主界面中的布局为左上角顶点与游戏主界面顶点重合，其大小决定了是横向铺满游戏主界面(也可称游戏窗口)。因为本实施例中游戏分辨率即游戏主界面也是1024×768。
2、界面20
2.1、计算组件20’相对于锚定目标“舞台”的相对坐标偏移_offsetX和_offsetY。从组件20’的属性框中可以看到，其锚点为右上角顶点，由于左上角顶点坐标为(798,31)，而宽为225，因此锚点坐标(anchorX,anchorY)为(1023,31)；而目标锚点是锚定目标的右上角顶点(也就是舞台的右上角顶点)，坐标(relativeX,relativeY)为(1023,0)。因此：
_offsetX＝(anchorX-relativeX)/StageWidth＝0；
_offsetY＝(anchorY-relativeY)/StageHeight＝31/768。
2.2、计算界面20的锚点相对于界面自身原点的坐标偏移off_x和off_y。由于界面20的锚点是它的右上角顶点，根据界面20的大小(宽225、高160)，因此off_x＝225，off_y＝0；
2.3、计算组件20’的目标锚点在游戏主界面中的坐标(relativeX’,relativeY’)，由于组件20’的目标锚点是舞台的右上角顶点，因此此处要求的(relativeX’,relativeY’)就是游戏主界面的右上角顶点坐标，游戏主界面大小为1024×768，因此(relativeX’,relativeY’)为(1023,0)；
2.4、计算界面20的锚点在游戏主界面中的坐标(tmp_x,tmp_y)，由于是按百分比锚定，则：
tmp_x＝relativeX’+_offsetX*screenWidth＝1023；
tmp_y＝relativeY’+_offsetY*screenHeight＝31；
其中，读取到该游戏当前运行的游戏分辨率是screenWidth＝1024，
screenHeight＝768。
2.5、计算界面20的原点坐标(_x,_y)，也就是界面20在游戏主界面中的实际坐标，如下：
_x＝tmp_x-off_x＝798；
_y＝tmp_y-off_y＝31；
从而，在游戏程序运行过程中，自动计算出了界面20的实际坐标为(798,31)，由于界面20的右上角顶点坐标为(1023,31)，可知，界面20在游戏主界面中的位置为：右边界与界面10的右边界对齐，整个界面20在界面10的下方相隔一行像素。
3、界面30
3.1、计算组件30’相对于锚定目标组件20’的相对坐标偏移_offsetX和_offsetY。从组件30’的属性框中可以看到，其锚点为左上角顶点，因此组件30’的锚点在舞台上的坐标(anchorX,anchorY)为(798,192)；而目标锚点是锚定目标的左下角顶点，而组件20’的左下角顶点坐标为(798,191)，因此目标锚点在舞台上的坐标(relativeX,relativeY)为(798,191)。因此：
_offsetX＝(anchorX-relativeX)/StageWidth＝0；
_offsetY＝(anchorY-relativeY)/StageHeight＝1/768。
3.2、计算界面30的锚点相对于界面自身原点的坐标偏移off_x和off_y。由于界面30的锚点正是它的左上角顶点，因此off_x＝0，off_y＝0；
3.3、计算组件30’的目标锚点在游戏主界面中的坐标(relativeX’,relativeY’)，由于组件30’的目标锚点是组件20’的左下角顶点，因此此处要求的(relativeX’,relativeY’)就是界面20的左下角顶点坐标，前述已经求得界面20的实际坐标(左上角顶点坐标)为(798,31)，因此界面20的左下角顶点坐标为(798,191)，因此(relativeX’,relativeY’)为(798,191)；
3.4、计算界面30的锚点在游戏主界面中的坐标(tmp_x,tmp_y)，由于是按百分比锚定，则：
tmp_x＝relativeX’+_offsetX*screenWidth＝798；
tmp_y＝relativeY’+_offsetY*screenHeight＝192；
3.5、计算界面30的原点坐标(_x,_y)，也就是界面30在游戏主界面中的实际坐标，如下：
_x＝tmp_x-off_x＝798；
_y＝tmp_y-off_y＝192；
从而，在游戏程序运行过程中，自动计算出了界面30的位置坐标为(798,192)，可知，界面30在游戏主界面中的位置为：左边界与界面20的左边界对齐，整个界面30在界面20的下方相隔一行像素。
在上述的实施例中，每个界面最终计算出来的实际坐标都与相应的布局组件在舞台上的坐标一样，是因为读取到的游戏分辨率刚好与舞台大小一样为1024×768；可见，在游戏主界面和编辑器舞台一样大小时，这三个界面经过布局组件属性设置，在游戏中就会有和编辑器舞台上一样的布局。而当游戏主界面大小和编辑器舞台大小不一样时，采用本发明的上述布局方法所得到的游戏中的实际界面布局相对于编辑器中的组件布局，就相当于进行了整体按比例缩放。
在一些实施例中，有的界面是不规则形状，例如，图3中所示的界面40，界面轮廓具有装饰物，针对这一类的界面，其界面的大小是用程序自定义的接口ufx_get_width()和ufx_get_height()来指定，比如，如图9所示为该特殊的界面40的实际截图，实际大小为737×512，但实际显示的有用信息在于界面中下部，因此在使用本发明的方法进行布局时，通过用接口ufx_get_width返回650×128，以按650×128来进行可视化布局。
以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的技术人员来说，在不脱离本发明构思的前提下，还可以做出若干等同替代或明显变型，而且性能或用途相同，都应当视为属于本发明的保护范围。