简介 这篇博客将作为个人知识体系的搭建进程,相当于一个技能池,来记录我的技能状态,同时作为博客的目录。 本篇动态更新 PS:本文的记录格式 技能|完成进度|文章链接(如果有) 计算机相关 语法基础 C# | 0.8 这个部分就不写了,因为菜鸟教程比我写的好我平时也都看菜鸟,和我看唐老师做的笔记。 菜鸟教程:C# 教程 | 菜鸟教程 B站唐老师的课程:【唐老狮】Unity系列之C#四部曲—C#入门_哔哩哔哩_bilibili C++ | 0 Lua | 0 数据结构于算法 计算机组成和操作系统 计算机网络 图形学 Unity游戏开发学习 Unity
前言 这篇文章算是对单例模式在实际运用时的进一步探索和讲解,本文的目的是阐明具有单例模式的类的使用(一般是Manager)和一类与Manager看起来很像的类Controller,并对Controller和Manager的区别详细讲解,并提供多种解决单例模式耦合弊端的三种方法。 前置篇:Unity游戏开发-基础设施单例基类 | 闲云野鸥 Controller与Manager是什么? manager与Controller为习惯命名,翻译为管理器和控制器。 Manager(管理器) 核心作用是提供给全局的服务,充当模块之间的粘合剂,要同时满足这两点才有必要设置,判断的因素是管理器不会随着某一
命令模式的概述 命令模式的定义是:把请求封装成为对象,以便用于不同的请求,队列或者日志请求来参数化其他对象,并支持可撤销操作。 那么命令模式主要用来解决哪些问题?这也是为什么需要命令模式,主要是以下四种 1. 请求者与接收者之间的强耦合 问题:如果调用者直接调用接收者的方法,两者就绑死了。如果接收者变了,调用者也要改。 解决:引入一个“命令对象”作为中间人。调用者只需要知道“执行命令”,根本不需要知道背后是谁在干活、怎么干。 2. 操作的“撤销(Undo)”与“重做(Redo)” 问题:普通的函数调用执行完就结束了,想反悔很难。 解决:命令对象可以保存执行前的状态(或反向操作逻辑)。在命令
开篇 距离上次更新技术相关内容已经过了有点久了,一方面意识到自己的开发实力还不够,为了提供更加优质的内容要在沉淀一下,另外之后会更新第一版背包系统的做法,另一方面是最近事情有点多,好了这篇文章主要是作为最近学习的总结和复盘来的 游戏开发需要什么? 不是宽泛的要学代码,要学美术这样的回答,而是更加深入和具体一点,这里只赘述在代码上的问题,美术上能力有限。 我们要清楚能写代码和能把代码写漂亮是两个维度的事情,能写代码可能只需要记住语言的基础语法和一些游戏引擎的相关API,但是把代码写漂亮就要更加深入的了解代码如何组织,学习设计模式,和一些基本框架比如(MVC等),学会组织代码是构建出整个游戏的
公共Mono模块介绍 公共Mono模块属于基础设施层次,可以让不继承Monobehavior的脚本也可以使用Unity内部的生命周期函数和协程。 公共Mono模块由MonoController和MonoManager两个脚本构成,MonoConrorller实现基础功能,MonoManager为单例模式提供唯一的访问点。 公共Mono模块代码实现 Mono模块代码比较简单本质上就是对Unity内部的生命周期函数和协程进行封装,涉及到了代理模式。(后续添加代理模式讲解) 123456789101112131415161718192021222324252627282930 using Sys
设计模式单件模式 其简洁的定义为单件模式确保一个类只有一个实例,并提供一个全局访问点。 它可以避免访问混乱,资源浪费和性能损耗,避免状态冲突与数据不一致,避免重复操作与资源竞争。 Unity游戏开发的单件模式设计:单例基类 单例基类属于游戏框架时的基础设施,为核心服务层提提供统一父类,避免重复书写单例模式。 这里我们将单例基类分为三种:继承自Unity的Monobehavior,纯C#,特殊的单例基类。 针对前两种单例基类还可以被写为带有以下优化特性:双重检查锁定,泛型,持久化,调节器,空对象。 其中双重检查锁定,泛型,空对象是两种单例都可以用,而持久化,调节器只有继承自Unity的Mon
游戏开发基础框架是什么? 比较官方的叙述是:从底层设计思想来看,Unity 框架的本质是“经验的抽象沉淀”。它是一套基于 Unity 引擎特性设计的“代码规范与功能模块集合”。与直接编写业务代码不同,框架更侧重于“如何优雅地组织代码”,通过预设的结构和接口,解决项目开发中的共性问题(如模块耦合、功能复用、逻辑混乱等),从而让开发者将精力聚焦于核心玩法的实现。 简单来说游戏框架是解决游戏开发中如何组织代码(不让代码逻辑变成史山)并且每个项目几乎都存在的问题(每个项目都要写一遍的),其底层原理是设计模式和软件架构思想等知识。 在设计的时候其主要要考虑的是,游戏类型和需求,可维护和拓展性,通用性和
要求(策划) 设计意图 为了解决传统Rigidbody控制器常见的“边缘掉落无法起跳(脑溢血操作)”、“起跳动作与物理位移脱节(滑步感)”以及“斜坡悬空”等痛点,本模块引入了土狼时间、动画事件驱动与贴地微重力机制,旨在打造具有“吸附感”和“高容错”的动作游戏3C体验。 3.2.1 核心机制与边界条件 ① 土狼时间 (Coyote Time / 地面缓冲) 规则:当角色主动走下悬崖或离开平台边缘时,系统不立即切断“地面状态”,而是保留一个短暂的宽限期。 边界条件: 宽限期内(默认0.1s)按下跳跃,视为地面起跳,正常触发跳跃流程。 若角色是被击飞或获得向上初速度(verticalVelo
观察者模式 官方定义: 观察者模式属于行为型设计模式。它的标准定义是:“定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。” 听起来可能有些抽象,接下来我用人话给大家拆解一下。 传统写法痛点:紧耦合地狱 假设我们要写一个天气系统,有一个用来获取数据的 气象站类,还有一个负责展示的 手机类。 在没有学习设计模式之前,为了在手机里展示天气,我们通常会直接在手机类中声明并实例化一个气象站对象来获取数据。但问题来了:现实中可能有成千上万部不同的手机!如果每部手机都直接绑定气象站的具体实现,一旦气象站的内部结构发生变化,所有手机的代码都要跟着改。
移动控制的方案分类 按照是否受到物理影响分为非物理驱动和物理驱动还有就是混合方案。 非物理驱动(代码绝对控制) 这类方法不依赖刚体物理,直接移动物体。适用于没有真实物理交互需求,或需要绝对控制权的游戏,其最主要的方案为Transform和CharacterController。 1.Transform 原理:每帧直接修改 transform.position 或调用 transform.Translate()。 核心特征: 零物理开销:这是性能最极致的方式。 绝对精准:你设什么位置就是什么位置,没有惯性、没有重力、没有任何延迟。 完全无碰撞:会直接穿透任何物体,除非你自己写代码处理。