4/23的部份
每寫個段落,可來這看成效,今天文字說明主要寫在註解中
我好像巴哈今天可能還會寫一篇,先等知乎那個回答完善完之後再看看情況!!
最近預計要做的事情有些太多了點
像看 《教父》第一部小說繁體中文版 、 《資本論》線上版
還有webRTC或者是旋轉泡泡球、橫版過關遊戲的程式處理
上次Corman_Lisp反組譯
因為發現運作原理好像是靠shellexec一類的,去獲取Common Lisp的執行結果
因此函數式語言與組合語言的對應研究其實還沒處理完畢
(要怎麼處理...也還有待研究)
原始碼在(記得要有圖檔 fox.jpg才能運作,圖檔內容不用一樣,但長寬可能要自行調整)
-----------------------------
以下是上次實況時
18:18更新:
暫時先去處理Web Audio API相關研究
這次更新放了兩個檔案 h_scroll_step_2_incomplete.html跟fox.jpg
(基本上是根據過往寫的仿闇箏改過來的,所以註解沒什麼說明
闇箏那篇(↓)有大致上講解過思路
18:21,哦,電腦上放上OneDrive時
好像不會自動同步
所以我剛才手動上傳一次
現在應該有檔案了)
如同過往,依然用Javascript製作而成
這次寫法打算跟上次俄羅斯方塊類似
也就是檔名大概是 h_scroll_step_數字.html這類,代表第幾步
嗯,那就開始吧!!
一陣子沒寫是有些生疏
h_scroll_step_1.html
這步目前還沒有關聯圖檔
可以只下載檔案或者是把文字部份複製貼上
存成.html檔用瀏覽器來開應該就能順利運作
瀏覽器版本太舊的話可能會有問題
但現在2017年4月,估計這類狀況會少些
用手機開的話
顯示大概是會有些問題在的
因為...畫面設定的長度問題
大概一個頁面不縮放的狀況下
不太好看
雖然我也沒真的用手機開過就是了
(其實這英文指的是水平卷軸,就通常會想到的可能是彈幕遊戲,就 小蜜蜂 那種
因為橫版過關遊戲的正式稱呼個人比較不清楚
就暫時這樣
step是 一步、樓梯的一階那類概念
所以step 1就是步驟1)
第一個檔案
可以參考俄羅斯方塊那篇
就稍微測試下UTF-8是否正常
網頁用自己常用的瀏覽器顯示是否正常這樣
(雖然說,若要在各瀏覽器間顯示得比較整齊的話
應該是要配合CSS語法的
不過個人不是那麼在意各瀏覽器之間的相容
主要也是針對桌上型電腦
那行動裝置類的
要做哪些改變還沒研究!!)
由於兩個不同的遊戲
第一份檔案都一樣
感覺有些詐騙、浪費空間這樣!!
所以先稍微想下
第一份檔案要達到的畫面是怎樣?
(先用小畫家跟滑鼠畫下)
那~
第一步
先把畫面做成這樣
(先用語法畫,跟幾個部份用貼圖語法,不然如果畫面只要做成跟示意圖一樣
其實用drawImage()就行了)
然後暫時不處理碰撞偵測
(避免一步做太多)
圖片可能高低不太相同
不過我想差異不大啦
(就可大可小,對於畫矩形的語法來說差異不大
當然若對成品講究的話,就不能這麼任性了!!)
至少在做碰撞偵測之前差異不是很大
(只是碰撞偵測麻煩的是不規則圖形,矩形不管大小碰撞偵測都比較好處理)
稍微找下需要用到的語法
我這次依然是打算用Canvas來做
因為不用Canvas來做的話
在Javascript與Win32 API的遊戲程式設計就會相對難轉換
找語法大概可以這麼猜
因為確定要用的是Javascript跟Canvas
所以直接打 Canvas w3schools 這類的就能找到
那這邊最主要要用到的是fillRect()函式
也就是填滿個矩形
以後有圖檔時,就改成drawImage即可
(雖然我覺得在個人克服繪圖一類之前,大概是不用想太多
就在那之前,大概只會示範下函數怎麼用,但對於畫面不用期待
因為我隱約覺得,繪師應該不是很樂於見到自己的作品被我這樣使用就是了!!)
在忘記幾十分鐘的奮鬥之後
(因為其實主要花時間在寫註解,與一開始忘記fillRect的參數涵義)
出來的成品是這樣的
嗯,「人生多麼善變~」
檔案已傳!!
(我程式註解會寫很多話
都列在這篇上面會太過冗長
所以緊接著就下一步吧!!
關於為何示意圖跟成品圖的差異與想法,就看註解!!
註解比較大的篇幅是在寫
瑪莉歐、洛克人還有古早玩家與現代玩家的遊戲環境差異
與相應的新手引導措施不同
(其實裡面沒寫的是,說明書的問題
可是我不確定,我以前好像是買正版卡帶時
也只有少部份遊戲才會真的附說明書
正常如果是代理跟進口的遊戲卡帶
好像幾乎都是沒說明書的)
第一步主要是熟悉下,座標系的差異
雖然若從俄羅斯方塊時期就有看我程式碼或實況的
或者是有稍微自己試著寫過類似的程式
第一步是有些多餘!!)
(稍微想下第二步要做些什麼!!)
雖然在實況中
而且實況前吃過東西
不過...
總之再去買些東西吃好了
去走點路
活絡下腳底經脈這樣!!
(若交通環境、空氣品質許可的話
我是建議多走些路
雖然也要看個性啦
很多時候走路會有些想法產生)
哦,對
因為最近又回來寫程式了
我過往在寫這類單機版網頁遊戲程式時
很常實況到一半
會去睡個半小時~1個半小時左右
雖然隱約覺得今天不會面臨那狀況
因為...橫向過關遊戲的程式
大多沒複雜到需要睡覺(特別是以現代桌上型電腦所擁有的硬體資源來看)
這也是為何《時空幻境》(《Braid》)、《超級瑪莉歐》較正經的遊戲
《人生大冒險》、《貓利歐》、《跳躍吧,八分音符》一類惡搞遊戲
會採取橫向闖關的模式
RPG還有很多遊戲
雖然表面上看起來很簡單
但是涉及到多個系統的切換
因此在寫的過程中
不見得會比彈幕遊戲、橫向闖關遊戲
那種玩家操作與在哪個時間點大致上會有的狀況比較好掌握的那類型遊戲
簡單多少!!
特別是RPG、策略遊戲那種介面、按鈕繁多的遊戲
要創新是相對橫版過關遊戲與彈幕遊戲麻煩很多的
至少單就美工的增加量而言
(所以RPG與策略遊戲大多增加的創新,都傾向於減少些美工的呈現為主
除非是大廠製作的創新可能才不太用那種取巧手法)
(玩RPG、策略遊戲一類的,大多會有別的遊戲的習慣
就像是即時戰略遊戲,在移動、攻擊的滑鼠操作是慣用滑鼠右鍵
然後早期的圖片處理軟體
滑鼠往下拉的話,畫面會往上跑
因為攝影相關的有個操作,就類似那樣,方向正好跟直覺相反!!
後來攝影變得比較小眾或者是手機的興起一類的
這類設計就從預設變成可選擇的操作
因此舉例的內容可能現在會比較難理解)
那h_scroll_step_2.html
就是增加玩家1操作的角色
(是否適合做雙打是一回事,但就俄羅斯方塊而言是做得到,因此這邊理論上也做得到
效果好壞的話要自己權衡,那...我這邊僅是確認下技術面有沒有問題)
移動與跳躍
先採用比較簡單的做法
(除了跳躍跟重力有些關係外
跟RPG移動是很類似的
雖然像超級瑪莉歐一類的移動
其實是有做些微調的
一開始奔跑前,按鍵的效果感覺沒那麼好
就有種加速到勻速的過程在
若橫軸過關遊戲不在意這些細節的話
是蠻容易的
雖然各類遊戲不在意細節的話,都不難就是了!!
或者是說遊戲不在意細節
現在網路發達的時代
大多遊戲類型都有原始碼可以抄或問答網站有些解決方案在
畫面呈現或說多媒體素材的部份
以現代科技的演變來看
還是比程式的門檻高得多
所以若想做自己想像的遊戲
美術跟程式,其中程式是比較能允許弱一些的地方
但畫面畫出來的跟想的對應不起來
大概就沒得救了
以目前來看
在腦造影或者說是能夠把所想畫面轉成電子檔的技術出來與廉價普及前
是肯定做不出來)
而h_scroll_step_3.html
就是做按照按鍵時間長短來變更跳躍高度的設計
(後來發現按鍵時間長短,其實跟判斷是否在跳躍狀況,可能是一體的
所以第三步可能改為處理碰撞偵測與畫面捲動)
創作內容
(置頂文)4/20起,橫版過關遊戲(以跳躍為主的,超級瑪莉歐那類)製作過程與想法(step2完成)
單機版網頁遊戲系列相關 (20)
