『求助』好像没人问过....请问怎样用吉里吉里2制作SLG？

可以的……
不过LZ要有足够的根性和爱啊XD……

两种方法……1种用KAG，一个一个的控制图片OTL（比较麻烦而且不能保证控制起来很方便）
还有一种是使用TJS，直接写系统（相对来说处理起来条理比较清楚但是需要编程知识）

本人推荐用TJS语言编写。

话说SLG最关键的是地图，地图有两种处理方法。
一种是把地形切分成部件，绘制和准备素材的时候比较容易（不过可能要写地图编辑器）但是写程序要有些技巧。
一种是把地图作为完整图片绘制，这样只需要跟随屏幕卷动地图就好，比较准备素材麻烦……

总之这边是比较高级的技巧。相对于自写引擎，Krkr是一个不错的基础，省去了很多处理底层工作的时间。
不过一般来说需要一些编程功力。即使用KAG，也需要程序员级别的清晰思路。

那个...我理科很差拉（也就是逻辑不灵）....编程也只会学校教的一些基础的....C++的那种....不过也不行...地图的画我是决定自己从WF游戏里提取....控制图片....怎么控制...能不能更详细的说一下....比如代码什么的....

最好是先写一个针对SLG的框架，包括地图显示，单位及其动作显示，玩家操作的响应，动态菜单，人物数据管理，等等。具体实现的话，如果直接用tjs写的话，那想写成什么样就写成什么样，就看楼主怎么设计了。如果用KAG框架的话(这样在表现剧情的时候很方便，表现战斗的时候不方便)图像控制可以用Action和Animation，玩家操作的响应和菜单控制就只能由楼主自己完成了。

但是，就算这些解决了，还有一个比较麻烦的东西，就是战斗动画。别说ps2的SRW alpha3 级别的战斗动画，就算sfc的第4次SRW(十多年前的东西)级别的也不是那么容易就能做出来的。当然，如果不使用全屏战斗动画就不用考虑这一点了。

还有一个条件，就是要准备大量的资源，图片，音乐，音效，等等等等。

SRW么？那个妥善利用好AnimationLayer就可以了……

汗了....那么....退一万步....如果直接用风4的引擎.....
战斗动画就是那些人物的动作么.？因该也可以提取....问题是....我现在不知该怎么安排....
全屏战斗？SLG不是大都都这样么/.........资源提取现成.....
不过我现在还有一点疑惑：KRKR2能不能表示出像WF系列那种样子...........
还有人物的动态图用PHOTOSHOP可以做么.....就是WF系列那种效果......那算3D么.....我总觉得只有背景是3D。。。

我不知道那个是不是真的3D，可能的话把你觉得看起来像是3D的地方截图我看下？
资源提取出来常常需要重新组织……不是那么简单的工作……

Krkr本身是一个接近万能的多媒体引擎，2D范围内能不能做出来不需要担心。

至于直接使用商业游戏引擎，我想大概我是做不到了，除非官方提供开发包。

客观一点来讲，这种用很多插件搭起来的东西，我觉得不能说其本身是接近万能的吧，没记错的话，KRKR连DirectGraphic都不支持啊，画面稍微大一点的2D卷轴游戏就基本没戏了


to楼主：
以您的情况而言，SLG完全不建议考虑，其实做AVG也不错的啊

个人感觉效果还好，虽然是GDI而非DirectDraw描绘，Krkr自身的工作效率相当不错，个人认为应该是没有太大的问题。
底层上说，作为一个2D引擎需要的功能，吉里吉里已经基本齐备了。ACT、RPG什么的可能会有些麻烦，只是SLG的话我相信不会有太大问题。

对插件的支持也是一种可扩展性的体现，如果一个插件也没有的话HSP会是什么样？
退一万步说，如果不能用其他代码扩展，Windows等OS，甚至我们的计算机又会是怎样？

PS，最近在研究用Krkr弄3D，已经基本成功把Kr和Irrlicht组合起来了。
不过因为焦点的问题使用Irrlicht的话键盘输入一直很成问题啊……

PS，如果LZ没有程序基础确实不推荐做SLG。

以下引用Miliardo在2007-2-8 23:26:14的发言： 个人感觉效果还好，虽然是GDI而非DirectDraw描绘，Krkr自身的工作效率相当不错，个人认为应该是没有太大的问题。 底层上说，作为一个2D引擎需要的功能，吉里吉里已经基本齐备了。ACT、RPG什么的可能会有些麻烦，只是SLG的话我相信不会有太大问题。 对插件的支持也是一种可扩展性的体现，如果一个插件也没有的话HSP会是什么样？ 退一万步说，如果不能用其他代码扩展，Windows等OS，甚至我们的计算机又会是怎样？

做一个可以跑的游戏自然是没有多大问题的，至于跑得好不好，需要怎样的配置才能跑，那就是另外一回事了

插件是需要别人去制作的，现在它就没有DirectGraphic插件，你说我要怎样在上面写基于DX的游戏呢？2D游戏也不是不讲效率的，KRKR的VM形式跟HSP一样，注定它们本身只能用来写一般的游戏脚本(HSP写的游戏，你玩过就知道了).你如果用此类RAD写过稍微大一点儿的程序，就该知道它们的执行效率是多么糟糕了.作为一个RAD，KRKR的本体是有相当程度的局限性的，我觉得这点不应该否认.它的优秀之处在于入容易上手，扩展功能丰富，而不在于适用面或性能等方面．我也退一万步说，C编译器提供了插入ASM代码的功能，但是这部分并不属于C语言本身的功能吧？如果我很熟悉C/C++，并且一个引擎没有对应容易使用的插件供我制做游戏(尽管它提供了使用插件的可能性)，你觉得我还应该选择用这个引擎来制做游戏吗？答案是很明显的．

回PS:
开源的东西修改起来相对应该容易些吧，大不了在创建DI对象后把主窗口给子类化了，过滤掉WM_KEYXXX消息XD