[DISC] Super-Tile editor?

Well, I'm beginning to plan a new game and I've decided that strille's super-tile method is definatly the way to go.

This however, has left me with a relatively un-resolved issue: There are no super-tile editor tutorials or open source examples. In fact, how to go about making such an editor is barely even mentioned anywhere.

The best I can think of, is doing it completely in Flash: (laying down tile mc's, putting them in container mc's- acting as the objects) and then looping through their properties to create the map data. Which really isn't a very ideal/practical editor.

So, can anyone here offer any tips or suggestions on how you master-minds would go about such a task. :)

Thanks very much,

Viza.

I think its just due to the nature of the beast why there are no supertile editors made public:
Tile based engines are for many people already more complicated to get into than to a art based engine. Once you get the hang of it its pretty easy but its usually not the first thing a newby jumps into. Same goes for creating a tilebased level editor.
Once one has the hang for it its still quite some work to not just do a tilebased editor but one which is really a generally reusable one where the map input/output can be highly changed for the needs of a certain game.

Supertile engines raise the complexity level a few layers more. Understating how the engine works is quite easy but its much more work to set it up,especially the editor side. Making that reusable to some customizable map format is again some more work.

Those are probably some of the main reasons why i´ve only heard of around 10 flash games made uising a supertile engine since strille first outlined the concept so long ago.

I stumbled upon all those things, too of course when i worked on the very first Monster Trucks game (which uses a super tile engine) so i talked with strille to see how he tackled the problem.
He had started working on a supertile editor and it was actually usable to some extend despite some bugs here and there, he had then stopped taking it further though and had instead used a method as the one you talked about to create his supertile based games.(So position things in the flash ide and then loop through the contents of that map mc and output the map data from there).
That was not the way i wanted to do it so i asked him if i could work on on his editor and he was cool with it so that´s what i did.
I fixed the bugs and made it a bit more user friendly and then it was fine for me to do maps for trucks with it.
I always thought it´d be cool to make that some more user friendly and the map format customizable and make that public then but yeah,due to much other work i never got around that.

I used it in the form i brought it to in several games and it was ok for that but yeah, its time for a major rewrite of it to do all bitmapdata based on engine and editor sides.

There its also quite problematic (as with many other things ;) ) how the garbage collector of AS3 works, essentially i´d make the editor and engine a bit different depending on whether its done for as2 or as3 games:
With the flash 8 virtual machine (so the as1/2 one) you could just constantly load the bitmaps from the lib into newly created bitmapdata objects,copy them to the stage or buffer bitmapdata and get rid of em once not needed anymore and other things like that example case.
With as3/virtual macine 2 that is not possible like that as the garbage collector doesn´t kick in so often. Overall its of course also just way more conceptual/setup work as you have to watch out not to have any strong references going on your stuff otherwise the ram will just never get freed.

Well,dunno, maybe if strille is around hes got some things to say on the topic, too, from my side the state is that once i have some time for it i´ll have to port the whole shebang to as3.

In case you´re curious to know, here´s how it looked:


http://www.stimunationgames.com/medi...atorScreen.jpg

The maps were in xml format and would also contain info on how many and which layers existed.
In the editor you could change locked state/visibility of layers similar to how the flash ide layer handler works.

It also loaded a tileset swf and those tiles then showd up in the library.
From there you could drag a tile to the editing stage, select several tiles to turn them into a supertile and do stuff like placing collision lines on supertiles.
Those are the pink outlines on graphics on the stage there.
(The actual game did not place those lines of course, they just symbolized the codeside line segment collision detection).

In next steps i think it would be useful to extend the functionality of the library so that one could add supertiles into the lib, make the whole user interface more dynamic and less clunky and yup, as said make the map format customizable and port all to AS3.
So yeah,another month of work at least ;)

I've actually made a super-tile based editor. Instead of having to copy and paste map data I decided to wrap the SWF with Zinc so I could easily load and save the map data to a text file. It works rather well but took a while to set up. I might show a simple version of it on my new site as soon as the site is up and running which will be next month.

I think the hardest thing to do was creating the map data. If the tiles were all made up of one tile it would be simple, but you'v got to cater for tiles within tiles. It wasn't too hard to get around.

yeah,its not difficult,just quite time involving. With the supertile editor you have to add way more editing tools and options than for a tile based engine editor to make it really user friendly and allow quick map creation.
And btw, the ed i talked about is zinc driven,too, so yeah, allowed saving and loading of maps,too, of course.
Looking forward to see yours :)

