UE GamePlay框架

概述

所谓的引擎,一般都是先要学习下引擎的主要框架。对于UE来说,一般先要去看下gameplay。这篇简单写下个人理解。关于框架类的关系,可以参考下下图:
gameplay框架

Actor

UE中Actor是放置或者生成的对象的基类。关于Actor的加载方式,这个之前写过一篇,可以参考下。UE Actor生命周期

GameMode

上图,可以看出,Game里边,GameMode和GameState是非常重要的组成部分。接下来了解一下GameMode。
对于游戏来说,都有一些基础规则,比如:

  • 出现玩家和观众,以及允许多少玩家
  • 玩家进入的方式,比如出生地点和其他生成/重生等规则
  • 游戏是否可以暂停,以及如何处理游戏暂停
  • 关卡之间的过渡,包括游戏是否以动画模式开场

来看下Lyra里边的GameMode的规则,如下:
ALyraGameMode
初始化各个类
从上图可以看到,ALyraGameState,ALyraGameSession,ALyraPlayerController,ALyraReplayPlayerController,ALyraPlayerState,ALyraCharacter,ALyraHUD都是在这里初始化的。

GameState

Game State 负责启用客户端监控游戏状态。从概念上而言,Game State 应该管理所有已连接客户端已知的信息(特定于 Game Mode 但不特定于任何个体玩家)。它能够追踪游戏层面的属性,如已连接玩家的列表、夺旗游戏中的团队得分、开放世界游戏中已完成的任务,等等。


以上部分来源于官方文档。我觉得对于一些非职业游戏开发者来说,不是那么容易理解的。我来说下我的看法,对于gamestate,主要用于存储整个游戏全局的信息,比如,包括当前玩家的信息,如果是多人游戏,还要包括多人的玩家信息。当然对于每个人的信息,在PlayState里边。如下图:
gameState
gameState

lyra里边,就放在lyraPlayState里。如下图:
ALyraPlayerState
AlyraPlayerState

控制器(Controller)

控制器(Controller) 是一种可以控制Pawn(或Pawn的派生类,例如角色(Character)),从而控制其动作的非实体Actor。人类玩家使用PlayerController控制Pawn,而AIController则对它们控制的Pawn实加人工智能效果。控制器用Possess函数控制Pawn,用Unpossess函数放弃控制Pawn。

控制器会接收其控制的Pawn所发生诸多事件的通知。因此控制器可借机实现 响应此事件的行为,拦截事件并接替Pawn的默认行为。 可以让控制器在给定的Pawn之前运行, 从而从而最大限度减少输入处理与Pawn移动之间的延迟。

默认情况下,控制器与Pawn之间存在一对一的关系;也就是说,每个控制器在任何给定的时间只控制一个Pawn。这对于大多数 类型的游戏都是可以接受的,但对于某些类型的游戏可能需要进行调整,因为实时策略可能需要能够同时控制多个实体。

对于Lyra来说,当然也有专门的控制器。如下图:
LyraController。在这个里边,包含了太多的内容,感兴趣,可以去看看源码。

摄像机(Camera)

摄像机,在UE中,它代表了玩家的视角,也就是玩家如何看待世界。对于我们游戏的主视角,playercontroller会去指定一个Camera Actor。关于CameraActor,如下图:
CameraActor
可以看到,CameraActor中,UCameraComponent这个组件主要操作相机。Lyra里,是直接用的ULyraCameraComponent这个组件,如下图:
lyraCameraComponent

用户界面和HUD

关于这块,用户界面,引擎底层主要是用slate框架写的。包括现在很多设计或者蓝图程序常用的UMG,都是基于slate。然后,很多项目采用一些继承机制,把UI分成多层,每一层有每一层的作用,也是很常见。至于这层,不同项目的解决方案不一样,不多说。
至于HUD嘛,这个举个例子,每个character上都有一些血量,经验值之类的,就是hud里做的。

小结

这篇主要写了以下UE的GamePlay的框架,包括GameMode,GameState,Controller,Camera,用户界面和HUD。其实,要看懂这些内容的底层代码,需要一定的C++功底,关于C++,可以去学习学习。OK,这篇结束。

FFmpeg是一款功能强大的开源多媒体处理工具,广泛应用于视频和音频的编码、解码、转换以及流媒体处理。然而,由于历史原因和标准限制,原生的FFmpeg并不支持将H.265(高效视频编码)格式的视频流封装到FLV(Flash Video)容器中。FLV是一种常见的网络流媒体传输格式,但其最初设计时并未考虑现代高效的H.265编码标准。因此,当尝试将H.265编码的视频与FLV容器结合时,会出现“Video codec hevc not compatible with flv”的错误提示,表明FFmpeg无法识别这种组合。 为了解决这一问题,开发者通常需要对FFmpeg的源代码进行修改和扩展。一个名为“用于解决ffmpeg不支持flv+h265需要修改的文件.zip”的压缩包中包含了一些源代码文件,这些文件旨在扩展FFmpeg的功能,使其能够处理FLV容器中的H.265编码内容。压缩包中的三个关键文件分别是“flvdec.c”“flvenc.c”和“flv.h”,它们分别对应FLV的解码器、编码器和头文件。 flvdec.c:这是FFmpeg的FLV解码器源代码,经过修改后可能支持读取和解析包含H.265数据的FLV流。解码器的作用是从FLV容器中提取视频数据,并将其转换为可处理的原始像素格式。 flvenc.c:这个文件包含FLV编码器的源代码,经过调整后可能允许将H.265编码的视频流封装到FLV容器中。编码器负责将原始视频数据编码为H.265格式,并将其打包到FLV文件中。 flv.h:这是一个头文件,定义了FLV格式相关的常量、结构体和函数原型。修改该文件可能涉及添加或更新与H.265支持相关的定义和接口。 要应用这些修改,开发者需要重新编译FFmpeg源代码,并将修改后的版本替换原有的FFmpeg安装。这样,用户就可以使用定制版的FFmpeg来处理FLV+H.265的
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值