Looking for Help Arranging Tiles

[C-Dawg]

Hey all,

As Zodiac wraps up, I'm taking a class in Allegro and C++ so my next project will not be dependent on another person's engine. So far, I'm up to being able to define my own 2-d integer array and have that draw blocks on the screen that a little dude can run and jump around on. Hooray!

In between learning the API and strange little things like how to pass 2D arrays in C++, that you need a ";" at the end of struct definitions, and so forth, I'm also starting work on the tilesets and sprites. I see there are utilities like Mappy and Tiled that allow you to draw tilemaps similar to what Zelda Classic allows. They even have a rough approximation of ZC's "combo" editor, as far as I can tell, that allows you to store data with the graphics.

What they do NOT appear to be able to do is re-arrange tiles on the tilesheet. As anyone who has used Zelda Classic knows, drawing a screen without an organized combo list is a nightmare. You need to group walls and corners next to each other so the designer can FIND the damn things. I'm making my own tileset at 32x32 in Aseprite, so I can export large sprite sheets of any dimension easily. However, I'm drawing them on 64x64 canvasses so that larger walls and objects line up for me to view as a group. When I export the sprite sheet from Aseprite and then load it into Mappy, I get a mess that looks like it has its own algorithm for just loading whatever into the "tile palette" (for lack of a better word.)

I'd like to avoid having to copy and paste my way to victory by manipulating the spritesheet directly in like, MS Paint, and then using trial and error to arrange it. I'd like to be able to use a mapping utility that lets me re-organize an already loaded tile sheet, like how ZClassic lets you C and P combos.

So, that's the question. Anyone know how this is done in a utility like Tiled or Mappy? Or, failing that, is there an easier way to do this? Are there utilities that let you just cut a .png into 32x.32 squares and click to move them around?

I guess coding my own such utility would be good practice... still...

[Gleeok]

I'm with you on the state of tools for 2D tile-based games: They just all suck donkey dick. Tiled editor is pretty awesome, but the tilemaps are so generic that I can't actually see how you can use it for a full game. I don't think they even support animated tiles still! Forget about anything more complicated than that I guess. It's a damn shame.

Since I also believe that treating an image as a tileset is "doing it wrong", I ended up just making my own. It easily supports anything ZC can do, and it let me extract all the maps from the PSP ROM and put them in my own format. The down-side is that I can't use an existing map editor tool, and have to write my own, which I haven't quite done yet... I guess you just have to pick your poison. I can tell you that 2D tilemap stuff is stupid easy, but perhaps only if you've written them before--my first iteration was a little crappy to be honest. As with anything in c/c++ it's easy to write bad code and hard to write good code.

As far as utilities for images go, I don't know. I haven't really seen any, but then again I am not particularly good or experienced at pixel-graphics stuff, only the code that uses it. I do know that graphics gale free lets you move rectangles around pretty easily though. I once used it for bitmap fonts.

Are you trying to port Zodiac, or working on something new?

[C-Dawg]

Porting Zodiac would be an very interesting challenge, since I'd have to recreate the source code of ZClassic from the ground up! Maybe worth it some day, after all, ZClassic crashed the reviewer's computer during the Twitch review of Zodiac last night, much to everyone's amusement. He did, however, soldier through and really enjoyed the game while praising the current devs, including you.

No, at the moment my intention was to start a newer project. Another metroidvania, but with a few new twists mechanically. So far, I'm able to get a little one-screen platformer working, but as I start to delve into object-oriented design for an engine, I need a reliable way to make lots of maps. I might later work with someone else on the map-making side of things, so a good mapmaking tool is a must.

I'd be interested to see what you came up with. Did you use Allegro 5? If there's nothing good out there, perhaps I can look at that and make my own utility application. What I'd be looking for is something that acts kinda like ZClassic does... just thinking out loud here...

1. Create "combos" by selecting a 32x32 pixel portion of a PNG at a time, building a combo palette like ZQuest has so tilesets are well organized;
2. Each "combo" having an array attached of, say, 50 ints that can be loaded with whatever. Used for flags and types on the combo, but not defined in the map maker. Also probably have a string for each combo so you can name similar combos with different properties.
3. Ability to point and click single combos at a time, define "brushes" like Mappy does, and possibly do relational drawing of large edges (though that would take some serious setup).
4. Output a three-dimensional array; [x][y], with each element just being an integer index to the combo sheet. Also output a "combo sheet" that is attached to the map and defines the properties of each tile.
5. Simple functions to load/draw a map saved in the format we created and return one of the elements 3rd dimension array.

