遊戲設計

>要改編一部原創漫畫為遊戲
會開這種條件就是想接收該漫畫的客群
那直接去找龍少年之類的漫畫月刊上的人氣作者洽詢就好了

不如直接找本本畫家合作出遊戲比較快，原創非18X很難活。
18X紅回水面上反而比較容易，至少餓死率比較低。

https://discord.gg/CkMmXjY

game maker的做法
https://www.dropbox.com/s/cmdl6qv6ucvjqyr/Pulseman8.0.gmk?dl=0

unity的話你直接看官方的unitychan2d教學會比較快

>>無名氏: 只拿內建的(現實)物理運動去運算，會漏掉很多遊戲中才會出現的(非現實)物理問題 (JbVZvGbg 17/04/30 22:42)

其實現實中也會有這種狀況，像搭電梯的時候，只是電梯通常不會很快。感覺上應該是剛體之類的沒有設好才會變這樣吧。

可能是重力加速度小於平台的下降速度。
要不然就是有其他動作腳本會偵測是不是在平台上之類的。不然照
理來說重力應該狠狠的把腳色壓在平台上台才對。

>>通常是內建的物理處理掉落使用"重力加速度"，初速度從0開始，才沒辦法跟"等速度"的平台一起貼著移動
BUG就在這邊
一個往下掉的人踩到了一個等速下降的平台而暫時停止掉落
再次開始自由落體的時候應該是從這個平台的速度開始加速
而不是從零
但是只要你一開始加速，就會踩到平台而回到平台速度
結果就是貼著平台

現實物理不會有BUG
會有BUG發生一定是因為你的人造物理不夠現實

角色狀態"移動"
只處理角色左右移動

角色狀態"跳躍"
角色腳下沒東西時,開啟物理

角色狀態"站在移動平台上"
當角色為此狀態,角色的高度與此平台同步,且關閉物理

>>No.12708
>角色狀態"站在移動平台上"
>當角色為此狀態,角色的高度與此平台同步,且關閉物理
這可能會有其他問題
在平台上被敵人攻擊時?
或是平台超長(半個畫面長)還要在上面戰鬥時?

>>No.12709
>在平台上被敵人攻擊時?
這個問題我覺得可以跟 [在自由落體當中遭受攻擊時的受傷動作要怎麼播放]一起討論
根據作法的不同平台上的受傷動作應該也會有不同的表現作法

>或是平台超長(半個畫面長)還要在上面戰鬥時?
這邊可以暴力解
那就是 [平台跟角色不動，動的是背景跟敵人(敵彈)]
只要確保角色在移動的期間不會離開平台
這樣連掉落物理都用不上

>>最近很多學校的畢業展覽，遊戲的作品中，很容易發現只要是動作類型的遊戲的話，都會有一個問題。
這麼巧 作品有共同問題
是用了同一套工具還是互抄程式啊?

如果是自己做的引擎的話
也是有一種做法是對所有碰撞到平台的物件加上平台的velocity

正常來說重力一直開著，不要開開關關就好了吧。要往上跳看是要用數學算Transform還是用Add force去弄。
平台就collider不可穿透、不要剛體。感覺是想弄太複雜的東西。結果搞砸。

假設是使用 Unity 開發的話

可以將角色的 Transform parent 直接設為移動中的平台 使得角色的物理運算從原本的相對於世界場景 轉換成相對於移動中的物件

你會發現 這時候不管你使用怎樣的速度上下左右平移你的平台物件 你的角色物件都還是死死的站在平台上 除非你旋轉並使平台傾斜 你的角色物件才會受重力引響往下掉

我用unity雖然不久但也有3.4年了
我還真沒聽過這種說法

不過我猜大概就unity中IEnumerator是模擬Thread
所以會有跟Thread一樣的缺點.加深複雜程度且難以debug
大概是老手會叫新手還沒基本概念前先不要用

至於效能來說寫在Update通常都比較耗能啦

我是原PO~
其實是讀了這篇：
http://unitytaiwan.blogspot.tw/2017/03/unity_15.html

然後讀了不少有關Update或Coroutine的相關文章
嗯...但還是沒什麼想法

目前練習的小程式用了幾個Coroutine時間大約在2~10秒結束
同一時間執行最大數量約在3~4個

不確定這樣的寫法好不好 (畢竟方便而且程式容易懂)
用在一些遊戲邏輯的計時之中

這篇文章指的耗能方面是記憶體.而我之前提到是CPU的部分
是會依據需求決定的.兩邊的寫法並沒有絕對

而他說就要盡力避免的是需要長時間即時判斷之類的情況
我舉例子來說好了

IEnumerator TestA()
{
int x = 1;
while (true)
{
print(x);
yield return null;
}
}


Update()
{
int x = 1;
print(x);
}

這兩段雖然都是每幀印出x這值.但在記憶體內Coroutine那個
除了紀錄Coroutine執行階段的值外.還需要紀錄x的值

但Update中x這值在離開Update生命週期後就會重記憶體內被釋放掉.雖然每幀執行Update時會在建立出來.但卻不必額外負擔Coroutine的固定消耗.

簡單來說如果這個Coroutine真有必要長時間存在.竟量使用在需要異步操作的功能上.如他所說的HTTP 傳輸、資源載入或是檔案 I/O之類

Coroutine 真正造成問題的時間點並不在於建立時配置的記憶體
而是在於累計了一段時間後 GC 導致的畫面卡頓現象
會說適合長時間等待的用途 是因為這樣的用途通常不會頻繁的開啟 Coroutine 而在 heap 上配置暫存用的記憶體
這樣的用途相對拉長了 GC 發生的頻率 或 GC 發動時 需要回收的記憶體數量

如果有從 Profiler 觀察頻繁使用 Coroutine 對記憶體配置時的效能影響
那麼要觀察的對象並非 GC Allocated 時的突波 而是 Total GC Allocated 暴跌的那個瞬間 (這時的的 CPU usage 遠大於 GC Allocated 時的 CPU usage)

當然要迴避 Total GC Allocated 暴跌時 CPU 的突波現象 最快的方法還是回頭查找 GC Allocated 的時機點 並視其情況重構

所以 並不是怕新手搞亂程式結構或閱讀困難的問題 事實上 Coroutine 的本意 就是拿來簡化 並增加程式碼可讀性的 所以有時候明知道可能會多一點效能問題 還是會視情況而使用 Coroutine 來處理事情

我是單人爲興趣做遊戲的人，真的不懂
我是不是應該做好本體和骨架、動作後
做個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做過一款遊戲，所以其實相當麻煩