meta data for this page
📚 差别
这里会显示出您选择的修订版和当前版本之间的差别。
后一修订版 | 前一修订版 | ||
reference:scheme [2023/04/06 00:28] – 创建 bibiboxs | reference:scheme [2024/03/26 16:07] (当前版本) – bibiboxs | ||
---|---|---|---|
行 1: | 行 1: | ||
< | < | ||
# 技术框架及方案 | # 技术框架及方案 | ||
+ | > **==此文档的内容可能已经过时,目前仅用于参考目的。==** | ||
+ | > | ||
> 注意:这里并非是【常见问题】解答或解决方案,而是有关游戏世界场景等技术性框架解释和方案分析。 | > 注意:这里并非是【常见问题】解答或解决方案,而是有关游戏世界场景等技术性框架解释和方案分析。 | ||
- | 如果有兴趣了解有关《沙盘引擎》的开发时的一些小手段,或者某些特殊的场景分析,您可以尝试阅览。 | + | > 如果有兴趣了解有关《沙盘引擎》的开发时的一些小手段,或者某些特殊的场景分析,您可以尝试阅览。 |
+ | > | ||
+ | > 当你可以试着了解一些世界框架的设计和原理时,可能会收获颇丰。 | ||
+ | |||
+ | |||
+ | |||
+ | ## | ||
+ | |||
+ | 《沙盘引擎》的设计初衷是实现一个**纯净但积极扩展的世界**。 | ||
+ | |||
+ | 默认的情况下,引擎会内置设计好许多预制部分,剩下的需要开发者使用脚本进行一些简单交互。 | ||
+ | |||
+ | > 举例1:引擎本身已经实现了【载具】功能,开发者并不需要重写类似“单车、汽车、飞机”这些功能,只需要新建一个载具json,修改配置的属性和模型ID,然后就无需编码的组成了一个新的载具,同时也可以使用API代码让某个角色执行上车、下车、AI驾驶等功能。 | ||
+ | |||
+ | > 举例2:引擎内置了【角色】【道具(手持)】这类的功能,开发者同样可以如上一样加入新的道具,也可以直接使用API将某个道具放置到某角色手中(或增删查改),或者让他直接AI使用,当然,很多情况下道具本身并没有功能,这也需要开发者进行代码绑定(部分道具,例如枪还是可以直接使用的,避免开发者重写射线这类相对复杂的操作)。 | ||
+ | |||
+ | 除此之外,例如世界的时间、天气这些也都内置了非常容易理解的API来使用,同时内置好了许多方便快捷的API和Event事件。 | ||
+ | |||
+ | 如果你尝试了解过编程相关知识,就会知道在《沙盘引擎》创造一个世界,确实十分方便。 | ||
+ | |||
+ | *以至于,哪怕有些玩家并不擅长编程,观察脚本也可以进行“照葫芦画瓢”,就像阅读一段文字一样,在尝试中不断进步。* | ||
+ | |||
+ | ```javascript | ||
+ | // | ||
+ | function OnWorldLoad() | ||
+ | { | ||
+ | SetWeather(1); | ||
+ | SetTime(12, 30); // | ||
+ | } | ||
+ | ``` | ||
+ | |||
+ | |||
+ | |||
+ | ## 多层建筑透视分层 | ||
+ | |||
+ | > ==**注意:此部分内容可能是过时\计划内的,目前仅供参考。**== | ||
+ | |||
+ | 如果细心了解过沙盘引擎,你会发现之所以命名为《沙盘引擎》,其中一个原因便是**游戏视角主流是2.5D鸟瞰视角**。 | ||
+ | |||
+ | 正因为这样的一个核心机制*(虽然后续可能会支持其他视角)*,**使用沙盘引擎衍生出的游戏大部分都是如此的视角方式**,那么通常偶尔会遇到一些特殊类型模型的规范问题。 | ||
+ | |||
+ | > **比如:**游戏内添加一些可进入的建筑房屋,但是这样的视角默认由上到下看到的只能是“房顶”,看不到具体内部的布局和情况,这明显是不符合玩家常理的。 | ||
+ | > | ||
+ | > **沙盘引擎在设计时考虑到了这个问题,所以增加了一种虚拟化的“楼层”方案:** | ||
+ | > | ||
+ | > 当相机按照鸟瞰视角向下看去的时候,**会自动检测当前跟随目标的“所在楼层”**,并通过**向上射线检测+半透明**的方式反馈给玩家视角。 | ||
+ | > | ||
+ | > 也就是说,如果有一个3层楼的建筑,玩家对象当前走进了第一层,那么相机视角将只能看到第一层内的信息**(建筑模型、这一层的载具、对象等)**,其他的层模型会以**半透明或全透明的方式剔除**。 | ||
+ | > | ||
+ | > 如果玩家对象走进了第二层,默认一层和三层都是“遮挡剔除”的*(1层不透明,但由于3D遮挡所以默认不可见;2层可见;3层不可见、楼顶半透明)*。 | ||
+ | > | ||
+ | > 第三层原理和第二层差不多,**利用3D遮挡本身的机制**,无需隐藏1、2层(因为默认被挡在了下面),直接展示第三层即可,同时将第三层的楼顶半透明化。 | ||
+ | |||
+ | ------ | ||
+ | |||
+ | 如上文所述的问题和解决方案理解,**目前并不能通过全自动的手段解决这个问题**。 | ||
+ | |||
+ | |||
+ | 等仍然属于世界规范之一。 | ||
+ | |||
+ | 沙盘引擎世界亦然如此,我们在设计世界框架时(现版本)将它分成了几个部分: | ||
+ | |||
+ | | 世界组成 | 说明 | ||
+ | | -------- | ------------------------------------------------------------ | | ||
+ | | 地上 | ||
+ | | 地下 | ||
+ | |||
+ | `{地表高度}`应该可以通过API进行提前调整设定,例如有些开发场景并不需要“地表下感官效果”,那么就可以将这个值调的很低,因为高度不符合设定,所以就不会触发这种效果。 | ||
+ | |||
+ | 当然,多数情况下开发者应该并不需要考虑这个选项,大概总结就是==默认地图之上就是地上,地图之下就是地下==,这个默认值大概在`Y轴-10`左右。 | ||
+ | |||
+ | |||
+ | |||
+ | ## 独立世界机制 | ||
+ | |||
+ | 在实际游戏开发过程中,可能会遇到一些指定给某个玩家特别的设定。 | ||
+ | |||
+ | 比如很多人都玩过童年游戏《罪恶都市》,我们都大概记得大桥上有一个封锁的路障,只有达到某个目标后才会允许通行(路障消失)。 | ||
+ | |||
+ | > 举一个不太恰当的例子,假设在一个游戏世界中,需要玩家自身等级> | ||
+ | > | ||
+ | > 这在单机游戏十分容易,甚至不需要有其他考虑,但在多人联机世界该如何处理? | ||
+ | |||
+ | 这里就会有一个想象,能不能给不同的玩家设置不同的路障模型? | ||
+ | |||
+ | 举一反三,这就需要用到【独立世界机制】。 | ||
+ | |||
+ | 在`CModel.Create`等API使用时,允许传入一个参数`World`,这里的本意是类似SAMP\VCMP中的网络同步通道,我们将这个概念尝试引入了《沙盘引擎》。 | ||
+ | |||
+ | > 也就是说,默认玩家加入服务器后都复活在`世界ID:0`,这是一个通用世界(大家都能看到),倘若我们将一个玩家角色、载具、模型的世界改为其他ID,那么就相当于创建了一个新的世界,只有当玩家角色的世界也改变到对应世界ID时,才会看到这个世界内所建立的东西,自然而然的,默认ID0下的世界内容将不再可见,直到玩家角色世界再次改为ID0。 | ||
+ | |||
+ | 通过此机制,可以实现一些有关【独立世界机制】的设定(例如独立的房屋之类等),但回到主题,这似乎并不能解决【独立路障】的问题? | ||
+ | |||
+ | 没错,上面只是介绍了World功能的机制,如果想实现“只在某个玩家世界内有效”的独立效果,那么也很简单,只需要将World参数填写为`player.UniqueWorld`即可解决这个问题,这个世界ID将表示**“只有此玩家可见的私人世界”**。 | ||
+ | |||
+ | ```javascript | ||
+ | // | ||
+ | var player = Player.Find(0); | ||
+ | |||
+ | CModel.Create(0, | ||
+ | CModel.Create(0, | ||
+ | ``` | ||
+ | *虽然以上的逻辑并没有什么问题,但是也可能会出现“满级玩家带着萌新过桥”的情况,这样实现起来也是不会报错的,因为在满级玩家的世界里确实没有路障,但在萌新玩家的视角就会看到大佬带着自己开车“穿过”路障,这里只是提供一种开发逻辑,具体防止违和的措施需要开发者自行想象。* | ||
+ | |||
+ | |||
+ | ## 剧情及RPG设计 | ||
+ | |||
+ | ==此处内容等待补充。== | ||
+ | |||
</ | </ |