New Level Editor Anyone?

[jake13jake]

I'm going to be making an advanced level editor for an independent study. Essentially, I'm seeking to add extra dimensions to the artform that allow for the creators of tilesets to define and modify structural constraints in the use of the tiles, which will in turn accomplish two things: help maintain the artistic integrity of the tileset, and allow for higher quality rapid development of levels.

i.e., one could say that I'm building a tile editor on steroids.

 

I don't intend this to be limited to Subspace, but my observations of patterns involving the use of tilesets have me looking at Subspace as a strong place to start.

 

I have noticed two kinds of patterns in the use of tiles in almost all games:

one-dimensional patterns, where a certain arrangement of tiles may be repeated sequentially, as though in a line.

two-dimensional patterns, where a certain arrangement of tiles may be repeated in multiple directions.

 

Subspace is quite heavy in one-dimensional patterns, and two-dimensional patterns, in most cases, rely on one-dimensional patterns in border spaces between different two-dimensional patterns. This is not so much the case in Subspace, where two-dimensional patterns like safe-zones and goals typically don't rely on one-dimensional patterns at all (or, well, on most servers).

 

I do intend on implementing both of these concepts strongly and allowing them to link together, but I believe I should probably be focusing on one-dimensional patterns before expanding into the area of linking them to two-dimensional patterns.

 

In order to apply this to Subspace specifically, I will need access to file i/o functions for levels in Subspace. I would expect that this project has, at the very least, an importation function for rendering. I have tried compiling Discretion on Linux many times before, but have generally failed to do so and thereafter lost a bit of my drive to skim through the source code. In other words, I was wondering if anyone would be interested in contributing in this sense when I get to the point of where I need to be in terms of a GUI environment.

[Bak]

Hmm sounds interesting.

 

So is your end goal to generate a bunch of tiles on a map that look decent or create a level editor along the lines of DCME, SSME, or CLT, or a level-compression mechanism based on symmetry or ?

[jake13jake]

Hmm sounds interesting.

 

So is your end goal to generate a bunch of tiles on a map that look decent or create a level editor along the lines of DCME, SSME, or CLT, or a level-compression mechanism based on symmetry or ?

 

Well, not so much any of the above. I've used SSME and CLT, never actually heard of DCME until you just mentioned it, but I suppose I'll have to check it out.

 

I'm not going to be working on a compression algorithm or an autonomous generator, though one could presumably do that. Essentially, what I'm aiming to do is make it much easier to tile on a larger scale. Subspace is a good game to test this on, but the concept isn't going to have most of it's value in games like Subspace. There are games where these concepts would save time on a scale that makes applying this to Subspace specifically seem extraordinarily trivial. I'm not saying it wouldn't surp!@#$%^&* available tile editors for Subspace, it just wouldn't do it by nearly as much as with other games.

 

Anyway, even using this kind of tile editor will require defining tiling patterns for an arbitrary tileset.

 

Ex:

-'s are horizontal wall tiles (which can be a horizontal repe!@#$%^&*ion of any nxn set of tiles)

|'s are their ends.

 

|------|

 

