zombe on 10/5/2012 at 17:54

---

The reason i asked was because about ~5y ago i noticed a movement to standardize all sort of tile based 2D game level formats with the intent of (somewhat dubious) interoperability of the levels and, more importantly, the benefit of having damn good editors with negligible efforts (as editors become essentially an standalone community effort) + base gamecode to render it to start with (ie. no need to reinvent the bicycle etc) leaving only (well, + a few exceptions here and there) the actual game logic to-do. It makes sense to some extent. For example, you mentioned some tile classifications (backround1/2 etc), it is fairly standard stuff and as the storage requirements of the old times are essentially irrelevant - level formats can indeed be largely standardized. However - everyone wants to do something a little different and one can not reasonably expect the "standard" to keep up. And it encourages mass production devaluing individual efforts.

Wondered what you managed to get hold of and how much you needed / decided to do yourself. Seems your base-editor was not terribly advanced leaving quite a lot of room to fiddle with (did not manage to find anything on the site, but from the pictures, it looks indeed very basic).


Yeah, not a priority indeed. However, i do not think it would be too hard either (well, besides the fact that every effort tends to take time - the scarcest resource around).

I do not know how much time it took, but i once wrote a map editor for Heroes of Might And Magic 2 - as the official editor always crashed even before ever getting past the splash screen. Later found that my version was way superior in every single respect :rolleyes: (*).

Reverse engineered the image formats (including shadows that used some quite bizarre packing method that took ages to figure out) and all the features in the map format (uh, max Town and Mine count is hardcoded - um, why!?). Among the editor features was the method of placement:
* pick a feature from list, lets say a multi tile mountain (foreground / background / passability-rules / tile-type etc ... iirc ~8 layers [or was it 12? ... i just remember that it had way more that i would have expected ... i think even shadow had its own layer])
* move around the map (the picked mountain gets temporarily placed where-ever the mouse cursor is).
* onscreen validation / conflict indication - which i intentionally allowed to ignore (iirc, official editor did not allow that kind of monkey business).
* click to actually place it (does not unselect of course).
* undo feature (quite limited stack, but more that a few, iirc).

Huge help as placing all the tiles individually (with all the crazy extra data) would have been essentially impossible. However, HOMM2 maps have probably way more crap in them in comparision (also, i used preexisting maps to help making the multi tile sets) - so, doubtful it would make as big a difference with your game.


Not to push you in the slightest, but you do have a blog :D Would be a nice place for it - and that kind of thing might catch a eye that otherwise might have passed by (disclaimer: i am talking out of my ass, as in, purely based on assumptions).

-----------------
*). Damn, once i open my mouth - i find it hard to stop.

WARNING: trip down the memory lane follows.

Speaking of reverse engineering stuff - used to do that way too often. There were times that there were no games i had and did not poke with:
* among the usual Wolfensten3D / Supaplex / and-a-shitton-of-other-simple-tile-based-games i made a level editor for ... etc ...
* made a tool for reverse engineering data files - mostly savegames (Zeliard was my first victim). Was primarily geared towards finding patterns, values and changes (ie. to figure out whereabout the stuff i am interested in is [allowed ~6 comparison windows to different, or same, files and editing them]). I still have the program and still used it every now-and-then, but had to abandon it with my current PC (64bit and program was of course 16bit). A few things that make me laugh when i think about that program:
1) 2 bottom-right chars were not drawn as i did not figure out how to prevent DOS (bottom one) and Norton/Volkov Commander (the one above it) from auto-scrolling (later on i used the b800/a800, or whatever the crap it was, memory addresses directly - made a crapton of text only games that way - which also replaced the 128-255 char range with my custom, game specific, graphical glyphs).
2) the find-file binaries (a concept that itself completely alien to me at the time) i had to use were way over my head and i fucked up pretty bad - the listing was almost always wrong x_x, but semi-usable ... most of the time.
3) it was written in turbo basic and had code like "LOCATION 1 2 ASD". First, i did not know that i am actually allowed to use lowercase for the commands x_x. Second, that ASD (Bare in mind that i did not understand a single word of English - Yes/No might have been the sole exceptions. I am not even joking.) was, shall i say, amazingly stupid. I just figured out what all the commands did by experimentation (well, what other choice did i have). In this case, when i put ASD there then it, while still moving the cursor, did not show it. ... well, it never dawn on me that the last parameter was supposed to be an optional 1/0 for, you guessed it, whether to show the cursor. Uninitialized variables, such as a nonsensical ASD, just happens to be 0. x_x ... never fixed any of the errors, but still used the program till ~2007/8. It did its job. Don't fix what is not broken i guess.
4) the window title is "X X X X X" - i was a bit embarrassed of the original title and used the sodding thing to change it / hack it out from itself x_x. Pst, don't tell anyone what was there before :p
* made a savegame editor for civ1 x_x (graphical map editor in 640x480 mode! [yeah, it was quite many years after civ1 release] - based my HOMM2 editor on it later ... with upped rez). The only game i could not figure out the savegame format by just looking at the savegame data itself. Had to trace it with an disassembler (can not remember what it was called - but it was a pretty damn good one for the time). The method it used was truly amazing for me (later found out that it is Lempel-Ziv compression algorithm with some funky runlenght encoding thrown in) - blew my mind. The other thing that blew my mind, in an different sense, was that over half of the file was 100% redundant. The bulk of the level format was essentially a rgb picture (std 320x200, mode 7 [iirc], format) where different color channels meant different things (i think there were 6 of thous rgb maps [so, total of 18 layers!]) - and the rest of the level picture data were the pictures of the leaderheads (or whatever they are called - 4 of them). Later read somewhere that the redundant copies where in savegame to avoid an extra floppy swap for the 2-floppy version x_x.
* even more crazy ... reverse engineered an editor for doom2 - from the savegames alone x_x. Seriously. No, i do not believe it myself either - wtf. Found the "binary space partitioning", as it is actually called, an amazing idea. The other thing was that i found i can trick doom2 and make multilevel floors (did not work most of the time tho - my implementation was just way too buggy (and made of shits and giggles) at bsp gen. ditched my editor immediately when i got my hands on the official editor). Unfortunately, doom2 collision checks with objects completely disregards the height differences.

