Sure. I guess for non-animated stuff we should just consume one of the standard mesh formats like .obj rather than rolling our own - unless there is any specific features we need? Can't really think of any. Maybe can use a generic format for animated meshes too, would need to investigate.Immortius – you up for writing a Blender general-purpose mesh importer? We could split up the part regarding the (skeletal) animation system.
In the Entity System world, creature definition files are subsumed into general purpose Entity Prefab file - you just define what components should make up a creature, with what settings.Creature definition files (existing item)
The way creatures work at the moment in the ES, there a bunch of generic components all creatures would have (Location, CharacterMovement, Mesh, Health, maybe Inventory, probably some sort of Creature component), plus one or more AI related components. Then you add a system that updates the movement component's driver fields (desired movement direction, jump request), uses items in the inventory, and reacts to events (collision, damage, death) for entities with a specific AI component (or components).Rough creature system foundation - ES relation? ES branch close to live?
Are they in Java or config files? I figure like blocks we should strive to eventually make it possible for players to define their own extremely easily by simply providing a plain text config file (so far usually a Groovy super props file)In the Entity System world, creature definition files are subsumed into general purpose Entity Prefab file - you just define what components should make up a creature, with what settings.
Don't worry to much about that. I, at least, understand, and think you brought up some good points here.Okay, bigger post time!
First a giant disclaimer: I don't know a thing about art or artists
I'm realizing I need to highlight that more as otherwise I'll totally miss stuff and end up making somebody feel bad or something
[Bold mine]I really like both dwarves posted so far, and especially would like to see how the first one would look textured.
Having two of them does bring up a tricky point tho: How do we collaborate and make choices in the artist space?
Quite right. Art re-use seems to me to be much more tricky.This is where my coder nature defeats me. It is easy to collaborate with code, since it is just an implementation of a concept that can be tweaked till you don't even recognize the code, yet it remains the same concept. Immortius did major refactoring to the block manifestation system I started, but I'm thrilled to see that as now it just works even better with more solid code (btw, I suck at code too). That's not so easy with art - re-use is far trickier. Add to that the international nature of the project and the potential for language issues / misunderstandings.
This is were things get complicated. Simply setting a general poly count (or other rather simplistic guides like that) is not going to cut it, yet we definitely need some sort of bigger guiding standard. I don't have much experience in this area either unfortunately (as I generally work by myself), but do have some ideas. First, there should be a "design sheet", some place where all the modeling,texturing, rigging, animation, etc. guidelines/tips/recommendations are. I already did this personally to some extent when I made my dwarf. I set myself a 12x128 texture, I made the model perfectly pixel proportional , etc. Stuff like that would go a long way in "unifying" the look, at least, of stuff. That would not really be enough though probably, at least not if we start getting a lot more than just 3-4 of us artists. The reason for this is that you could still get stuff that fulfills all technical guidelines and still looks "wrong". The only way to remedy this as far as I know is to have some sort of "Art director" or "Art lead" that could kind of "moderate" all the incoming art assets. I don't know how this would exactly work though being an open-source project.So I'm figuring (correct me if I'm wrong) that we need to arrive at a general poly count / level of detail range and other guidelines like that to have the models be fairly similar. And maybe we can use dwarves as the proof of concept example to see how dwarves at different levels of detail would compare with each other? In theory this might be doable even without a more concrete game concept, since the models need to fit nicely with the world, regardless of the theme or flavor to the world.
Yes, you could and that would be a good idea to break up the load. Again though, you are going to get really varying results even if everything is up to the guidelines standards.With guidelines in place then we could actually divvy out specific art issues so at that point we only have one person working per race or other grouping, with feedback from others or outright requests for alternative takes by the author?
Similar models for the same thing? Yes, if they look good together. Having a few different models for each character would be really nice actually. Here, though, I have to point out that I would not consider glasz's and my models to be "similar" in this regard as they both have different design guidelines (not saying that either is better). For instance, his has floating arms, hands, and legless feet. If you saw both of these in a game, at the very least, it would be rather odd looking (at least to me). I think that design differences like this are definitely a concern if we want a game that looks like it has a nice "cohesive world".At the same time, can we actually use multiple similar models for the same thing? Could we have mountain dwarves and plains dwarves, looking differently (like the two examples in this thread) in the same world, without clashing in style? If that would be a concern, I'm not an expert
Yeah, I would have guessed that their poly count wouldn't be a huge concern. As for different texture sets/skins, that is a great way to introduce some nice, simple variety.Begla indicated on IRC that the poly count for either model here should be well below any point where the game would have any sort of trouble rending a pile of them running around. So that's great. I'm figuring it isn't a big issue either to have multiple variety texture sets? Almost as in DF where different professions = different looks
Those interesting I guess...