L

1.前言上一篇TeamCity大概介绍了开发、打包及更新流程，这篇继续上一篇遗留的一个问题不能自动化的问题。 2.TeamCity Dependent Build上一篇的流程中需要将YooAsset的增量包提交到仓库中所以不能在有变动时自动出包及制作更新包，就刚好利用TeamCity的依赖构建[1]先在基础设置中配置构建物收集目录目录支持*通配符，规则[2]大概就是从项目目录 => TeamCity目录，上述配置构建成功后可得到如下构建物：设置完Artifact Paths后，去设置一下Dependencies就YooAsset做更新而言(其他资源更新方式也是差不多的流程)，我配置了两个依赖： 首包资源（YooAsset首包会有一个1版本的资源目录及原始bundle资源目录UnityManifest） 增量资源：基于上一个版本构建出来的资源目录及版本号文件UnityManifest/StaticVersion.bytes 其中首包依赖中需要剔除版本为1的UnityManifest/StaticVersion.bytes 剔除规则就是用-:目录或者文件的形式，之所以要剔除是因 ...

1 前言关于TeamCity的安装教程以及Unity插件安装无需赘述，参考:工作流篇（2）： TeamCity，15分钟搭建U3d CI环境，自动测试、版本发布、部署 目前项目热更新方案是使用的HybridCLR；资源管理使用的是YooAsset. 整个构建过程是囊括了以上两个方案的流程。 2 版本控制2.1 VCS checkout目前项目分支结构为 v1/release、v1/hotfix。出包使用release分支，同时将release分支内容同步到hotfix分支，后续热更新往hotfix分支提交。需要出新包的时候就是新建v2/release分支。 起初是准备在TeamCity上面创建两个Build，分别监听hotfix和release分支 为了省一点硬盘空间 将两个Build的目录指向同一个，但两个不同Build启动的时候会将当前目录清空，重新拉取仓库内容，unity切换平台导入资源每次都会耗时2个小时，所以后来hotfix、release共用一个Build，构建步骤用条件进行区分头三个checkout模式在两个不同的Build任务执行时都会将 ...

布鲁克斯 2. 人月神话 提前预留足够的测试时间 开发并推行称产率图表、缺陷率、估算规则 pingcode的速率图、燃尽图 缺陷率。总结归纳作为前车之鉴 缺乏合理的时间进度，是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大 围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。 想进度落后的项目中增加人手，会是进度更加落后(任务重新分配、沟通成本、培训成本、原有任务中断) 4. 系统设计 为了获得概念完整性，设计必须有一个人或者具有共识的小型团队来完成。 5. 画蛇添足 这部分内容对应PMP中的范围，即：做且仅做。防止范围蔓延而带来的额外成本。 范围蔓延在游戏项目中应该属于最常见的事情，游戏功能、玩法经常改动 6. 贯彻执行 手册/文档 在游戏项目中，最应该做这部分的应该是一些中台技术(SDK、游戏后台数据上报、CI/CD)及引擎优化建议；因为游戏类型不一样(MMO\FPS\MOBA)除了上述一些通用接入类型的事情，很难总结出一些有用内容，以及没有那么多时间来写项目手册； ...

开源地址: huatuo 现在市面上使用比较多的就是xlua等几个lua热更方案，纯c#的热更方案有ilruntime。每个方案都有各自存在的道理，水群里面经常出来一些“干死lua”之类的声音,这事儿在我看duck不必。我不喜欢lua的原因是因为引擎本身就有一层黑盒子 用了lua之后把游戏代码又封了一层。层层加码之后实际上阻碍了团队部分人员能力的提升.回到正题。项目目前用的是ILRuntime，因为是第一个unity项目，团队成员对unity以及c#的把控能力不高出现了以下一些问题: 频繁的添加适配器 频繁的添加委托 AOT裁减 就目前而言huatuo宣称上能够很好的解决以上的部分问题，使用起来简易不少。问题比较大就是对il2cpp的代码入侵较大，在没有成功上线项目下感觉要趟不少坑。跟着官方项目走基本能熟悉流程；我用自己的项目从ILRuntime切到华佗后遇到了以下一些问题： 打包的Mac项目报找不到imageplayersetting里面需要把ios也选上.NET 4.x [Android] * error only support 64bit。顾命思议,playsetti ...

