程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> 更多編程語言 >> 更多關於編程 >> 游戲開發設計要注意哪些問題

游戲開發設計要注意哪些問題

編輯:更多關於編程

       游戲開發設計必須注意哪些問題?游戲開發設計的黃金法則!未來是一個游戲的時代,所以現在很多人都開始從事游戲開發這方面的工作,可是在當下的時代新的游戲不斷的被開發出來,可是有多少游戲能夠真的吸引到玩家呢,究竟其中存在什麼問題,下面我們一起來看一下前輩們總結出的相關經驗吧。

    游戲開發設計要注意哪些問題 三聯

      1、避免游戲登錄時的頻繁的點擊

      在新游戲出來是許多的玩家都想進去看下游戲的可玩程度,之前大家登錄是卻需要點擊好多的點擊,大家的激情就被你那頻繁的點擊給抹掉一半了,等到進去是發下游戲不是很理想時,基本上激情給抹滅的差不多了。一般設置的時候按鈕點擊不要超過三次最好。

      2、隱藏復雜性。

      “高級”標簽的作用就在於此。在將玩家引入游戲玩法體驗時,所有當前不相關的內容都需要被隱藏到其他對話框中。這種想法不是說要移除游戲的復雜性(這也算是種恰當的做法),而是不需要立即呈現這些復雜內容。當然,你可以允許玩家改變參數,但是不必要求甚至強迫他們查看能夠改變哪些參數。那些想要做這件事情的人自然會找到可以幫助他們實現目標的選項,但是 要記住的是,試圖改變參數的玩家比例不足50%。對於50%以上的玩家,你只要呈現無需他們更改的選項和功能,因為過多的選擇只會讓他們備感困惑。

      3、在同一個地方向玩家呈現所有信息。

      保持信息呈現位置的一致性。你需要引導玩家查看某個地方而且只需查看這個 地方就能夠獲得所有游戲信息。當然,信息呈現方面有個技巧,就是對信息內容進行過濾,這樣玩家就無需去注意過多來自游戲或其他玩家的信息,信息量過大可能 會導致玩家丟失關鍵信息。但這是信息的過濾層面,留待以後作深入探討。必須注意,如果你只是高亮顯示錯誤或遺漏的輸入內容,也算未遵守這個規則。當你在網 頁頁面中填寫表格時,它們經常采用的就是這種方法,這當然是允許的。但是,如果你要這麼做,不要只使用文字顏色來暗示錯誤,這會給色盲用戶帶來不便。你需 要做的是反向高亮文字內容,所以不要只將不當文字顯示成紅色,還要將背景顯示為紅色。這樣,即便是色盲用戶,也能夠領會到輸入錯誤。

      4、過濾信息,呈現含義。

      能夠呈現信息固然很好,但是你分享的信息越多就越好嗎?從某種程度上來說,情況確實如 此。但是,如果信息大量湧向用戶,他們就會感到反感。“你確定要這麼做?”等重復性信息會成為垃圾信息,會被用戶忽視或直接點擊,而垃圾信息過多會使用戶 忽略重要信息。設定重復性對話框的呈現冷卻時間是種不錯的做法,比如3次呈現某個對話框後,在預設的時間內不再呈現該對話框,可以將預設時間設定為上次對 話框呈現的5分鐘時間內。通過這種方法,用戶就無需不斷點擊相同的對話框,也就不會受這些信息煩擾。允許用戶過濾某些信息類型也是個不錯的做法。比如,允許用戶忽略來自腳本系統的警告或信息。這需要對信息進行恰當分類,這樣系統才能識別其屬於哪個類別。雖然麻煩,但卻是可以采納的做法。而且,在某個地方保存所獲得信息的列表指未經過過濾的所有信息,同時確保用戶知道這個地方。這樣,如果他們需要這些信息,可以隨時查看。對於信息的呈現,還有點值得一提:將他們所做出改變的含義告知用戶很重要,尤其是工具。如果用戶在虛幻編輯器中點擊“所有內容使用動態光照”按鈕, 那麼需要告知他們此等做法會對幀率產生的影響。使用在屏幕上通過顯示文本來解釋每個按鍵作用的傳統方法往往是不夠的,因為內容或其他設置的不同經常導致某 種控制產生的影響發生變化。如果只是2000 poly場景中的單個對象,那麼設置“所有內容使用動態光照”不會產生負面影響,只有當在10000 poly世界中渲染400個對象時,負面效果才會明顯。所以從根本上來說,我的觀點是要對控制改變可能引發的其他改變進行內部分析,將其與可能對用戶產生 極大改變的其他影響方法相比較。再次強調,注意對話框和信息的呈現次數也是必要之舉,因為總是會出現某些特殊事例,使得應用認為用戶提出的是非意願行為要求,因此而不斷發出警告。

      5、保持所有UI呈現內容一致性是關鍵。

      有些做法是顯而易見的,比如應用中可以使用單選按鈕或復選框,但是不可 融合使用這兩者,在所有對話框中,保持所使用文字類型、字體和大小的一致。但是,還有些更為精致的東西。比如,如果你需要在工具中提供路徑,保持使用浏覽 器按鈕,不要期望用戶會直接輸入路徑。XCode便是個絕佳的反例。還有個不錯的做法,使用滾動欄而不是要求用戶輸入數值,但可以仍支持用戶使用數值輸入 方法。數據輸入最重要的部分之一是從一開始就避免用戶輸入不良或沖突性數據。應用程序中有許多代碼可以處理不良數據,但是從一開始就杜絕不良數據的輸入是個更好的方法。這正是使用預設下拉菜單的原因所在,因為你就可以確保程序不會獲得拼寫錯誤的單詞以及不良的數據。

      6、如果能夠實現無需用戶輸入內容的話,就采用這種方法,這是第5點的擴展。預設下拉菜單標簽或者在需要用戶輸入的地方提供默認文本,這樣如果用戶不願意的話,就無需自己動手輸入任何文本。所有東西都應當有默認選項。

      7、可以設置通過多渠道查看相同對話框,Windows XP在這一點上做得很好,允許用戶通過多種途徑打開相同的控制對話框。這樣做是可以接受的。應當注意,在使用這種方法時,應當保證對話框本身的一致性。無論你通過何種渠道打開對話框,它們都是完全相同的,包括外觀、表現和功能。

      8、控制設置於相同且唯一的地方,這是第6點的擴展。同種控制只應當存在於單個對話框中,而且不可設置外觀看似相同但功能不同的控制,這會讓用戶在理解上遭遇困境。同樣,XCode在這個方面做得很不好。

      9、對話框深度不可超過3層。

      如果你制作的是RPG游戲的話,或許可以設置4層。對話框深度設置的底線是,不可 讓用戶對他們所處的位置、正在做的事情以及原因感到困惑。你還需要在對話框樹中呈現他們所處的位置,添加後退鍵固然不錯,但是一個小的對話框樹指示器會顯 得更好,可以參照Windows系統資源管理器的做法。

      10、對話框切換。

      對話框切換時間最好在150毫秒內完成,最多只能是200毫秒。如何切換以及切換的精美程度 都無關緊要,用戶想要的是短暫的響應時間,尤其當他們通過UI對話框樹導航的時候。華麗但漫長的切換就像是在跟用戶開玩笑。用戶剛開始或許會覺得設計很 酷,但是一段時間後就會感到厭煩,你要做的只是讓整個過程更快就可以了。

      11、讓所有內容均可配置和保存。

      允許用戶修改每個窗口的大小以及位置,並將其保存。設置默認選項是很簡單的事情,但是確保應用程序能夠保存所有用戶做出的改變。記住,對話框布局能夠給用戶節省大量時間。

      12、任何能夠在視覺上影響其他內容的事物都應當即時變更。

      如果你不知道光照或服飾改變對角色以及其他內容的影 響,那麼就應當即時呈現這些內容,這樣用戶就能夠看到他們改變設置後的效果。有時候,這一點可能無法實現,因為單項設置的改變會影響到其他內容(游戲邦 注:比如在腳本值的修改中,只有修改另一個後才能使之生效)。但在可以實現這種即時呈現的內容上,你最好這麼做。

      13、區別呈現信息和可變更數據。

      用戶無法改變的信息應當以特定的方法呈現,讓用戶明白這些是靜態信息。可變更 信息應當以略微不同的字體、顏色或大小呈現,或者以某種用戶可以顯而易見感受到這些是可變更內容的方法呈現。這個方面跟第2點息息相關,如果用戶意識到某 些數據是可變更的,他們就會尋找更改的方法,開始探索你的對話框UI結構。

      14、對PC開發者而言,你需要查看打開對話框時內容是否真正呈現在屏幕上。

      許多情況下,用戶會改變他們的顯示器設置,隨後忽然發現他們已保存的對話框從屏幕上消失。你需要查看是否出現這種情況。我不止一次碰到這種問題。

      15、最後這點可能也是最具爭議性的規則:

      你設計的目標是為了滿足數據變更流動,還是為了滿足數據聚集?簡單介 紹下背景知識,針對數據變更流動的設計意味著你會將許多不相似的數據聚集在單個屏幕、對話框和UI版塊上,按照用戶需要展開的流程來排序,這樣用戶可以從 中選擇他們需要前往的步驟,比如輸入名稱、選擇文字類型、選擇游戲類型、選擇服務器和進入游戲等。這些元素都是不同“類型”的數據。多數游戲會將它們分離 成多個屏幕,添加許多額外的按鍵和信息,供用戶用來修改體驗,但實際上多數用戶不會去使用。另一種是“相似數據”分組方法,每個屏幕都圍繞特定功能設計, 用戶可以從中做出選擇。數據流動屏幕會將用戶必須選擇或改變的所有具體功能放在一個屏幕中,讓他們可以同時看到要求,做出選擇然後繼續前進。一種重在呈現 選項,另一種重在簡化過程使用戶能夠快速抵達想到的地方。對於這個問題,我的個人看法是兩種方法都是合理的。我偏向於呈現數據流動方法作為默認方式,因為多數人都會使用這種方法,尤其是首次使用應用程序的 用戶。等用戶熟悉應用程序後,可以讓他們使用另一種方法,因為他們需要更快地找到自己想要的內容。這一點與第2點緊密聯系,復雜性可以存在,但不是必要因素。

    1. 上一頁:
    2. 下一頁:
    Copyright © 程式師世界 All Rights Reserved