Keeping the forum manageable

OK, that's my insight so far:


  • An FAQ would be helpful, when up to date. The existing one in the wiki already answers a bunch of faq, I'll update it with the four questions I have com up with. I already changed the layout to be more readable. Of course, that'll only do any good if new users even find the wiki. Maybe the link should be bigger, or something?

  • some kind of wiki<->forum interoperability would be nice, but would require some changes (anything from moderate to drastic) in the site.

  • Threads asking a question already answered could be answered with a link to the faq, nd closed/moved to an archive subforum

  • A wiki section for "more advanced tutorials"

  • My suggestion: an even easier "getting started guide" than we have now, with links to related topics on http://euclideanspace.com/ or similar sites. If nothing unexpected happens, I can contribute that before next week's end.


Anything missing?

On a side note: the faq lists two steps to start with jme as follows


3) Go through the eight short beginner tutorials in the folder jmephysics/tutorial/ of your installation.
4) Next, go through the Hello World tutorials (learning_jme) for more advanced features.

Wouldn't jmephysics be a requirement for 3)? Why is that in the basic steps, and even before the jME tutorials? Would anybody object to move that to another topic, specifically "Getting started with jmephysics"?

that's in error, I suppose - should be flag rush, probably

Like stated earlier, I could create a tutorial on the questions stated in the first post. I'm going to throw out my physics anyways, so I just have to copy my own code.

Structured and organized information has more value. As programmers using an Object Oriented language everyone here should agree to that.



So maybe the tutorials should be organized in some way from beginner to advanced. And have prerequisite tutorials section. Then:

  1. Tutorials can be read in sequence, preventing people from jumping ahead and asking questions they would have found out just by doing some tutorials.
  2. If they do jump they would know prerequisite tutorials they need to complete if they have problems understanding something.
  3. If someone is asking about a particular tutorial you could assume they are required to know all the previous tutorials and give an answer based on that level of understanding, instead of having to guess how much that person know about the engine already.

Just wanted to say that I really appreciate everything you are doing here, jME is zero without the community. Let us know if you need something specific from the devs to take these things forward…

MrCoder said:

Just wanted to say that I really appreciate everything you are doing here, jME is zero without the community.

Good to hear that, thank you! :) We'll definitely need some devs to look over any tutorials, to check if they are doing things the best possible way.

lex said:

Structured and organized information has more value.

Word :)

SeySayux said:

Like stated earlier, I could create a tutorial on the questions stated in the first post. I'm going to throw out my physics anyways, so I just have to copy my own code.

Just go ahead! I think I'll make my own anyway, because I think your's will probably be rather practically oriented, and I'd like to have some very basic concepts explained in the first tutorial. So I'll build mine more around the question "what concepts should newbies know to wrap their head around opengl 3d simulation", rather than "how do I build a game with this" (which your "copy my own code" approach seems to imply).
hevee said:

SeySayux said:

Like stated earlier, I could create a tutorial on the questions stated in the first post. I'm going to throw out my physics anyways, so I just have to copy my own code.

Just go ahead! I think I'll make my own anyway, because I think your's will probably be rather practically oriented, and I'd like to have some very basic concepts explained in the first tutorial. So I'll build mine more around the question "what concepts should newbies know to wrap their head around opengl 3d simulation", rather than "how do I build a game with this" (which your "copy my own code" approach seems to imply).


Out of my own experience, what newbies want are mostly explained examples. That's why I'd stop using java 3d : you had to know how the tiniest openGL packet was built. People aren't interested in this nerd talk (well... I am interested in it....). The common newbie wants to have stuff being done as easy as possible, without having to learn complex programming languages or know in detail how the tiniest piece of openGL works. They want clear, easy code.
BTW, what do you think that are the most common 3d games? FPS'es, RTS'es and RPG's (and their MMO equivalents). They all need a basic gravity algorithm, but none of them requires really accurate physics simulation (yes indeed, they could use it, but it's not required, you basically need for a simple game only gravity, right?). That's why I'm going to write the tutorial. But I'll only able to post it in some months (my health isn't very good at the moment, so I can't code -- I am really too tired to code, it's already two weeks like that).

I thought about another suggestion, just few moments ago. It would be really helpfull to add a Troubleshuting section, similar to the FAQ, that explains how to resolve tipical problems with jME. It is not easy to maintain because there are a lot of tipical problems that a coder can meet or errors he can do. But i think that can help to quickly find solutions when things do not go as expected. While the FAQ is more similar to an "How to do?", a Troubleshuting list could be more similar to a "What I did wrong?".

@Ender:  That's a good idea.

I've actually written an interactive knowledgebase that I'm trying to get approval to open-source.  If i do this might be an ideal solution for what what you're suggesting.  It allows searchability and hierarchical browsing and if you get to the end without finding a solution you can enter further details of your question and it sends it to an admin to resolve the issue and they'll get an e-mail when the question has been answered.  This is much nicer than a forum because the same questions don't get asked over and over…they get asked and answered once.

Regarding this… I would like to see threads in troubleshooting to be marked as [Solved] whenever they are… er… solved.



It is very confusing to go troubleshooting hunting a 10 page thread just to find that the actual answer was posted in page 2.  :expressionless:

darkfrog said:

I've actually written an interactive knowledgebase that I'm trying to get approval to open-source.  If i do this might be an ideal solution for what what you're suggesting.  It allows searchability and hierarchical browsing and if you get to the end without finding a solution you can enter further details of your question and it sends it to an admin to resolve the issue and they'll get an e-mail when the question has been answered.  This is much nicer than a forum because the same questions don't get asked over and over...they get asked and answered once.


Sorry if I insist ;) But I think it'd be better to use a KB plugin for dokuwiki or SMF. I know dedicated tools are better (including yours DF, I'm sure :) ), but integration IS a problem. Think about it: there's already a wiki, a forum and a CMS, three different tools with 3 databases (including users...) and lots of redundant info. Now put yourself in a newb's shoes (or even a casual user): where do you find the info? Sure, if you start lurking, you see that the forum is the place to go (for now), except for a few tutorials on the wiki and some screenshots on the CMS. Now add a couple more "dedicated" tools, good at what they do but not integrated with the rest... They don't get used, simple :)

That's the reason why I proposed earlier to merge the wiki and the forum. There's a wiki plugin for SMF, and some discussion plugins for dokuwiki. I tried both, they do their job. Sure, not as much features than today with both a wiki and a forum, but at the same location. One place to look, one paradigm, one syntax, one search engine, one login... And you can add other plugins, for FAQ, KB, dev tasks, etc.

If you don't wan't to merge, at least use a bridge (if it exists).

And it's not just for newbies. Some of us (that is, me, at least ;) ) believe that good integration make up for less features ;)