The next great Mac Game Development Book

Founder
Posts: 1,138
Joined: 2002.04
Post: #46
PowerMacX Wrote:Anyone knows what finally happened to the postmortems? Last thing I heard a proofreader was hired to check them, but that was months ago. I don't think a book could be made just out of them, but a few could probably be used to complement one, or simply to complement/exemplify tutorials.
See the thread here:
http://www.idevgames.com/forum/showthread.php?p=127968

Carlos A. Camacho,
Founder
iDevGames
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #47
Carlos! You're alive!!!

OneSadCookie Wrote:Sure, but there are two questions there -- one, the amount of time you spent learning about skeletal animation (which can usefully be taught in general terms in a book), and two, the amount of time you spent fighting with Maya, your own format, and the actual conversion process (which can't usefully be taught in a book, because the information both about Maya and about your own format is far too specialized).
Okay, fair enough. You have a point in there somewhere, even if it's a bit vague.

I'm still not sure why you seem to be campaigning against the idea of sharing techniques, even if they are somewhat specialized. It's not like we have many (any?) standards when it comes to content pipelines. But whatever... Whatever I've done myself is certainly not very special. And like you said earlier, it ain't rocket science. Figure it out for yourself I guess...

igame3 Wrote:Didn't Brian Greenstone cover that in his book specifically?
No. He did not cover skeletal animation at all, whatsoever, in any way. I was pretty disappointed about that subtle omission. What he covered was getting basic mesh geometry out of Maya by writing a plug-in for it using Maya API. Maya API is *horrible*. It is an excellent example of how NOT to use C++. I had successfully developed a few small plug-ins myself using his book as the starting point, only to discover later how much nicer MEL was (Maya's scripting language).

To my knowledge, there are no skeletal animation tutorials of any kind for game programming on the Mac, let alone MEL scripting for game programming on the Mac. I would guess that if there is any info in that direction to be found at all, it'd probably be found somewhere in the Unity community, but I haven't visited there in a while. If there is any readily available info now, it certainly didn't show up on Google back when I was learning it.Rasp
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #48
I'm not arguing against sharing the knowledge, just that the m*n possibilities for source and destination formats don't lend themselves to a book. If you're not interested in the particular combination under discussion, the content's not useful to you. The chance that any particular person is interested in any particular combination is slim.

So, documentation on individual formats is useful (and there's plenty of good stuff out there on the internet), but "tutorials" on specific format conversion issues are of seriously limited usefulness.

Also, these topics are not Mac-specific in any sense. Sure, any given tutorial for the PC might use Direct3D rather than OpenGL and therefore have slightly less relevance, but in most cases that's the least relevant part of the material.

There is the issue of how to make this stuff accessible to "newbies", who lack the experience or knowledge to read the documentation and make stuff go, but I think that's a separate issue, and one much better solved with libraries and tools than with a lot of words.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #49
OneSadCookie Wrote:I'm not arguing against sharing the knowledge, just that the m*n possibilities for source and destination formats don't lend themselves to a book. If you're not interested in the particular combination under discussion, the content's not useful to you. The chance that any particular person is interested in any particular combination is slim.
By that logic then, it shouldn't matter that...

Quote:So, documentation on individual formats is useful (and there's plenty of good stuff out there on the internet), but "tutorials" on specific format conversion issues are of seriously limited usefulness.
... they are almost always about formats for Windows ...

Quote:Also, these topics are not Mac-specific in any sense. Sure, any given tutorial for the PC might use Direct3D rather than OpenGL and therefore have slightly less relevance, but in most cases that's the least relevant part of the material.
... and that I can't really relate to them in any significant way like the folks on the intended platform do.

Quote:There is the issue of how to make this stuff accessible to "newbies", who lack the experience or knowledge to read the documentation and make stuff go, but I think that's a separate issue, and one much better solved with libraries and tools than with a lot of words.
hmph...Annoyed
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #50
I'm afraid I really don't know what you're getting at any more.

To write format conversion code
1) understand the problem domain
2) read documentation for format(s)
3) write conversion code

Tutorials on 1) (eg. the principles of skeletal animation) are useful. 2) is already documentation, and if you can't do 3) then either the documentation in 2) was useless, or you need some more programming experience.

If it's the case that you simply need more programming experience, then I agree, you shouldn't be prohibited from doing the conversion, but the chance that there is a tutorial for the specific two formats you've chosen is slim, and the chance that you could follow it if there was is slim. Much better to have a third-party library which loads a (possibly different) destination format, and a tool which converts from the source format to that destination format.

