LeeKa 的酒馆

摘录

对于数组a，&a+1 输出了什么？&和+在这里的作用是什么？

前言

PCA（Principal Component Analysis）是一种常用的数据分析方法。

前言

算术编码是一种编码算法，它比哈夫曼编码更高效。

前言

2022 年参加 Seed 训练营的笔记，另附 Seed 训练营感想。

前言

记第二次实习：在维塔士西安工作室的虚幻Demo。

开始与 Unreal 学习

七月的困顿中发现了老师在群里发的维塔士西安工作室的实习海报，于是抱着再怎么样也比在学校勉强自己对着牛客OJ发呆好的态度报名，然后面试等等各种流程走下来，也就是入职了。

维塔士西安是西安仅有的几家游戏公司，所以虽然本身是 2B 的业务但是居然也让我听过，再加上上个学期有参与 OpenDay 也就更熟了一点（和 NS 失之交臂呜呜）。

Git树上下

树下的肥（屎）料（山）

这次主要是负责了 Buff 系统;整个设计大概是这样的：

• 角色有 Buff 和技能；
• Buff 修改玩家的属性，技能则由玩家主动施放，由更多的自由度。
  • 例如，我们可以将手雷设计为一种技能，血包设计为一种技能，他们有对应的按键，有特效，有各种独一无二的动画和逻辑……
  • 而 Buff 只需要储存什么修改了玩家的什么属性即可
• 所以 Buff 只需要是一种数据结构
• Buff 有冲突、有一个 Buff 改多种属性、有时限，有延时增减等情况。

话是这么说，但是实际上写起来却乱七八糟。一开始我设想了一种基数据类，他存储了最基本的数据信息，然后，对于不同的时限等问题分开衍生子类。这样，就可以用一个指针队列存储所有的 Buff 了。但是这样做的问题在于数据类型实际上是不一样的，需要类型转换（例如我们也许会有 Float 型的血量，但是 int 型的金钱）。这样做技术上来说并没有问题，但是说到底 void* 指针强转本身就是不安全的。尽管在这一方向的尝试让我了解了模板的一些知识，但是最后我还是放弃了这种做法。

最后的“摆烂”做法是将所有的数据堆在了一个数据结构中，对于不需要的数据（例如一个无限时的 Buff）直接置空就行。这种做法当时看来是摆烂、权宜的做法现在想想其实是正确的。回头翻翻在西山居的代码，也是读表读出的字符串，然后在构造的时候做类型转换。（这里的类型转换是基本类型，而且不牵扯到内存地址，所以并不是那么的不安全）。那么对于这个数据结构，我们也完全可以做这样的权益，即大家都用 float 型，或者放大以后用 int 型，抑或 string，这样就可以使用统一的容器存储他们了。如果我们用的时候是做其他类型的值————无非int/ float / bool 等等，再去做类型转换就 ok 了，至于转换的逻辑，例如大于零则视为 bool 为真完全可以放到对应属性的逻辑函数中去做。

我原本的设想是数据结构中有一个指向其附属角色的指针，这样就抽象成将 *buff.AttributePtr 赋值为 buff.value 就可以了。但是事实上根本没有足够多的属性值得去这么做，即使有，也完全可以写成让 changeAttribute() 根据实际参数去定义一个对应的指针。

事实上，在云计算的课程中就讲到过，应该是 google 云计算数据库只能存入字符串类型的值，大大简化数据的存储管理，不管要什么值，要值的一方自己去做转换即可。毕竟索取值的一方自己肯定很清楚值的类型。

另一个值得一提的思考是属性组件，按理来说属性组件是存储所有的属性，但是事实上这样做不妥：如果是 public 那么属性是不安全的；如果是private/protected ，每个组件用到属性的地方都会产生一个函数调用。而且，UE 框架中的 MovementCoponent 本身已经是写好的了，我们总不能重载它去适应我们的属性组件吧？

