https://github.com/miaohengming/PigTail
| 隊員 | 博客鏈接 | 具體分工 |
|---|---|---|
| 繆恆銘 | 博客鏈接 | 游戲開發及測試 |
| 唐勁霆 | 博客鏈接 | 素材收集，原型設計 |
一、原型設計（20分）
[2.2.1]提供此次結對作業的設計說明
-
這部分的首行原型作品的鏈接:
-
采用的原型開發工具:
-
由於之前沒做過原型設計，所以也不太了解，所以通過
B站、百度等搜索后，比較主流的幾款原型開發工具是Axure RP、墨刀、Balsamiq Mockup、JustinMind等等。最后，我選擇了使用Axure RP8，我在B站學習了宋老師的Axure教程，這里附上鏈接——宋老師的Axure教程。（感謝宋老師)但是由於初學，研究不深，所以做的原型比較一般。(=_=)
-
-
部分原型圖展示及說明（
由於不知道怎么上傳視頻，似乎有點麻煩，所以只能上傳gif，然后就下載了個工具來錄制gif進行展示）：-
1)游戲首頁：設置了按鈕及游戲標題等等待500ms后出現，動態效果為逐漸出現。
-
2)加載界面：在游戲首頁點擊Start按鈕后，跳轉到加載頁面，加載頁面主要是設置了一個進度條百分比加載展示，這邊是學習了另一個B站視頻（感謝0.0）——Axure的進度條制作。 具體的步驟是：
a.進度條的加載，通過設設置“進度條”的載入時用例：設置其尺寸的寬為“邊框”的寬，高為20，錨點為左側，動畫為線性，時間為2000毫秒。
b.百分比的數字加載變化：設置“百分比”的顯示時用例：設置文本文字為“進度條"寬度占“邊框"寬度的百分比，利用公式：[[Math.floor(“進度條"寬度/""邊框"寬度*100)]]%，floor函數作用是向上取整。
-
3)說明界面：在游戲首頁點擊About按鈕后，跳轉到說明界面，主要包括游戲規則介紹以及制作者。
-
4)模式選擇界面：
-
5)結束界面：設有Restart按鈕，可以重新跳轉到游戲首頁。
-
6)一些頁面的Back和Exit按鈕：點擊Back按鈕返回首頁，點擊Exit按鈕跳到結束界面。
-
[2.2.2]遇到的困難及解決方法(原型設計過程中)
-
困難描述:
-
首先，由於之前沒有做過原型設計的經歷，所以起步就遇到了困難。
-
但是由於我下載的是最新Axure RP10，而教程是Axure RP8，版本導致界面的改動較大，操作不熟練。
-
制作進度條的時候出了點小bug，顯示不出。
-
-
解決過程：
-
我先是尋找了一些原型設計的基本資料以及教程。
-
我選擇重新下載了Axure RP8(=_=)，頁面功能比較好找，操作比較流暢。
-
關於進度條bug，我先是檢查后發現公式的輸入有問題，但是還是不可以，然后又認真看了幾遍教程視頻，我發現是因為幾個用例事件添加沒操作好導致了覆蓋了前面事件的問題，所以造成顯示不出進度條，最后只能重新再來一遍。(=_=)
-
-
有何收獲：
-
收獲肯定是很大的，學習了原型設計的一些基礎操作啊之類的，畢竟之前一直沒有接觸過相關的知識（
太菜了）。現在掌握了原型設計的一些基礎，也為之后的團隊作業的原型設計打下了基礎。
-
二、原型設計實現
[2.3.1]代碼實現思路：
-
最終界面展示：
-
代碼組織與內部實現設計（類圖）
-
說明算法的關鍵與關鍵實現部分（流程圖）
-
貼出你認為重要的/有價值的代碼片段，並解釋
-
1)吃牌操作是本游戲區別於同類卡牌游戲的根本；因為置牌區的牌頂卡必定是玩家抽牌或者出牌產生的，所以可以將玩家最后一次出/摸的牌記錄下來，與新到置牌區的卡牌作花色比較。若花色相同，對置牌區的子對象遍歷，並根據當前回合，分配給對應的玩家。在吃牌操作的結尾，還應當將置牌區緩存清空。
點擊查看代碼
public void clear_put()//吃牌 { List<Transform> children = new List<Transform>();//存儲置牌區卡牌 int p = 1;//當前玩家 if (cou0.activeSelf) p = 0; foreach (Transform child in Putcard.transform) children.Add(child); foreach (Transform card in children) { card.gameObject.GetComponent<ThisCard>().place = p;//設置卡牌所屬玩家 card.SetParent(GameObject.Find(p + "type" + card.GetComponent<ThisCard>().thisId / 13).transform); if (p==0) a++; else b++;//手牌數增加 } lastvalue = thisvalue = -1; } -
2)在一局對戰結束后，應當令卡牌清空，回到原來的狀態等待下一場對局。但總不能再調用一次Awake或Start函數，這時候OnEnable函數的優勢就體現出來了，可以利用其每次顯示都會執行的特點，在游戲結束時連續隱藏顯示，達到重置的效果；另外隨機摸牌也是重點之一，我的做法是靜態隨機，在開始前設置一個0到51遞增不重復的數列，代表一副撲克牌；然后將其兩兩交換，以達到隨機卻不重復出現的效果
點擊查看代碼
public void OnEnable()//卡牌重置 { sum = 52; a = b = 0; int i, j, k;//產生隨機摸牌序列H for (i = 0; i < sum; i++) H[i] = i; for (i = 0; i < sum; i++) { j = Random.Range(0, sum); k = H[i]; H[i] = H[j]; H[j] = k; } js.SetActive(false); texterror.SetActive(false); cou0.SetActive(false); turn_change(); clear();//清空場上的卡牌對象 }
-
-
性能分析與改進
-
開發初期為了追求方便，大量的使用了Update函數進行數據的更新，產生了眾多資源浪費。改進后能不用Update就不用，非用不可的，也可以通過一些等待函數來加大其更新周期。資源能省就省，一些同界面的小功能完全可以由一個腳本來控制完成。重復的代碼盡量都做成函數
-
-
描述你的改進的思路
-
雙方玩家都有對應的抽牌、出牌按鈕，這些屬於同一體系的功能，完全沒必要分別調用一個腳本來實現，封裝在一起即簡潔又高效
-
三種模式的按鈕，封裝在一塊
-
與卡牌位置變化有關的行為，由同一腳本控制，根據不同的指令產生、移動和銷毀卡牌
-
-
展示性能分析圖和程序中消耗最大的函數
-
展示出項目部分單元測試代碼，並說明測試的函數，構造測試數據的思路**
-
Unity前后端數據相連，在調試中很容易就能看出數據是否異常；例如下圖的隨機數組，點了刷新按鈕就會動態切換，因此無需構造測試數據
-
[2.3.2]貼出Github的代碼簽入記錄，合理記錄commit信息。
[2.3.3]遇到的代碼模塊異常或結對困難及解決方法。(unity2D開發過程中)
-
困難描述：
-
實際開發中發現，隱藏的gameobject不會自動執行其腳本的update函數，結果找了半天的bug；
-
在設計“退出”按鈕時，需要重置桌面的牌及相關的游戲數據，一時無從下手；
-
原型設計難以直接與實際界面聯系；
-
-
解決過程：
-
在界面新建一個gameobject來搭載該腳本，同時將所有調用原腳本的對象，其目標對象修改為新的游戲對象；
-
查閱資料發現：在腳本 Awake（）和 Start（）函數的周期之間，還要執行 OnEnable（）函數，功能為每一次顯示都會執行一次。獲得啟發后，將腳本需要重置的數據放入 OnEnable（）函數中，並給“退出”按鈕設置上相關的函數，讓腳本隱藏並顯示，以達到重置相關數據的效果
-
將素材打包，根據原型設計與實際開發環境的綜合考慮，模仿設計、適當調整；
-
-
有何收獲：
-
理論與實踐不是一回事，B站視頻刷的再多，也不及卡殼許久后查閱的一篇相關文章讓人記憶深刻。實踐才是檢驗真理的唯一標准。
-
[2.3.4]評價你的隊友
-
唐勁霆：
-
值得學習的地方：學習能力很強，之前也沒學過相關的東西，就學習了一段時間后很快就能上手了。
-
需要改進的地方：和本人一樣，臨近ddl才開始准備學習，導致有點趕，還是應該提前做好規划，提前學習准備哈哈哈哈。
-
-
繆恆銘：
-
隊友值得學習的地方：在deadline前具有極大的學習動力，樂於溝通。
-
隊友需要改進的地方：前期不着急，后期趕進度，導致大量工作堆積在一起。
-
[2.3.5]提供此次結對作業的PSP和學習進度條（每周追加），示例如下(2分）
-
PSP：
PSP2.1 Personal Software Process Stages 預估耗時（分鍾） 實際耗時（分鍾） Planning 計划 · Estimate · 估計這個任務需要多少時間 20 15 Development 開發 · Analysis · 需求分析 (包括學習新技術) 720 1040 · Design Spec · 生成設計文檔 60 80 · Design Review · 設計復審 10 5 · Coding Standard · 代碼規范 (為目前的開發制定合適的規范) 0 0 · Design · 具體設計 120 120 · Coding · 具體編碼 1080 1200 · Code Review · 代碼復審 200 120 · Test · 測試（自我測試，修改代碼，提交修改） 60 60 Reporting 報告 · Test Repor · 測試報告 120 90 · Size Measurement · 計算工作量 60 45 · Postmortem & Process Improvement Plan · 事后總結, 並提出過程改進計划 30 30 合計 2480 2805 -
學習進度條：
第N周 新增代碼（行） 累計代碼（行） 本周學習耗時(小時) 累計學習耗時（小時） 重要成長 1 0 0 5 5 整理思路，討論分工，嘗試微信小程序（最終放棄），學習Axure軟件 2 100 100 20 25 熟悉c#及unity的基本使用，原型設計完成 3 300 400 17 42 正式開發，學習unity常用組件的使用，腳本的搭載，在改bug的過程中一點點的熟悉unity 4 200 600 5 47 音樂的加載，游戲窗口的設置，exe文件的生成等等收尾工作
三、心得
-
唐勁霆：
-
剛開始看到這個作業的時候只能說，
一臉懵逼。因為之前沒學習過開發小程序/web/軟件等的經歷，所以第一反應就是好難啊，這怎么做，該先學什么，只能說摸魚總是該還的。然后就沉寂了一段時間，沒去搭理這個作業（=_=）。（這不到ddl不趕工的毛病真得改，這也算是啟發之一吧）之后才開始詢問一些同學以及在網上查找一些開發的教程什么的，然后我開始去學原型設計。學習了一段時間后，掌握了Axure原型設計工具的基本操作，這也應該是這次作業比較大的一個收獲，對於以后的開發等都打下了基礎，所以還是挺有收獲的。還有的啟發就是，應該在平時就應該去主動學習一些開發的知識，不然等真的需要的時候再去學就會太遲了而且壓力很大，所以真的該好好學習，不能摸魚了。
-
-
繆恆銘：
-
作業本身要求不難，但要考慮實現的方式、前后端的交互等等一系列的問題，對於我當前的能力而言還是具有極大的挑戰的。在作業開始的初期，嘗試過微信小程序的開發，學了一些相關的知識后，最終還是放棄了，感覺上手難、教程少。最終我選擇使用unity來實現本款游戲。雖然也要學很多的知識，但教程多、邏輯清晰，上手很快；我先是看了c#、unity的入門教程，然后找了一些卡牌類游戲開發的學習視頻，等心里有數了才開始開發。不過學習和實踐是兩回事，開發過程中還是經常遇到問題，充分發揮了我面向CSDN和博客園編程的能力。最終還是勉強在deadline前交了答卷，雖然不完美，仍需要許多相關知識的學習。通過這次的作業主動學習了許多的知識，在之后的學習中希望能保持這種學習的動力，不斷強化自己的能力。
-