cocos creator周边工具开发【spine预览】小记
cocos creator周边工具开发【spine预览】小记
前言
- 在工作加班之余用ccc开发了一个丑陋的spine动效预览工具，目前只支持window上运行；
- 在n个版本的更新和需求下暂时算开发完成，可以拿出来丢人现眼了；
- 来记录和分享下开发过程中碰到的问题和自己的思考；
详细信息可以看: github项目链接
大致就长这样：
替换插槽示例
曲线预览示例
用法
管理员运行 添加右键快捷（管理员运行）.bat 即可将命令写入右键注册表，可以自行打开修改命名。
这时候右键json文件即可看到添加的工具。
cd /d %~dp0
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\background\shell\www" /v SubCommands /d "" /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Directory\background\shell\www\shell\checkSpine\command" /d %~dp0\checkSp.exe /f
reg add "HKEY_CLASSES_ROOT\SystemFileAssociations\.json\shell\www" /v SubCommands /d "" /f
reg add "HKEY_CLASSES_ROOT\SystemFileAssociations\.json\shell\www\shell\previewCurve\command" /d "%~dp0\previewCurve.exe "^"%%1""^" /f
reg add "HKEY_CLASSES_ROOT\SystemFileAssociations\.json\shell\www\shell\checkSpine\command" /d "%~dp0\checkSp.exe "^"%%1""^" /f
2-3 行是 右键文件夹空白处打开spine检测工具，不需要可以删除
5-7行是 给json文件增加右键功能 6： 本预览工具 7：同2-3行的工具（不需要可以删除）
功能部分
- 把动效中包含的动画都展示出来 （在切换动画时，会将动画名复制进剪切板，为什么有这个功能呢？）
- 目前开放的有3种模式来对spine进行操作
- (preview) 预览模式，实现控制spine播放进度（类似视频播放器进度条）
- (curve) 曲线预览模式，实现可视化修改调整spine骨骼点，动效实现效果，程序调整骨骼坐标即可
- (replace) 替换插槽模式，实现可视化替换资源到spine的插槽中（实现替换插槽和还原插槽）
- 基础功能都是ccc自带的spine的一些属性了
- 其他的就靠使用的时候去发掘了
开发中的决策和问题
单论ccc工具的开发没有什么任何难点，一个3年左右的cocoser都可以完美实现，我只说ccc开发之外的：
首先就是在考虑怎么能让工具在用的时候尽量一键化和低的学习成本上，考虑了很多方案：比如打开工具，拖入动效资源文件；或者右键json文件就能打开；
最终选择了右键json文件直接打开的方式，此右键打开非彼右键打开。
这时候想到的就是给文件写入自定义的注册表，来实现此效果。
reg add "HKEY_CLASSES_ROOT\SystemFileAssociations\.json\shell\www\shell\previewCurve\command" /d "%~dp0\previewCurve.exe "^"%%1""^" /f
但是又有问题了，用注册表链接之后打开什么东西能够预览当前的动效文件呢？
这时候想起python可以把.py文件打包成exe文件在window上运行，于是链接了一个exe文件写进注册表中，这样就可以在右键json文件的时候插入想要的实现；
为什么要加一个二级选项呢
因为考虑之后可能对动效文件不止一个工具，所以增加二级选项，防止之后如果工具多了，会污染右键列表。
exe文件又怎么样能调起一个ccc项目呢，以及怎么能把一个json文件传进去呢？
通过把一个ccc构建的web包打成一个html文件的方式，在打开之前通过py把目标的json，和同名的atlas、png文件数据，转base64之后写入html文件赋值给一个全局变量，这样在项目中就可以访问到这个动效了。
初衷-结尾
吹牛bi
为什么要开发这个工具呢?
在炫酷的功能开发中，不免会遇到使用动效的问题，而有些效果是需要程序和动效人员共同协作才能实现的。
比如曲线模式的视频效果，动效想实现一个曲线效果，起点终点未知，有拖尾有粒子，程序开发的话大概就是 bezier 曲线实现，但是具体的效果好不好，这个调的过程是痛苦且不尽人意然后也就那样了；
即浪费程序时间也浪费动效时间。
如果让动效在spine制作的时候，对一些骨骼的移动加入路径约束，对约束的骨骼设置对应的权重之后，再由程序控制【起点，控制点，终点】骨骼的坐标，就可以完美实现动效想实现的效果。
这样只浪费动效的时间就行啦。
而曲线模式就应运而生，动效在导出之后通过工具打开，可以可视化的调整骨骼的坐标，能够很好的调整权重等数值信息；
更重要的是有的时候动效制作的带路径约束的动效文件是有问题的，比如约束错误的骨骼、约束值是错的、起点和终点反了，这都是在制作中发现不了的，只有在放进项目中踩，踩，踩坑。才能发现的；
小菊观
在我看来，工具的开发和设计是一个很容易忽视且很重要的部分，尤其是这种跨部门的协作的时候，彼此不知道彼此的痛点，或者说是有苦说不出？因为自己只能看到自己的一亩三分地，别人的高高挂起或者看不到，这样就在跨部门协作开发的时候感觉对方是sb，对方也觉得你是sb。
工具的开发和积累是日积月累的解决细小的问题，并形成一套体系，然后维持迭代之后确定的开发流程。每个小问题都是不容许被绕过的。
以前的老板嘴里一直念叨着把动效制作工业化，只是把一个部门的开发流程规范化了而已，在我看来不叫工业化，部门和部门之间都没有打通，交接效率一样慢。
为什么我要把工具设计的要尽量一键化？因为用的人的学习成本也是要解决的一个问题，操作越简单意味着要解决更多的问题，同样所节省的精力和时间都是不可忽视的，但是这是无法计量的东西了。
就酱，不一定对，以我这脑容量再去思考的话就要长脑子了。
仅此来记录第一次开发工具和第一次写这么长的帖子；（丑陋的排版，丑陋的文采，丑陋的工具）
上学写作文的时候都没写过这么多字