※ 引述《zxcmoney (lol)》之铭言： : >可能用到的函式 : 自然改革时间(NreformT(a,b,c)) : a为改革力的增减 b为改革进度 c为改革成本 : 回传自然改革所需时间 : 加速改革(VreformT(a,b,c,d)) : a为改革力的增减 b为加速改革次数 : c为改革进度 d为改革成本 : 回传加速改革能缩减的日数 : …嗯 可能用到的非常多 : 我看还是看过资料结构 写好函式再寄给你好了 : 建成的函式会附上如上的说明 : 此外这部份看要不要开放有意愿的编写 其实我想最最基本的问题是, 论游戏开发, 永远是求诸人不如求诸己. 如果自己不写的话, 那任何的提案或者企划, 都不可能超越纸上的. 主 要问题在於, 每人心目中都有自己理想的「游戏」或者「系统」, 没有 人理想中的游戏是完全一样, 能够实现自己理想中的系统的, 哪怕只是 部份也好, 基本上也只有自己一个人会去完成. 而人会愿意自己完成的, 就只有自己的那一套系统. 在用别人的系统时, 那往往不会是 100% 合乎自己所想的, 但是如果能 有 70% 以上合乎自己的想法, 大部份人就会接受了. 毕竟这是使用者 的接受范围, 但开发者的接受范围的话, 如果是免费的人力, 那是十分 狭窄的, 这是我常说同人游戏开发中, 「免费的人力比起受薪的人力更 昂贵」的原因. 如果要将一件工作交予别人, 那麽不论那是甚麽工作, 也等於将那件东 西的设计的权利, 也交予了对方. 这才有可能交予别人, 自己设计东西 然後让别人实现, 一般来说只有给钱才可能做得到. 所以如果要设计一个系统出来, 最好是自己去实现它, 这是我说为何要 写(即程式码)出来的原因. 主要是, 如果自己不写的话, 那会停留在设 计阶级然後流产的可能性是很大... 在这个 GameDesign 版, 之前也有 不少人说过一个重要的问题, 就是其实最难的事情, 就是「开始然後完 成」, 半途而废是游戏设计最常出现的问题. 这往往是因为我们都会喜 欢做一些自己有兴趣的部份 (例如企划) , 避开自己不感兴趣的部份 ( 例如除错) , 但大家有兴趣的部份其实往往相同, 不喜欢的部份也往往 相同, 要完成游戏和开发游戏, 只能在做自己喜欢的部份时, 也去做自 己不喜欢的部份. 除了写之外, 写本身也包括了自己测试的过程, 像人工智能这种东西, 推理时往往和实际执行时有落差, 如果不去写 code , 应该是没有机会 证实一个人工智能是否可行或者有破绽. 所以这其实是避不过的. 所以我十分鼓励你去实现他, 我愿意开放我的 source code 给你, 我 的人工智能其实大部份都放在了几个大的 procedure 里, 有些会细碎 , 虽不能说容易修改, 但是直接改下去应该最方便. : >现在可能需要更动程式的地方 : 我不知道你现在设计的ai行动到底怎麽运作的 : 不过要让玩家来修改的话 我想应该会需要改成这种方式 : 1.轮到此ai行动 : 2.读取ai行动决策树 : 3.将行动内容存入行动阵列 : 4.扣除行动阵列所用的行动力 : 5.重复2-4直到行动0 : 6.实行行动阵列内容 : 7.回合结束 : 其中ai的行动决策是开放玩家编写的部份 : 虽然决策的方向与行动大至分成 : "改革" : 方向:依现在 或 预定达成的情况 决定改革方向 : 行动:决定推动改革 决定加速改革 : "建设" : 方向:依照现行体制 改革方向 军事状况 外交状况 决定建设行动 : 行动:建设建筑 开发 投资 : "外交" : 方向:依照现行体制 改革方向 军事状况 建设状况 外交状况 未来目标 决定外交行动 : 行动:朝贡 宣战 请求资援 : "军事" : 方向:照现行体制 改革方向 军事状况 外交状况 未来目标 决定军事行动 : 行动:整备 训练 强化 转职 解散 : 但依状况不同决策树的各方向的子决策树优先权也不同 : 基本上这是受ap制的影响 使各方向的行动的互相影响其次数 : 如果是独立出来的话 这些决策树可以分开 : 观察其他的决策树的决策 然後独立运作 : >其他 : 开放玩家编写的话可能会有不合设定的行动出现 : 例: : 对战力低的国家进攻5次(0+1+2+3+4)总计10AP : 或TP不足的国家仍可以建设.补给或强化部队 : 为了避免玩家设计的ai行动出现这种错误 我想最基本的问题是截取资讯本身, 人工智能要实现, 基本上以上 含糊的部份都必须要精准的变成实际的算法. 比方说, 「军力强过对方就攻击」, 这是看起来简单, 实现却很复 杂的, 因为这包括了一个重要的问题, 就是「电脑怎样判断自己军 力的强弱」, 判断本身就已经是一个人工智能了. 举例, 以我目前的 source code, 部队有一个 function 叫 battlevalue , 用途就是为每个部队定一个战力指数, 方便部队判 断是强是弱. function TUnit.BattleValue(seed : Integer) : Integer; var i : Integer; begin // 1 general 综合战力指数 // 2 front 前排战力指数 // 3 back 後排战力指数 if (seed = 1) then begin i := MaxHP; end else begin i := Strength; i := i div 2 + (i * Morale div MaxMorale) div 2; end; if (seed < 2) then begin i := i * (BS + WS) div 6; end else begin if (seed = 2) then i := i * (WS * 2 + BS) div 9; if (seed = 3) then i := i * (WS + BS * 2) div 9; end; BattleValue := i; end; 大概你可以从数值的名称, 看出那代表是甚麽, 这是目前对战 力判断的形式. 但这十分的阳春, 自然会产生缺憾, 例如把战 力较弱的部队看成是战力较强的部队, 或者低估了实力, 这就 是人工智能真正麻烦的地方, 而这种麻烦是写成了程式码後才 能够发觉出来的. 而这种算式本身就是人工智能重要的一部份, 可以说, 如果电 脑要进行任何判断, 至少先要有判断部队强弱的能力. 如果欠 缺了这种能力, 任何对战力的判断的人工智能都不会有意义, 无法成立, 因为欠缺了最重要的「源头资讯」, 「可比较的资 讯」. 这些工具是最重要的, 能否准确的判断部队的强弱, 对战略和 战术智能的影响十分大. 因为根据误判之下作出的决定, 无论 过程是否复杂或者合理, 结果一定会是错误的. 这是工程上常 说的一个问题, Garbage in, garbage out, 进去的资讯品质 不高的话, 根据那资讯进行的决定也不会好. 那就是说, 如果你要设计人工智能, 就必须要动到函数的内容 和运作, 而不能单纯的依赖游戏里提供给你的函数. 而如果你 不动这些相关函数, 你几乎是无法开发出任何可用的人工智能 , 但这些东西如果要用编辑器放出来, 如我之前所说, 这等同 「设计一个程式语言和编译器」. 因为这和其他 custom 的部份不一样, 其他 custom 的部份, 你改的是「参数」, 参数只是一种「资料」. 但人工智能不能只看成一种「资料」, 人工智能是「逻辑」, 你要向电脑输入资料, 让它应用是容易的, 但你要让电脑理解 一个逻辑, 写程式, 已经是最快, 最方便, 最有可能达到的方 法, 不可能舍近求远. : 在实行行动阵列内容要作好判断并在出错时回报玩家 这本身就是人工智能. 问题就是为了开放让玩家做人工智能, 本身就已经需要很多人工智能. 事实上, 要判断一个人工智能的错误, 需要的是比那个人工智能更优越 的人工智能. 这就像你写一个象棋的人工智能, 和写一个「能找出你的人工智能的错 误的人工智能」, 後者其实比前者还要复杂. 这是我说这为甚麽是人力黑洞的原因, 你想想, koei 的三国志威力加 强版, 也不可能去到让你修人工智能的地步, 这不是兴趣的问题, 是成 本和效果的问题. 程式语言本身就是最好的「人工智能编辑器」, 要修人工智能, 最好是 直接修 source code. 把游戏实现是最重要的第一要务, 合理地运用自己手头上能用的所有资 源去完成它, 将效益发挥至最大. 不奢望有任何目前没有的资源会突然 出现, 这点是游戏设计中很重要的, 不论是商业游戏还是同人游戏都一 样, 如果我们的设计中要有一些目前不存在的资源(例如人力)才能够完 成的, 那个设计是一定不能完成的, 因为目前不存在的资源, 未来九成 也是不存在的. 只要你能写程式, 不要浪费这技能, 这就是资源. 好好利用他. -- 基於饮水思源的理念, 还是该打的广告, hkday.net --- 硕果仅存还愿意和其他地区转信的香港 BBS -- ※ 编辑: chenglap 来自: 218.252.90.21 (02/15 23:40)