Here's a second idea<http://www.wesnoth.org/forum/viewtopic.php?p=414090#p414090>I had for the GSoC 2010: porting the Wesnoth AI to a JVM language such as Java or Scala. This would mainly be in prevision of a full port to Android, so I'd be particularly careful with memory issues, but it could also be an interesting addition to Wesnoth in its own right, adding one more language (or actually, all the JVM languages) in which to write AIs for the game. You have my proposal below, it's a revision of the forum post I linked to.
--Language-- I'm proposing Scala as my favorite language, since I'm learning it right now, and I see a lot of advantages: - Where you can run Java, you can run Scala; interoperability causes no problem, so others can use my Scala API and finish the Android port in Java if they want. - The syntax is much lighter, but it's static typed just as Java or C++ - You can basically start by writing "Java without the semicolons" in Scala, so there's no inherent risk in learning it as you go. It's also easy to understand for other Java developers, see for yourself<http://bazaar.launchpad.net/%7Eflodiebold/fotgk-7drl/trunk/files/head%3A/src/main/scala/roguelike/> . - Once you get past the previous step, there are many powerful constructs to use, and nifty features such as static duck-typing (i.e. after-the-fact interface discovery) - Ok, there's a disadvantage: the language is still evolving fast, so I guess parts of the API get deprecated faster than in Java. But for a rapidly evolving project such as Wesnoth, this has much less impact than if it was an enterprise app. Note that if you're not convinced and still prefer Java (or if early prototyping somehow shows Scala isn't a good idea for the Android platform), I can do it in Java too - the ride will just be a bit less comfortable. --Architecture-- The general idea would be to create a wrapper to allow it to interact with the rest of the C++ code (see A below). This way the new AI would be usable with mainline Wesnoth. When work on the port resumes, you'd rip out the wrapper and connect it directly to the rest of the Scala port (see B below). (A) Scala AI -- Interface/Proxy class(es) -- JNI wrapper -- C++ code (B) Scala AI -- Interface/Proxy class(es) -- rest of the Scala/Java port As far as I understand this would be much more work than providing Lua bindings, as another project is doing: in this case the goal is to replace as much C++ code as possible. Prove me wrong, but I think portability issues would just kill an Android project that carries a huge chunk of native code. This could also be a good occasion to reduce somewhat the alleged (at least Kyle Pool mentioned it) coupling between the AI code and the rest, but Crab and others did a lot of work recently in that area, so I don't want to step on their toes. --Random similar ideas-- I imagine the same approach could be applied to another part of Wesnoth, such as the interface, map display, and maybe (??) the network code or WML engine. Or maybe a silly little project similar to those WoW iPhone apps that show you your character stats would be a good excuse to implement some netcode in Scala: make an Android app that shows you live stats from running games on the server and allows you to chat with people. Well, I'm awaiting your comments.
_______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
