One Soap Box

So I implemented a better map editor that what I had yesterday. Effects, tiles, trainers, and warps all move around the map with ease, stay within its bounds and moves along the edge relative to where the mouse is if it can’t go where the mouse is. There is also an adjustable grid so that finding out where you are is easier. None of the map objects snaps to them yet, but I’ll get to that at some point. There is also the option to view the tiles as where they can be walked on. This allows viewing paths through the map to be a lot easier than trying to figure out what parts are available for movement and what parts are not. Tomorrow, I hope to be able to start either the shape editor or the world map editor.

So it’s been a while since I’ve written. In the meantime, I have gotten the plugin viewer to be much better. I also wrote a plugin for a Canvas using QGraphicsScene, which turned out to be very simple to do. I realized that since the server and client are completely separate, the server has to do collision detection. This allows the Canvas plugins only have to deal with drawing what they are told to draw and manage transformation plugins for the sprites. In addition, I wrote the base plugin factory for Clients and extended the API of Client to allow for message passing as well. Previously, Player (which subclasses Client) has some special handling which made it hard to do plugins from Client to Player. Eventually, I think Player will end up folding back into Client completely (well, minus the Team; the Arena or Overworld can just tag a Player together with a Team instead of having Player own a team), but I’m not sure quite yet at this point. It will most assuredly be less cluttered than it used to be. I’ll probably decide after writing some basic plugins which implement the Client interface what should be done.

I think that I’ve also figured out a way to implement the editing of the effect and warp areas. To simplify things, I’ll only do basic shapes (lines, rectangles, and ellipses) for now (though the way I’ll be doing it will allow for more complex shapes eventually). Since there is a way to group items in a QGraphicsScene, I can get an overall QPainterPath (which nicely represents the region of the map that the effect or warp is active on) for all of the simpler objects in the composite that make up the effect or warp area. In addition, I would like to make an editor for placing all of the main maps onto a world map and making the edges known to the game where two maps make a border. It would have to enforce a few things.

• That all edges where the map is “open” (walkable) touch another map
• That no two maps overlap (this is easier with QGraphicsScene collision detection)
• Maps would have to have previews of the tiles inside of them as well as a way to view the collision masks for maps
• A way to lock the position of the map

It sounds like a lot, but it shouldn’t be too bad. And with how I jump around on what I’m working on, I don’t know when I’ll get to either of these, but I think I’ll get to them sooner rather than later since I have to sort out what to do with Client.

I also have to decide what I want to do with Arena plugins as to drawing. The default plugins should gracefully handle any number of teams with any number of clients on each and any number of fighters per player. I don’t know how to approach the problem yet, so that’s also being put onto the drawing board with other stuff.

I have other things that still need to be done as well, such as Config saving its custom data and flags out to a file somehow. It will probably end up being a binary format since text could be more hassle than it’s worth (all save data should be stored on the server, so it’s not readily accessible in any case).

There is more I’m missing that I need to do yet, but I hope that it doesn’t delay things too much.

Homework sucks. MPI and debugging pthreads is a pain. I don’t really want to do it for a while, and it looks like there’s a lull in school work coming up, so I should be able to get more work on Sigen done. Since my last post I have gotten some things done, but not as much as I’d have liked, but I’ll take what I can get I guess.

I have an plugin browser working to some extent. It loads up plugins and displays information about them. I still have things to do like painting the current state of the item (hover and selected) due to the custom painting I do since I want it to be a little more than just a boring text list. I had lots of stupid little issues on my way getting to here. Forgetting to link libraries sent me on a wild goose chase for a while trying to figure out why my tags for exporting symbols weren’t working. One character making members into references makes non-constructor methods crash. Lots of dumb stuff. But, I’ll be less likely to do it in the future with any hope.

Anyways, I guess I’ll post an obligatory picture here.

Until I get the map effect and warp editing sorted out, I’ve moved back to working on plugins. I added a simple Canvas interface and got a base plugin class for it complete. After looking at KGLEngine, it looks as though it won’t work in its current state. The engine being a singleton makes it impossible to work as a plugin. So for now, it’s going to be QGraphicsView.

I also started a skeleton for the battle application. Before I do too much on it, I want to get a class that loads up plugins for everything and offers an interface for it (similar to the “Add Widgets” dialog for Plasma). This would also link up with the Get Hot New Stuff protocol to allow for downloading of new plugins and so on. My usage for the dialog would be a bit more complex than the “Add Widgets” stuff (since the plugins can offer more than one actual class of a type), but the base display for an item would be nice at least. Unfortunately, the headers are not shipped, so it’s effectively a private API I can’t use. Besides being in kdebase-workspace which is a little higher up the dependency tree than I would like.

It’s pretty late and I guess I should call it a night.

This should be my first post on Fedora Planet. If this is your first post, it would probably be best to start from the first one.

So yesterday’s troubles have been fixed and it was all my fault. Forgot that mutable iterators in Qt prefer to be used with while loops rather than for loops.

Anyways, those troubles are in the past and I have made progress. Today I got quite a few things done. I fixed up the Arena plugin to be a little more sane. The plugins for Sigen will use KService and the arena plugin is already using it. I got the core class in sigscript and pretty much everything on top of it, Config, to be thread-safe. I also got the packaging to be split for a more fine-grained install.

The next step will be to write a simple way for scripts to draw to a widget that will also be a plugin. This will let the server offload the drawing to clients and also allow for different widgets for each operating system (QGraphicsScene for everything, KGLEngine for more advanced stuff, DirectX on Windows, Core Image on Mac, and so on). In addition, drawing to the widget will be able to use transforms on items in the widget. Now each widget will need its own set of transformers, but I still have time to make it nicer. The transformers will be plugins as well. Did I mention that Sigen is extensible?

I’ve stated a couple of times lately that I’d get to the to-do list that I made last week on break and I’ll do that now. It’s basically a brain dump right now, so don’t expect any structure to it.

Sigencore, the base library for the actual engine that handles the larger constructs of the game and flow control, needs to be made thread-safe. There are other plugins that need to be designed: the viewport and transformation plugins stated above, a player plugin, and a plugin to control tournaments. There will probably be more in the future, but this is all I’ve been able to come up with as of now. Of course, bridges for Kross will also be available for each plugin. I need to test a plugin loader which has yet to be written, but KService should make that easy. Arenas need to allow moves that are currently working to have “states” and allow other moves to interact with active moves. This would allow a water-based move to put out a fire or a wind-based move to make them stronger. I’m not quite sure how I’m going to do that yet. Documentation for both the API and Sigmodr are in dire need of well…existence. SVGs may be possible for images, but that would introduce inconsistencies all over the place with how images are handled as I see it, so it may not happen despite my wanting them to be preferred over raster images.

I’ll see what happens tomorrow since I’m basically off except for homework. Maybe I’ll have a basic plugin explorer done tomorrow. One thing that needs to be done is a simple Sigmod that I can use to test out the arenas. Sigmodr needs the testing and writing documentation for documentation is boring. It’s a lot easier to take my describing things to people and turn that into documentation. Any volunteers can join the #sigen channel on FreeNode and I’ll help whoever shows up with getting started.