遊戲設計

我是單人爲興趣做遊戲的人，真的不懂
我是不是應該做好本體和骨架、動作後
做個T POSE時衣服的模組
export到unity 後，再在衣服inspector上加上cloth 就可以？

二進位的方法是老方法，叫做位元運算，>> << & |。

假設狀態一 1 狀態二 10 狀態三 100。

X = 111 
if (X & 1) //是否是狀態一
if (X & 2) //是否是狀態二
if (X & 4) //是否是狀態三
X |= 1; //X加入狀態一
X |= 2; //X加入狀態二
X |= 4; //X加入狀態三

然後你的異常狀態可以寫成資料庫，一開始直接窮舉丟入陣列裡。
把異常狀態的不同通通抓出來弄成資料庫欄位每個欄位放入，再把IF判斷式用陣列去循環判斷。

>>No.12733
如果有一種buff或debuff
會因為人物屬性變化的話
那也可以這樣寫嗎?

例如依照使用buff人物的力量跟智力
決定你被扣防的程度跟時間

struct BaseBuffer
{
AActor* _owner; //施法
AActor* _target;//目標
uint32_t _flag;//作用於 行動前 行動後 被攻擊 frame
uint32_t _type; //effect of time? count
int _count;
float _time; //啟動時間
float _end_time; //結束時間
virtual void update(float deltatime)=0;
};

struct HealOfTime:public BaseBuffer
{
float _lev;//等級
float _heal_ratio;//比例
float _heal_point;//一次回多少血
void update(float deltatime);
};

二進位是古老時代運算資源不足時的做法
只能支援固定、沒變化性的狀態
中毒就是中毒
不管是誰放的、用哪招放，扣血量都一樣，也沒有持續時間

如果你要自由度比較高的Buff
能在裡面有動態參數、狀態能改變、能隨著版本更新大量增加新狀態
那就要把狀態包成一個struct(或class)
然後用陣列或串列儲存

兩種例子上面都有範例了
顯然是>>No.12733的版本程式比較短
但>>No.12736可以支援的功能比較多元
除非你的遊戲本來就是低成本小遊戲，否則一般來說會建議用後者

感謝大家回覆，原本以為沒人回了QQ。
----
想在尋問一下關於後者的方法BaseBuffer
所以如果我有一隻角色可能同是有一堆Buff狀態
class Character
{
BaseBuffer buff[BUFF的總數量];
}

然後判斷的時候是，for迴圈
for (int i=0;i=buffMAX;i++)
if (Buff[i].flag == 行動前)
.....

這樣的設計方式是可以的嗎？ 謝謝（或是有什麼更好的方法）

這種東西本來就沒有很固定的寫法
能滿足你需求就行

以比較原始的做法來說，大概像是

//at turn end
for(int ci=0;ci<charaMax;ci++)
for(int bi=0;bi<chara[ci].buffMax;bi++)
   switch(chara[ci].buff[bi].type)
      {
      case POISON:
      case BURN:
         chara[ci].damage(chara[ci].buff[bi].arg[0]);
         break;
      case AUTO_HEAL:
         chara[ci].heal(chara[ci].buff[bi].arg[0]);
         break;
      case FREEZE:
         if(rand()%100<10)
            chara[ci].deleteBuff(bi);
         break;
      }

在各個時機去檢查buff並做出對應的處理
但這樣的缺點是buff種類一多起來程式碼就很髒

要改善這點，可以把buff效果用多型處理

class Buff{
//...
virtual void atStart(){}
virtual void atAttack(){}
virtual void atAttacked(){}
virtual void atEnd(){}
virtual bool isActable(){return true;}
};

class Poison:public Buff{
int poisonLevel;
void atEnd()
   {
   chara.damage(poisonLevel);
   }
};

class Stun:public Buff{
bool isActable()
   {
   return false;
   }
};

