手遊《奧林劈圖》的開發日記(三)
你一定要過得好,不然對不起我的不打擾。雖然我有一萬個想見你的理由,但唯獨少了一個見你的身份,不是我們不夠好,只是時間不湊巧。
感謝你們,那無數個陪伴我熬夜的燦爛星空!
[2016年5月23日]
資料,狀態,動作,事件
上層:StateMachine
1. 介面 (setData, getData)
2. 主體A的Action: (setData, getData)
3. 主體B的Action: (setData, getData)
下層:
Data(樹形管理,路徑作為id) , 如: NotifyData
ChangedEvt
當客戶端接受到伺服器push來的新關卡:XYZ123時,
資料庫中增加記錄, 同時在Notify樹中,把newStage的數量+1. (Action1)
ChangedEvt廣播發出,介面更新(顯示有幾個新關卡)
玩家進入最新關卡介面,開啟一個新關卡,把newStage的數量-1. (Action2)
ChangedEvt廣播發出,介面更新(顯示有幾個新關卡)
NotifyDataTree:
|----newStage
|----count (1+1=2)
[2016年5月25日]
關卡介面分為三種:
1. Play
2. Edit
3. Hint
Play (SplitLayer, SplitMab)
Edit (EditLayer, EditMab)
Hint (SplitLayer, SplitMab)
關卡布局資料庫
欄位包括:
_id uid name vers src dst blks time src_area dst_area src_w src_h dst_w dst_h src_g dst_g src_edge dst_edge blk_num
src_blank dst_blank src_corner dst_corner fence limit src_fc dst_fc
[2016年5月26日]
1. 關卡的背景圖
2. 關卡選擇介面的設計
3. 主介面的背景設計
4. 關卡的字串表達,通過json傳遞關卡資訊。
5. 玩家建立關卡,點贊,收藏,評論。
6. parsermap只取boundingrect範圍解析
昨晚把關卡的遠端資料庫讀寫打通了。這樣我就可以在手機上編輯關卡,儲存到伺服器,再從伺服器讀關卡編輯或執行。
今天要做的就是關卡列表了,或者說也是關卡選擇器。把資料庫的關卡表(shape)按照某個查詢條件傳回本地,然後顯示關卡列表,在列表裡選擇關卡編輯,或檢視某一個關卡的詳細資訊。
[2016年5月27日]
關卡資料表示
blks:["001001", "00101112","0010011213"] //matrix
src:{
"blks":["00","23","33"], //origin
"size":{"w":4, "h":3},
"limit":{
"pear":["11","20","23"],
"orange":["23","33","34"]
}
}
dst:{
"blks":["00","23","33"], //origin
"size":{"w":4, "h":3},
"fence":{
"wall":["340","231","330","431"],
"stone":["11","20","23"],
}
ShapeList表示:
"shapes":[
{"blks":["00","11"],"src":{"blks":["20","01"]},"dst":{"blks":["00","11"]}},
{"blks":["00","11"],"src":{"blks":["20","01"]},"dst":{"blks":["00","11"]}}
]
[2016年5月31日]
關卡設計備忘
長變寬,寬變長,鋸齒變平滑。
分離伸展變聚合,窟窿被填充。
劈分有限制,填充有障礙。
方塊拼接要不同。
[shape特徵]:
width, height
area (目標會與源不同)
hole (blank)
inside corner
wall capacity (一共可以新增多少個wall,用來計算wall選擇的空間量,可以反應出劈分難度)
wall (提示答案中新增的wall數)
girth
feature code
[stage描述]:
1. 所有srcShape和dstShape的描述
2. block的型別(featurecode)和數量
Block, srcShape, dstShape都可以使用g2Shape計算特徵。
Block是簡單的形狀,srcShape和dstShape是複合的形狀。
應該讓有特點的圖形作為被劈分的源圖形,玩家會有新鮮感,興奮。
劈分的方塊數應儘量控制在3個以內,如果超過3三個,可以增加提示以降低難度。提示包括:
1. 目標圖形提示方塊形狀。
2. 源圖形使用“形影不離”道具,源圖形採取分離式佈局,提供更多資訊給使用者。
牆的數目應該控制在7個以內.
源圖形的形狀採取仿生設計: 字母型,動物型, 數字型,樓房,傢俱 ...
目標圖形儘量對稱,規則,與源圖形差異顯著,與源圖形相映對仗...
相關文章
- 手遊《奧林劈圖》的開發日記(一)
- 手遊《奧林劈圖》的開發日記(二)
- 安卓APP開發日記1——名為Another的日記APP開發安卓APP
- FLOWERS開發日誌(三)
- 開發日記10
- 營運型手遊開發、測試、正式的三階段開發架構架構
- 小辣椒開發日記
- 安卓開發日記57安卓
- 安卓開發日記56安卓
- 安卓開發日記55安卓
- 安卓開發日記26安卓
- 安卓開發日記25安卓
- 安卓開發日記24安卓
- 安卓開發日記28安卓
- 安卓開發日記27安卓
- 安卓開發日記4安卓
- 安卓開發日記13安卓
- 安卓開發日記14安卓
- 安卓開發日記12安卓
- 安卓開發日記17安卓
- 安卓開發日記16安卓
- 安卓開發日記15安卓
- 安卓開發日記19安卓
- 安卓開發日記18安卓
- 安卓開發日記46安卓
- 安卓開發日記45安卓
- 安卓開發日記47安卓
- PHP手遊開發(手遊專案)PHP
- 5.13安卓開發日記34安卓
- 5.9安卓開發日記31安卓
- Web 前端開發日誌(三):HTML 節點的記憶體洩露問題Web前端HTML記憶體洩露
- 軟銀1500億日元收購手遊開發商Supercell
- LayIM.AspNetCore Middleware 開發日記(三)基礎框架搭建NetCore框架
- 雲音樂vue開發日記Vue
- 5.11安卓開發日記32安卓
- 5.16安卓開發日記37安卓
- 5.12安卓開發日記33安卓
- 5.14安卓開發日記35安卓