I have been looking through the documentation and FAQs, and I am having trouble finding hard numbers. It would be very handy for me, and I suspect handy for others as well, to have a "bible" that listed basic Coldstone statistics, to wit;

Size of graphics, particularly size of sprites. What are the maximum limits? What are the averages?

Formats, in a little more detail; will the Coldstone implementation of QuickTime handle MIDI events? What is the bit depth supported in the AIFF files? Would Coldstone run properly if all PICTS were held to 16-bit (aka thousand-color)?

How many NPCs, how many tiles, how many items, etc., etc., can the game support. Which is to say, the kinds of data given in the original, un-annotated EV Bible.

And, although it may not fit in the above, I would personally love to see some rules of thumb on length/frame rate of average walk cycle and attack animation. I hate to re-invent the wheel trying different framings, and it seems a little untidy to download every sample I can to reverse-engineer those ranges.

------------------
everywhere else, it's --
"Nomuse"

Most of these matters are pretty flexible, but I agree that more info would be nice.

Quote

Originally posted by Commander Arashi:
Size of graphics, particularly size of sprites. What are the maximum limits? What are the averages?

Limited only by memory and processing power available so far as I know. Average? Whatever works for your game - if you want tons of sprites onscreen simultaneously, they'd better be small for speed, but you could also use really big ones if you only planned to have a few around at a time.

Quote

Formats, in a little more detail; will the Coldstone implementation of QuickTime handle MIDI events? What is the bit depth supported in the AIFF files? Would Coldstone run properly if all PICTS were held to 16-bit (aka thousand-color)?

Good questions. I'd like to see these answered myself.

Quote

How many NPCs, how many tiles, how many items, etc., etc., can the game support. Which is to say, the kinds of data given in the original, un-annotated EV Bible.

Again, as far as I know, memory and processor are your only real limitations here. Coldstone is file-based rather than resource-based as EV, so there are generally not the same sort of hard-coded numerical limits on this sort of thing.

Quote

And, although it may not fit in the above, I would personally love to see some rules of thumb on length/frame rate of average walk cycle and attack animation. I hate to re-invent the wheel trying different framings, and it seems a little untidy to download every sample I can to reverse-engineer those ranges.

Sorry to be unhelpful, but again, that's really 100% up to you. I don't think there really is any generalized rule of thumb - there's just so many variables. Larger sprites or ones with more drastic motion (swinging a claymore as opposed to firing a pistol) would likely require a higher frame rate to look as nice as smaller, simpler animations at a lower rate, slow-moving characters will be more easily observed, and so might require a higher frame rate than would a character which is nearly a blur due to its speed, et cetera et cetera.

------------------
"A scientist can discover a new star, but he cannot make one. He would have to ask an engineer to do it for him."

It seems to me that a lot of these things are matters opinion. The answer to sizes and frame rates is just whatever looks good.

As for graphic types supported, it might be nice to see a detailed list (although there is some stuff about it in the appendix near the end of the manual). The other way to learn a lot of these is just to try it (and make sure it works in the final compiled game, and not just in Coldstone).

-Jeff

------------------
Experiences = Integrate( Life, {t, birth, death} )

Quote

Originally posted by Paploo:
**It seems to me that a lot of these things are matters opinion. The answer to sizes and frame rates is just whatever looks good.

As for graphic types supported, it might be nice to see a detailed list (although there is some stuff about it in the appendix near the end of the manual). The other way to learn a lot of these is just to try it (and make sure it works in the final compiled game, and not just in Coldstone).

-Jeff

**

Thanks, all. I was hoping to avoid part of the trial-and-error...at least, after working all weekend, I got Coldstone to compile the demo game without crashing. I can now tweak the elements and see just what works, what is necessary, etc.

I've answered several of my questions to my own satisfaction. I'm thinking, also, of drawing up a flowchart that shows which files contain which resources and link to which other files; might make it easier to understand the needs of a game.

