不知不觉比赛也已经接近尾声了,直到最后两天才开始为游戏填充视觉、音效还有关卡内容,怎么看都是充满了失败的flag呢。事实上,直到现在,复杂的技能系统还是没有做完。上一篇日志有提到通过提供包含逻辑的节点,就可以用xml来描述技能逻辑,从而达到玩家设计自己的技能的效果。设计普通的技能,例如对n个目标造成n点伤害这样的,只需要提供逻辑节点即可;但一旦涉及复杂的技能,例如使用每四个技能,第四个技能花费为
书接上回,为了避开动态执行代码的限制,我设计了一款基于xml来描述技能逻辑的DSL(Domain-Specific Language),这次来讲讲具体是如何实现的。从代码中构建技能方法构造出来的xml可以看到,在代码中使用建造者模式逐个添加节点,最后调用Build就可以生成技能。你可能会疑惑,这弄了半天不就是造了一堆数据出来吗,难道还要搞一个解释器来运行它吗?答案并非如此,奥秘隐藏在通过Ad
上一期结尾时约定了分享自己在支持UGC内容上做了哪些工作,虽然我因为使用的冷门技术不兼容taptap创意工坊而放弃了在线试玩,但是对于UGC开发思路还是可以复用的。首先要了解一下是什么阻止了在线环境允许mod,其中最主要的一条是不允许动态执行代码,毕竟这非常不安全,恶意脚本可能会窃取用户的信息,甚至攻击服务器;除此之外,在线环境无法直接访问用户的硬盘,不能从一个mod文件夹直接读到mod文件,如
比赛结束的第二天,终于从后劲中缓过来了,最后两天熬夜熬到凌晨,基本只睡了2个小时。从结果来看,这次比赛可以说是完全失败,提交的游戏运行时充满了bug,甚至没上传实机演示,连参与奖的资格都没有满足。开发工期严重爆炸,最后一天上午(更准确的来说,是凌晨)才开始填充关卡、敌人数据等内容,还有数不尽的bug要修复,论本次失败最重要的原因,必然是工期管理的失败。当我写下策划案的时候,就预估到本次比赛无
事情是这样的,我正在开发的游戏是使用C Sharp代替JS编写逻辑、操作DOM,最后把C Sharp编译成Web Assembly在浏览器中运行(也就是Dotnet中Blazor Web Assembly使用的技术,虽然我用的不是Blazor)。相比用游戏引擎开发游戏然后WebGL导出,这套技术明显小众多了,肯定是不敢直接在比赛里用的,为此,我专门单开了小项目,打算先试试这个套技术能不能在tapt