mota-js
mota-js copied to clipboard
ckcz123
HTML5魔塔样板，支持全平台游戏！ 即使完全不会编程的用户，按照模板和说明文档也能很快做出一个魔塔游戏！
- [x] 设置画布不透明度 - [x] 复制或移动一个操作 - [x] 未保存切换列表时弹出保存提示 - [x] 绘制图标不能指定大小 - [x] 旋转画布等操作删除后预览不会还原 - [x] 绘制椭圆在预览界面上无法显示 - [x] 绘制文本字体大小带px等单位反而无效的问题 - [ ] 控制绘制条件(if) （循环据说不用也行？ 我感觉有比较好 - [x] 期望能预先写好一些参数创建新ui...
- [x] 自定义视角 - [x] 摆脱正方形样板 - [x] 自定义单元格长宽 - [ ] 事件流改为promise - [x] 使用pixi的sprite - [ ] 更自由的状态栏 - [ ] 重构编辑器
* [ ] drawThumbnail的任意窗口绘制 #502 * [ ] 编辑器中大地图模式下的任意窗口绘制 * [ ] 对话框的额淡入淡出 * [ ] 高清UI？
# 对3.0编辑器开发失败的检讨 在相关开发工作停滞接近三个月之后, 5月29号, 3.0编辑器正式宣告失败, 这意味着在编辑器上数百小时的工作报废, 应该算是mota-js相关开发里最大的失败项目了(笑), 因此在此我试图梳理一下, 3.0编辑器的整个开发历程, 分析编辑器开发失败的主要原因, 抢救一些作废的部件, 并且制定下一阶段的开发目标 ## 3.0编辑器的源起 3.0编辑器最早的源流大约是在去年2月份, 在设法复刻精灵石, 废都物语等游戏时, 感受到现有编辑器难以满足需求, 尝试开发的新编辑器, 不过, 在8月之前, 整个编辑器都近似于一个空壳, 这一阶段中, 编辑器的api与现在有很大区别, 仅举一例 ```js // 地图编辑器初始化函数 mapEditor.initialize =...
经过讨论和分析 编辑器对core的引入,只有drawmap的使用是本质的 用两个版本, 通过只使用改动后的core.drawmap+部分组件化了的编辑器, 来减少编辑器和运行时的耦合 从而使得让运行时崩溃的改动仍能在编辑器中修改恢复
当前样板已发展到2.7，和一年前不同，我对运行时、编辑器和3.0的看法有所改变，具体如下： **运行时定义：** 仅在网站游戏时加载的内容，包括`libs/`, `project`, `index.html`, `main.js`, `styles.css`等。 **编辑器定义：** 制作运行时的可视化造塔工具。 1. 运行时应当只留一套。之后想加什么功能，比如大地图、sprite化等，也应该在现有运行时上改。继续基于全新架构尝试制作，可以尝试，但不会去期望其可用性。 2. 运行时应当是独立的可以脱离编辑器运行的，甚至是允许直接改文件造塔的(即兼容1.x模式)。 3. 在运行时上构建编辑器，目的是为了更方便造塔。编辑器应当兼容运行时并不应该大幅修改运行时本身的架构。现有的2.x编辑器就是编辑器的一个实现的例子。 4. 可以基于现在的运行时开发一套新的编辑器，比如叫3.0编辑器。里面使用全新的界面，全新的造塔和绘制地图方式，等等，与现有编辑器并行。 5. 现有的2.x编辑器由我持续维护，原生ES5实现，支持手机；如果实现新的编辑器可以任意天马行空，可以不支持手机造塔，可以使用任意的新技术。但是**运行时必须是同一套，保证兼容性**。 6. 在编辑器的逐步开发过程中，反向推进运行时开发。 关于仅维护一套运行时的理由： 1. 运行时是样板的核心。样板可以没有编辑器（回归1.x造塔模式），但是不能没有运行时。 2. 当前的运行时发展到2.7，已经成了一套很自洽的系统，包括事件流，操作，录像，等等，非常自洽。同时基于该运行时才能支持服务器端的人数统计、成绩上传、录像检测系统、存档同步等诸多功能。 3. 我认为，脱离当前运行时，全新构建一套新的运行时体系是一个值得尝试，但是不会予以期待的行为。涉及新的运行时可能存在大量问题，例如事件系统的可兼容性、录像回调链的可靠性等等，都是当前运行时踩了大量坑而最终予以完善的内容。 4. 事实上，随着样板不断发展，运行时也在不断不断的进行完善。2.7已经解决了大量历史遗留问题，2.7.1打算重构大地图的实现，等等，之后也许就会以原生的方式来实现Sprite化或其他功能。...
# 需求&&目标 - 目前的2.x编辑器正在非常高速的新增和完善各项功能，与此同时，各个部分代码也在激增，在一年前，2.x编辑器的可读性就显著比样板差， 在2.6重构以及完善文档的辅助下, 这个差距更加明显 - 以五图层插件为代表, 2.x编辑器开始探索编辑器扩展性, 但是目前仍然限于与样板一样的hack处理, 由于编辑器可读性更差, 这样的扩展难度相当高 - 在mota-js整体功能完善后， 出现了更多想要制作非魔塔的需求， 在这种情况下，除了扩展编辑器，移除已有的编辑组件也是需要考虑的(可插拔) - (出于私心)3.0编辑器报废后，遗留了大量的可复用模块，对其进行重用可以完善一些编辑器功能 # 解决方案 - 完善编辑器的jsdoc, 并使用// @ts-check 进行类型检查 - 引入[框架](https://github.com/tocque/AMEF.js ) AMEF.js是一个半MVVM框架， 其支持大部分vue语法,...
提供类似steam的成就系统 主要包含以下几点 1. 游戏内的成就展示 1. 无须写js脚本的成就编辑和触发 1. 与游戏胜利无关的成就提交 1. 塔详情页面/个人中心的成就展示: 总点数/在所有玩某个塔的玩家中该成就的完成百分比 + 游戏内的展示可以参考[斗罗魔塔](https://h5mota.com/games/douluomota/) + 需要编辑器内提供相应的图块, 以及可能需要单开一个标签页 + 需要网站服务端添加相应支持 每个塔提供的成就点数最多1000由造塔者自由分配 成就系统可以提高用户系统的黏性以及吸引玩家多玩塔, 以及提高蓝海的可重玩性
树结构的存档
 + 白色是自动存档,是当前进行的分支,2*3的框是屏幕显示的存档,通过上下左右滚动. + 用树结构体现存档的分支和继承.从而可以做到从上一个存档开始播放录像,而不是一定要从头开始. + 存档不再选择位置,只有两个选项,直接追加或者覆盖上一个存档,分别绑定为s,以及另一个快捷键. 存档时按键直接存,无需考虑位置,自动会出现在当前路线最后面. + 读旧档再存就是开新分支,每个分支是一行. 点击新游戏时,进地图就根据难度建立一个存档. + 有两种删除,删一个节点,或同时删所有子节点,用于存档管理. > 自动存档始终自己独占一行更合理,当前进行的分支和自动存档不是同一概念