You would select the pattern, it would implicitly place the end tiles, you could extend it in either direction for as far as you want, or you could extend a vertical pattern from anywhere in the horizontal pattern. I call these one-dimensional patterns because they are meant to work in one direction, connecting to stubs (like the pipes), voids (where it just doesn't matter if the pattern disappears), or other one-dimensional patterns (ex. a horizontal wall).

 

Now, this one-dimensional repe!@#$%^&*ion of tiles could actually go in directions other than 90 degrees, but the idea is that this particular type of pattern is meant to be repeated in one direction. One-dimensional repe!@#$%^&*ion often occurs among tilesets that show two-dimensional patterns. Gr!@#$%^&* in an RPG for instance, can be extended in any direction. However, if you have a spot where the gr!@#$%^&* ends and there's water or a desert or anything, there are going to be tiles specifically meant for dividing them, and these are almost always of one-dimensional repe!@#$%^&*ion.

 

If there's an online game that accepts player levels at a high rate, it could run a server that loads the constraints of the tiling patterns to the level editor. This could save a lot of work in checking for tile errors, for the simple fact that the tiling patterns should outright prevent them.

 

I actually wanted to make a game engine for my independent study, but my professor asked that I focus on something a bit more specific, and something that I'd learn a bit more from. I figured from my own experiences, the amount of time spent on building levels for games by far surp!@#$%^&*es any scripting or programming that I've ever done for games. Not so much because it was my focus, but because it was the most tedious, most horrible work. However, creating or contributing to a game environment shouldn't be tedious, it should be, far and away, the most rewarding work anyone could do. Because of this, I want to reduce the amount of work it takes to build levels.

 

I'm going to take a wild guess that with the scale of this project and my grade depending on the final outcome, this is going to keep me extremely busy for the next three months. Fortunately I'm doing this because I ran out of requiement space on CS classes to take. Doing this in place of taking Visual Basic, where I wouldn't learn a !@#$%^&* thing.

[Bak]

Hmm I see. This sounds a lot like the autotile tool in CLT ( http://continuumlt.sourceforge.net/manual/#autotilewindow ). I think DCME has a similar functionality.

 

Discretion does accept different formats of maps, although the current format accepted is only the traditional .lvl format because that's the only thing I coded. A module for another format could be made, however.

[Samapico]

In order to apply this to Subspace specifically, I will need access to file i/o functions for levels in Subspace.

Basically, you want to know about the file format?

 

Which language do you plan to use?

DCME (and CLT) does have a walltile feature, that allows you to tile bases quickly. However, the feature is quite limited... Also, what would be nice is if the program handled itself the rotation of the tile graphics and such...

 

I was looking forward to redo the whole walltile feature in DCME. There is also a feature to generate a walltile set, but again, it is very limited and only does a bunch of rotation and flips.

 

If you can come up with algorythms that do all that nicely, would be great... I might be tempted to port them in DCME as well . DCME is in VB6 by the way.

[jake13jake]

Hmm I see. This sounds a lot like the autotile tool in CLT ( http://continuumlt.sourceforge.net/manual/#autotilewindow ). I think DCME has a similar functionality.

 

Discretion does accept different formats of maps, although the current format accepted is only the traditional .lvl format because that's the only thing I coded. A module for another format could be made, however.

 

Yea, that would be an example of the capabilities. The main difference is that the autotile tool there has an absolute definition of tiles used and in what patterns, acting as a predefined macro of sorts, which is obviously going to be a bit more efficient than mine, but it is not nearly as flexible. With what I'm doing, you can build any set of constraints among any set of tiles in any order.

[jake13jake]

In order to apply this to Subspace specifically, I will need access to file i/o functions for levels in Subspace.

Basically, you want to know about the file format?

 

Which language do you plan to use?

DCME (and CLT) does have a walltile feature, that allows you to tile bases quickly. However, the feature is quite limited... Also, what would be nice is if the program handled itself the rotation of the tile graphics and such...

 

I was looking forward to redo the whole walltile feature in DCME. There is also a feature to generate a walltile set, but again, it is very limited and only does a bunch of rotation and flips.

 

If you can come up with algorythms that do all that nicely, would be great... I might be tempted to port them in DCME as well . DCME is in VB6 by the way.

 

Rotation, in itself, would have to be implemented in the game engine to be of any practical use in a tile editor, or you would have something that builds rotations into the images during the level compression.

[Samapico]

Well, I meant like if you draw an horizontal tile, it would handle rotating the graphic to create a vertical tile. So you'd just give the program the graphic of one tile, and it would draw any other tiles with it.

[jake13jake]

Well, I meant like if you draw an horizontal tile, it would handle rotating the graphic to create a vertical tile. So you'd just give the program the graphic of one tile, and it would draw any other tiles with it.

 

That would actually be something that could be added.

 

Anyways, I've been trying to write this level-editor with pygtk, and will probably rewrite different parts of it to death, but I've decided on general capabilities that I want to have done for May. This includes defining tiles in terms of vertices, edges, and two-dimensional patterns, each with different properties, as well as multiple layers of arbitrary sizes, a defined background color, and the ability to scroll background layers at an arbitrary rate against some other layer.

 

The layers don't necessarily need to be interacted with but I do want to make that possible. I can just imagine a wormhole that instead of warping you to some random location, warps you to some area below everyone else.

 

With layers that are different sizes from the main (perspective) layer, they will scroll relative to the main layer (smaller layers scroll more slowly, larger more quickly). There's also the constraint that the size of the smallest layer is the largest the screen can show. Scrolling layers can be of arbitrary size, but are repeated and scroll at a specified rate relative to the main layer. I don't think this is necessarily the most original idea, but I want to add it and see more functionality than I've typically seen games with scrolling backgrounds present.

 

I'll tell you something though, the two biggest issues I have right now is that this is the first large project I've done using either Python or GTK+, so I'm not experienced to know what the best ways to structure everything surrounding everything is, and particularly efficient means of drawing multiple layers. The fact that I'm actively learning while programming this means that I have to restructure my code after every milestone.

 

I was wondering if anyone who knows the gdk portion of the gtk+ library would be able to help me out a little bit.