PTT動漫區 / TypeMoon

Fw: [ＸＤ] FGO要舉辦技術講座了

看板TypeMoon作者 (沒了戒指的魔王)時間8年前 (2017/07/03 11:22), 8年前編輯推噓21(21推 0噓 63→)
留言84則, 19人參與, 最新討論串1/1
原文刪掉，主要是來補上後續消息，後面有相關更新會再補上 http://gamebiz.jp/?p=187946 這裡已經有部分當初技術討論的文章 關於「定期的な更新」「長期的な運営」的技術總結就是 「分工且表單轉換自動化」 其實裡面提到的技術也不是啥最新科技，應該說是 "我們最初沒有人力採用這樣的設計，現在人力足夠後就有機會導入別人早就 行之有年的技術了(笑" 7/5 新增關於伺服器基礎建設相關的文章 http://gamebiz.jp/?p=188024 7/7 新增"技術力がなければ面白いゲームを創れない理由とは… 変化に強い構造の作り方" 標題看起來很聳動，但內容其實是很基本的程式設計概念 結論上來說，就是善加使用 Design Patterns http://gamebiz.jp/?p=188232
→
07/03 11:24, , 1F
最大進步應該是免停服維修
07/03 11:24, 1F
※ 編輯: Golu (61.219.144.228), 07/03/2017 11:27:20
→
07/03 11:28, , 2F
連維修石也要吃掉~WTF
07/03 11:28, 2F
※ 編輯: Golu (61.219.144.228), 07/03/2017 11:28:55
→
07/03 11:32, , 3F
「找個金飯碗IP，之後要怎麼搞都慢慢來不要急」
07/03 11:32, 3F
→
07/03 11:33, , 4F
急」
07/03 11:33, 4F
推
07/03 11:34, , 5F
抱到好IP大腿才是正解
07/03 11:34, 5F
推
07/03 12:04, , 6F
哈哈，要不是抱到型月早就倒了
07/03 12:04, 6F
推
07/03 12:14, , 7F
excel 來管理 ，wow
07/03 12:14, 7F
→
07/03 12:18, , 8F
樓上，遊戲資料表單用Excel基本上沒啥問題
07/03 12:18, 8F
→
07/03 12:18, , 9F
Excel wwwwwwwwwwww
07/03 12:18, 9F
→
07/03 12:19, , 10F
不是資料庫直接抓就好惹嗎
07/03 12:19, 10F
→
07/03 12:22, , 11F
企劃要維運的資料用excel基本上沒啥問題呀
07/03 12:22, 11F
推
07/03 12:25, , 12F
自己建database很難嗎www
07/03 12:25, 12F
→
07/03 12:26, , 13F
問題是有建database的必要嗎？
07/03 12:26, 13F
推
07/03 12:27, , 14F
看到excel的部分了，這樣也敢辦講座，真是了不起
07/03 12:27, 14F
→
07/03 12:30, , 15F
Excel就是方便管理跟輸入數值資料的工具，儲存到database是
07/03 12:30, 15F
→
07/03 12:30, , 16F
另一件事啊...
07/03 12:30, 16F
大家不要看到excel就興奮(?)了，一般遊戲開發時，數值設計或者是關卡內要放置 啥獎勵與怪物都是由企劃主導，設計工具/介面時會以最範用的表單工具進行參數 設置，excel是最常使用的表單介面 文章中是將參數設置好後，再交由表單建構工具把表單內容轉換成程式對應的參數 ※ 編輯: Golu (61.219.144.228), 07/03/2017 12:34:19
推
07/03 12:34, , 17F
重看了一下，企劃excel放在SVN，輸出CSV放在GIT，在用Jekin
07/03 12:34, 17F
→
07/03 12:34, , 18F
s去跑，感覺就是為了企劃端完全不懂電腦才做的流程，如果企
07/03 12:34, 18F
→
07/03 12:34, , 19F
劃端不會用其他工具，excel其實也算是沒辦法中的辦法了
07/03 12:34, 19F
→
07/03 12:36, , 20F
其實日本很多IT公司還是很誇張的，我親眼看過日本人企劃給
07/03 12:36, 20F
→
07/03 12:36, , 21F
前端網頁工程師的改變清單是把網頁整個印成一張A3，然後便
07/03 12:36, 21F
→
07/03 12:36, , 22F
利貼貼滿說要改什麼
07/03 12:36, 22F
推
07/03 12:37, , 23F
這很正常吧... 企劃誰跟你看code....
07/03 12:37, 23F
→
07/03 12:37, , 24F
企劃 -> PM -> SA -> SD -> PG
07/03 12:37, 24F
→
07/03 12:38, , 25F
阿中間人力省掉了你PG就擔待點一人扛四個人的工作～ 正常
07/03 12:38, 25F
→
07/03 12:40, , 26F
放svn之後excel在輸出成database能吃的格式，應該不難理解吧
07/03 12:40, 26F
→
07/03 12:40, , 27F
？當你遊戲資料欄位是好幾十欄好幾十列的時候，這樣才是真
07/03 12:40, 27F
→
07/03 12:40, , 28F
正省企劃工時的方法
07/03 12:40, 28F
→
07/03 12:42, , 29F
很多時候玩家抱怨遊戲內容太慢活動太少，根本不是RD開發不
07/03 12:42, 29F
→
07/03 12:42, , 30F
完，而是企劃上的來不及。這包函數值面、設計面、溝通面、
07/03 12:42, 30F
→
07/03 12:42, , 31F
文案面、跟測試面...
07/03 12:42, 31F
→
07/03 12:45, , 32F
而且雇用企劃誰管你程式強不強，想法正確跟能夠迅速交接工作
07/03 12:45, 32F
→
07/03 12:45, , 33F
才是真的
07/03 12:45, 33F
→
07/03 12:47, , 34F
用execel才好啊...
07/03 12:47, 34F
推
07/03 12:48, , 35F
真 Der 好企劃可以省非常多事情
07/03 12:48, 35F
推
07/03 12:50, , 36F
雖然fgo營運的確為人詬病，只是不希望大家為砲而砲
07/03 12:50, 36F
其實核心概念就是"分工"，一但工具越便利，分工越明確，每個單位就能減少處理額外 工作的時間 文章中也提到多工同時開發遊戲不同項目的更新，這部分實務上還是容易遇到兩邊開發 的修正互相衝突的可能，文章中也沒有特別提到如何處理，有可能多工僅限於活動機制 的設計，最終程式的更新還是得由少數人員進行處理，這部分就是開發流程的問題
推
07/03 12:54, , 37F
我之前公司是有開發社內工具和介面給企劃和行銷人員用，如
07/03 12:54, 37F
→
07/03 12:54, , 38F
果沒有人力去開發和維護社內工具，excel算是最好的辦法了
07/03 12:54, 38F
推
07/03 13:03, , 39F
小作坊當然是盡量從簡，有現成的就用現成的
07/03 13:03, 39F
※ 編輯: Golu (61.219.144.228), 07/03/2017 13:23:48
推
07/03 13:21, , 40F
結論 你要先有個鍍金IP 然後技術什麼的開服後再來慢慢弄就
07/03 13:21, 40F
→
07/03 13:21, , 41F
好
07/03 13:21, 41F
→
07/03 13:21, , 42F
遊戲資料欄位是好幾十欄好幾十列的時候才更應該用自動化的
07/03 13:21, 42F
→
07/03 13:21, , 43F
工具吧。
07/03 13:21, 43F
→
07/03 13:22, , 44F
演講題目：如何成為石頭精算師
07/03 13:22, 44F
→
07/03 13:22, , 45F
資料少的話就算了，資料多的話調整起來會很煩人的。
07/03 13:22, 45F
推
07/03 13:24, , 46F
只是我覺得FGO應該已經大到可以養一個這種team了啦，現在還
07/03 13:24, 46F
→
07/03 13:25, , 47F
說自己是小作坊的話我覺得有點誇張啦 XD
07/03 13:25, 47F
→
07/03 13:26, , 48F
原來master data是企劃規劃ㄛ 懂惹 沒細看還以為是玩家
07/03 13:26, 48F
→
07/03 13:26, , 49F
資料
07/03 13:26, 49F
這邊的Master data指的是每周要更新的"主要資料" 一般多工開發時，會有許多的旁支資料，最終要更新時會合併成主要資料 比方說，這次的不夜城有的人負責關卡掉落數值，有的人負責關卡敵人強度數值 開發與測試時，一般是兩個團隊各自設置與測試自己負責的部分 當兩邊都設定好後，再把檔案合併(Merge)成同一份主要資料，提供給人員上傳至server
推
07/03 13:28, , 50F
小作坊高營收才好啊,你看$ony在Anip背後笑得多開心啊
07/03 13:28, 50F
※ 編輯: Golu (61.219.144.228), 07/03/2017 13:31:10 ※ 編輯: Golu (61.219.144.228), 07/03/2017 13:32:01
→
07/03 13:31, , 51F
怪物hp，名稱，模組，幾回合放哪個buff(遊戲企劃面所有noc
07/03 13:31, 51F
→
07/03 13:31, , 52F
的狀態變化都叫做buff,跟一般玩家認知不一樣），碰到特定角
07/03 13:31, 52F
→
07/03 13:31, , 53F
色需不需要有特別演出？敵人間如何增援？Ai模式？各項機率是
07/03 13:31, 53F
→
07/03 13:31, , 54F
不是特殊公式...一堆凡足不及備載的項目要設計跟填表，更甚
07/03 13:31, 54F
→
07/03 13:33, , 55F
者是好幾份以上的表格、負責企劃要互相配合去新增、編輯資
07/03 13:33, 55F
→
07/03 13:33, , 56F
料，哪有什麼自動化工具可以用...
07/03 13:33, 56F
"設計的過程"當然是沒有自動化的，能有自動化工具的場合就是"轉換表單"讓程式能吃到 指定變數的數值 文章中的自動化也只有針對檔案轉換 ※ 編輯: Golu (61.219.144.228), 07/03/2017 13:36:31
→
07/03 13:36, , 57F
開發了一個不適用所有狀況的工具，結果造成每次資料片要用新
07/03 13:36, 57F
→
07/03 13:36, , 58F
功能反而要去修改那樣「工具」，結果造成額外的人力時間成
07/03 13:36, 58F
→
07/03 13:36, , 59F
本，這樣的狀況也不罕見呢
07/03 13:36, 59F
→
07/03 13:37, , 60F
是啊，表單自動化的轉存格式，這當然毋庸置疑是可行的XD
07/03 13:37, 60F
→
07/03 13:38, , 61F
不過專門負責工具設計的單位也是存在的，我所任職的公司與
07/03 13:38, 61F
→
07/03 13:38, , 62F
同事前任公司都有專職負責優化轉換與開發工具的單位
07/03 13:38, 62F
※ 編輯: Golu (61.219.144.228), 07/03/2017 13:39:35 不過就像mkhwz所提到的，開發工具如果欠缺擴展性以及缺乏維護人員，便會成為降低產品 活力的原因 ※ 編輯: Golu (61.219.144.228), 07/03/2017 13:42:10
推
07/03 13:42, , 63F
看到master data嚇死，我還以為真的用excel存玩家資料
07/03 13:42, 63F
推
07/03 13:43, , 64F
參數設計不願或不能模組化的話就只能一項一項手動啊,可是DW
07/03 13:43, 64F
→
07/03 13:43, , 65F
的錢沒有拿去請足夠量跟質的人才會做得那麼辛苦吧
07/03 13:43, 65F
→
07/03 13:44, , 66F
不過這點有重要到拿出來講嗎（抓頭 不過很多講座也是一
07/03 13:44, 66F
→
07/03 13:44, , 67F
堆廢話
07/03 13:44, 67F
所以我文章很快就點出結論啦(笑
推
07/03 13:47, , 68F
所謂的「開發工具」從簡到繁都有啊，陽春一點的，Excel上
07/03 13:47, 68F
→
07/03 13:47, , 69F
寫個巨集能自動去試算機率就算是了啊。或者一隻不到幾十行
07/03 13:47, 69F
→
07/03 13:48, , 70F
的小程式，可以像我發的那幾篇一樣可以去計算掉落率那種也
07/03 13:48, 70F
→
07/03 13:48, , 71F
可以節省很多測試時間的。
07/03 13:48, 71F
推
07/03 13:49, , 72F
所以用Excel沒錯啊 （？
07/03 13:49, 72F
→
07/03 13:49, , 73F
khwz大概以為是世紀帝國的編輯器之類的東西吧，不用到那麼
07/03 13:49, 73F
→
07/03 13:49, , 74F
複雜。
07/03 13:49, 74F
→
07/03 13:51, , 75F
excel這項工具的極限還是蠻容易碰到的，所以我說數據一多
07/03 13:51, 75F
→
07/03 13:51, , 76F
的話還是要寫自己寫一些工具出來用。
07/03 13:51, 76F
→
07/03 13:52, , 77F
隨你猜囉XD 我只是就工作實務上碰過的狀況做經驗分享而已
07/03 13:52, 77F
※ 編輯: Golu (61.219.144.228), 07/03/2017 13:59:58 ※ 編輯: Golu (61.219.144.228), 07/03/2017 14:16:54
推
07/03 14:44, , 78F
簡單的說就是一場自曝其短的說明會wwwwwwwwwwwwwwwwwwwwww
07/03 14:44, 78F
推
07/03 14:54, , 79F
excel ,沒有問題啊，只是他們公司已經賺了不少吧？應該會
07/03 14:54, 79F
→
07/03 14:55, , 80F
有更多錢找人來做事，程式優化，資料庫處理等等，在一些狀
07/03 14:55, 80F
→
07/03 14:55, , 81F
況，也處理過 txt 檔來處理資料轉換或處理 o,o
07/03 14:55, 81F
推
07/03 15:08, , 82F
txt檔我反而不會有意見，因為拿來開txt的一般不是記事本..
07/03 15:08, 82F
→
07/03 16:59, , 83F
地圖編輯器或者是模組編輯器那種程度的開發工具實務上也存在
07/03 16:59, 83F
→
07/03 17:00, , 84F
也有使用開發工具(如unity)建構出的模組編輯器
07/03 17:00, 84F
※ 編輯: Golu (61.219.144.228), 07/07/2017 10:42:40
‣ 更多 Golu 的文章
文章代碼(AID): #1PMRXfOW (TypeMoon)
TypeMoon 近期熱門文章
更多 近期熱門文章 >>
PTT動漫區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 Golu 的文章
文章代碼(AID): #1PMRXfOW (TypeMoon)