Looking pretty awesome! Is that on-calc?

Tasty screenshots! Nioce work guys, keep us updated

Nope, these are just mockups made in GIMP to help us try to figure out what kind of playfield size would balance visibility and level complexity properly. You'll know when we have actual on-calculator screenshots, because we will be inordinately proud of the success of our tilemapper.

I agree can you try mocking up a 10x10 full res and 12x12 Fullres for us? I am currently learning how to play with qt for the level editor...Its awesome. Bloaty but awesome.

As requested, here's the mockup using 12x12 sprites with full resolution. I quite like it, although it does limit the levels to being quite small still.

I think the sprites at 8x8 and bigger more detailed maps are going to be more fun/playable? Haha, maybe even have smaller maps load in the 12x12 format, and bigger maps load in the 8x8, giving a sense of zoom? I don't think your collision detection would have to change much, just add a variable here and there to determine sprite sizes. Yeah this means double the sprite data, but I think it's a good idea.

That's a great idea! An 8x8 spritesheet and a 12x12 spritesheet would not be the end of the world at all, and would certainly give us flexibility for two types of levels. I heartily support this idea.

I should be able to modify the level drawer routine to support this without much trouble, I'll do it tonight if I have time

I am all for it, collision doesn't change to much at all. I think it changes some numbers but that's trivial.

So We need a finalized Level format

Here is my thoughts on it

Code:


+: So we can specify Big Small Puzzle/challenge levels. Anything that had a different set of controls To Base engine Is what this defines.
++: Each Item that can be rendered. Gold, Bombs, Rockets, EndLevelDoors, Enemies, Etc
+++: Since we are parsing the above we just call it over on this type.

is the first X/Y the coordinates for the items, or the second X/Y?

If it's the first, why put the X/Y before the item type, when putting the item type first would allow omitting an X/Y for the end flag.

Also I'd like to suggest making the X values bytes, and then having the code multiply them by 2, unless we have a good reason not to.

Edit to clarify.

I see no reason to. Yeah it will eat up more space. But the density that there will be for items We should have that fine grained control I planned on making level sets compressible anyway. So they only have to be extracted at runtime.

I've modified the tilemap renderer to work with the format geekboy posted. I haven't been able to test it yet, but I will be able to test it tonight and I'll update my post when I know it's working for sure.

Darn, I didn't read that soon enough. I was going to suggest that it might be easier to move the variable-length field (the level name) to the end of the header, after the fixed-length fields, just to make the fields easier to find. It's really not that important either way, though.

Imo its just as easy to find anything you just move to the end of the string. It's just one more step but not the end of the world like you said.

The time traveling feature sounds like timemu, a game on armor games

What I have in mind is very different then that. But follows something similar. I think we are game for other ideas then just time travel. So What else do you all have in the lines of suggestion.


EDIT:

level editor is slowly coming together!


Nothing is really coded it. It is nothing more then a glorified QT mockup But hey now the fun of actually doing it can start

Oh there is one thing coded in. The File -> close option works >.>

Any chance I can get a mockup of the tile sets in individual files. Going to make it dynamically load the tiles from Disk so we can make edits to them arbitrarily and add new ones just as easy.
Also we made a (minor?) Change to the level format as noted here.


EDIT: Minor change to the mockup. Realized i needed a way to specify available Constructs as well as Already placed one. For you know easy access

Looks cool! These kinds of tools can greatly speed up development.

Thanks. The real goal behind making it is to help me learn a GUI framework. But yeah it will help with level development a ton. Since it will allow us to make levels and place arbitrary items with out much thought. Drag. Drop. Click Export CLP. Paste. Compile. Profit.


Edit Yay more progress

Ok another change to the level format. Because it will just be easier to parse for everyone again >.>

It's back to a construct of 255 is the end of the level data.