您好,欢迎来到12图资源库!分享精神,快乐你我!我们只是素材的搬运工!!
  • 首 页
  • 当前位置:首页 > 开发 > WEB开发 >
    20年,1人写出70万行代码!沙盒游戏「鼻祖」13年靠玩家捐赠维生
    时间:2021-08-03 08:06 来源:网络整理 作者:网络 浏览:收藏 挑错 推荐 打印

    20年,1人写出70万行代码!沙盒游戏「鼻祖」13年靠玩家捐赠维生

    一款游戏,让一位玩家皈依佛教。

    这位玩家曾寄信开发者,因其开发的游戏了解了「众生皆苦,世事无常」。

    20年,1人写出70万行代码!沙盒游戏「鼻祖」13年靠玩家捐赠维生

    终究是什么游戏还能让人看破红尘?

    Dwarf Fortress (矮人堡垒)!

    20年,1人写出70万行代码!沙盒游戏「鼻祖」13年靠玩家捐赠维生

    在Roguelike游戏界,你一定不要错过大名鼎鼎的矮人堡垒!

    2006年面世的矮人堡垒可以说是「开创类的老游戏」,就连《我的世界》开发者们表示本人深受这款游戏的启示。

    你可知这个游戏背后的开发者如何将其建造出来?

    矮人堡垒是由Tarn Adams(又名Toady One)一人开发,20年来,亲身写下70万行代码!

    20年,1人写出70万行代码!沙盒游戏「鼻祖」13年靠玩家捐赠维生

    最「理想」的游戏,最有理想主义的开发者

    Tarn Adams 从2002年末尾就在矮人堡垒任务。最后,它只是一个兼职项目。

    从2006年末尾,Adams一心投入,本人编写一切的代码。

    时期,Adams的兄弟还协助他来设计和创立基于游戏的故事。

    20年,1人写出70万行代码!沙盒游戏「鼻祖」13年靠玩家捐赠维生

    图右为Tarn Adams

    目前,他正在开发一个带有像素图形和改良用户界面的版本,可以在Steam上购置。

    近13年来,矮人堡垒并未在任何游戏平台上出售,这是由于「亚当斯兄弟」的信心。

    他们希望这款游戏和市面上发布的商业版本有所不同,并且矮人堡垒也要以10年为单位,不断更新下去。

    关于这漫长的更新,这对兄弟表示并没有任何规划。

    「想到哪,做到哪。」

    20年,1人写出70万行代码!沙盒游戏「鼻祖」13年靠玩家捐赠维生

    开发后的游戏不卖钱,波动的支出从何而来?

    全靠玩家捐赠维持生计!听说,亚当斯兄弟每个月可以有几千美元的捐赠支出,足以维生。

    许多游戏玩家为此平心静气,但他们却表示,「我们只是不想成为商人,赚钱对我们来说没有意义」。

    他们开发了最「理想」的游戏,却是最有理想主义的开发者。

    沙盒游戏「鼻祖」,70万行代码,亚当斯兄弟自述

    矮人堡垒至今已继续开发20年,有3种游玩形式。

    1、要塞形式(Fortress mode):玩家要协助一小群矮人从无到有建造城市。

    2、冒险形式(Adventure mode):该形式下四处都是中世纪武器和要命的怪物。

    3、传说形式(Legend mode):玩家可以体验逐渐演化的精巧历史,亲历充溢英雄人物、横跨几代人的史诗战争。

    那么仅凭一团体,如何敲下这70万行代码?

    20年,1人写出70万行代码!沙盒游戏「鼻祖」13年靠玩家捐赠维生

    Adams表示,「我尝试给变量和对象分歧命名,并且留下足够的注释来提示本人到了一个代码点时会发作什么。有时分我需求屡次搜索才能找到想要的线索。

    当我去重温一些曾经十年没有碰过的游戏片段时,这种状况常常发作。」

    在矮人堡垒开发进程中,Adams 主要运用了2种编程言语,C和C++。

    为了将其更容易地移植到OSX和Linux系统中,Adams运用OpenGL和SDL来处置引擎成绩。

    整个项目中,除了SDL以便我们可以做端口之外,一切这些都不断保持不变。

    在游戏机制方面,Adams并没有运用很多外部数据库,但是偶然会选择一些随机的数字原始材料—— 比如梅森旋转算法(Mersenne twister),还有SplitMix64。

    20年,1人写出70万行代码!沙盒游戏「鼻祖」13年靠玩家捐赠维生

    其它相似于矮人堡垒的游戏会由于算法成绩「夭折」。

    矮人堡垒用的是A*算法,速度很快,但Tarn以为还是不够好。

    普通而言,为了简化操作,开发者会在地图顶部添加各种大型结构。

    但由于矮人堡垒的地图十分大,而且还会不断变化,用A*算法只会消耗少量维护时间。

    20年,1人写出70万行代码!沙盒游戏「鼻祖」13年靠玩家捐赠维生

    所以Tarn决议,经过行走来追踪可抵达的衔接组件。这样就算地图变化再快,更新也很容易。

    虽然更新维护变快了,但这个办法还是有缺陷:

    维护的部件指数只能用于行走。

    针对这个成绩,Tarn做过一些尝试,但都以失败告终。

    他留意到有些成功的游戏用了矩形掩盖,觉得这个办法还蛮不错,但又没法确定那些游戏的地图大小和波动性。

    Tarn以为,最复杂办法其实就是为飞行生物添加一个新索引。

    但由于两个索引都需求同时维护,而其中一个索引曾经够差了,所以这对内存和速度有很大影响。

    又或许可以跟踪它们的途径属性,但是随着地图的变化,维护起来还是会变得困难缓慢。

    Tarn表示,在代理和地图复杂性方面,目前曾经尽最大才能来支持agent和复杂的地图了,所以假设我们想从中失掉更多,就必须做出一些退让。

    (责任编辑:admin)