Might be another good application for AIR. Malee's editor was really nice in AIR, granted most of the features were disabled.

As far as the topic is concerned, I read over our little chat last night and I think the bounding box theory sounds like a winner. The logic behind it is just complicated but I think at this point it's clear to say that there is no "easy" way to do a st editor.

i´m not entirely sold on the AIR concept yet, i have to try it first hand in comparison with something i´d make in zinc before to see how it does performancewise (cause one of the downisdes of all other existing flash standalone wrappers was that you´d get some drop of performance) but yeah,other than that AIR doesn´t bring much to the table yet which makes it exciting for me. The cross platform side with the own runtime is nice, its also cool to be able to do it right in the adobe dev tools and have more streamlined api/language support, but yeah, zinc still has so many more commands/features which AIR lacks, makes me hesistant to give AIR a go.
But yeah,one of the things i´ll give a try in my next holidays :)

I don´t know which chat you mean (were you talking to Cortana?) but yup, bounding box logic is what was used to decide which supertiles are plotted/removed in trucks and the ed, too (you can see there´s a little checkbox in the ed screen where you can tickle on/off showing bounding boxes of supertiles).

I meant Viza and I's chat on MSN. Sorry for the misconception. But that's exactly how I'd do it with bounding boxes.

:)

most engines I write already include the editor within the game/ engine.
That way it´s piece of cake splitting it up at some time into editor and game though booth share many libraries and classes.

What the supertile concept basicly needs within an editor is the ability to place tiles/sprites. anything else is optional- the very same is essential for the engine it self- so you could for example start writing a engine that can place tiles later on

yeah, having editor and engine in one can be a good thing, for example for testing the level right away. It depends on what you want to achieve with the editor and game though and also on the state of both.
For example i like my eds to allow saving files and some other features which only wrappers like zinc (and partially air) allow, the game itself shouldn´t be a standalone though so its then no use to pack the ed into the game.
Then there would be the option to bundle the game engine into the editor.
Nice by itself,but there are several issues with that,too. First of all my game engines are in constant evolution till late dev phases so i´d then constantly have to move the updates from the game over to the ed base. yeah, well, i could go on listing reasons speaking for and against it, bottomline is do it as you want and as it fits the current game project :)

First of all, thanks so much for everyone’s feedback, it's all really appreciated.

Right now, I'm beginning to have doubts about the whole concept, as the more functionality I think would be ideal/handy, the more difficult and complex the whole editor becomes. In fact, the complexity of the whole game that's planned so far has actually got me worried about striving towards making a great game technology-wise (not that I'm a good coder, but I'd give it a crack) rather then something fun to play (hence, why I’m starting to write a comprehensive game doc to keep things planned before thinking about the code side of things).

Anyway the point is, for what's its worth I’m now not convinced that going through all of the trouble and allocating so much time on just the editor is really worth it when I could get started straight away making the maps using just Flash’s authoring environment. It may sound like a wimpy way out, but I have considered the options and construction of an editor, and the cons outweigh the pros. Besides, the only time consuming part of using just Flash is naming all of the instances (which I’ll admit, will be a complete pain in the a**).

What I had planned for my own editor would be a system similar to this:
-Drag and drop tile gfx from a library onto the stage.
-Dropped tiles become mc’s
-MC’s can be moved with a hand cursor.
-Select cursor allows for selecting/grouping and deletion of mc’s
-When a group of tiles mc’s have been selected, you can (at the press of a button) create a super-tile: create empty mc, delete old tiles, place old tiles into new mc and move to previous positions
-tiles inside their respective super-tile are treated as a whole (you can only move/select a super-tile, not its contents)
-ability to undo a super-tile: delete the super-tile mc, and replace its contents back to stage
-To create map data I’d create a function to loop through all super-tiles and their contents and spit out the important properties.

I know it’s nothing other than words now, but if I did go ahead with making an editor that’s how I’d go about the functionality.

TomSamson or anyone else, I’d love to hear more about the actual methods of how the editor ran code-wise (ie. How did it handle the creation of super-tiles, or load in tile gfx, etc.)

Viza.

Quote:

---

Besides, the only time consuming part of using just Flash is naming all of the instances (which I’ll admit, will be a complete pain in the a**).