------------------
everywhere else, it's --
"Nomuse"

I would also like to see sme kind of summary of the hard facts about what the engine does and does not do. There are a lot of invisible mechanics (like how exactly an attack is resolved) and preferences (such as the ideal image format for various picture elements). Trial and error will help us fumble our way through most of this stuff - but I would rather spend the time creatively.

------------------

Quote

Originally posted by Alex Gray:
**I would also like to see sme kind of summary of the hard facts about what the engine does and does not do. There are a lot of invisible mechanics (like how exactly an attack is resolved) and preferences (such as the ideal image format for various picture elements). Trial and error will help us fumble our way through most of this stuff - but I would rather spend the time creatively.

**

Since I posted the above, I learned quite a bit more. Unfortunately, I mostly learned what the questions really were. The little description of file formats given in the manual is at best incomplete. A quick browse through this web board will pull up tens of posts from people attempting to learn which exact file types, alpha channels, compressions, suffixes work. And so far, the answers appear to be unique to each need in Coldstone. i.e.; you have to go through the whole annoying routine of trying files and watching the game crash for each and every resource the game supports. Not fun!

I admit now that rules of thumb would be fun, but hard to establish. Best is to deconstruct the weapon, NPC, monster, tile set that looks like what you want and figure it out from there. If anyone generates some bench-marks, tho, ("Never run a sprite larger than 32x32 on a 601-603 series chip!") those would be apreciated.

And, yes; the invisible mechanics are a pain in the posterior. The manuals and tutorials are far too button-oriented "Press the Import Graphic button to import a graphic" (D'uh!) It would be good to know what general processes the engine is going through when, say, a player hits an NPC with a pointed stick.

I certainly hope we are not seeing the edge of a philosophical divide here. Lately there has been a real rise in software of the "push-button art" type (click-and-build web-sites, drag-and-drop sample music). Perhaps the greater market for Coldstone is the user who take the graphics off the CD, makes a simplistic clone of PoG out of it, and in that small way gains the satisfaction of having created something. For that user, the current manual and tutorials are adequate, the CD complete, and the flaws and bugs in the engine immaterial.

Coldstone can be used by an intermediate designer as well, though. It can be used to do a decent-looking original game. I do hope that this smaller (but more vocal) group of users are also supported in their efforts -- by improved documentation, by a bug page, by inclusion/repairs in the 1.1 release of certain key functionalities (the ability to use the dialogue picture, the ability to use &&tag; values in coordinate sets.)

------------------
everywhere else, it's --
"Nomuse"

I've been trying to figure out the equations used in the combat system, in case you're still wondering, here's what I got so far.

The manual does explain how hits are determined in the descriptions for Dexterity and Perception. The fact that your accuracy and evasion is dependent on the same attribute pleaseth me not.

As far as armor, is mentions when armor is more effective and less effective, but it doesn't say exactly what it does. So I set the PC at a Dex of 0 and an NPC at a Dex of 1 (this should allow, according to the manual, maximum efficiency of the armor rating)and let the PC get pounded on using various combinations of damage and armor. I came up with a damage reduction table based on what your armor rating is from 0 to 141 (although it's easy to calculate after you know the pattern).

AR 0-1: -0 damage
AR 2-5: -1 dam
AR 6-11: -2 dam
AR 12-15: -3 dam

From here the AR side goes up by six, then four, then six, then four, and so on. Anyway, it's nice to know exactly what armor does. If anyone has anything to add or comes up with something different, lemme know.

myshkyn

------------------
"I'll give the fans just what they want, and nothing else at all."

I would also really appreciate a bible of some type, preferably in print. Using Adobe is all very well and good, but it's so much easier just to be able to pick up a manual and turn to the needed page. Perhaps Ambrosia could publish something like this and then either enclude it in the package with the CD or have it as a seperate purchase item. It would help a whole lot.