I envision then just defining constants in the game engine like SOLIDITY = 1; FRICTION = 2; and that kind of thing that would allow you to quickly access "properties" of the tile. Like, current_map.get_property(x,y,FRICTION); or something.

That makes the mapping utility as minimal as possible and gives lots of flexibility to how you would use it.

Continuing to think out loud here, let me think about the next things I need to know to make this utility: 1. Multiple windows or at least the appearance of them; 2. Capturing mouse input other than the "x" to close the window; 3. file i/o for graphics and 3d arrays; 4. importing outside resources into Visual C++ (I know they have tons of folders set up for this purpose); and... I think thats it. I really have no idea how to create output that I can then use in Visual C++, but I'll learn.

I'll start tinkering with some of the basic things I need to learn this weekend. You wanna help out with this, Gleeok?

EDIT: This guy states the problem better than me:
http://forum.mapeditor.org/t/tiled-n...evelopment/678

EDIT2: In fact, now that I look more at Tiled, it looks like that utility may have MOST of the functionality I'm looking for. Looks like you can't move your "combos" around after you've made a map, but otherwise it looks pretty solid...

[Anarchy_Balsac]

If it's simple enough, you can use a character matrix that reads from a text file to create your levels, then making your maps is as simple as editing the text file.

But a better way for Metroidvania games is to use XML with an integer matrix. I don't remember exactly how it worked, but I've used it before and it's effective.

Now, for either of these two methods, you will have to view your level, when editing it, in a way such as this:

.................................................. .........................
............G..................................... .........................
.......--------....................---------...............................
.................................................. .........................
........................e......................... .........................
....................--------....................---------..................
.................................................. .........................
.......................................e.......... .........................
.......----------................---------.................................
.................................................. .........................
.....P............................................ .........................
tttttttttttttttttttttttttttttttttttttttttttttttttt tttttttttt

or this:
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.177.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.003.003.003.003.000.000.000.000.000.000.00 0.003.003.003.003.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.003.003.003.003.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.091.000.000.000.000.000.000.000.00 0.091.000.000.000.000.000.
000.000.000.003.003.003.003.000.000.000.000.000.00 3.003.003.003.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.020.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
100.100.100.100.100.100.100.100.100.100.100.100.10 0.100.100.100.100.100.100.

But it works, it allows you to have a sense of scale, AND it is nowhere near as cumbersome as developing a whole level editor.

[C-Dawg]

If it's simple enough, you can use a character matrix that reads from a text file to create your levels, then making your maps is as simple as editing the text file.

But a better way for Metroidvania games is to use XML with an integer matrix. I don't remember exactly how it worked, but I've used it before and it's effective.

Now, for either of these two methods, you will have to view your level, when editing it, in a way such as this:

.................................................. .........................
............G..................................... .........................
.......--------....................---------...............................
.................................................. .........................
........................e......................... .........................
....................--------....................---------..................
.................................................. .........................
.......................................e.......... .........................
.......----------................---------.................................
.................................................. .........................
.....P............................................ .........................
tttttttttttttttttttttttttttttttttttttttttttttttttt tttttttttt

or this:
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.177.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.003.003.003.003.000.000.000.000.000.000.00 0.003.003.003.003.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.003.003.003.003.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.000.000.091.000.000.000.000.000.000.000.00 0.091.000.000.000.000.000.
000.000.000.003.003.003.003.000.000.000.000.000.00 3.003.003.003.000.000.000.
000.000.000.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
000.000.020.000.000.000.000.000.000.000.000.000.00 0.000.000.000.000.000.000.
100.100.100.100.100.100.100.100.100.100.100.100.10 0.100.100.100.100.100.100.

But it works, it allows you to have a sense of scale, AND it is nowhere near as cumbersome as developing a whole level editor.

Yeah, Im aware of that method. That's how I've got my one-room game thing working at the moment; I just raw-dogged an integer array and told my code what to do with it. An editor would ideally output something very similar to that, plus the .pngs themselves.

