User Guide as PDF

I am sorry if there is already a post about this, I checked and couldn't find any.



Anyway, I was looking at the link that says you can download the users guide as a PDF and the only chapter available was chapter 1, it was really well done and I am wondering if there are more user guides like this or if they guy who made that one is working on making more.

I think that was a one man show, and he only got that far. It was a while ago, so I may be wrong.

Well you could always check out either of these four and maybe work something out without too much hassle anyways. We tried a MediaWiki pdf export with the Radakan project, seemed to work great.

I think that was a one man show, and he only got that far. It was a while ago, so I may be wrong.


Yeah, looks like it was made by Tomas Lazaro. Anyone recognize that name? Says it was written in july 2008, so not that long ago, to bad there aren't more.

Hi, once upon a time I made that pdf. It was a complete copy & paste pain, I did all by hand, including a lot of editing in the latex files to build the pdf. As Sadr suggest a wiki export tool should be a better for many reasons:



1.Build the whole documentation

2.Easily runnable (no copy & paste hell)

3.Easily updatable (imagine copying & pasting the whole wiki once a month by hand…)



As a last resort a web crawler could be made to go through the wiki an generate a pdf or maybe a latex file so it could be improved by hand (I've done some web-crawling with java to download manga from manga reading only sites).

Ok, back again, not spamming.



I think this issue is really important. It has surely been discussed before but jme needs proper documentation in a uniform manner. A book one could read cover to back to know how to use jme. Beggining jme is really hard, everyone who is new gets lost from the start, just installing and running is complicated. And after you have everything setup, you read the flagrush turorial and then you realize you have no idea on how to use jme and can't make even the most stupid game and don't even know what you are supposed to know so you can't see a clear path to follow to learn.



I will say it again: we need a book one could read cover to back to know how to use jme.



We should first make sure we can make an automatic build based on some documentation everyone can contribute, like the wiki. If that doesn't work we have to plan something else asap and seriously begin planning the book. Some time ago I read that someone was writing a book, anyone knows about that?

I agree. There needs to be a way to teach about jME whether it is an only book or an actual book on Amazon.com. The tutorials are helpful, but I think there needs to be a resource that teaches about why jME is different from other engines, about the core of jME, about what can be done with jME, and so on.

Treebranch said:

I agree. There needs to be a way to teach about jME whether it is an only book or an actual book on Amazon.com. The tutorials are helpful, but I think there needs to be a resource that teaches about why jME is different from other engines, about the core of jME, about what can be done with jME, and so on.

If you want to know how the jME core is designed and why, then read David Eberly's book 3D Game Engine Design.
Beggining jme is really hard


That which does not kill us, makes us stronger...  ;)

Could someone please give a real answer?



I say "Learning JME is hard" you say "have fun figuring it out".



There's been a lot of talking about making jme to be considered a serious engine but when people ask for proper documentation no one steps forward and says "yup, we need documentation", all we get are excuses.



I'm not dumb, I learned how to code on my own by reading books. I usually read 1 o 2 technical books a month, sometimes more, I have even finished 700+ pages books in a weekend. Last week I read the new Scala book in 4 days. I'm not bragging, surely most of you study even more than me or has read more books than I. Also just reading books doesn't automatically make me good at writing software and you are most likely better at it than me. What I want your to understand is the way I like to approach new stuff I want to learn.



A book is didactic, a bunch of tutorials scattered trough the web, outdated, incomplete, short, not covering enough and many times not showing the best way to do things are definitely not didactic. Having a concise and self-contained text explaining everything in a uniform manner, covering all areas that should be covered, laying the information so that the necessary information the reader needs has already been exposed makes learning new stuff really smooth and rewarding.



I'm also saying that when there no centralized documentation the learning process is many times slower. Just making one crappy example to work might take you hours and perhaps all you needed to know was some stupid fact to make it work and it's wasted effort that could be avoided with proper guidance.



I volunteer to help making the documentation, I'm willing to really help but I can't pull it off on my own because I'm not good enough with jme. If anyone actually understands this issue and wants to starting working on solving it let's do it. Lets make a proper plan, form a group and do it, for real, once and for all. I'm in.

wow!