-----------------
Oh, Me and my blabbering ... anyway. I was thinking today about compressed texture formats, in regards of the thingine i am (slowly) making, and finally picked one of them - and i do not really like it, but do not see a choice:

Need to encode:
* color (duh)
* normal
* height
* specularity (oh, speller, why are you so useless: peculiarity, spectacular, particularity ... sigh ... it redlines my version, but i do not see anything wrong with it)
* ... um ... whatsitcalled ... falloff / microfacets / specular power ... sounds like it

Must fit in 2 textures. Thous are my choices:


Not much choice there :/. BC3 it is then:
* tex1: rgb = color, a = x component of texture tangent space normal
* tex2: r = specularity, g = height, b = specular power, a = y component of texture tangent space normal

Color part is fine'ish (the previous pics use BC1 [=== rgb part of BC3] texture array).
Normal should be fine (BC3 encodes alpha separately: two 8bit values + 3 bit interpolations per texel).
The rest is very iffy ... but i do not see any other option.

zombe on 10/5/2012 at 21:22

---

Yeah, that was a brainfart - in WADs. Like one of the teachers used to say: "mouth is singing and heart is worrying".

:D. Hex edited together?

Sadly, there was no possibility for any internet back then for me - would not have been of any help either (due of the impenetrable language barrier).

I had the benefit of having a graphical backbone to the editor at the time i finally sufficiently understood what was what (well, it had problems like i mentioned). My approach at first was to find coordinates of things (as they must be there somewhere and are easily recognizable) => look up stuff that could be coordinates and draw them on screen. As i had, obviously, played the game quite a lot then it was easy to know when i hit some kind of coordinates. I remember that i was a bit confused when i got a hit - it looked regular, and strangely familiar, enough to confirm that i indeed got some coordinates, but i could not recognize exactly what. Wth? Never saw that coming ... then realized that just the coordinate system was a bit weird (ie. did not match the in-game map orientation with how i imagined the coordinate system). So i went, unraveling it step by step - including ways to mess with things i figured out or was trying to figure out (meddle with it and see what happens in game) to the editor thingie. One of the things i noticed when moving the vertices around was the rendering ... very peculiar bugs ... strangely logical ... amazingly clever ... aka bsp geniality (well, besides the visibility bug ... the strange lineups of seemingly unnecessary vertices in middle of straight walls also helped - the level that starts on a cross in green sludge was the one where i realized how it all fits together, has some telling vertices for me to recognize and meddle with). Made very clear how that works logically - now, how to make one ... um ... no clue ... just cut randomly :D. That part kind of worked - provided i helped it a little by lining walls up to not miss by some small value. The sector business to go with it was a mess tho. Also, i could not figure one of the named sections (whatever they are called) out ... nothing i did there seemed to affect anything at all - even writing random garbage there. I do remember one of the sections by name "BLOCKMAP" - which dealt with collisions and was the easier one of the structs to generate ... and abuse / muck with (or brick the level, x_x).

So, the multiple floors thingie (ie. one area going below the other - like one tunnel crossing below the other for example), as far as i can remember, was based on the "accuracy" of that detection. To make it miss the wall in one sector and not the other (only "doorway", the conflicting bit, mattered - at least i did not notice anything strange going on in anywhere else). Did use fake walls too to ... um something ... at least i remember messing with them, but i think it did not help. I remember it glitched for some attempts at the conflicting wall when changing direction at the magic spot (getting stuck or out of the intended playing area).


Zero chance of finding any of that anywhere - also, i never did any level from ground up with my thingie, just altered them (especially the first one as it cooperated with my meddling the best). Did a crapton of my own levels with the official level editor tho - with equal chances of ever seeing any.

Speaking of invisible pillars / walls ... I vaguely remember something at least similar (i used a few with the official level editor), i think it was just reversing the single sided walls and let the opposing side be from same sector (very foggy memory here) and/or using an invisible texture (ie. something that is not meant for wall and has no repeat and moving it way down) - unfortunate texture choice made it super slow / crash (or draw memory like garbage at parts of the texture). So, there might have been a neater solution. Can not think of any way how something like that could be done with BSP.

Hm, there was some gotcha with the top part i think (if the texture is missing then it normally just extends it till it hits some other floor - creating a "sea" effect). That of course only when player can see the top, from anywhere else it is completely invisible.

Eldron on 12/5/2012 at 10:34

---

Been working on a tileset for the awesome cataclysm roguelike with the recent inclusion of a fantastic graphics-mod.

http://www.eldpack.com/images/cata.png

Volitions Advocate on 14/5/2012 at 02:01

---

What you say is true Koki, but teaching an AI to develop puzzles is a bit more difficult than simply having it make levels.

june gloom on 22/5/2012 at 07:46

---

That's our Koki, anti-intellectual to the end. The bitter, stupid end.