   So - what are we doing?
  OK, now that we're starting to get people joining up, it's a great time to discuss what we're actually going to be doing.This is my list of content we should do:- Rewritten lessons, starting at Lesson 1 and working our way up. Possibly with different organisation.- A new SDK (gregs seems to have a start on this one)- Totally new tutorials - probably kind of mini-lessons or things we can have to complement the lessons (llvllatrix is particularly interested in these)If you have any other ideas or anything else to add, please speak up.Additionally, these are "overall" things that I think we should aim for:We want to teach beginners how to be good coders, so:- Correct usage of C++ and its features (such as exceptions and RAII).- Use of STL (we should also discuss the use of boost?)- Particularly std::string (someone on the forum has this signature: "if you're posting in For Beginners and your code has char* in it - you have a bug" - we want to stop teaching beginners bad techniques)- No GLUT - it's very, very outdated.Also, we want to make this easy for ourselves, so:- Integration: Preferably tutorials should build on code from the previous ones - preferably with nice C++ inheritance, but also just expanding on it. Also we should use (and explain) the SDK in the lessons.- Malleability: Make it so we can rapidly change the lessons and such with minimum fuss. In particular - changes (like bug fixes) in one lesson should be easy (preferably automatically) integrated into other lessons (and the SDK). To achieve this, we should probably use some kind of "build" system? Doing things with "magic comments" (Doxygen-style) seems like a possible starting point. But maybe something more flexible is needed? After all - we're writing tutorials, not documenting an API (except for the SDK - Gregs, you recommend a good "magic comments" tool for this - what was it?).Any ideas on how to do this? Do we bother, at least initially? And if not, what system are we going to use to write tutorials (the Wiki? HTML? plain text? Word documents?).Finally - the original NeHe lessons have been translated into many different programming languages and "actual" languages. I'm not really sure how to solve this problem - but maybe you guys have some ideas? Joel's idea of using MediaWiki and just opening it up seems solid (only problem is GameDev.net uses ASP, not PHP).   
  I was just on my way out the door to do some whitewater rafting when I was able to get on gamedev (server was busy for some reason..) - so I dont have a lot of time, but a few quick comments:Thanks for the add to the team!  Good to work with you guys.I like the goals and objectives, especially using proper coding techiques and technologies to begin.Coming up with a build system is a terrific idea, and I think we could expand on this idea some - gamedev has had a few good articles on this we could leverage.Some questions and thoughts:1.  How much will the framework do and how much reliance do we want on it?  The reason being, (as stated earlier) we are not documenting an API, we are teaching game development and we need to decide if the SDK is the nexus of the course or training wheels that once the first chapter is finished can be removed.  I think there are reasons to go either way - having an SDK can hide some ugly details that are difficult to teach in "lesson 1".  However, at some point do you want the tutorials to extend into how the SDK is built and when/how do you do that?2.  Build system/SCCS.  I dont think any book *really* covers this at all and I think we have a great opportunity to shine here.  One of the parts of being "good coders" is how you store your code and maintain it.  This can help *greatly* in our Malleability objective in that we can present the tutorials as a progression of a code project that is maturing.  So instead of downloading a zip file of the code - they would checkout from the trunk for date XX:YY, and work along with lesson.  There are a lot of possibilities here.Build systems are also an under-explained process.  We dont need to have anything super elaborate but if the student can checkout, modify, and then run a build that would smoke.  Even better if at some point they have their own SCCS system that they can check in modifications they make, pin versions, and revert changes that dont work out.I dont think this needs to be in lesson 1 - but introduced once the problems these systems solved.3. Do we have some coding standards established yet?4. Code orginization?  I assume this will be multi-platform and therefore will need to handle gcc/g++, visual studio, codeX (are we doing MAC as well?).  Obviously these systems work differently and so organizing this cleanly will make student code samples easier to work with.5.  Lesson templates/standards - do we want to device a cool template or style for the lessons?  Do we want to have PDF versions for download/printed copies for the student/user?  Since we have some challenges for working with the original lesson's data format, we may want to learn from that and see if there is a way we can abstract the lesson material from the content provider.  I would lean a bit towards PDF since its portable for viewing on windows/unix/mac and it will always display the same way no matter where its at.  It simplifies our "printing version" process since we wont have to format it.  It provides a nice way to download the whole article/lesson.  PDFOnline converts docs to PDF for free - so we can avoid the cost of distiller.Anyhow - just some initial thoughts for discussion.  I gotta get my gear ready and get to the River!  Talk to everyone soon.Dan-0;  I can cover Xcode and other important tools for the Macintosh contingent. Most tools these days (other than MSVS) just use GCC as its compiler, so I don't think we're too differentiated between Xcode/DevC++/LinuxGCC.Again, I think most of the "setup" articles on NeHe are rather up to date (except for the OS X one which probably needs some review).Also, I think that if we were to go portable for our API, a "glue" layer like a thin veneer of SDL would seriously help us here. That's what I do for all of my games, and portability is easy as pie (minus changing some niggling things about shaders when porting to Windows [rolleyes]).   ;  I have to agree with the use of SDL.  It's simple, easy, and has been used in commercial ports, I see no reason not to use it.  Not only will it make the tutorial code cleaner (ie, no long lines of window initialization), it will make the users familiar with using libraries, rather than reinventing the wheel.  If we do add mini-tutorials, we can always make one of those how to create an OpenGL window on X platform for people that really do want to roll their own stuff.   ;  Of all the glue layers to use, I'd sway to SDL anyday. I know Andrew said that we were gonna stick low-level with just Win32 and OpenGL, sans GLUT (thank God)...portability would require some form of API such as SDL. I don't particularly care, just a thought.To clear up the fog in my own brain, what exactly would the SDK entail? Low level stuff (window setup, projection, etc), with it gradually being revealed as the tutorials advance...like moving it out of the SDK and into the base code?About the code being ported to other languages...how did NeHe originally handle this? My guess is people aren't going to exactly flock to update their ported code for the new SDK and tutorials, so would it be possible to just have one person manage updates being sent in and post them? One last thing...how do we plan on updating content? One tutorial at a time? Do fixes to the existing article while we work on a whole new shebang, then release all the new tutorials at once? I know some people are really attatched to the current tutorials, and would probably blow a gasket if they were dropped all the sudden.[Edited by - c-gibson-s on May 22, 2006 11:52:15 AM];  My biggest issue with OpenGL/DirectX tutorials in the past (including NeHe) are that although they teach you to use a technique, they don't really apply them too well in a way that would be readily dropped into a real game. To do so, we should promote modularity and discuss (if anywhere) how these techniques can be applied into a larger overall system.I would especially like to see some real-world use of Shaders (GLSL) in games as this is one area that I don't have a clue about, nor do I have any real idea how I'd put them into a game.Should we also start covering OpenGL ES?   ;  I'd also like to see the return of NeHe's mini-contests again :)   ;Quote:Original post by evolutionalMy biggest issue with OpenGL/DirectX tutorials in the past (including NeHe) are that although they teach you to use a technique, they don't really apply them too well in a way that would be readily dropped into a real game. To do so, we should promote modularity and discuss (if anywhere) how these techniques can be applied into a larger overall system.Thats an interesting point.  Perhaps the "end point" of the lessons is actually a full featured engine with a basic game on top.  Then we could use the lessons as small individual "units", that have an overall idea in mind.  If we provide access to the code via an SCCS system, we could further reinforce some development concepts on how you would build a small piece of functionality, test it, and then integrate it into a larger project.The one pitfall I can think of here is how to keep the lessons informative and digestible while still having value to the overall project.  Usually the way you really want to implement the code is not the most digestible from a learning stand point.How this fits into the SDK piece of the project would also need to be thought through.  Are we extending the SDK in the lessons, or just building on top of it?;  I think using SDL would simplify things alot, it would keep the tutorials focused on whats important..OpenGL. And of course SDL is an amazing API for all kinds of things, we wouldnt need to worry about handling input, thats already done, and for possible future stuff like sound, networking etc. there are extra SDL libraries. (i.e. SDL_net, SDL_mixer)For the writing of the tutorials I think using a development Wiki would be a really good idea, that way if someone writes a tutorial and puts it on the Wiki for a little while (a couple of weeks?) we can all make changes and fixes before going live.Are we going to follow the same tutorial titles as Nehe has now? Or are we going to come up with a new list of tutorials?Should there be a separate set of *Engine* tutorials where the tutorials are integrated and more focus placed on data structures and the building of an engine? Luke.   ;  As others have said, I feel that it would be best if we did completely new lessons.  NeHe in it's current state is great to learn the basics of OpenGL, but when it comes to actual game development it is lacking.  I think the lessons should focus more on OpenGL in a game development sense, than the broad sense.  That way we could have the lessons progress and build upon each other rather than how NeHe is now, where the first 10 or so lessons build upon each other, then it is just a free for all.For example, lesson one could be about window / OpenGL initialization.Lesson two could be about setting up the projection and a simple intro into matrices.Lesson three could then allow the user to render simple shapes to the screen.Lesson four we then go into more detail about some of the matrix math which willpave the way for rotations and translations.Etc.All of this building into a simple SDK that people took lessons to develop, and can then actually use it to develop a game.   