DNF my life (postmortem)

Nowhere near enough time this week - between work, and BOTH of my home computers crapping out on me - I probable only spent 5 or so hours.

Most of that was wrestling with the Kivy framework rather than actually making a game.  Mistake.  I do intend to still make this game, but it will be in pure Pygame rather than Kivy.

To say I was disappointed by Kivy would be an understatement.  The only potential advantage would be the ability to run a Pygame game on Android, but even a simple Hello World app was force-closing, so there goes that.  There's lots of API documentation, but very little to tie it all together.  Similarly, all the examples are extremely limited to the scope of doing one specific thing - nothing on how to put it all together.  The one main Kivy game "in the wild" is Deflectouch.  I was hoping that would be the holy grail example I was looking for.  However, it was written for a contest, not necessarily to be a good example of coding - so it really wasn't the help I had hoped it would be.

(log in to comment)

Comments

Yeah, I spent a bunch of time wrestling with Kivy as well, mostly in layouts but also working around some simple bugs (one pull request already accepted.) I was also seduced by the potential for deploying to Android.

The documentation, as you mention, is a bit of a mess (and their HTML doc table of contents does this annoying Javascript scrolling thing such that sometimes you simply cannot get to some points in the contents!) There's also some magic in there too. For the life of me I cannot see how the title is laid out and rendered in a Popup. The title property is there but there doesn't ever seem to be a rendering of it...

Since my Kivy adventure started I have also discovered Ignifuga which I'll probably look into next. It's really young though (as is Kivy I suppose.)
As an aside, I note that both Kivy and Ignifuga both appear to be pushing their own non-Python layout-definition language (Kivy as .kv files, Ignifuga as JSON.) Hmm.
Yeah, I looked at that. I wondered if it had been inspired by QML.
Yeah, the "magic" is the part that's really irking me.  Regarding the .kv files, they're not *entirely* non-Python, as you can actually embed snippets of Python logic, HAML-style.  Still, the "magic" relation between the kv file and the code was one of the biggest sources of confusion for me.  I'm all for using a DSL to describe the tedious parts of GUIs rather than building them up in code, but there are good ways of doing this where the relationship is explicit and logical (see: PyGlade) and then there's...the Kivy way. :-\

Now that my frustration is cooling off a bit, it's still tempting to think about managing to make the one well-commented and well-layed-out Kivy game that would serve as the de facto example and tutorial...  Hmm...still better prototype in Pygame first, though!
Side note on the Deflectouch example (and maybe Kivy in general).  I about lost it when I started seeing some this very un-pythonic "call super" anti-pattern!
class Bullet(Image):
     def __init__(self, **kwargs):
        super(Bullet, self).__init__(**kwargs)
If I wanted my code to look like that, I'd just write in C! ;)
Supposedly, making heavier use the the kv files can partially sidestep the need for this type of shenanigans, but still...there must be a better approach!
I'm still banging my head on it. I find their approach to logging to be strange - I suspect it's just a lack of experience with the standard Python logging system (which is, to be fair, quite immense.)

There's also no support for easy scene changing. Or other widget management, really. To have a popup be able to dismiss itself (via its own "OK" or "Cancel" button, for example) you need to pass the popup object in to the widget construction so that the button event handler may call dismiss() on the popup. It's just a bit icky.

In order to have somewhat sensible "scene" management I have this code in my App build:

        m = Menu()
        m.bind(on_new_root=self.new_root)
        return m

and then the Menu widget generates the on_new_root event when it wants to indicate there's a new root widget. This then is caught by the App:

    def new_root(self, old, new):
        from kivy.core.window import Window
        Window.remove_widget(old)
        Window.add_widget(new)
        self.root = new
        return True

One of the other oddities I've noticed is the occasional API mismatch between the pygame Window class and the base Window class.

I also have this helper that I use almost everywhere I need a button:

def compact_button(text):
    b = Button(text=text, size_hint=(None, None))
    b.texture_update()
    w, h = b.texture_size
    b.size = (w+12, h+8)
    return b

(this is the only way I have found to make a button that fits the text inside it)

Again, there's some nice bits, but there's also some odd bits. For the (relatively) quick-n-dirty prototype I'm developing, it's made some things a lot simpler, but I have spent frustrating time fighting its layouts and documentation :-(
CrazyPyro: I may be missing something but isn't that how you normally subclass in Python? That example seems entirely in line with the examples at http://docs.python.org/library/functions.html#super and http://rhettinger.wordpress.com/2011/05/26/super-considered-super/ (linked from the official docs).
cyhawk, Yeah you're right.  I just got a little carried away with my complaining is all. ;)
richard, thanks for the tips - I'll try that out.
Did anybody get anything working with the Android Kivy launcher?  It just always dumps me back to the desktop immediately.  Maybe there's some logged errors I'm missing. (I didn't have any problems with logging on the PC, but I'm not sure where the logs go by default on Android.)
I've not even tried the Androidification of my game yet :-)