FAangband - 64 x 64 graphics

[Shockbolt]

The long intro text can be read here: http://angband.oook.cz/forum/showpos...29&postcount=1

The short intro text is as follows: Assuming FAangband is a non-profit game, the following tiles posted in here can be used freely within FAangband and other Angband variants as long as they continue to stay non-profit versions.

The tiles painted for FAangband is likely to be added into the tilesheet being constructed for Angband V these days.

Should FAangband want to go commercial, a non-exclusive license will have to be acquired in order to continue using the tiles. I'm not doing this to be an ass, I do it simply because I think it is "unfair" to have my tileset used for free if you aim to make money from your game.

[Nick]

Brilliant, thanks - I'll put together a list of the extras needed some time soon.

As far as the licence goes, FAangband will become a paying game over my lifeless corpse.

I assume you're also OK with the tiles being used for my fork of FA, Beleriand? That may also add a little terrain, but it will probably also be largely a subset of what is needed for NPP.

[Magnate]

Can anyone else see this turning into shocklib, the tiles library for angband and its variants?

[Shockbolt]

Can anyone else see this turning into shocklib, the tiles library for angband and its variants?

Single tile library, arranged in folders and subfolders?

[andrewdoull]

As far as the licence goes, FAangband will become a paying game over my lifeless corpse.

It's worth pointing out that Nick lives within half a days drive of me, and there's a lot of desert around to hide bodies in...

[nppangband]

Single tile library, arranged in folders and subfolders?

That sounds great. It would make it much easier to add new tiles rather than the current system. I would code it if I knew how. Maybe this question should go on the development folder, but what changes would have to happen to that each tile was it's own file?

[Zyphyr]

I haven't actually looked at the code, but I imagine each in a seperate file would result in simpler code - no need to break down the images internally. On the other hand, it would increase both memory and HD storage space due to each tile/file having its own overhead. That is presumably why the current system was implemented in the first place.

[Magnate]

I haven't actually looked at the code, but I imagine each in a seperate file would result in simpler code - no need to break down the images internally. On the other hand, it would increase both memory and HD storage space due to each tile/file having its own overhead. That is presumably why the current system was implemented in the first place.

Yes, but all those years ago both RAM and HD space were a whole lot tighter bottlenecks than they are now.

I've been thinking about this quite a bit - I think we need to stay clear of using any kind of index numbers. To specify exactly what each tile represents, we should use a system like

size-word1-word2.png

For monsters, word1 is taken from monster_base.txt, and word2 is the monster name from monster.txt

For objects, word1 is taken from object_base.txt, and word2 is either an sval (from object.txt) or an artifact name (from artifact.txt) or a flavour (from flavour.txt).

We probably also need a word1 "meta" for tiles which are neither objects nor monsters, e.g.

32x32-meta-pile.png
32x32-meta-unknown_object.png
32x32-meta-trap_border.png

etc. I guess we'll need to turn spaces in names into underscores, and dispense with the single quotes in artifact names.

This way anyone can contribute a single tile by calling it

32x32-sword-dagger.png
64x64-dragon-baby_green.png

or whatever.

It will certainly take up a lot more disk space, but it should be considerably more flexible for adding and changing individual tiles.

Thoughts?

[Shockbolt]

object_food_beef_jerky_1.png

object_food_ration_1.png

object_artifact_phial_of_galadriel_1.png

trap_spell_rune_of_teleportation_1.png

terrain_wall_dungeon_lower_1.png (bottom of the 2.5D wall)

terrain_wall_dungeon_top_1.png (top of the 2.5D wall, the part that would render partially ontop of player/npc/any object that was standing to the north)

terrain_floor_dungeon_1.png

weapon_sword_falchion_1.png

dragon_ancient_multi_colored_1.png

spiderkin_unique_ungoliant_1.png

spiderkin_spider_mirkwood_spider_1.png

Then either have the code downsize the graphics from 64x64 to 32x32 or smaller, or stick 64_ or 32_ to either the beginning of the file or the end of the file. Obviously, having the code downsize the graphics from 64 to smalles would mean a smaller .zip to download for the players.

As you see, I've ended each file with _1 , incase I go mental and decide that I want to make many versions of the same tile. This would be somewhat fun, as you could then call for the image of a broken sword, a rusty sword, a new sword, a sword that has flames running up it's blade, a sword with dripping poison etc.

[buzzkill]

