遊戲開發，UI的資源命名，該有美術做還是前端做？

---

策劃和程序共同定義命名規範

然後美術給出資源時按照命名規範來。

策劃檢查資源時如果不符合命名規範更正之

---

我讓程序定名字，原因很簡單：

1，程序的起名規範可以看得出程序員的代碼水平。

2，美術不具備程序的邏輯思維和知識要求，往往起出來的名字具有二義性、中英文混用、錯別單詞等導致程序無法維護的問題。所以降低他們的工作要求到，只要複製黏貼名字到文件上就好了。

3，美術和程序的合作中總是充滿了各種問題，UI永遠是最致命的，一般老手在開發遊戲的時候最怕的都只有UI，其他的真心是隨手拈來的，因為UI存在一個很大的隱患：改動問題。而好的、技巧性的命名規範也有利於緩解（而非直接解決）這個問題。

4，軟體工程要求：在項目開始前定義好一切名詞，所以不存在多人配合時候的命名問題，出現了則是項目管理問題，及時調整就好。遊戲行業經常出現這個問題是因為隨便一個不咋的的人，連coding是什麼意思都不知道的人，他都能做項目經理、主策劃、主程序這種項目主導型職位。

至於題主的問題開端那個，我覺得其實很多公司招募了一個「資源策劃」，也就是干這個的吧，畢竟策劃這裡可能需要統籌規範一下美術資源，所以美術做好圖，起個名字表示這是什麼，然後資源策劃整理歸檔，同時按照程序要求重命名一份交給程序。當然這是流水線車間的作法，你不能說不好，因團隊而異吧，團隊中個人實力都很強（個人實力很強也包括做事積極）的話，就不需要資源策划了。

————————看到更新了問題，沒法跟帖回答只好修改繼續回答————————

其實資源命名也是屬於程序開發命名的內容，程序開發是要講究命名規範的，所以自然是有專業性可言的。說點題外話，程序對資源命名、策劃建立數據表，這些事情說起來都是跨工種的工作，但事實上這是流水線生產引出的概念，對於一個程序員來說命名規範就像古代打仗武將安營紮寨的能力（我也這麼比喻過策劃建表能力），安營紮寨能力強的才會是上將（劉備被人火燒連營你懂的），乍一看這事兒並不重要，但是項目越是大，而且越是後期，這種小事兒的重要性就會體現出來，這是項目可維護性很重要的一部分。

國外一些專家級、大師級的程序員，在評定你代碼好壞的時候，第一眼看2樣東西，首先你得代碼是否整齊（至少你別超過屏幕右側那條線），其次是你的命名規範，包括資源和變數等。如果這兩樣不對勁，他就不會往下看，直接告訴你"smells bad"。可見有經驗的人是很講究這些細節的，尤其是這背後透露出的是一個程序員寫出來的代碼，是否大多是ijw(it just work)的。

---

誰定為所謂，關鍵是要有規則，美術出資源的時候就得按照規則命名來提交資源。

---

我們一般是策劃定- -

道理上該程序定。

不過策劃和程序猿是親密無間的

所以他們會怎麼定我們也知道 就順便在提需求的時候一起定了吧~

---

任何命名，千萬不要讓美術定命名，我能很確定告知想偷懶的策劃和程序員們，讓美術定命名，就是項目作死的前提了。

拿我這裡一個特效師為案例

一個怪物技能特效，他這麼命名的

Fx_monster_001_skill_01_chongfeng_lvse_high

應該所有人都能明白，這特效啥意思。但是也太長了吧！還有中英文混搭的問題！

我就問他了，你打算這個特效只給這個怪物使用么？

他說不是啊,我再改啊。

還有怪物Skill_01已經清晰表示就是一個技能，你還加那麼多描述，序號，顏色，大小 幹什麼？

這不是把人逼瘋了嘛

---

遊戲美術資源命名，以及遊戲里的角色、技能、物品等等，第一版全都是由策劃提前做。

而且命名嚴格要求用英文，英文如果搞不定可以用拼音或者是混合的方式。

然後由策劃和程序一起進行核對，得到確認的版本。

必須按這個流程走，因為開發過程中程序的工作量很大，代碼寫到一半還得停下來想命名，甚至要額外查單詞，思路直接就被打斷了，再次回到開發的軌道可能得半小時以後。誰能耗得起這個？

由策劃提前做好命名，另一個好處是可以產生規範的文檔，將來其它人接手項目時可以根據文檔去閱讀程序。讓程序去整理文檔不是不可以，但就平均水準而言，肯定沒有策劃做得好。

---

想起了當初我們遊戲定的名字 equipmentqianghua 容我再笑笑

