The zipfile contains a "zipfile" called Contactb002.sd7 - models are in native Spring-RTS s3o format - research shows that there is a blender import/export plugin. Converting and uploading some of the models to say .obj and .blender would be nice. I think they may be useful for some projects, among others they've got weapons (G36 par example), (space-)marines, a Tank, a Spaceship - but that's just what I've seen from screenshots.
In general the Spring community has a lot and a wide range of nice assets as it seems (some of them proprietary IP though).
Yes, adding semantic information is a daunting task - I tried to test-write metadata for my street-tileset and just like http://www.frogatto.com/?p=290#more-290 suggests: It is an data explosion even for small tilesets - getting worse the larger the set gets. That's why we need standards and tools.
We aren't talking about artists on OGA writing metadata for submissions by default. Maybe Feedback is the wrong place - could be under "Programming - Procedural Content Generation".
Nobody forces an artist to do write down metadata (at least not my intention...yet ;) - it can be retrofitted by caring developers or using simple tools. BUT to create metadata a developer may need the original artist's help. Because the artist knows his tileset better (metadata == canned knowledge). Speaking for myself: Sometimes I can't discern head and tail on a complex tileset. Which ones are supposed to be adjacent? Which one is in which layer? Which one is an alternative to which other? How do I build walls and corners? ...
But I don't want to talk about yes or no, I'd like to talk about where to go. It's actually quite curious to think about it that there is no adopted standard for anything like this after so many years of tile-graphics. I'm sure it was done several times in proprietary game-map-editors and even open projects but general purpose open map-editors and formats are still where they where decades (+flashy gui) ago. Just think about what we got format-wise: tga, jpeg, gif, png,..., mp3, ogg, ..., avi, divx,..., obj, VRML, X3D, ..., XML, HTML, RSS, OWL ..., and not a single standard format for Map-editing and tiles? Don't even mention metadata. Search the internet and you will find this very forum page. Maybe now - that tile graphics are mature and with a need and the means for collaboration - it's the right time.
Assuming there would be a standard metaformat then mapeditors like Tiled could support creating portable metadata through clicking here and there to link tiles and assign tags. And then a mapeditor may suggest you which tile to place where and speed up mapediting in a smart way. Or it may autoplace some patches. And one task at hand is automatic/procedural map generation which relies on metadata either hardcoded-throw-away (nay) or metafile-based (yay). And finally new game projects may rely on standards and standard libraries to ease efforts.
This is a huge effort but to those interested: Start it by collecting data and building a hub right here!
It is about Frogatto's way to use multi-tile-patterns (MTP) - ie. building a larger tile out out of smaller 'tilelets' (with random variation). Noteable is that images may be doubled/replaced by others (with random chance).
Wow, quite fast shooting. I've got to install a newer browser...
You mentioned "Skeleton interpolation between keyframes." on your todo list - I just wanted to point out that you may have a look at nlerp (normalised linear interpolation) instead of slerp (spherical linear interpolation). nlerp is a simple and a sufficient approximation when there are not-too-big-differences between q and q'.
I'd vote for JSON, too (+human readable, +wide support, +convertable to XML, ...).
Let's start finding attributes for image (sprites/tiles) objects:
Image:
tags : List of tags for finding/selecting (aka multi-type/id: sprite, tile, portrait, slope, water, plain, deco, north-east ...)
layers : List of recommended layers (layernames) where the image may be placed
file : Filename of image (when it is a tileset you may use scissorbox to select individual tile)
name : Readable name for tile/sprite
info : Readable description
size : Width and height of image.
scissorbox : 2d box for cutting out a single tile when 'file' is a tileset (top left will be 0,0 after cut)
offset : 2d offset when painting
hotbox : 2d box for collision hot zone {x,y,width,height}
east : List id/tags of tiles allowed on the right.
west : "
north : "
south : "
not_east : List id/tags of tiles explicitly not allowed on the right.
not_west : "
not_north : "
not_south : "
...
Using standard tags would make tilesets interoperable but they could be translated somehow, too. An Image id can be replaced by adding a unique tag to the tag list. east/west/north/south may change when using, say hex tiles: north, northwest, west, southwest, southeast, east, northeast.
For animation I would assume individual animation objects which reuse images.
Animation:
tags : List of computer readable identifiers
name : Human readable name
desc : Human readable description
frames : List of Frames, see below
...
To animations attributes may be added for side effects (display text, invoke function, start sound) which may be game specific. Frames may be objects again containing the metadata for a frame (static offset and hotbox of the Image could be overridden).
Frame:
image : tag/id of Image to show this frame
duration : how long should this frame be shown before the next
hotbox : 2d box for collision hot zone (overrides image hotbox)
offset : 2d offset when painting (overrides or adds to image offset?)
(sideeffect : Whatever your game may do at this point in time)
...
Of course not all attributes are always required but specifying more increases reusability.
Some more considerations regarding size, bandwidth and loading performance:
I've got a rather small model 476 Faces, 296 Vertices, 25 Bones, the binary MisfitModel 3d file is 58KB and the ascii md5mesh is 44KB only. If you compress them into zip files that ratio is even larger 18KB to 11KB. That's because modellers dump down whole state structures - binary game related formats may be smaller. But there is the tendency to save only what's needed in ascii and write down whole structs with binary. And with ascii you can control filesize by controlling precission of numbers (digits) - that would get you a size/quality tradeoff.
Of course there is a difference in loading performance (and overhead for writing a compatible robust parser) but as for the impact: Loading will virtually always consume fixed x% of your processing power the only question is what models your system can handle.
Slow system => small models => fast load => ok rendering performance
Faster system => bigger models => still fast load => ok rendering performance
With the right datastructures loading scales linearly. I fully agree to Pompei2: Loading isn't the bottleneck, except if you needed thousands of models but then you'd probably stream the data anyway. And if bandwidth is a problem then compression may help.
http://www.atmind.nl/blender/mystery_ot_blend.html points out: Blender is a moving target and only dumps internal structures down - internal structures change => format changes. Yes, it's better to write an export plugin for blender and maybe blender supports (or eventually will) support commandline converts. And it's probably even easier and faster to 'buy' than to make.
md5mesh and md5anim are quite "nice" text based and proven file formats. There are Exporters for Blender <2.5 and >=2.5, for MisfitModel 3D (Milkshape-but-open, a GPLed exporter plugin is part of the LinWarrior3d distribution ;) and other modellers. There are serval libraries for loading and a lot of websites describing that format.
There is another similar and derived extensible format IQM (little-endian binary) and IQE (ascii). I prefer formats readable with a candle and a magnifying glass ;) for long-term-source-persistence. IQE can be used as a kind of source to be compiled to IQM. There are several open fps games supporting IQM/IQE but only Blender supports export - export only so far. No libraries so far but there is public domain sample code in the SDK. A drawback is that the sdk does not contain a IQE sample model - only IQM - kind of counter intuitive given that the sdk contains the IQE to IQM compiler.
That's what I found out when I was searching for a suitable fileformat.
For an Asteroids-Pack you may rip/scale/rotate these to make a complete Asteroids Game Starter Kit:
explosion gfx: http://opengameart.org/content/explosion-with-alpha
explosion gfx: http://opengameart.org/content/explosion
explosion sfx: http://opengameart.org/content/explosion-somewhere-far
explosion sfx: http://opengameart.org/content/rockbreaking
shot sfx: http://opengameart.org/content/4-projectile-launches
shot sfx: http://opengameart.org/content/bombexplosion8bit
shield/collision sfx: http://opengameart.org/content/space-ship-shield-sounds
dead/gameover sfx: http://opengameart.org/content/random-sound-effects
menu sfx: http://opengameart.org/content/various-sound-effects-from-rubiks-race
big asteroid, mine and alternate explosion: http://opengameart.org/content/asteroid-explosions-rocket-mine-and-laser
small asteroid and shot gfx: http://opengameart.org/content/particle-effects
background gfx: http://opengameart.org/content/galaxy-skybox
background gfx: http://opengameart.org/content/4-large-planets
background gfx: http://opengameart.org/content/space-background
background gfx: http://opengameart.org/content/planets-pack-8
story/intro bgm: http://opengameart.org/content/history
victory/credits/outro bgm: http://opengameart.org/content/xeon-theme-remastered
happy bgm: http://opengameart.org/content/techno-geek
intense bgm: http://opengameart.org/content/space-music
tension bgm: http://opengameart.org/content/gi-i-dark-ambient-techno
danger bgm: http://opengameart.org/content/gloomy-musictechnoambient
stressless bgm: http://opengameart.org/content/the-core
arcade bgm: http://opengameart.org/content/attack
melancoly bgm: http://opengameart.org/content/through-space
desolate bgm: http://opengameart.org/content/tragic-ambient-main-menu
ship: http://opengameart.org/content/spaceship-360
Guess I just made an Asteroids DIY pack ;)
With other backdrops and ships you could make a shoot'em'up.
Contact: Tactical Squad RTS as reported on Free Gamer has some nice models which are BY-SA according to their (otherwise empty) project homepage - a release can be found here.
The zipfile contains a "zipfile" called Contactb002.sd7 - models are in native Spring-RTS s3o format - research shows that there is a blender import/export plugin. Converting and uploading some of the models to say .obj and .blender would be nice. I think they may be useful for some projects, among others they've got weapons (G36 par example), (space-)marines, a Tank, a Spaceship - but that's just what I've seen from screenshots.
In general the Spring community has a lot and a wide range of nice assets as it seems (some of them proprietary IP though).
[edit: somehow formatting gone wrong]
Yes, adding semantic information is a daunting task - I tried to test-write metadata for my street-tileset and just like http://www.frogatto.com/?p=290#more-290 suggests: It is an data explosion even for small tilesets - getting worse the larger the set gets. That's why we need standards and tools.
We aren't talking about artists on OGA writing metadata for submissions by default. Maybe Feedback is the wrong place - could be under "Programming - Procedural Content Generation".
Nobody forces an artist to do write down metadata (at least not my intention...yet ;) - it can be retrofitted by caring developers or using simple tools. BUT to create metadata a developer may need the original artist's help. Because the artist knows his tileset better (metadata == canned knowledge). Speaking for myself: Sometimes I can't discern head and tail on a complex tileset. Which ones are supposed to be adjacent? Which one is in which layer? Which one is an alternative to which other? How do I build walls and corners? ...
But I don't want to talk about yes or no, I'd like to talk about where to go. It's actually quite curious to think about it that there is no adopted standard for anything like this after so many years of tile-graphics. I'm sure it was done several times in proprietary game-map-editors and even open projects but general purpose open map-editors and formats are still where they where decades (+flashy gui) ago. Just think about what we got format-wise: tga, jpeg, gif, png,..., mp3, ogg, ..., avi, divx,..., obj, VRML, X3D, ..., XML, HTML, RSS, OWL ..., and not a single standard format for Map-editing and tiles? Don't even mention metadata. Search the internet and you will find this very forum page. Maybe now - that tile graphics are mature and with a need and the means for collaboration - it's the right time.
Assuming there would be a standard metaformat then mapeditors like Tiled could support creating portable metadata through clicking here and there to link tiles and assign tags. And then a mapeditor may suggest you which tile to place where and speed up mapediting in a smart way. Or it may autoplace some patches. And one task at hand is automatic/procedural map generation which relies on metadata either hardcoded-throw-away (nay) or metafile-based (yay). And finally new game projects may rely on standards and standard libraries to ease efforts.
This is a huge effort but to those interested: Start it by collecting data and building a hub right here!
[\political campaign]
Just found this meta-data-related info: http://www.frogatto.com/?p=290#more-290
It is about Frogatto's way to use multi-tile-patterns (MTP) - ie. building a larger tile out out of smaller 'tilelets' (with random variation). Noteable is that images may be doubled/replaced by others (with random chance).
I think this model of your's (and especially it's animation) is noteworthy good too:
http://sourceforge.net/apps/phpbb/eightk/viewtopic.php?f=4&t=52
I can imagine a lot of games could make good use of your models, too, if you add walk/run animations.
It's going to be featured in Linwarrior. I just got it converted and integrated it. We'll be talking more about that later.
Wow, quite fast shooting. I've got to install a newer browser...
You mentioned "Skeleton interpolation between keyframes." on your todo list - I just wanted to point out that you may have a look at nlerp (normalised linear interpolation) instead of slerp (spherical linear interpolation). nlerp is a simple and a sufficient approximation when there are not-too-big-differences between q and q'.
I'd vote for JSON, too (+human readable, +wide support, +convertable to XML, ...).
Let's start finding attributes for image (sprites/tiles) objects:
Image:
Using standard tags would make tilesets interoperable but they could be translated somehow, too. An Image id can be replaced by adding a unique tag to the tag list. east/west/north/south may change when using, say hex tiles: north, northwest, west, southwest, southeast, east, northeast.
For animation I would assume individual animation objects which reuse images.
Animation:
To animations attributes may be added for side effects (display text, invoke function, start sound) which may be game specific. Frames may be objects again containing the metadata for a frame (static offset and hotbox of the Image could be overridden).
Frame:
Of course not all attributes are always required but specifying more increases reusability.
[Edited 2011 01 04: added Image.file, Image.scissorbox,described 2d box]
[Edited 2011 01 11: left, right, etc tags renamed to west, east, etc]
Some more considerations regarding size, bandwidth and loading performance:
I've got a rather small model 476 Faces, 296 Vertices, 25 Bones, the binary MisfitModel 3d file is 58KB and the ascii md5mesh is 44KB only. If you compress them into zip files that ratio is even larger 18KB to 11KB. That's because modellers dump down whole state structures - binary game related formats may be smaller. But there is the tendency to save only what's needed in ascii and write down whole structs with binary. And with ascii you can control filesize by controlling precission of numbers (digits) - that would get you a size/quality tradeoff.
Of course there is a difference in loading performance (and overhead for writing a compatible robust parser) but as for the impact: Loading will virtually always consume fixed x% of your processing power the only question is what models your system can handle.
With the right datastructures loading scales linearly. I fully agree to Pompei2: Loading isn't the bottleneck, except if you needed thousands of models but then you'd probably stream the data anyway. And if bandwidth is a problem then compression may help.
http://www.atmind.nl/blender/mystery_ot_blend.html points out: Blender is a moving target and only dumps internal structures down - internal structures change => format changes. Yes, it's better to write an export plugin for blender and maybe blender supports (or eventually will) support commandline converts. And it's probably even easier and faster to 'buy' than to make.
Tartos, if you use http://jsfromhell.com/classes/binary-parser then I'm sure ascii is on par with binary for java/js because that code *parses* IEEE floats 32 bit, *bitwise*.
Just to make black and white things a bit more gray ;)
md5mesh and md5anim are quite "nice" text based and proven file formats. There are Exporters for Blender <2.5 and >=2.5, for MisfitModel 3D (Milkshape-but-open, a GPLed exporter plugin is part of the LinWarrior3d distribution ;) and other modellers. There are serval libraries for loading and a lot of websites describing that format.
There is another similar and derived extensible format IQM (little-endian binary) and IQE (ascii). I prefer formats readable with a candle and a magnifying glass ;) for long-term-source-persistence. IQE can be used as a kind of source to be compiled to IQM. There are several open fps games supporting IQM/IQE but only Blender supports export - export only so far. No libraries so far but there is public domain sample code in the SDK. A drawback is that the sdk does not contain a IQE sample model - only IQM - kind of counter intuitive given that the sdk contains the IQE to IQM compiler.
That's what I found out when I was searching for a suitable fileformat.
Pages