在不同時候呼叫對應的virtual function，處理該buff的效果
如果該buff在該時機沒有特別的效果，就會呼叫預設的空白函式
好處是主要戰鬥流程部分的code比較簡潔
可以把各種buff自己的code集中在一起，方便管理
但這種語法比較依賴程式語言
上例是C++的版本，如果是其他語言可能要用不同的語法關鍵字，甚至根本不支援這種做法

這邊有一個MMO RPG 範例
裡面滿滿 buffer 技能 附魔 寫法
https://github.com/DarkstarProject/darkstar

抓一下來觀摩一下

感謝各位，收獲良多
我這幾天會改成這樣的方式製作 m(_ _)m

與其說是維持熱情，不如說要先有一個認知：
所謂的獨立遊戲製作，就是包含了80%的時間去做你不想做的事情，只為了剩下20%的時間你可以做你一直想做的事情。

把這點牢記在心，然後你就會知道你是想做遊戲，還是只想畫圖寫設定。

一聽就知道是挑戰了太難的遊戲才會這樣
先從貪食蛇、棋類、卡牌開始就不會那麼累了

> k8Pgu6JM
應該算寫遊戲的，我簡單說一下我的需求，
我需要的是人設，與跟這人設相關的事件劇本。

舉例來說，現在流行妖精追著獸人跑，
我會需要這妖精的基本人設，
入隊條件，
像是幫忙牠弄到獸人寫真集。
入隊事件，
玩家怎麼得知這件事與怎麼弄到手。
日常事件，
應該就只是閒聊相關話題。
角色支線，
看是有獸人慘遭毒手還是妖精契而不捨的故事。
角色結局與條件，
只有一個結局，就不寫條件也OK，
但是如果有複數結局，
像是跑完角色支線一個結局，沒跑完又一個結局，
請寫一下條件。

外包的部分大概就這樣，該角色的其他運用，
會以這些內容為參考去自行運用，或著視情況再次外包。

>>No.12726
先說結論，你需要的不是人設，你需要的是一個幫你把心中故事寫完的人。
要先知道你在你提的這個專案中，你是主導一切的製作人。從你的發文來看先假設你是負責程式這一塊，你現在應該要做的事情應該是這樣：
1. 決定遊戲玩法，從你目前的概念來說AVG應該是很足夠。
2. 決定遊戲風格，前期這個部分你可以直接跳過美術製作，直接在網路上找到各式各樣的素材來套，事後真的有需要再找美術：
美術：http://darts-x.sakura.ne.jp/m/
http://masato.ciao.jp/haikei/furemu.html
音樂：http://maoudamashii.jokersounds.com/
3.人設跟劇情走向，這個是你要寫好的，像是獸人與精靈的個性，故事發生的背景等等。以你的回應來看玩家應該是操縱精靈去追獸人，那你就要從精靈的角度去把你所想的各種事件設計好，像是你舉例的入隊條件、日常事件等等。事件內容是你要去設計，外包的劇本工作則是把對話內容給填好。
4.依照AVG遊戲的分歧選項方式把劇情分支走向訂好，包括各種觸發條件，這邊以片輪少女為例：https://i.yuki.la/vg/1356435489881.png，這個是你要去做的，不是交給外包劇本，外包劇本工作是把對話內容給填好。
5.開始製作遊戲雛形，利用美術素材拼出一個可以動的遊戲，以AVG遊戲來說，雖然當中應該是會有一堆分歧選項或是依據不同好感度導致對話不同，但是都先不管，把一個可以從頭跑到尾的線做完，確認好每個段落的故事演出跟對話，把一條線的故事完成。詳細台詞對話交給外包給專業劇本去寫，最後只要將外包的文字套進去就可以玩玩一條故事線的遊戲。故事內容是你要去設計，外包的劇本負責的是詳細對話內容。

先把這些"試著"完成，你就會知道你需要外包的東西有哪些。