---

策劃定，正常公司都是策劃定。明明規範也是策劃定。策劃連個名字都定不了，怎麼能提清楚美術需求，連美術需求都不清楚，讓美術怎麼畫

---

最好是做分類

UI布局這塊內容可能是程序也可能是美術，同時還可以是策劃。

而策劃做這塊是最好的，為什麼這裡就不說了。切身體會！

如何分類？

我在做這塊工作的時候首先是psd的拆分上就做好分類。

首先，整圖psd拆成各個部件的psd方便後期改動，然後再轉png或者其它格式。

其次，命名規則，我個人命名是這樣的，按鈕類的就打頭BT，底版打頭DB，其它類型的打頭MB，當然你可以更細化，第二個是分界面關鍵詞，例如主界面底版就是DB_MAIN，主界面按鈕就是BT_MAIN，最後是功用劃分，比如主界面按鈕的確定就是BT_MAIN_OK.png，關閉就是BT_MAIN_CLOSE.png。

最後，每個界面元素進行整合存放在單獨的文件夾。

---

應該程序改名字,有時加圖時名稱有序是最好的.

如果一定要美術出你就pic1,pic2...pic1024看看誰先瘋

---

批量的素材按前端要求來命名

但有些UI，比如面板比較零散，一般是美術命名提交後，前端再次重新命名（美術對程序的框架和邏輯的認識根本是兩個世界，很多命名規則過於強求了，就算按程序要求來命名，還是很多不合「標準」，反而不如程序自己來定的好。換句話說，2個程序都可能因為自己喜好不同，而對圖片命名規則都不同，你奢求美術能站在程序的邏輯角度去正確命名？）

多溝通就好了··· 不能奢求程序有審美，也不能強求美術有邏輯，沒有溝通的團隊還是散了吧

---

根據經驗，應由策劃發起會議，詳細解釋需求，技術參與討論，共同制定命名規範，全體項目組人員參與旁聽

命名規範制定好後，誰命名都可以，遵照規範即可

---

策劃與程序溝通，然後策划出圖像需求表，美術按照需求表的規範來命名。

這是我認為的。

不過我遇到的現實是，boss告訴策劃要做啥功能，策劃以圖文形式轉達。

製作的過程中，美術頻繁發現問題，提出問題。

但事後非要等BOSS確認有問題策劃才修改，一般都是讓美術先按原來的做。

耽誤工期。

遇到這樣的團隊，美術的參與感很差，卻勞心勞力。

---

有個職位叫技術美術。

---

理論上美術做會省時間，但是。。。總有但是，很多項目後續這樣反而會很糟糕，各種召喚程序查問題。。。。所以還是程序自己來吧

====================

看了下前面很多答案說策劃定，這我是反對的。美術搞不定的，策劃就一定能搞定？？坑爹的策劃少的話，市面怎麼又這麼多垃圾遊戲

==================

再次補充，還是加個例子妥當。

一般遊戲配置表的名字很多項目都是策劃來，有時部分項目約定遊戲中程序類要和表明一致，結果策劃隨便起個名字就沒事了，結果程序中好多地方要訪問那個你不習慣的名字，何必大家互相這麼呢，這種隨手事情，苦逼的程序還是寧願順手做了，免得後患無窮。

---

這個看美術的能力和素養能不能勝任命名這一任務。

最優方案是由文件創建者，也就是美術人員命名。但是接觸過很多團隊，美術人員都不足以勝任這一工作，所以程序還是拿過來自己改吧。

---

我們這些美術大大豈是你們凡人可以用邏輯性和工整性理解的。

---

由我的經驗來說,最好不要由美術來命名.沒有別的意思...

---

我們當初是花1個小時開會定好這些，弄個框架，美術做的時候就可以加上去，懶的話就扔給程序和外包的素材一起處理

---

在我的經驗里也是策劃定。。。

---

應該有專門的資源策劃來管理，由程序提供工具，或者牛逼點的策劃自己弄了

---

謝邀，第一次收到邀請

我是一個遊戲後端開發，哈哈

開發遊戲，尤其是開發中國古代神話類的遊戲，命名是一件很要命的事，比如，之前有款遊戲，有個玩法叫八魔陣，我想了半天，最終決定用bamo來命名，別怪我太low，我是真想不出比這更貼切的命名了。

至於美術資源這類，我沒接觸過，我覺得還是讓前端命名吧，這樣前端在開發或者調試的時候，不用花太多時間在資源目錄下找需要的東西。折中一點的辦法，策劃給資源定前綴a，a_b, b的事情就讓美術和前端自己協商了。

---

推薦閱讀：