Inkscape & acceleration

It's not easy finding time to work on software projects when one works alone and has to support one's self delivering pizzas, but slowly I'm thawing out again.

I've written an Inkscape-svg-to-pyglet tile conversion script to make working on tiles easier.  Currently it only works on solid-color shapes (am working on gradients), and only quads, but it does the trick.  Importantly, it handles multiple layers, so a single vector tile can contain foreground and background elements at the same time.

I keep looking for ways to improve performance.  Here is a round-up of the methods I've investigated, variously and tried to get working recently:

* Psyco was what I used before.  It worked with Pygame.  But Psyco hasn't been developed for years now.  This was the source of the first great delay for the project.  I've given up on using it.

* Cython is a system that will translate a Python script into a C extension.  I have trouble getting it to work though, a problem sourced in stock Python's insistence on a specific development environment for extensions and the need to maintain a whole C-compiler and set it up.  My current issues with it: I can't get it to produce a workable extension, it keeps erroring out with "C:\Python27\libs/libmsvcr90.a: file not recognized: File truncated".

* Pypy, Psyco's successor, is a Python JIT compiler, and looks like it'll be very promising eventually.  There's an issue of how to package it as a standalone interpreter, and currently Numpy, which I use for building buffers for pyglet, is only partly and experimentally supported.  It seems like it has no problems with pyglet itself though.

Those are the two major non-stock libraries I use, pyglet and Numpy.  If it doesn't support those, it's not useful to me.

Tile editing progress

After some aborted attempts at writing a tile editor, a friend pointed me to a really obvious solution.  Use Inkscape as an editor!  It outputs to SVG, which is an XML-based format ripe for interoperability.  So after being stymied for a while, I've suddenly got a good amount of a tile file converter written.  Huh.

Today: Worked on tile storage format

Today, I planned and worked on the tile storage format.  I didn't conceptualize the problem appropriately though, and so I'm having to spend a bit of time thinking about how the data stored by the editor will be referenced and unpacked for quick access by the engine.  It is difficult keeping all the bits of data and their representations straight in my head.

Mood: weary.

Working on a visual editor for In Profundis tiles

Trying, bit by bit, to work my way through the things that make working on the game harder, on the infrastructure of its construction.  Lately this has taken the form of a visual editor for designing the vector-based tiles the game uses.

You see, the tiles the game uses are constructed out of OpenGL graphics quads on different "layers."  This provides many subtle advantages: we can arbitrarily scale up or down the graphic size, most of the quads are stored on the graphics card and displayed as needed "for free" and so we only have to change those quads that are both visible and have changed since their last display, we can have larger-than-grid-size tiles if need be, the layering system, where each tile can have components on different layers, gives us free outlining and neat effects, and so on.  I honestly don't think I've even exhausted my idea space for what the system can be used for.

The catch is, I can't design tile graphics in a graphics editor.  At the moment, all the tiles are stored in the source code as sets of coordinate and color values, which reminds me uncomfortably of coding up large DATA statements back in C64 BASIC 2.0 days.  The idea is to use the visual editor to design them, then store them in an external file, probably as a Python pickle, at run time.  Of course I'll release the editor too for modding purposes.  Since realtime performance isn't such a priority I can use Pygame for it.

Well, that's the update.  So you see I'm not completely idle, there are things being done.  I'm churning away, although keeping everything straight in my head is a formidable problem I am nowhere close to giving up on this.

Gonzo skill system trials

Rather than taking it for granted that my weird skill system idea will work as hoped, I'm taking a small detour to make a simple game testbed for it, so I can get some picture of what it'll work like in practice.  I am considering making this available to backers as a bonus, something to play around with.  That is, when it's written.

The past couple of days have been mostly spent designing it further, and looking into the capabilities of the IGraph software, which has a Python package interface, to this end.

Native AI, crawling

Slow going as I go through and try to figure out how to implement these things.  For native pathfinding, I'm considering a variation of the kind of pathfinding that ants use in the real world (and in fact is used in Will Wright's SimAnt).  Before that though is crawling.  Since the player is an entity in the world, although one composed of multiple tiles, crawling actually changes his shape.

In positive news, the interaction cursor works fairly well.

Crawling

The main character can now crawl.  It sounds like a minor thing, but now that the character is actually an entity in the cellular system, the system has to be able to resize entites, check to make sure there's room, and things like that.  The analogue in the platforming system is all those problems with handling wall embeds and ejects, which is one of the trickiest parts of programming a platformer, so trading these problems, which are now solved pretty much, for those, which I never could get to work right in the prototype's dynamic world with a sprite overlaid, is a good trade I think.

I'm going to have to modify the display engine now to display multiple possible actor states.  After that, more inventory work, then maybe actually putting in new entity types, like growing plants, the beginnings of an ecosystem, and other actors.