>>No.12728
我是2u0KHUas，直接說了，我手上沒有故事。
但是我認為我的玩法需要足夠的故事，
而該玩法以類型來說，可以歸類為RPG。

所以我需要的就是人設，
像是獸人與精靈的個性，故事發生的背景等等，
而玩家跟獸人與精靈是不同的角色，
所以才會有入隊條件。

就你的說法，是人設等等的東西，
沒有辦法外包?

目前看來原PO就是喜歡寫寫劇本和畫畫人設不是嗎?

>>No.12730
我是大羅伊，直接說了，你~還沒準備好！
遊戲這塊沒有什麼是不能外包，你出得起資金的話甚至還可以外包整個遊戲團隊，從零開始把你的遊戲打造出來。

如果你的遊戲是以故事為主體的RPG類型遊戲，技術方面RPG Maker版在下。回到遊戲本體來說，你需要的不是人設，你需要的是知道怎麼把遊戲做出來。

你可以試著先Google"獸人與精靈"，找篇你喜歡的設定，把一小段劇情全部照抄轉成遊戲形式，分歧劇情找一個段落自喜想像個分支填上，其他入隊條件啥地都別管。

先做出來看看如何，你就會知道為什麼我會說：你需要的是知道怎麼把遊戲做出來。

>>No.12731
你是說像這樣?
https://www.sendspace.com/file/6quba7

這裡是原PO~

>一點一點做，直到變成習慣
真的也只能這樣了

>原PO有興趣接外包嗎? 我缺人幫忙寫人設、劇本之類的東西
早一點說的話，也許就可以跟你一起做了
現在工作和學業繁忙，能擠出一點時間做自己想做的事情已經很勉強了

>>No.12723
果然是這樣，遊戲很多東西都很硬
雖然我滿喜歡大部分遊戲製作的東西，但心裡還是有個喜好排序
像是寫程式會一直想玩演算法，討厭那些繁瑣又無聊的碼農工作

>>No.12724
現在在做的是click系列的遊戲，暫時只有html5自己刻
難度上應該還好，只是弄介面弄到有點崩潰

Scratch網頁版不能打中文是因為沒有中文字型
下載版不知道能不能抓到字型?

為什麼不用Unity?

諸君，主架構基本完成了!開放給各位試玩!
因為目前考慮到修改內容的方便性，所以內容物是英文，除了些許部分有稍微修改以外，大部分內容可以參考開串的那篇原梗文
然後是不久前腦洞大開弄的宣傳影片(ﾟ∀。)
https://www.youtube.com/watch?v=HoG4d6g1v-I

https://scratch.mit.edu/projects/153292605/
因為程式碼之類的東西都是完全公開的，也歡迎閒人自由修改或者除錯優化喔!

借串請教
Scratch要怎麼匯入一張大圖當背景？
想把角色固定在中央，捲動背景
像RPGmaker那樣
但是匯入的圖片都會自動縮小還有放大限制的樣子

這是add後

3D-max小弟機乎忘光了，只供參考用

小弟推測問題應該是你的建模的過程吧
你在 edit poly 之後應用是用對稱複製 最後加上 smoooth
這個過程感覺是沒啥問題，只是在加上骨架的之前
我會建議在 smoooth 的時候轉全打散轉成poly物件
(沒記錯的話右鍵應該有個 C???? TO Poly 就可以打散轉成poly物件)
之後再上骨架，應該就沒問題了

原因 (小弟是 MAYA 派的，參考就好)
在maya中在看的模型些資訊，像是角度，位置，大小等資訊
是直接顯示在旁邊給你看的，但小弟上骨加前會把這些資訊歸零
在上骨架，不然機乎都會出問題，這方面我猜應該跟3D-MAX差不多吧才對
應該是你建模的歷史過程中，有什麼資訊留下來導至會位移
所以我會建議你打散再上骨架看看

至於為什麼save之後不能動，小弟就無能為力了

