Project1

标题: 捣鼓了个简单的解释语言 [打印本页]

作者: Mr.Jin 时间: 2016-12-20 13:53
标题: 捣鼓了个简单的解释语言
本帖最后由 Mr.Jin 于 2016-12-21 12:30 编辑

HamannScript(v0.1).zip (221.79 KB, 下载次数: 65)
(打不开的话就装个java吧…)

打算给自己游戏作剧情脚本用的,东拼西凑找资料就做了这么个东西出来
语法很简单,功能很有限,
看看能不能引出这方面的高人来指点指点啦

增添一个jar档,要是上面的打不开就试试这个了,不过必须装java了

jar.zip (68.67 KB, 下载次数: 45)

作者: 杨师叔 时间: 2016-12-20 17:16
这是啥语言？

作者: mxymxy 时间: 2016-12-21 00:21
于是这世界上有这么多语言，能做成嵌入式的也不少，还有很多现成的库啊解释器啊啥的。
现在搞自创语言的都是对编程语言有极大兴趣的真大神了吧，大部分工业用都用现成了……
感觉还是用个啥Lua啊Ruby啊交易语言（Py）啊括号神教(口胡)之类的比较好

作者: 寒冷魔王 时间: 2016-12-21 00:38
本帖最后由寒冷魔王于 2016-12-21 22:32 编辑

额，居然要求32bit JRE，，我的电脑上是64位的。。。没法测试。。

表示这种东西基于JVM的没啥优势，除非宿主也是基于JVM的。。

要用在自己做的游戏？请问你的游戏是基于什么的？

如果是基于Java的话，配合起来倒是可以。。
用C++的话，建议改用C++写这个解释器。

与宿主使用相同的环境（编译环境(C++啥的)或者运行环境(JVM啥的)），能方便互相调用。
尤其是脚本语言这种，源码级调用宿主提供的接口是最好的。
二进制接口也不是不可以，但是还是源码级调用最好。

如果宿主和解释器使用同一编译/运行环境，解释器能够最大限度地利用宿主提供的东西（详见lua, RGSS），这样提供的对外接口才能比较方便的使用。

另，如果是打算在RGSS上跑解释器，要么用Ruby写（效率会很坑，不如直接用Ruby），要么生成个dll调用（建议大部分游戏逻辑也写在dll里面，不然传递效率也是个问题），要么把RGSS黑了重造一个。。哦对，还可以直接在Ruby上JIT生成机器码跑，，不过这个工程量可大了。。

嘛，总之加油吧

===================================
@Mr.Jin 水区禁止连帖我就在这里写了（然而晴兰大大就在评论区，表示十分害怕，大大别批评我 >_<）

看了一下源码（Procyon反编译的），表示LZ很厉害啊，Lexer、Parser啥的写得中规中矩的，可以感觉出来LZ熟练等级很高。。
→_→然而我没写过这种类型的Parser所以没怎么看。

表示，Interpreter部分太少了吧！Hamann一共1800+，Interpreter竟然才几十行。。。。

看得出来这个是直接跑在AST上的。当然直接跑AST上不是不行，不过如果LZ愿意的话不如做个Instruction Compiler？

感觉单纯的Parser不是很好玩（写起来麻烦又没啥太大成就感。。），Java版Parser可以考虑ANTLR（虽然没用过）。

我觉得好玩的地方在编译部分（生成字节码或者机器码），运行部分（扩展程序功能什么的），（当然其他的我也没做过>_<我只能说这么些了）最近在做静态优化，把运行期检查提前到编译期什么的，还是挺好玩的。

>_< 嘛，我只是个beginner，就随口说说。LZ加油。。

作者: SivanZhao 时间: 2016-12-24 23:29
JVM上面成熟的语言很多了，Xtend，Kotlin，Scala之类的，自创无意义。（当初自己也造了个轮子，发现然并卵，现在还是直接用Xtend（这货坑的要命，要不是我蠢看不懂Kotlin的文档））

欢迎光临 Project1 (https://rpg.blue/)