所以更好的办法是每次修改值的时候，属性组件去查询对应的组件的值然后做修改，如果有事件，不妨也在属性组件做通知。这样只要保证大家都从属性组件做修改就不会有问题。此外，可以所有的组件声明属性组件为友元，这样就可以不写函数接口，而只有属性组件能只有访问那些私有成员，其他的组件没有办法去做修改。（当然友元的写法会破坏面向对象的封装性，但是暂时想不到其他更好的解决办法了，也许最好的办法是不要AttributeComponent）。

其他的一些工作：改蓝图，让 Buff 加成的属性在血条上显示成蓝色（其实是做了两个血条）。以及各种情况下的读蓝图，也算会了点蓝图的基本操作。

树上的猴子

这次实习我们使用的是跑在局域网上的 Git 仓库，之前不能说没有用过 Git 但是还确实没用过其进行多人协同，这次也算是一次体验了。 rebase, merge, fetch,revert... 这些操作有些之前不是很熟悉也借此机会有了一定的了解。一次很离谱的操作则在于某次 push 后所有的 commit 都有我作为合作者了……另外一个麻烦的地方则在于每次有版本落后，即使没有冲突，使用 VS-git 也会自动创建一个 Merge commit 使得分支受到了一定的污染。

另一方面则是隔壁的某组模仿我们组没有使用 SVN，结果看到他们反复地请正式员工来做 git 的 debug……看到这种场景不由让人领会到自己平时的训练积累的重要性。说到底如果没有有关经验的人在正式项目中这么做的话，不提时间、效率的问题，也难免会让人产生挫败，消磨斗志。

其他的一些思考与牢骚

• 蓝图这种可读性居然需要通过挪格子和连乱七八糟的线来保证的产品，虽然降低了一点点门槛，但是看得真是让人头大。
• 不想和不会做变量命名、写出来的东西只有自己能 debug 的人说话。
• 远离指针……
• 通勤时间实属人幸福感的一部分，每天七点过起床赶八点的高新六路，然后忍受堵车，下车找共享单车骑在早高峰的十字路口……这种体验实在是一个月就够了。

前言

GAMES101-P4：视图变换和投影变换（正交投影、透视投影）。透视投影部分内容在原视频P5

前言

GAMES101-P3：基本线性变换（旋转、缩放、切变）和平移、仿射变换矩阵、齐次坐标、三维变换中的旋转问题。

前言

GAMES101-P2：回顾线代：向量、矩阵。

试图调整 VS Code 的 C/C++ 编译默认设置，结果却……

Pre：生活中总是免不了和各类文章、笔记、心得产生交到。有被动地学习，也有主动的思考产出。各类文字（下统称日志）的质量、功能、隐私性等等不一而足。这里，通过反思和整理，我将给出我的答案。

七年后，当 Nick 在发布他大热的第三张专辑《ASCEND》的时候，是否还会想起2012年吸毒过量后被抢救回来的那天？

使用 git bash 新建博文过于繁琐，有没有更简单无脑的办法？

前言

Heavenly Side 是收录于ILLENIUM的第四张专辑的一首歌。

天国王朝语摘，自翻与所看版本的翻译

这个功能在VS code 中被叫做片段（snippet），其功能是在输入用户定义好的触发词后，可以像代码补全一样补出一段代码。

2021年，关于“如何看待当今游戏产业”在国庆期间所作演讲稿

提要

~~这是一篇对神话篇、历史篇未涉及但是又有趣的一些内容补充，请注意你必须要先对历史、神话篇加以了解以免出现理解上的困难。~~这里目前是一个草稿

前言

本文承接前文，以 NexT 主题为例，讲述如何更换主题并对其进行配置。

前言

本博客搭建于大一（2020）。当时，作为一个“萌新”，给自己的坎坎坷坷的博客搭建历程写下了些许文字，原名为《搭建个人博客 || 一、在本地搭好博客》。2023 年末，我回过头重新审查文章，重新编辑了一些说的不严谨的地方。

现在（2024 年 1 月），我自觉对使用博客有了一套自己的连贯的流程，故在原文基础上重新编辑完善如下。希望能给你一点帮助。🩷