didn't mean to offend, I guess I should have thought twice before posting.  Having said that, you are right, it would be MUCH better for beginners (and the not so newbish) to have better documentation.  I can offer a little bit of effort, but time wise Im pretty tapped out as of late…

@Tomygun I would like to help in compiling some sort of book or guide for jME. I think it is an exciting resource that more people would like to use if it was easier to learn. I think there is a lot that can we done with this tool. However, I, like you, am not very proficient with jME yet. I plan to learn as much as I can about jME, but I would like to make it so people don't have to struggle with it like me.


If you want to know how the jME core is designed and why, then read David Eberly's book 3D Game Engine Design.


I am glad you said that because I asked for that book as a Christmas present. I also asked for "Killer Game Programming in Java" by O'reilly press.

As with many other open source projects, documentation is scarce… Most of the time the developers of the project spend working on the code, rather than providing documentation, as time is limited and a compromise has to be made between more code or more docs.

Consider that many people in the community do not believe they are capable of producing such documentation, especially if they lack understanding of certain things they believe they are not yet fit to do it. When I just joined jME, I've been doing my own share of edits to the User's Guide and other parts of the wiki and I've often felt this way.

I hope you all came to the realization now that since the original devs are no longer here, tasks such as improving the docs are left to the common user.

A book for jME might be an overkill though, as to produce one might cost more than the profit you would make from it…

A book for jME might be an overkill though, as to produce one might cost more than the profit you would make from it..


Very True.

However, I think this community could do a better job of providing documentation. I think a more complete collection of definitions, explanations, tutorials and examples (in an organized fashion) is very attainable.

I meant "book" as a way of organizing stuff not as an actual production paper book. The User's Guide is split into chapters and if it were more complete it would be "bookish" enough I guess. A key factor is a pdf version and not having to browse the web. What about wiki to pdf tools?



As I see it the documentation process is really important exactly to allow for more development to be done. It's an investment, if we all focus on making really good docs, in some time many capable developers should be ready to help increasing the work rate in the long run. I know I would.

For Radakan’s wiki I found a one-button-make-me-pdf extension (test output), though jME uses DokuWiki so for it different extensions are available:

http://www.dokuwiki.org/plugin:dokutexit

http://www.dokuwiki.org/plugin:pdfdownload

http://www.dokuwiki.org/plugin:pdfex



Unfortunately those only seem to operate on a single page rather than the entire wiki so you can’t get a “readable book” kind of thing.

I will explore the idea I suggested earlier to do the web crawler and parse the HTML by hand, or I could make it chose "Edit this Page" and work on plain text and try to emulate how the wiki understands it. It could work remotely or if run from the server itself it should save the bandwidth and the download time. Also we could schedule automatic builds to always have an updated pdf in case the user's guide is improved. I will get to it…

I'm back. I've been working on the web crawler yesterday (and you all thought I was bluffing :P).



I'm writing the code in Scala, it compiles to a .class and it deploys to a jar so it's java for what matters, I used Scala because of it's great Parsing library and language magic that makes it really simple to solve this. What it currently does is load a page from the wiki en goes into "Show Page Source" (it's done in a single step, not two). Then it takes only the raw input the users add to the wiki, the Doku Script. I already figured, Headings, Links, Code tags, Lists and Enums (but not nested lists or enum yet). It parses that and generates a list of DokuElems that I later convert to pdf using the iText library. It no ready yet as I have to support all the synatx listed on http://www.dokuwiki.org/syntax but I don't think it would take me much more time.



After that I'll work on improving the output to make a better looking PDF but it will serve the purpose even if it's not that pretty yet.

Well well, I will give you all a little preview because it's looking pretty good. this is just the User's guide Table of contents, Foreword and Getting Started. Links were parsed but when converted to pdf I only marked them as plain blue text.



Now I will start writing support for images.


Mark did a very nice job of explaining the classpath, something which is probably the #1 newbie problem.  Although I don't think you need to include each jar file explicitly, rather just the directory; and it makes it seem more more daunting…



Having said that, maybe we should edit it and link/include it in all 'setup' tutorials. 



And other than a little formatting problems (could be problems here) with the tabs, it looks pretty nice TomyGun :).