文字接龍

Date: 20191216
Version: 1

1. 可參考上篇「文字戰爭」，這算是重啟之作，在上次實作之後，給了身邊的朋友測試，但效果不盡理想，最主要的原因是，一般人常用或口語用的詞彙，常常會與資料記載不符，也就導致詞彙無法送出，無法進到下一步，造成遊戲體感不佳。
1. 假設有N個字，有M個有意義的詞彙，M<<N
2. 2個字: M2 / N^2，M2<<N^2
3. 3個字: M3 / N^3，M3<<N^3
4. 以此類推，當隨著單字長度不斷增加，有意義的詞彙比例就會不斷下降，換句話書，越不容易送出非常態用的詞彙，也就是說會越接近資料庫所擁有的詞彙。
5. 因此，在這階段，會將長度小於2的詞彙移除，僅保留長度大於2的部分，也就是相關詞彙會從長度3開始，後續再依照實際使用狀況進行修正，看是否要將長度3也拿掉。
6. 雖然一開始想說把詞彙規範在成語當中，但成語的長度並非一致不變的，有長有短，最後就只保留長度3以上的詞彙。
7. 資料來源主要是《成語典》、《國語辭典簡編本》、《唐詩三百首》及《宋詞三百首》。
8. 《成語典》、《國語辭典簡編本》包含大部分的成語，而其中有一些具有逗號的成語，會相對應新增沒有逗號的版本，畢竟有的人會用逗號，也有的人不會用，所以沒有使用標點符號來進行分割。
9. 但在《唐詩三百首》、《宋詞三百首》，逗號是作為分隔線的存在，會依照標點符號進行分割，故不會保留。
2. 再來就是，因將相關詞彙資料放到Firebase上，在初始連線上所需要花費的時間過長，也會造成遊戲體感不佳。
1. 將改由SQLite資料庫進行支援，變成local版本，在資料的處理上都會比之前方便快速許多，唯一需要注意的是需使用SQL句，但對我來說還算熟悉，因工作需求，要使用到MySQL、MSSQL、Oracle，所以SQLite對我來說，算是非常簡單的，優點就是輕巧，適合可攜式裝備也就是APP使用。
2. APP Inventor 2本身並沒有SQLite的元件可使用，原生的只有TinyDB，所以需要另外裝SQLite套件才能使用，相關連結附於下方參考文獻。
3. 除此之外，你要建立SQLite資料庫出來，可使用下方DB Browser for SQLite的程式進行建置SQLite資料庫。
4. 而相關詞彙的資料可先用Excel建立好後，另存CSV檔，之後使用Notepad++轉編碼為UTF-8格式，這樣SQLite才能正常匯入CSV檔，因為平常Excel是以BIG5為主，所以會因為編碼不一樣導致亂碼，所以要先轉成UTF-8格式編碼。
5. 資料庫結構如下：
1. dict: 
1. id: INT, PK, NOT NULL(NN)
2. vocab: TEXT, UNIQUE, NN, 詞彙
3. first_word: TEXT, NN, 首字
4. last_word: TEXT, NN, 尾字
5. source: TEXT, NN, 來源
6. len: INT, NN, 長度
2. source_code: 
1. source: TEXT, NN, 來源
2. code: INT, NN, 來源編號
3. SQL句如下:
1. 電腦，開始，可接龍
• SELECT vocab FROM dict 
• WHERE source IN (SELECT source FROM source_code WHERE code = ?) 
• AND len <= ? 
• AND last_word IN (SELECT DISTINCT(first_word) FROM dict) 
• ORDER BY random() 
• LIMIT 1;
2. 電腦，接續，可接龍
• SELECT vocab FROM dict 
• WHERE first_word = ? 
• AND source IN (SELECT source FROM source_code WHERE code = ?) 
• AND len <= ? 
• AND last_word IN (SELECT DISTINCT(first_word) FROM dict) 
• ORDER BY random() 
• LIMIT 1;
3. 電腦，接續，不可接龍
• SELECT vocab FROM dict 
• WHERE first_word = ? 
• AND source IN (SELECT source FROM source_code WHERE code = ?) 
• AND len <= ? 
• ORDER BY random() 
• LIMIT 1;
4. 玩家，確認
• SELECT vocab FROM dict 
• WHERE vocab = ?;
3. 而這次除了改進上述問題外，還打算加入多人連線模式，而這個就會使用Firebase來做為線上資料庫來使用，而建置方式很類似於線上聊天室的模式。
4. 雖然源自於BattleText，但我還是想稍微做一下改變：
1. 對戰背景色修改，原為紅黑，後續改為紅(#d75b66ff)藍(#4e7ba7ff)配色。
2. 單人遊戲又分為積分戰和生存戰兩種
1. 積分戰：跟原本機制一樣，比分數，4.3/6.9 = X/50，X=31.2，分數比照字串長度等比例提高至30分。
2. 生存戰：無法接龍者扣血，血量預設3滴血 or 5滴血，無法接龍1次，扣1滴血。
3. 但因取消長度為2的字詞，可能導致難度提高，不確定積分戰是否可行，後續還要測試評估。
3. 跟上一版相比，使用多個Activity來進行畫面的切換，而這次想改使用多個TabView的模式來使用，降低使用Activity，統一在一個Activity中加入相關元件，降低不同Activity之間呼叫的複雜度。
4. 單人遊戲設定：
1. 辭庫：預設《成語典》、《國語辭典簡編本》，選用《唐詩三百首》、《宋詞三百首》
2. 長度：電腦可使用的詞彙長度上限，3~4字、3~7字、3字以上
3. 難度：電腦有機率會忘詞，簡單(40%)、普通(20%)、困難(10%)
5. 多人遊戲設定：
1. 個人ID是使用GUID作為辨識，故第一次開啟APP後就會獲得一組GUID。
5. 待處理問題：
1. 雙方出一個無法接龍的辭時該如何處理。
1. 當雙方都無法接龍時，不論出題者是哪一方，由電腦自動產生新辭
2. 所以會多一個參數來記錄雙方無法出題數
3. 無法出題者系指真的沒有可以接龍的辭，而非困難度所導致
2. 電腦不能出一個不能接龍的辭，但若因人出了而電腦無法出一個可接龍的辭呢？
1. 原則上電腦盡量要出一個可以接龍的辭。
2. 若電腦無法出一個可接龍的辭，同理，玩家也無法出一個可接龍的辭，就會回到5.1。
3. 所以當電腦無法出一個可接龍的辭時，就會跳脫5.2.1，而出一個無法接龍的辭。
4. 這時玩家無法接龍，換到電腦也同樣無法接龍，就會回到5.1。
5. 為解決上述問題(5.1&5.2)，資料庫需進行修改，程式需再調整。
3. 當無法接龍時，字樣上的呈現上應該要為3個全形空白，會比較清楚。(已解決)
6. 單人遊戲製作過程還算順利，因為已經有過類似的經驗，所以製作上還算快，經測試有出現一些問題，列在上方第5點，後續要持續改善，而多人遊戲的話會先從Firebase聊天室開始下手，目前會先把單人遊戲部分完善，再繼續執行多人遊戲的製作。

參考文獻：

1. 古典中文語料庫
2. 教育部國語辭典公眾授權網
3. APP Inventor 2 SQLite
4. DB Browser for SQLite