游戲UI可以說是整個游戲的基石，在每個面板中都包含了各種控件，控件則可以說是UI的組成成分，是它的元素，

游戲UI程序設(shè)計與開發(fā)

    目前的開發(fā)流程和情況是：在開發(fā)前，由策劃提出需要那些控件，然后程序根據(jù)需求開發(fā)出達到效果的控件。在用這些控件拼UI的時候就出現(xiàn)了不少問題，因為策劃在提出需求，需要哪些控件的時候并沒有給出之后設(shè)計出來的成型的UI圖，導致后面的開發(fā)過程中不斷在調(diào)整控件以適應(yīng)當前UI所要達到的效果，又由于之前控件的設(shè)計沒有能考慮到現(xiàn)在所碰到的需求，而沒有相應(yīng)的擴展性，那么就在不斷的修改中將控件和UI的耦合性提高了，隨著新UI出現(xiàn)，新需求出現(xiàn)，甚至可能臨時要增加新的控件來滿足要求，在不斷的增加需求，改變需求的過程中，控件的功能也在不斷改變，想要能以很低的耦合性滿足所有不斷更新的需求，這樣好擴展性的控件是不容易設(shè)計的。長此以往，就算是勉強完成了策劃的需求，UI達到預(yù)期效果，但是代碼層面的混亂就無法避免了，以后的修改和維護將會變的很難。

    我認為UI里的控件在開發(fā)之前必須要好好設(shè)計，控件的擴展性，健壯性都要注意，盡量降低它和具體UI的耦合性，而且需求不能一變再變。這就要求在開發(fā)前，策劃能拿出所有面板的效果圖，程序和策劃討論根據(jù)效果圖來確定最終需要那些控件，控件的具體功能是什么，明確的詳細的效果，讓策劃來描述，程序根據(jù)這些詳細的需求來周全的設(shè)計控件，通用的地方進行封裝，需要變化的地方留出接口，比如留出該控件的畫圖事件和點擊函數(shù)事件來根據(jù)具體情況具體寫，最好還能留出一個類似友元函數(shù)的接口，讓外面的方法能夠讀到控件里面的數(shù)據(jù)，而不總是用全局變量解決問題，全局變量的時效性不好控制，比如有個按鈕要讀取某個包裹里的值，用全局變量記錄了選中包裹中的值，這樣就要在選中狀態(tài)消失的時候消除掉全局變量的值，否則，我沒有選中任何包裹，依然可以點擊按鈕進行操作，這樣就不對，但是在選中狀態(tài)消失的每個出口都要檢測就讓程序變的很雜亂，同樣就像面板關(guān)閉一樣，如果用全局變量記錄了面板里的值就在在面板消失的所有出口進行消除全局變量，這樣的程序太雜亂，

電腦資料

    單個的控件只要注意自己的封裝行，保持自己的低耦合性，就比較不錯了。在lua里面，控件的封裝是利用表的原表特性，目前接觸到的控件結(jié)構(gòu)是把所有控件集合在一個全局表里，這一個表里面裝了所有的控件，這就涉及到在一次點擊中會遍歷所有的控件來查找該那個控件響應(yīng)，那么如果一次點擊事件的坐標（可能在點擊過程中帶有拖動）擊中了兩個控件的有效區(qū)域，如果不加區(qū)分處理，就會觸發(fā)兩個控件的響應(yīng)，除非是故意要達到這種效果之外，我覺得最好的效果應(yīng)該是，在點擊按下的時候判斷是擊中了哪個控件，那么在之后的拖動和抬起事件中，整個屏幕上都只響應(yīng)這一個控件的點擊事件，就算拖動過程和抬起處在了別的控件上，也屏蔽掉其他的非選中控件的點擊事件。還有控件的點擊事件觸發(fā)只有一種情況，就是在點擊和抬起的時候都在該控件的有效點擊范圍內(nèi)，中間的拖動動作經(jīng)過了什么地方都不用管，因為屏蔽了其他控件的響應(yīng)，不會造成什么錯亂。這些算是控件自身點擊事件的嚴謹性吧。