Unity序列帧播放器 核心: 帧率 播放下一帧 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151using UnityEngine;using UnityEngine.UI;using System;/// <summary>/// 序列帧动画播放器/// 支持UGUI的Image和Unity2D的SpriteRenderer/// < ...

古往今来最大的弱势群体：沉默的大多数。 这些人保持沉默的原因多种多样，有些人没能力或者没有机会说话；还有些人有隐情不便说话；还有一些人，因为种种原因，对于话语的世界有某种厌恶之情。我就属于这最后一种人。作为最后这种人，我有义务谈谈自己的所见所闻。 恕我直言，能够带来思想快乐的东西，只能是人类智慧至高的产物。比这再低一档的东西，只会给人带来痛苦，而这种低档货，就是出于功利的种种东西。

石田衣良 平平淡淡的一本书，感觉就是作者在写自己的日常写作生活，以及为了拿直木奖的一些小凡尔赛。(ps：后来翻了一下直木奖获奖名单，发现里面居然有东野圭吾的《嫌疑人X的现身》)全书读下来就感觉一句话说的挺到位小说能把读者带入另一个世界，这或许才是小说最为珍贵的力量吧。

可能是因为悬疑小说看多了，我总感觉最后的乔西在拉开窗帘沐浴在太阳中的时候应该是去世了。从《远山淡影》这个书里面读到的石黑一雄风格就是网上或者书评中写到的“时间、记忆、自我欺骗”手法来看当时的故事就是两个感觉完全不同的故事最后合并在一条故事线上。那么如果用同等的感官来看克拉拉这个故事 我总感觉乔西应该是去世 克拉拉一直扮演者乔西直到母亲从伤痛中走出来离开家 把克拉拉放进阁楼。 小说整体感觉一般。既没有科幻的感觉，也没有普通故事的阅读感。石黑一雄的写作水平感觉极其不稳定。

公司是内网Gitlab所以配置的webhook没办法直接跟pingcode交互。然后就衍生出了这个奇奇怪怪的姿势：拥有外网访问权限的机器上创建一个jenkins任务 每隔两分钟利用Gitlab API获取每个分支的commit以及合并请求构建成webhook内容访问PingCode提供的接口，再通过PingCode提供的RESTful API同步工作状态及登记工时 Python脚本主要干了以下事情： 检测每个分支的提交，然后构建push的webhook提交到pingcode commit的title带上#+pingcode的任务编号(例:#D-123)关联提交次数 merge_request带上#+pingcode的任务编号关联到Merge state commit的title内容带上$[0-99](例: $4)登记工时 commit自动关联到任务的父任务 提交后自动将任务变更到“进行中”状态 检测每个往develop提交的合并请求，然后构建merge_request的webhook提交到pingcode 状态为opened时，将任务变更到“已完成｜已修复” 状态为merged时， ...

unity使用命令行打包的时候是不能再开一个unity编辑器窗口进行工作的，所以常规有一个额外的打包服务器。一般手游都需要接SDK，所以常规是导出一个androidstudio(IL2cpp)工程 1.基础配置1.1 安装jenkins在官网下载jenkins安装包即可。jenkins需要填一个jdk路径，所以就需要先下载一个jdk 1.8 1.2 配置JDK- Manage Jenkins→Global Tool Configuration→JDK。 - 设置JDK - 别名：jdk 1.8 - JAVA_HOME: *1步骤中下载的jdk安装路径，如果是默认安装则在 C:\Program Files\Java\jdk1.8.0_31* 1.3 配置Gradle- 安装Gradle - Manage Jenkins→Global Tool Configuration→Gradle。 - name: gradle版本号 - 我勾选了Install automatically，选择了一个6.8的版本 - 设置GRADLE_USE ...