实现设计师友好的代码
设计师友好的代码为什么要开发设计师友好的代码?
好处有很多,可以防止一些意想不到的bug,也可以提高沟通效率……
设置参数反射标记
通过Serializable可以提高参数的可读性,如下图的MoveSettings和AttackSettings。
通过[Min(0f)],[HideInInspector],……,防止设计师乱搞。
12345678910111213141516171819namespace Character{ [Serializable] public class MoveSettings { [Min(0f)] public float moveSpeed; } [Serializable] public class AttackSettings { public GameObject weaponPrefab; public Transform weaponEquippedTransform; [HideInInspecto ...
实现通用的UI布局
前言为什么要实现通用的UI布局?
因为作为对美术一窍不通的程序员,并不想花太多时间去精致的摆放每一个UI,不如直接用锚点,看着太差不差就好了。
但是每次调整Unity锚点时都需要重新设置位置,真的很麻烦,干脆写个脚本,实现在运行时通过滑块调整UI布局。
通用的UI布局何为通用的UI布局?
在我眼里就是网页设计中标准的,页头,正文和页脚三元素(其实就是一分为三块),想要多一点块就不断的嵌套,想要少一点块就将某几块的高度设为0.
于是就可以实现以下这样的PageLayout类。
在Awake时获取三元素的初始数据。
然后在Update时根据滑块数据不断的调整锚点位置。
123456789101112131415161718192021222324252627282930313233343536373839namespace UI{ public class PageLayout : MonoBehaviour { private void Awake() {#if DEBUG _headerR ...
Game Design, Art and Concepts
Game Design: Art and Concepts今天截至目前完成了GameDesign的第一周作业,等会提交一下,这是我第一次完整的将概念做成demo(纸质版),感觉确实不错,之前那灵光一现确实有点啥都不算了,准备把另一门课学完之后就开始开发上GameDesign时的Idea。


不得不说这种有限制的创意确实更容易具象,不然太天马行空了,反而难做,怪不得老师说可以先找一个主题。
不过DeepSeek给我的这几条建议确实不错,很受用。
警惕“知识松鼠症”:用“30分钟试学”过滤伪兴趣:任何新领域先投入半小时,确认是否值得进入主题周/月。
设置硬性输出指标:每个周期必须产出可展示成果(视频/文章/原型),避免陷入“好像学了很多但说不出”的状态。
保留20%弹性时间:每周留出1天处理未完成内容或突发兴趣(如临时想研究瑞典流行音乐)。
Story收获比较多的就是Story这部分,因为我之前就不怎么care游戏的故事性,课里说游戏的故事脉络主要有三种呈现思路。
Writer-Driven:主要是完全由作者控制走向。
Writer-Led:相比 ...
基于InputSystem实现本地多人游戏(二)
个性化Player相比昨天主要是完整实现了角色的异化,来看看具体的思路吧。
首先,因为 PlayerInputManager 不支持异化,只能构造通用的 Player,所以就没法直接让 PlayerInputManager 根据不同的 PlayerIndex来 实例化不同的 Player。
所以想到可以让 PlayerController 直接管理一个 static list 来存储所有的异化 Player,然后再通过 PlayerIndex 来获取对应的 Player,但是这样破坏了封装性。
干脆就直接让 PlayerController 直接获取对应的 PlayerSpecific,然后拷贝或者创建对应的组件,所以我们就可以在创建中创建一个 PlayersSpecifics 的空物体,然后在里面放置所有的 PlayerSpecific。
再通过下面的代码,为每一个 PlayerIndex 查找对应的 PlayerSpecific,如果找不到就使用默认的 PlayerSpecific。
1234567891011121314151617181920212223242526272 ...
基于InputSystem实现本地多人游戏(一)
InputSystemInputSystem 是 Unity 自带的一个上层输入系统(隔离了不同的输入设备),可以让我们更方便地处理输入事件,当然同时也不可避免的会失去一些精细的调控。
要想实现本地多人游戏光有 InputSystem 可不够,还需要用 PlayerInput 对输入进行二次绑定以及 PlayerInputManager 来管理多个PlayerInput。
PlayerInput设置
大部分设置保留默认就行。
Camera:这里由于我是 2D 游戏,所以没有设置 Camera。
Behaviour:这里我没有用默认的 SendMessages,是因为我希望能更精准的控制这些 Callback,所以我选择了 InvokeUnityEvents。
脚本需要编写一个脚本来处理所有你需要的输入事件,然后在 PlayerInput 组件上注册函数。
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162 ...
游戏机制设计师详解
1
构建作品集与在线影响力
在GitHub或ArtStation发布项目代码与设计文档,撰写技术博客分析经典游戏机制(如《塞尔达》的物理交互、《文明》的资源平衡),吸引潜在雇主注意。
21. 理论基础:从设计原则到数学模型
核心概念
推荐学习材料
搜索到的《游戏平衡性设计原则》PPT(网页2)详细拆解了平衡性设计的方法论,如通过玩家反馈、数据分析和A/B测试发现问题。
《游戏设计心得——实现游戏平衡性的技巧》(网页8)提出“模块化设计”和“复杂性控制”原则,例如将游戏要素功能单一化以简化调整流程。
2. 技术工具:数据分析与快速迭代
数据分析工具学习使用游戏引擎内置的Analytics工具(如Unity Analytics)或第三方平台(如GameAnalytics),分析玩家行为数据(如胜率、资源消耗、流失节点),定位平衡问题。
数学建模工具结合计算机背景,用Excel或Python建立平衡性模型。例如,通过马尔可夫链模拟玩家决策路径,或利用博弈论优化多人对战的经济系统。
3. 实践方法:从原型到测试
小型项目实践设计一款简单游戏(如卡牌对战或平台 ...
游戏引擎架构阅读笔记
前言不只是阅读《游戏引擎架构》的笔记,更多的是做引擎时的心得。
项目管理版本控制、项目构建等等其它方面的工具自选就行,好用就完事了。
引擎核心层引擎入口建立 Engine 的基类,同时在 main/WinMain 中创建 Engine,将其编译成 Lib 库后暴露给编辑器,编辑器通过继承 Engine 类以实现对引擎的配置。
1234567891011121314class Editor : public Engine{public: Editor() {}; ~Editor() {};private:};Engine* CreateEngine(){ Editor *editor = new Editor(); return editor;}
实例化引擎顺序书里面说要注意,但我觉得还好,不容易崩,实在不行就用书里面的优先级队列吧。
不过引用友元也是会初始化的,所以最好还是在 PreInit 或者 Init中完成。
事件日志管理和计时器这种都是自己想怎么弄都行,不会消耗太多性能,不同的日志和计时 ...
DX12渲染管线学习笔记
前言零散的笔记,是我在学习过程中的思考,自认为简单的东西并不会记录在内。
Direct3D 基础初始化 D3DFactory 和 Device说实话 DirectX 中的架构思路真的值得去学习,这里的工厂和驱动都是蕴含了很多的设计思想的,但我目前还不能真正的理解。
WRAP应该不需要去写它的意义吧,猜猜就知道了。
命令个人感觉 CommandList 类似于资源描述符,而 CommandAllocator 类似于缓冲区,将 CommandList 中的命令传入 CommandQueue 中,但是 CommandAllocator 还是原来的,这也是为什么在 CommandQueue 的命令被执行完前不能重置 CommandAllocator。
渲染流水线目前这里指的就是普通的光栅化流水线。
这里特地拍了一张我在书上的笔记,是想展示一下数据的流向。
Step1 内存数据流向显存可以先到后面看一下流水线状态,可以发现主要就是绑定根签名表和 Shader,缓冲区都是在创建时绑定的,当然绑定的都是描述符,绑定数据的话带宽直接废掉了。
书里也说得很清楚了绑定的时候 GPU 会自动创建描述符 ...
Games101学习笔记
前言感觉自己一开始没有认真学,所以现在基础有点差,最近打算重学一遍,该手推就手推,不偷懒了。
这次主要是跟着 GAMES-Webinar 的课程学习,所以如果你想要看懂这份笔记,我建议先去学习相应的课程。
TransformationView transformation相机需要设置的参数。
将相机平移至原点并同时将 look at 和 up 及其叉乘共三个向量同时对其标准坐标轴的矩阵即为 View matrix。
唯一要注意的就是由于直接计算旋转矩阵比较复杂(从任意向量变换到标准坐标轴),所以先计算其逆矩阵(从标准坐标轴变换到任意向量)。
Projection transformation其实只要求从四棱台压缩到矩形的矩阵就行了。
直觉上其实很容易得出结论,难点在于求出相应的变换矩阵。
为了计算出来就得补充两个假设。
Any point on the near plane will not changeAny point’s z on the far plane will not change
解方程后也能求出来最后的投影矩阵(还需要用 FOV 和长宽比进行参数替代)。 ...
基于OpenGL的光栅化渲染管线
前言最近在写游戏引擎,在这里将主要记录一下如何架构跨平台的 Rendering Pipeline。
在大部分人眼中,这就是 Rendering Pipeline,但是其实这只能说是 Shader Pipeline,真正的渲染管线远比这更加复杂。
光栅化的渲染管线固定的渲染管线这是早期架构的渲染管线,因为引擎的交互还不完善,所以暂时不需要考虑动态的情况。
Rendering/
RenderingInterface.hpp
Platform/
Windows/
WindowsRenderingPipeline.hpp
WindowsRenderingPipelineState.hpp
DirectXInterface.hpp
Android/
AndroidRenderingPipeline.hpp
AndroidRenderingPipelineState.hpp
OpenGLInterfac ...