>>樓上那個我個人不推薦
為什麼?
看起來該工具的目標是不怎麼需要技術的
要寫到堪用應該不難吧?

我以前就覺得電子小說類的遊戲應該要有更簡易的工具才對
又不是3D類的那麼苛求效率

我覺得遊戲設計就是看需求啦，很多人會直接推難度較高的unity也是因為這樣對未來比較有幫助

NVL的問題是NVLMaker for BKEngine這款還在內測中，索取與使用上都相當麻煩，索取條件是使用NVL做過一款遊戲，所以其實相當麻煩

做遊戲需要一大～票數都數不清的技能
程式只是當中一部份的統稱
其他還有美術、音樂、演出、編劇等等跟程式無關的東西

如果你們學校有好好教你有好好學
資工系應該會把遊戲程式需要的功力都教給你
但是這年頭流行現成引擎
不需要像以前一樣紮紮實實地從底層寫起
所以你學到的東西可能有很大一部分是用不到的

至於資工系裡面不屬於資工的課程（所謂的通識）
這些就是大學教育的原罪，沒辦法的
但反正你想要大學畢業的文憑的話遲早還是得修過這些課，躲不掉的

整體來說
除非你意志堅定，不讀大學也要做遊戲
不然我還是建議你把資工系讀完，不要轉去遊戲設計系之類的地方
畢竟在台灣做遊戲吃不飽飯
讀資工至少你有退路，做遊戲賺不了錢還有一堆行業缺程式

尤其是如果你想做很有創意、很開創性、很特別、很互動的遊戲的話（例如：PMGO）
你可能會需要用到某些不常用的資工技術
這時你們團隊的程式（也就是你）的功力就很重要了
但如果你只想做做一般RM等級的東西，那就沒什麼差別

去接外國的案子 歐美國家薪資高很多

應該說許多行業都不太需要大學的學科
需要的是大學的學歷

看你要做到多深入
在下反而是覺得以前沒有好好把一些科目讀好太可惜了...

看你要做到哪個程度的遊戲,
如果是2D RPG那基本上什麼都不用會, 用RM也行

如果是3D那線性代數要稍微有些概念,
理論上計算機圖學好像會需要不過這部份所有3D引擎都會幫你處理掉,
微積分也是理論上算圖會需要但是3D引擎也都會幫你做掉,
如果要做動作遊戲類的話物理最好要懂一些,
如果要做到有物理引擎的程度的話那就要懂更多

計算機網路基本上很需要, 雖然很多免費套件可以幫忙處理,
但是寫出來的封包大小跟能掌控到多細的細節就有差,
不過台灣這邊好像也不是很重視這塊, 沒概念也沒差

組合語言基本上叫超重要, 但是不是要你去刻組語,
而是要有哪些程式碼去編成的Code其實對電腦負擔會到哪個程度,
有沒有辦法做到有效的優化基本上要看對組語的概念,
但是其實這種東西遊戲廠商不會管, 所以當作沒一回事也OK

離散數學雖然直接來說用不到,
但是要平衡調整的時候有概念才比較好知道哪些參數設計起來會太奇筢,
會節省掉很多不必要的Try&Error的時間

資料庫如果是要寫網遊或頁遊就很重要,
如果純寫單機就用不到

物件導向是不會的話就不要說自己是搞程式的,
要不然做遊戲要跟人協作很頭大, 自己維護程式碼也很頭大

系統分析看得懂就看得懂, 到了業界每間公司會自己有另外一套,
學校教的基本上只是基本型而已


自己本身是刻3D引擎刻了算很有經驗的,
最覺得可惜的是當年沒把線性代數學好所以很多東西看資料還是一個頭兩個大,
雖然當年物理也沒學很好不過自己做的遊戲對物理引擎的需求比較低,
但是不管怎麼說師父帶入門修行看個人, 學校沒教的還是要自己有辦法補

>>No.12686
有在用github嗎?
我對建立物理引擎有興趣