I think we need to stay clear of using any kind of index numbers.

Why? Doesn't everywhere else else use index numbers?
Without much thought put into it, something like this...each tile size gets it's own folder, each tile type gets it's own sub-folder, each tile is named by index number plus descriptive name (just for ease of editing, doesn't need to be exact).

Thus 32x32/monsters/001-Filthy_Street_Urchin.png and 32x32/monsters/001-FSUrchin.png and 32x32/monsters/001.png would access the same tile.

Admittedly, I've no idea of the advantages/disadvantages of multiple folders, long file names, etc... anything really.

[Magnate]

object_food_beef_jerky_1.png

object_food_ration_1.png

object_artifact_phial_of_galadriel_1.png

trap_spell_rune_of_teleportation_1.png

terrain_wall_dungeon_lower_1.png (bottom of the 2.5D wall)

terrain_wall_dungeon_top_1.png (top of the 2.5D wall, the part that would render partially ontop of player/npc/any object that was standing to the north)

terrain_floor_dungeon_1.png

weapon_sword_falchion_1.png

dragon_ancient_multi_colored_1.png

spiderkin_unique_ungoliant_1.png

spiderkin_spider_mirkwood_spider_1.png

Then either have the code downsize the graphics from 64x64 to 32x32 or smaller, or stick 64_ or 32_ to either the beginning of the file or the end of the file. Obviously, having the code downsize the graphics from 64 to smalles would mean a smaller .zip to download for the players.

As you see, I've ended each file with _1 , incase I go mental and decide that I want to make many versions of the same tile. This would be somewhat fun, as you could then call for the image of a broken sword, a rusty sword, a new sword, a sword that has flames running up it's blade, a sword with dripping poison etc.

No problems with the extra versions, that's fine.

Your names don't follow a clear hierarchy though. Some start with a tile category - object, trap, terrain - others start with monster type. In order to code the recognition/loading of tiles properly, the name has to break down into elements:

category_basename_name_number.png

or something. Buzzkill is right that we could use subfolders instead of long names:

lib/xtra/graf/64x64/objects/

with similar folders for monsters/ terrain/ artifacts/ misc/ etc.

But we do need to separate different-sized tiles into different-sized folders. The game supports multiple tile sets, and the code needs to know what size it's loading (regardless of whether it then shrinks or stretches the tiles).

@buzzkill: IIUC takkaria has long wanted to move to indexless edit files, so that they can be edited without breaking savefiles and without requiring any concomitant changes. If we use index numbers in tile names, they need changing every time they change in object.txt. I can't see any advantage in using them.

[Shockbolt]

I was not providing the "final" solution, merely adding fuel to the discussion-fire

removing:

terrain_
object_
monster_
weapon_
spell_
trap_
misc_
etc_

and instead just use the appropriate subfolders would work also. My only wish is that they/the tiles/the files should be easy to recognize and easy to alter/replace for non-programmers.

[Magnate]

I was not providing the "final" solution, merely adding fuel to the discussion-fire

removing:

terrain_
object_
monster_
weapon_
spell_
trap_
misc_
etc_

and instead just use the appropriate subfolders would work also.

Note that "weapon" and "object" are overlapping types. Categories must be MECE: mutually exclusive and collectively exhaustive - i.e. every tile belongs in one and only one category.

Since all objects are in one edit file (object.txt), there's no point in having separate tile folders/types for weapons, armour, devices, scrolls etc. But OTOH it doesn't particularly hurt if you want to, as long as the folder/type names are as set out in object_base.txt

[Shockbolt]

Note that "weapon" and "object" are overlapping types. Categories must be MECE: mutually exclusive and collectively exhaustive - i.e. every tile belongs in one and only one category.

Since all objects are in one edit file (object.txt), there's no point in having separate tile folders/types for weapons, armour, devices, scrolls etc. But OTOH it doesn't particularly hurt if you want to, as long as the folder/type names are as set out in object_base.txt

Yes, but you got my point didn't you. What I forgot to type was object_ infront of weapon_ , then again as I wrote earlier, I was not providing a final solution.

[Magnate]

Yes, but you got my point didn't you. What I forgot to type was object_ infront of weapon_ , then again as I wrote earlier, I was not providing a final solution.

Of course - but since you're the guy who gets to choose how your tiles are organised in folders, I just wanted to make sure you didn't end up with something we couldn't use!