Summary: | create python AI interface | ||
---|---|---|---|
Product: | [Applications] kmines | Reporter: | Ethan Anderson <ethana2> |
Component: | general | Assignee: | Dmitry Suzdalev <dimsuz> |
Status: | RESOLVED LATER | ||
Severity: | wishlist | CC: | piacentini |
Priority: | VLO | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Ethan Anderson
2008-08-01 17:44:46 UTC
Mauricio, do you have any comments on this? Well, we had a solver in KDE 3, so I guess that if someone wants to implement it that code could be a good starting point. But frankly I am not planning to add it, as I think the game works OK as it is and is simpler to maintain. The exception is maybe for demo purposes, but even in this case we could simply write some very simple C++ code that chooses a starting point and keeps revealing adjacent mines (that it knows are good) until a given threshold is hit, and then it errors out. Introducing a python dependancy for this is a mistake imo, but each one has its own itch to scratch, so I would not discard any contribution along these lines. Regards, Agreed. Another option I had in mind regarding this: instead of creating python interface, it could be simpler to export some DBus interface, which in turn can be easily scripted using python-dbus bindings... DBUS? That sounds swell. I'd go for that. I get what you're saying, but gnome chess has a 3d feature that requires python OpenGL bindings to be installed-- and it isn't a dependency of gnome chess. Chess works fine without it, and if it's not installed, you just don't get the 3d is all. Perhaps a similar approach would work? On 4 Aug 2008 12:10:07 -0000, Dmitry Suzdalev <dimsuz@gmail.com> wrote: [bugs.kde.org quoted mail] |