---

no need for that just place movieClip instances on the stage and use a code like this to get their default instance names:

PHP Code:

---

for (var a in _root){
    if ( typeof(_root[a]) == "movieclip" ){
        trace("instance: "+eval(a)._target+"  xy:"+eval(a)._x+"/"+eval(a)._y);
    }
} 


---

Quote:

---

TomSamson or anyone else, I’d love to hear more about the actual methods of how the editor ran code-wise (ie. How did it handle the creation of super-tiles, or load in tile gfx, etc.)

---

since I like to store map data into xml xml is my first step before anything else to create a engine. Within xml I start writing a map structure that is easy enough to read and b.) flexible enough to expand later on.
Once that is set- I write a sample map with that in any text editor and try to code a engine in flash that can read that information for me like it is supposed to be displayed later on in the game.
Once that´s tweaked I add another class just for the editor purposes and make it completely independent from the rest of the code- and in most cases add the interface of it in a overlaying movieClip over the engine- with a keypress usually I can then enable/ disable the editor

examples:
http://www.renderhjs.net/bbs/flashkit/tank_move/demo13/
(press d to switch to editor)

some editor concept I never finished but has perhaps some nice ideas
http://www.renderhjs.net/renderhjs/a...TileEditor.swf

a working zelda editor (tile based) with hitmaps and expression placer
http://www.renderhjs.net/renderhjs/Z...editor_015.swf
explaination: http://board.flashkit.com/board/show...48&postcount=2

I wish someone would adapt tUME to Windows. :-) It supports super-tiles of any configuration.

somehow that text only website doesn´t convince me that hard,
so I tested tume- and it´s like a dos tool that runs in 320*240 fullscreen and is anything but not user friendly, intuitive or quick to handle

I've never even attempted a superTile engine, the main reason not being the map editor ( Although it's a factor ), rather the collisions.

Do you guys who use them define a list of vectors for that and test against them ? So it's a case of laying down the map, and then a collision "layer".

Perhaps a bit of lame thing to say, but I'm happy with tried and trusted engines, ie tile based with a already existing map editor and easy collisions.
It seems like a lot more work for not a huge amount of benefit. I'd be interested to hear from you guys who have actually done a complete game in it to see ( Tom I know it makes sense for a Trucks style game to use one, as all the collisions need to be vector based, but for something like a run and jump it doesn't seem worth the effort ).

Squize.

its more effort initially, but yeah, well worth it depending on the game type of course. Essentially you gain the level/layout freedom of an artbased engine but with similar (in some case superior) performance as in /than a tilebased setup.
yes, its useful for physics based stuff but its also just generally cool if you want more organic level layouts than is practical to achive with a tilebased setup.
A tilebased setup makes a lot of sense if you know you will have those tiles which will pretty much be in the same size or multiples of that. Supertile based is nicer if you want to have total freedom in the dimensions and positioning of your art.
For example i´d do something like mario in tilebased setup but something like metal slug with its more custom shaped organic sceneries more in supertile setup.
And yeah, if you do physics based stuff you´d do your ed in a way in which you can place collision info on each supertile.

I'm not sure if anybody else does this, but I think it beats the poo out of tile engines in both ease and performance. I may even adapt it so that you can simply draw the map, and it will generate the AS code needed for the level. Basically, it involves setting a reference point at every slope change, then generates an equation, and uses the distance between the object and the reference point to decide where the path is. It is great for physics, because all of the information is referenced in an array with the slope and y-intercept.

Disadvantages! 1. I haven't worked it out to the point where you can have one platform over another. 2. You can't have curved lines, only lots of tiny straight lines. 3. As I have it now, you can only have one point of the character hit with the line, so it may go above/below the line.

@Squize: Well, I personally believe a super-tile approach is best suited for my game because of the obvious advantages it has over a tile based game: Different sized tiles, more flexible level design, more flexible objects (bridges, swings), slightly more flexible collision detection (in my case).
However, the more I think about the difficulties and even lack of knowledge on the super-tile method the more I'm starting to reconsider this decision (though, I'm really pushing for a little less 'blocky' level design) - especially after seeing this tile demo made by Iopred: gotoAndStop platform game

@Render: Thanks very much. Should prove very handy indeed.

I realise this is an entirely different subject, but since the issue of collision detection has been brought up I thought I may as well pose a questions: How exactly would you guys go about collision detection for a platform game.

