[問題] 容量超小3d射擊遊戲

看板Old-Games作者 (蝌蚪)時間5年前 (2018/07/31 19:03), 編輯推噓7(7推 0噓 33→)
留言40則, 10人參與, 5年前最新討論串1/1
記得在15年前左右 網路上有載過一款fps射擊遊戲 全3d但是容量只有10幾kb 當時為之震撼 載下來只有一個執行檔沒有其他東西 請問有人玩過嗎 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 110.26.134.39 ※ 文章網址: https://www.ptt.cc/bbs/Old-Games/M.1533034992.A.734.html
→
07/31 19:08, 5年前 , 1F
.kkrieger? 不過這款約96KB
07/31 19:08, 1F
→
07/31 19:45, 5年前 , 2F
應該就是樓上說的那款了 當年是96kb遊戲比賽的冠軍
07/31 19:45, 2F
→
07/31 19:46, 5年前 , 3F
google "64k intro"可以找到很多很嚇人的東西
07/31 19:46, 3F
推
07/31 23:42, 5年前 , 4F
這96K太扯......
07/31 23:42, 4F
推
08/01 01:14, 5年前 , 5F
為什麼可以這麼猛啊.....
08/01 01:14, 5F
推
08/01 01:30, 5年前 , 6F
聽說完全用組合語言去寫...XD
08/01 01:30, 6F
推
08/01 01:34, 5年前 , 7F
再加上強力壓縮及演算法
08/01 01:34, 7F
→
08/01 01:52, 5年前 , 8F
但是作者當初說要做三個關卡，卻從未完成。
08/01 01:52, 8F
→
08/01 01:53, 5年前 , 9F
現在留下來的也只有引擎原始碼跟這個demo(還有官網上
08/01 01:53, 9F
→
08/01 01:53, 5年前 , 10F
其他的，但是就沒有任何關於這款的後續了)
08/01 01:53, 10F
→
08/01 01:58, 5年前 , 11F
作者的FAQ寫到並沒有壓縮，而是直接以製作模型和材質的
08/01 01:58, 11F
→
08/01 02:00, 5年前 , 12F
過程方式變成數據存在執行檔中，執行時再"製作"出來(
08/01 02:00, 12F
→
08/01 02:01, 5年前 , 13F
所以一開始的loading條就是將遊戲的所有資料生成出來)
08/01 02:01, 13F
→
08/01 02:01, 5年前 , 14F
因為只儲存最原始的"製作步驟"，所以能將容量壓得很低
08/01 02:01, 14F
→
08/01 02:04, 5年前 , 15F
簡單說就是有個模型材質聲音生成器在遊戲執行時開始製
08/01 02:04, 15F
→
08/01 02:05, 5年前 , 16F
作出來，遊戲程式中只儲存生成器需要的參數資料。
08/01 02:05, 16F
推
08/01 10:21, 5年前 , 17F
其實現在新遊戲很多過場都用即時演算來省空間算是一樣概念
08/01 10:21, 17F
→
08/01 10:21, 5年前 , 18F
不過以前的資源跟效能，這樣搞真的是很厲害
08/01 10:21, 18F
推
08/01 13:49, 5年前 , 19F
當時玩過 超卡XD
08/01 13:49, 19F
→
08/01 14:15, 5年前 , 20F
現在的遊戲容量都不知道在大幾點的,還是有好遊戲沒錯,但根本
08/01 14:15, 20F
→
08/01 14:16, 5年前 , 21F
不覺得這樣的內容需要10幾20GB去做.
08/01 14:16, 21F
→
08/01 19:15, 5年前 , 22F
啊就一堆人要畫面要影音然後木耳低解析螢幕根本浪費空間XD
08/01 19:15, 22F
推
08/01 23:48, 5年前 , 23F
高解析度材質跟高品質音效，這兩個東西都是肥大保證。
08/01 23:48, 23F
→
08/01 23:49, 5年前 , 24F
即時算就是要用時間(載入長)換空間(容量小)。
08/01 23:49, 24F
→
08/01 23:49, 5年前 , 25F
但是如果要載入快一點(先不論優化問題)，需要演算的直
08/01 23:49, 25F
→
08/01 23:51, 5年前 , 26F
接就能使用(載入快些)但是容量很大很大(如BMP、WAV)
08/01 23:51, 26F
→
08/01 23:51, 5年前 , 27F
但是解析度越來越高，就算再好的演算法也是有極限的
08/01 23:51, 27F
→
08/01 23:54, 5年前 , 28F
你不可能希望4K解析度卻只要幾個MB就能搞定吧(光單格純
08/01 23:54, 28F
→
08/01 23:55, 5年前 , 29F
總像素就7、8百萬，全彩x3，32位色深x4，多肥阿)
08/01 23:55, 29F
→
08/01 23:57, 5年前 , 30F
最後還是都得靠演算法來降低容量，然後就是看演算法跟
08/01 23:57, 30F
→
08/01 23:57, 5年前 , 31F
程式本身優化來看能節省多少時間...
08/01 23:57, 31F
→
08/01 23:58, 5年前 , 32F
但是如果想要1080p以上甚至4K等級，又想容量小？那就
08/01 23:58, 32F
→
08/01 23:58, 5年前 , 33F
只能降低色彩數了。
08/01 23:58, 33F
→
08/01 23:59, 5年前 , 34F
不過聲音的話，就不一定了，因為使用者的發聲裝置品質
08/01 23:59, 34F
→
08/02 00:00, 5年前 , 35F
會影響，但一般來說，MP3那種規格的其實很多人就已經
08/02 00:00, 35F
→
08/02 00:01, 5年前 , 36F
聽不出差別，但也是有人聽得出來那差異。
08/02 00:01, 36F
→
08/02 00:02, 5年前 , 37F
而且又有如ogg這類的規格，聲音容量肥大的程度不會比畫
08/02 00:02, 37F
→
08/02 00:02, 5年前 , 38F
面品質大就是。除非你不追求高解析度，不然遊戲的容量
08/02 00:02, 38F
→
08/02 00:02, 5年前 , 39F
越來越大應該是正常的(除非以後有那種劃時代的格式可以
08/02 00:02, 39F
→
08/02 00:02, 5年前 , 40F
大幅減少超高解析度的容量)
08/02 00:02, 40F
‣ 更多 xu5pu 的文章
文章代碼(AID): #1RO47mSq (Old-Games)