【号召】开发公用技能、系统平台

eff

由于现在大家做演示都是自作自的，所用UI也千差万别。

看似花样繁多的演示实际上都很难移植，只好作为学习使用。

本人在此提出“GA-地图工厂”的概念，希望可以做一个基于官方WE的平台，和所用UI无关，任何演示中提到的技能，只要你将演示中的代码部分添加到自定义代码中，然后在触发中调用一个函数即可。

实际上就是将模块基于统一的平台，并且不需要过多的本地化即可使用。

现在已知和UI，地图无关的手段是自己写一个xxx.j并且导入地图，并且添加自定义的系统。

比如：

地图A---导入了该平台

将代码直接复制进自定义代码（对于使用了辅助单位的函数，按照提示进行调整）

作者自己填写触发事件，条件，并且在动作中调用系统提供者使用的函数。

----------------
比如：
事件：
单位开始一个技能
技能是“新星”
call NovaStart(GetTriggerUnit(),xx,xx,xx,xx)
----------------
就是说只要一个函数和参数，就可以将该技能再现。
-----------------------------------------------------------------------

如果各位对于我的建议持肯定态度的话，我将写一套函数编写规范以供大家参考。

可能成立一个平台编写小组，为大家提供方便的功能及解决方案。

附上本人自己写的东西，虽然只是一个简单的DataSystem但是可以作为一个基础概念演示。

-将H2I，I2U等函数直接整合到common.j中
-没有缓存效率低下的问题
-------------------------------------------------------------------------
其中：

Timer数据位置：0~9(integer),R0~R9(real)
Unit数据位置：common 0~29(integer),peoriodc 0~29(integer),critical 0~29(integer)

GetTimer()--------获得一个可以绑定数据位置的Timer
ReleaseTimer()---释放一个Timer以再次使用
GetTimerIndex()--获得一个Timer的索引以访问某个数据
TimerDataConfig_Integer(integer tmIndex,integer flag,boolean Chg,integer NewValue)
TimerDataConfig_Real(integer tmIndex,integer flag,boolean Chg,integer NewValue)
InitUnitInfo()------为一个单位注册一个数据组
ReleaseUnitInfo()----释放单位占据的数据组
------------------------------------------------------------------------
相信如果大部分演示都是基于一个通用的，简单的平台的话，那么移植起来将非常简便，这将是一项方便地图作者的措施。

kook

一些第三方加强WE如WEU，很早就以GUI提供了一些比较“流行”的技能模版和特效模版，和一些rpg可能比较通用的系统。

但其实WEU的推广并不算成功吧，(其实早年我曾尝试实用，无人指点之下多次败在繁琐的初始设定上），当然本身语言当然也是一个因素（很长一段时间不支持中文）。如果排除这类因素，WEU确实是不错的加强型WE，而且与原型同类的图像界面比较好上手~

另外的一个例子是Vex的castersys，特点是可塑造的技能覆盖面广而代码非常之巨大- -b  不管是原基于gamecache还是改进后的vj版。 这个和lz设计似乎差不多，核心脚本、引用、一些可扩展的..内容，不过别人可是有好几年的历史了。

那么，再综述以上的不足是处。
1.冗余，castersystem..由于历版不停的往里面堆技能模版，其自定义代码堆可以达到，直接卡死我的WE的程度。。。
那么，作为一个作者，就算不考虑自己到底能用到多少，把需要的函数名挑出来恐怕都是挺头疼的事。
而经过WEU“强化”过的地图冗余就直接表现在了地图大小上，一个使用了“自定义高级触发”的新建地图就达到400多k。

2.过分的依赖，由于功能的强大和模式化，相对的，于作图人的个人灵感、创造力之类的会造成一定的冲击。比如vex自己做的技能演示，除开像模拟暗黑技能之类，怎么看起来都是都是这么相似捏= = 聪敏的地图作者要明白，带来的威力的同时会造成束缚（主要还是模版类的拉，相反，像利用return bug 将原来不可想象的变为可能的技术，是起正面作用的）


最后，看了lz的演示，仅仅是将自定义函数以脚本形式写在common.j里...，能让它运行吗？...

eff

- -这个自然可以。。一些提供了方便，高效基本功能的基础脚本作为通用脚本。

比如为某个object绑定数据的函数，如果大家能使用一个公认为比较高效，通用的函数来写脚本那么可移植性将大大提高。

----目前反正是除了静态数据我是不想用缓存了，死慢。

----------------------------------------
关于vjass，因为据说它提供了类的功能（模拟的），但是那样会让生成的代码运行状态无法预知，而且也不是一个成熟的东西（主要不是blz开发的）。

而使用增强UI的坏处是地图打开很不方便，有时候用一个UI做的地图还要用另外一个UI查找演示，很麻烦，而且不一定能方便地整合在一张地图里面。
---------------------------------------

我们的目标是提供尽量高效的基础函数，比如SetTriggerData(tg,flag_1,flag_2,value)<-----------不用缓存的高效解决方案

并且将公认方便的操作方案整合起来，比如物品合成系统，单位强制移动系统。关键这是不需要特殊UI的。只要基于基础函数，你就可以方便地调用他们。

havonz

LZ可以去试试整理头文件
WEH的IMPORT命令让这些东西很容易能够实现
而且头文件中能够声明全局变量

280259078

恩。。。支持头文件
的确方便