The problem is:

(1) I'm making my own tileset, and I'm aiming for SNES-quality with slightly higher resolution. This means LOTS of tiles. I am not barfing out some stupid-looking JPRG field tiles here, I'm taking my prior work up a notch by making something that looks more like Super Metroid-quality. (For those who are interested, I'm trying to do an artistic theme similar to Ultionus: A Tale of Petty Revenge; big, colorful, and very "poppy" if that makes sense.) This means LOTS of tiles, and potentially lots of different tile properties. Using integer arrays will be very, very hard to keep straight.

(2) I don't plan on doing all of the mapping myself because, let's face it, it took me 7 years to finish Zodiac. Even without a 5 year hiatus in the middle, this time I gotta make an ENGINE first, and lord knows how long that'll take. The easiest thing to get outside help with is map making, since anyone can do that (though few can do it WELL and consistently) without knowledge of programming.

So, I gotta have some fairly robust map making software that I can load into whatever Allegro engine I end up excreting.

[Anarchy_Balsac]

I know what you mean, it's a tad cumbersome, but it works, and you can get used to it faster than you might think. The time you'll spend making an editor will be exorbitantly long and probably not worth it. I know this from experience because I tried it myself, and adapting to the above method really was the better option. It's annoying until you get used to it, but you WILL get used to it, and far more practical than it might seem at the moment.

An editor is only worth it if you need people to build your maps for you.

BTW - is this an actual Metroid game?

[C-Dawg]

I know what you mean, it's a tad cumbersome, but it works, and you can get used to it faster than you might think. The time you'll spend making an editor will be exorbitantly long and probably not worth it. I know this from experience because I tried it myself, and adapting to the above method really was the better option. It's annoying until you get used to it, but you WILL get used to it, and far more practical than it might seem at the moment.

An editor is only worth it if you need people to build your maps for you.

BTW - is this an actual Metroid game?

An "actual Metroid game?" Heavens no. I don't have the intellectual property rights for something like that. I may like to pay homage to older games, but I want to develop my own characters and story rather than cribbing off and existing franchise.

Of course, this is very early; details will be evolving as I work on this.

[Gleeok]

Oh god... don't use byte-maps!

The problem is going back and forth to see if it "looks right" ad infinitum... Plus, wait 'till you add in event layers, objects, enemies, dialogs, etc.. and try and manage all that with text files.
Works great for just throwing together a quick map for gameplay prototyping though.

I'd be interested to see what you came up with. Did you use Allegro 5? If there's nothing good out there, perhaps I can look at that and make my own utility application. What I'd be looking for is something that acts kinda like ZClassic does... just thinking out loud here...

1. Create "combos" by selecting a 32x32 pixel portion of a PNG at a time, building a combo palette like ZQuest has so tilesets are well organized;
2. Each "combo" having an array attached of, say, 50 ints that can be loaded with whatever. Used for flags and types on the combo, but not defined in the map maker. Also probably have a string for each combo so you can name similar combos with different properties.
3. Ability to point and click single combos at a time, define "brushes" like Mappy does, and possibly do relational drawing of large edges (though that would take some serious setup).
4. Output a three-dimensional array; [x][y], with each element just being an integer index to the combo sheet. Also output a "combo sheet" that is attached to the map and defines the properties of each tile.
5. Simple functions to load/draw a map saved in the format we created and return one of the elements 3rd dimension array.

I envision then just defining constants in the game engine like SOLIDITY = 1; FRICTION = 2; and that kind of thing that would allow you to quickly access "properties" of the tile. Like, current_map.get_property(x,y,FRICTION); or something.

That makes the mapping utility as minimal as possible and gives lots of flexibility to how you would use it.

Continuing to think out loud here, let me think about the next things I need to know to make this utility: 1. Multiple windows or at least the appearance of them; 2. Capturing mouse input other than the "x" to close the window; 3. file i/o for graphics and 3d arrays; 4. importing outside resources into Visual C++ (I know they have tons of folders set up for this purpose); and... I think thats it. I really have no idea how to create output that I can then use in Visual C++, but I'll learn.

I'll start tinkering with some of the basic things I need to learn this weekend. You wanna help out with this, Gleeok?

