前陣子原本想做個RPG對話系統，越做越覺得這個問題的範圍比自己想像的還大，難度也比原本想的還高，只好暫時擱置。
至於有沒有完成它的一天就不好說了...(小聲)
而且悶著頭做有點悶，寫點什麼好像會比較好玩。
西瓜遊戲雖然已經是兩年前的遊戲了，不過最近一堆holomen直播都在玩，帶起了一波風潮，而且每個都笑果十足。
(擷取自Youtube頻道：Miko Ch. さくらみこ)
正好我這個Unity菜雞找不到適合自己難度的點子，覺得這個益智小遊戲應該不會太難才對...(Flag先立起來)
這次我要來挑戰用兩個禮拜的時間來完成一個西瓜遊戲(偽)！
(それでは、意気込みをどうぞ！)
兩個禮拜一定有辦法！！！...嗎？
其實專案是在10/26開始的，已經過了3天RRRRRRRRRR。
現在的進度長這樣。
--------以下是技術部分----------
本次重點：C#事件
先把水果叫做球吧。
首先，寫一個球產生器，就叫它 BallGenerator 吧。
它有兩種產生球的方法。
A方法：創建一顆拿在玩家手上的球。
B方法：兩顆相同的球碰到後創建一顆進階的球。
A方法要在玩家丟下手上的球，並在球落地時執行。
B方法要在兩顆相同的球碰到時執行。
這兩種情形都跟碰撞有關，就另外寫個碰撞處理器。
就叫它 BallCollisionHandler 吧。
內容是碰撞後要做什麼動作。
我可以在碰撞處理器裡面寫，
1. 當玩家手上的球落地，就叫球產生器執行A方法。
2. 當兩顆相同的球碰到，就叫球產生器執行B方法。
但這樣會讓碰撞處理器依賴於球產生器。
意思是說，如果球產生器有變動，碰撞處理器也得改。這樣很麻煩。
不如改成這樣：
我在碰撞處理器裡面寫，
1. 當玩家手上的球落地，就發出(落地事件的)通知。
2. 當兩顆相同的球碰到，就發出(相同的球碰到了的)通知。
通知誰？我(碰撞處理器)不管，反正我只發出通知，其他跟我無關。
那，誰想知道事件發生了沒？球產生器想知道。
所以我在球產生器裡面寫，
1. 注意碰撞處理器的A事件，發生的話就執行A方法。
2. 注意碰撞處理器的B事件，發生的話就執行B方法。
換句話說，就是讓球產生器去訂閱碰撞處理器的事件。
可是，這樣不是換成球產生器依賴於碰撞處理器嗎？
其實不一樣，因為球產生器只需要知道「有事件發生」，不需要知道這事件是怎麼發生的。
這樣球產生器和碰撞處理器之間不會那麼緊密相依，之後更容易修改或者升級。
以上是在這次專案中使用事件的經過。
補充：這次比較了C#的事件跟Unity Event之後，覺得C#事件更靈活，就選擇了C#事件。
Unity的事件，就像是一個餅乾機器上有個按鈕。按下去就只能做餅乾，想改的話要把按鈕和餅乾機器都拆開來改。
C#的事件，就像是按鈕只是發出一個叫聲，誰想聽就聽，餅乾機器聽到了就開始做餅乾。但是以後如果有咖啡機，也可以選擇聽這個叫聲然後開工。