I figured vectors are probably unnecessary (as the game would not involve a great deal of physics), and I may as well use some kind of grid system to narrow down the search (since the tiles are already divided by areas). I suppose this leaves me with a basic hitTest (since the amount of different platforms/obstacles wouldn't vary that much) or possibly a collision map (player checks colour value of map, and reacts to that collision based on the colour returned) - most likely I'd opt for the hitTest. Anyway the point is, what should I be considering for a platform game?

..I know it seems like I'm asking you guys to plan a game for me, but I'm just trying to gather some general info and advice before I go full throttle in development (after this weeks school exams).

Thanks in advance for any further advice that can be offered.

Viza.

Mate, all the advantages you listed are all possible in a normal tile engine.

I've got bridges ( Sonic style ) and multiple angled slopes in my game and it's using the same scroller engine that I posted on here before.

I was chatting with IP last night as he was working on an editor, and the more I think about it, the less appealing developing a superTile engine is.

Sorry, don't mean to poo poo it for the sake of it, but I think there's a reason there are so few superTile games out there.

Squize.

Yeah btw I scrapped the editor. I'm not really going to use it since I stick with tile based engines anyhow. ;)

to Squize: I think as soon as you CAN do all the things i listed in what you call a tile based engine its essentially not a tilebased engine in the old definition sense anymore :)
Cause some of the core definition elements of tile based engines always were that graphics of same size (or exact multiples of that) are aligned next to each other at equal spacing to form a grid like constrained layout.

Therefore i think there´s a confusion regarding what is a tilebased setup and what is a supertile based setup.

This is probably because there can be quite a difference between the setup in a bitmapdata based solution and an older flash version´s movieclip based solution.

With pre f8 (pre bitmapdata solution possible) flash versions the difference in setup had to be way bigger and therefore the differences were more obvious:
A tilebased setup would be a gotoandstop scroller, all tiles would essentially be the same size in the scroller and be contained in their own mc. you´d scroll the thing and when tiles moved out the screen on one side one would change their frame to the image of tiles coming in on the other map side, move em there and go on. (There were some other sub approach sets but yeah,let´s leave it at that for comparison :) ).
So this setup would be useful if a) you always want to fill the entire screen with tiles and b) your tiles are always the exact same size or the exact multiple of that base size.
In a supertile setup in that flash possibilities generation you´d again have tile images but you´d bundle several into a supertile mc. you could place them at any x/y coordinate on the map and you´d scroll less elements as you´d only scroll the supertiles,not the tiles contained in them each by its own.
This setup was clearly superior if you a) didn´t want to fill the whole screen with tiles but maybe just position some graphics in front of a bg
and b) wanted to have total freedom regarding graphic sizes and positioning.

With a bitmapdata based approach of newer flash versions the implementation of both setups can be way closer ,you normally in either case don´t have more than a single screen bitmap (maybe a buffer bitmap,too) and use copypixels to bring your tile graphics onto that bitmap. There doesn´t have to be a difference in mc count or things like that.
You could also just use copypixels in a tilebased engine to copy some additonal not aligned in the grid constraints images somewhere onto the other drawn tile graphics. So yeah,the line becomes more blurry whether you´re doing a tilebased or supertile based engine or something that maybe is so different that we should actually define a new term than for the old flash 7 engines :)
Since its bitmapdata based your supertile engine side (total freedom in positioning and compositing graphics) or tilebased setup (positioning equal sized stuff on a grid) could also just exist on the editor side and at runtime its still plotted different.

Quote:

---

Originally Posted by renderhjs

somehow that text only website doesn´t convince me that hard, so I tested tume- and it´s like a dos tool that runs in 320*240 fullscreen and is anything but not user friendly, intuitive or quick to handle

---

Duh, why do you think I said I wished someone ported it to Windows?? Translation of your comment is: "I don't know how to use it, therefore it sucks". :-D

The UI adheres to Deluxe Paint conventions, which are now outdated (in terms of the hotkeys), unless you are a ProMotion user. That tool was used for map editing for Cool Spot, Alladin, Jungle Book, Global Gladiators, MC Kids, RoboCop VS Terminator, Prince of Persia (Gameboy), and a crap-load of other SNES, Genesis/MegaDrive, and Gameboy games.

If it were ported to Windows, and UI updated to modern conventions, it would rock!