I didn't use allegro 5. I'm not a fan of allegro 5 for three reasons: It's bulky, there's too many add-ons that have too many dependencies, and the event handling is difficult. I use my own windows layer that can use either Win32, SFML, GLFW, or whatever to make a window, handle input and gamepads, etc. Took a bit of work, but I am not dependent on any libraries or chain of library dependencies. :) Why get all the extra bloat when you can do it yourself?

For what it's worth; I spent so much time on the engine that I fell way behind in other things, like, you know, the actual game stuff. It's a pretty deadly trap, actually. I kept thinking "oh no problem, I can just add this, then that, then refactor this... then that." It's all fine if you can spare 8 hours a day on a game like a "professional" indie dev, but as a spare time thing it sucks up most of your time very quickly, possibly years, especially so if you are still learning the basics. There's nothing like spending a few days on some little stupid thing only to realize you haven't actually anything important to the game! You might want to get someone dedicated to music, and another for low-lever engine code, maybe, so you can just work on the game itself and learn it by doing that.

Funny enough, it just happens that the next thing on my todo list is map event and object layers. Well actually there's about a dozen other things associated with that, but yeah, all that good stuff. I kind of miss the simple shmups, those were so much easier to make.

Sure, I'll help you out. You can also look at anything else I've done, feel free to ask away.

[Anarchy_Balsac]

Oh god... don't use byte-maps!

The problem is going back and forth to see if it "looks right" ad infinitum... Plus, wait 'till you add in event layers, objects, enemies, dialogs, etc.. and try and manage all that with text files.
Works great for just throwing together a quick map for gameplay prototyping though.

Oh I know, I've done it. Maybe I just have a much easier time with it than yall do.

[C-Dawg]

Gleeok, I will probably take you up on that offer to some extent. I didn't reach out to you as a programmer initially because I know you have your own fish you're busy frying.

As for Allegro 5, I figure that bloated code can't be THAT bad when we're just talking about a 2-d, tile-based platformer. I mean, I was able to do everything I wanted in Zodiac using just 32 FFC objects, why can't I get similar results using Allegro 5? Besides, my goal here is to get an engine that's JUST good enough to do what I need without getting to crazy. From there, I can work with what I have, like did with ZQuest. I don't need tons of features, I just need a bare-bones engine and I can tinker from there.

I chose Allegro 5 basically because it's user-friendly. I mean, I was from hello-world to making sprites move around in a total of like 4 hours, and most of that was spent looking up the API. My strategy is to make a series of smaller games (based loosely on the on-line curriculum I'm working on) and slowly grow to understand what's possible and what's not. Along the way, I'm making assets as I need them for what I'm doing and stashing them away for later use in design.

By way of example, I now have a little game (just main.cpp) that has one screen with blocks defined by a byte-map. You walk and jump this little astronaut around, he can shoot projectiles and blow up infinitely spawning green hoppy things. Right now all the sprites are just structs that store the relevant variables, and the game loop just adds and removes them to vectors (EnemyList, PBulletList, EffectList, etc) as needed, and handles stuff like applying Vx and Vy. I need to implement a few more things like sound and a score board, but I think I know how to use fonts and sound already.

From there, I want to figure out:
1) Non-keyboard input, at least from X-box
2) Mapping utilities (like I said earlier, but at first blush Tiled looks like it does what I want)
3) True object-oriented design
4) File i/o
5) Manipulating the size of the window, full screen mode, and size of sprites and tiles.
...and probably 50 more things I'm not even thinking of that I'll run into.

I'm sure I'll run into more issues as I dig deeper. Like, I'm told that to make Tiled output (.xml) work with Allegro, I need to code a "parser." I have no idea what that is, except in the broad sense that I guess it reads the .xml file, but i'll get there eventually. I don't know how to use all the sub-folders that Visual C++ provides.

All that said, if you want to help out, that's cool. I'm not really ready to collaborate right now, though, because I don't really know what I'm doing yet. If you want to dropbox me your map editor utility, that will probably help me understand file i/o and some other basic concepts I'm not thinking about. Any other "lessons" you want to toss my way would be appreciated. And, who knows? Maybe down the road you can help with streamlining whatever horrible, noodly mess of code I come up with when I'm actually getting the real engine together.