The scope of writing tutorials which cover conversion between all possible format pairs is m*n; the scope of writing libraries and tools is m -- it's a much more rewarding and worthwhile endeavor.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #51
OneSadCookie Wrote:I'm afraid I really don't know what you're getting at any more.
Cute. It's plainly obvious that you and I exist on two completely different planes of exsistence -- yours wrong and mine right Rasp

To write format conversion code:
1) understand the problem domain: I need to get this stuff from here to there
2a) read documentation for format... Oh yeah, I'm on a Mac, they didn't target documentation for this format, never mind...
2b) figure it out
2c) come up with plan to improvise
3) write conversion code

... and (according to you):

4) don't share, because anyone working in this problem space will already know how to solve it on their own or they shouldn't have been programming here to begin with

m*n what?

The question is, what are *you* getting at?
Quote this message in a reply
Member
Posts: 715
Joined: 2003.04
Post: #52
Not to piss on your fire guys, but this month's Game Developer
magazines goes into some detail about Collada. Just thought I'd let you know.

wizzzzzz....pssssss
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #53
File formats are platform-independent, and documentation on them is therefore platform-independent. I don't know what you're trying to hint at there.

I also don't read tutorials and go "oh look, they're using glDrawElements rather than display lists, *that* must be the crucial decision here" just as I don't go "oh look, they're using Direct3D, *that* must be the only way to do this".

In less than a year, OpenGL as we know it will fade from existence, to be replaced by the new "Mount Evans" API... are you going to completely dismiss all tutorials written against the current OpenGL API when that happens?

There are concepts, and there are details. I believe that tutorials need to focus on the concepts, and only give enough details to be understood by the target audience. The more details the tutorial includes, the less its long-term relevance, and the more distracted it becomes from the crucial point, of actually improving the reader's understanding, rather than their superficial knowledge.

And I certainly didn't say "don't share", I just don't see the point in writing a lot of words writing out a tutorial on how to do your particular conversion when all of 3 people will ever care about that exact combination again.

m reasonable source formats times n reasonable destination formats. That's how many conversion tutorials need to be written.

If you have a library which loads a particular destination format, then you need m (reasonable source formats) tools to do the conversion.
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #54
OneSadCookie Wrote:m reasonable source formats times n reasonable destination formats. That's how many conversion tutorials need to be written.

Well, I would pick "example" formats to show a real-world implementation of say, static formats (a basic implementation of an .obj loader, for instance), keyframe-based formats (something simple, like md2) and skeleton-based animation formats. Just because the specific format chosen on the book may not match the one you want to use doesn't mean it couldn't be useful, at least in the sense of helping visualize what is involved.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #55
OneSadCookie Wrote:File formats are platform-independent, and documentation on them is therefore platform-independent. I don't know what you're trying to hint at there.
I am trying to say (not hint) that articles, documentation, tutorials, or whatever, are hardly *ever* written with the Mac in mind. Sure, file formats are generally platform-independent in nature, but that is completely side-stepping away from the discussion, which is to help make it easier for Mac programmers to comprehend how to implement those formats on the Mac. And beyond that, I'm not even talking about file formats specifically, but rather to also include a tutorial or two about scripting languages within environments, such as Maya, to be able to export scene data to arbitrary, possibly custom, formats before it even hits the disk. Sure, you could simply teach Python or MEL (both used in Maya) as languages and say, "there you go, now get the data you need", but wouldn't it also be helpful to include some examples of how to traverse the scene graph? You seem to be suggesting not, and I am suggesting that even though those examples might not specifically yield the exact format you're looking for, there would likely be information that you could use to extrapolate from to create the format your looking for. So, I simply disagree with you on your point that one would have to write m*n tutorials or whatever. Like what PowerMacX said, what would be wrong with a few representative examples? You seem to be insisting that you have to do all variations or none at all.

I also disagree with you on concepts versus details in tutorials. I would rather tutorials focus on details, even if they are not the exact details that I'm looking for, rather than broad, long-standing concepts for all of eternity to witness. For a given problem, I might even drop my current approach in favor of the detailed approach given in a tutorial, simply because it offered a workable standing solution.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Game Development in a Post-Agile World SethWillits 7 6,308 Feb 10, 2010 01:06 PM
Last Post: cmiller
  iPhone Game Development--New from O'Reilly Carlos Camacho 1 3,804 Jan 16, 2010 11:54 AM
Last Post: kgutteridge
  Why Extreme Programming is Great for Game Development SethWillits 6 5,343 Mar 3, 2007 12:04 AM
Last Post: Fenris
  Great math book Duane 1 2,627 Feb 20, 2007 06:22 AM
Last Post: unknown
  Macbook Pro game development performance (GLSL/OpenGL) ravuya 9 5,283 Jun 6, 2006 06:42 AM
Last Post: ravuya