To start, here's Louren's rough topic list (expanded with some stuff from the old discussion on it), it's not neccessarily where things will end up, but it's somewhere to start a new discussion . To go with this, we should come up with a structure/outline for the wiki. So, content, structure and presentation: Topics Basics: - a programming language - how to program - how to design programs - how to manage a project for a bit (version control maybe, working together, organising your work) General stuff: - Algorithms and datastructures - Threading and synchronisation - Files and I/O - Networking principles? - Scripting? - Performance/timing analysis? Maths: - Linear algebra - Some logic - Numerical computing (representation issues, etc.) - Modeling/Simulations - Other math (as relevant) Games-specific stuff: - AI - Graphics (2D?/3D) - Audio - Networking in games Tools? - 3rd party libraries - Image manipulation, Animation, etc. Structure & Outline Overall: - ToC - Intro - ? - ? - ? - Contests? - Index - Appendices Intro: - Nature of design - Nature of programming - Nature of games - etc. Specific Topic: - Intro - Demos (executables, not source) - Discussion of topic. - Platform/environment/tools specific stuff - Questions/problems/exercises + solutions & discussion? - Links to existing (more in-depth) articles? Presentation Um... We wanna pwetty wiki! . I guess there's not much to say about this here . Also, do we want most bits of code to be able to fit together nicely? So they write a simulator in the simulation section and they can expect that it won't be incompatible with the 3d renderer they wrote in the 3d section.

As much as its quite hard to learn, I think we decided C++ was the best option, because 'everyone wants to learn it'.

---

I have no idea what I am talking about

My 2 cents, scripting should definitely be in... start from Lua as that's the one that most people use. XML should be in too... it's gaining ground fast. Also something about debugging and profiling in run-time should be in there. Log files, custom asserts, etc. The earlier you learn how to do it, the better.

---

It would be amazing if you make thing like this. It would be very interesting to read But i am afraid im not much help when it comes to making it..

Okay, here are some thoughts about the presentation and structure. I think we have a pretty good overview of what we want to teach people in the list above. The question is how to present it, and in what order. One of the things that was posted here recently was something along the lines of "Okay, I'm doing all this stuff with variables and expressions, but how does that relate to making a game? I want to make a game!" I think that that is an important thing to consider. Going through a tutorial that teaches you about the various concepts of the C++ language is nice, but you still won't have any idea how to use them, when to use them, or what to use them for. Something else that's obvious is that types are hard to understand. Understanding types goes a long way towards being a good programmer, because it makes you understand what's really going on much better. So I think that that should also be one of the first things in it. Keeping in mind my first point, I'd like to write this thing in the form of a book describing the development of a series of simple games. Let's say we start with a text-mode version of Hangman for the first couple of chapters. That's quite complex already, but we can build it up in steps, and it gives plenty of opportunity to discuss variables, types and expressions (including const, but no pointers and references yet I think), input/output streams, functions, and control logic, as well as some design aspects like separating the logic from the graphics code and keeping everything nice and modular. We will be working towards a clear, game-related goal, so hopefully people will hang around. The second game should be a bit more complex, and can add things like dynamic allocation, classes, and pointers and references. It would use the same general structure of hangman however, so that we can show that the overal design is similar. Maybe we can say something about design patterns as well, although maybe that would be a little too soon after the introduction of classes. Ideas for which game are welcome . And should we go to a graphical system here already? Also, there should be an explanation of libraries and header files and linking in there somewhere, but I'm not sure where. Oh, and there should be a chapter 0 that explains about source and object code and compilers and so on, and about setting it all up on various platforms. Comments?

Ah, I much prefer that idea of doing it ALL in simple games, rather than leaping into tutorials about the 'boring stuff'. When do we make the leap to using some sort of graphical API? Its a lot to take on board, but its what most people want. SDL is probably a good place to start - write a couple of entries on how to set up a simple wrapper utility ( Textured Quad stylee ), and make some simple games. That deals heavily with pointers of course, whats an understandable way of getting the concept of memory across? I'm currently teaching Fyska ( If you remember her ), and when dealing with buffers to 'some data' in DirectX ( Filling resources ), she's STILL not understanding what it actually means, after several attempts at explaining it.

---

I have no idea what I am talking about

For the tasks set in the introductory programming part, my thought is that we should first identify all the things they will need to put together a small game (or several?) and determine how these might be logically split up for the tute. During the tute we could provide the source for a set of primitive (but still reasonably detailed) games (hangman or whatever) that be compiled and run. As we progress through each topic of the basics section, we identify appropriate parts of those games to work on as exercises. As a very simple example, if we want them to know what a string literal is, we would first describe what a string literal looks like in code (i.e. something in quotes) and then ask them to go through and change a bunch of string literals, recompile the code and see how the output has changed. The blocks they're working with would grow larger as they progress, for example, after a while we'd be getting them to replace a whole function, then design a class, etc. The final exercise would be the game we identified at the start, which by then they've hopefully learned all the neccessary components that will enable them to construct it entirely by themselves. The idea is that they always have something working, get an idea of the context(s) into which each structure they're learning to build fits and get lots of code to look at and analyse in addition to just learning how to construct those thnigs. I think it's important to clearly identify goals and show how each hoop we make them jump through is a neccessary exploration on the way to that goal.

I'm not sure I like the idea of providing all the source up front. I'm afraid that people will try to understand it all at once rather than following the tutorial, and while I'm all for experimenting, I'm a little afraid that we're going to get loads of threads of people asking about things that will be covered later in the tutorial. Of course, if you want to browse through the tutorial without reading, scoop the code together, and try and compile and run it, nobody is stopping you. Also, providing all the source up front may help teaching people to read code, which is a valuable skill in multi-developer environments (that is, everywhere). And, as someone wrote, when we start learning a human language we start reading first, and learn to write later. So why not do the same with programming languages? Which makes sense until you realise that human languages are actually two-way; that is our computers don't talk back to us in C++. The equivalent would probably be interpreting compilation errors (which, incidentally, is also a very valuable skill that should play a key role). So, after having started this post with an unfounded opinion, and then having given a random collection of arguments pro and contra, I will now conclude by saying that I don't know either, and will sleep on it tonight .

One rather good way to learn a new language is to provide the programmer the proper interfaces but not the actual implementation. You give them the cpp, h files and then they have to fill the function implementations. This is how they teach Symbian in my uni. Worked quite well in my opinion. Of course this requires a good documentation on how to actually implement the stuff you need to implement... which means more work.

---

I know for definite that if something like this is set up, I will be reading it for sure.

! If you have any suggestions or ideas, please post them! BayStone: But part of good programming is good design; I want to teach them to create good designs as well. And giving them the interfaces would be giving them the solution already...

design, god please, let us do that. Some of the people I deal with when coding don't have a clue.

---

I have no idea what I am talking about

 Quoting: Lourens Veen

! If you have any suggestions or ideas, please post them! BayStone: But part of good programming is good design; I want to teach them to create good designs as well. And giving them the interfaces would be giving them the solution already...

Yeah... it works only for learning the "language" and it's mechanings. This could apply well with some APIs, etc. Well, it comes down to the question that do we learn the language first or how to design things? At least for me, the language is more important in the beginning. Also by providing good initial design, we can inforce the learners to imitate that design. It's hard to come up with a great design on your own. Especially in the beginning. It's like martial arts, first you show the techniques, then you teach them and finally they'll do it themselves. Anyway, this is just a idea.

---

I think it would be a good idea to have a very obvious section (perhaps under tools) giving the names and locations of good free development tools/compilers. Let's face it most people reading the guides will be Windows users and good and more importantly free C++ compilers (or IDEs) are hard to come by for windows. It would be good to find a user frienldy IDE or compiler which has the features we need but is also easy enough to use for beginners. I think it would be a good idea to find on main IDE or compiler and refer to that throughout the tutorials so that everyone is working from the same system and each tutorial when referring to an IDE or compiler says the same things. Obviously people like me who have managed to get a copy of VS .NET would prefer to use that but when I first wanted to learn how to code I wasn't in a position to get an IDE like that so perhaps a consensus should be made to refer to an opensource IDE/Compiler?

 Quoting: Lourens Veen

I'm not sure I like the idea of providing all the source up front. I'm afraid that people will try to understand it all at once rather than following the tutorial, and while I'm all for experimenting, I'm a little afraid that we're going to get loads of threads of people asking about things that will be covered later in the tutorial.

I think that will happen regardless of whether we provide the source or not.

 Quoting: Lourens Veen

I think it's neccessary to teach two things at once, analysis and design. Giving them things in little bits is a bit like trying to teach design without analsysis, and imo, you can't design something that you don't know how to analyse (at least, you can't be sure that your design is any good or that it does what you think it does ). If it's neccessary to restrict the scope of what they're analysing so they don't become overwhelmed, I think that can be provided with snippets of pseudo-code (in fact, I think this would be a neccessary part of focusing them at the appropriate level and on the appropriate bits of real code). Note that we can make them identify and use interfaces (per Baystone's suggestion) and all that if we provide the full source. It will hopefully teach them that a piece of code can be looked at from many levels, from literals to statements to algorithms, to interfaces, etc. They should be able to look at a bit of code and say "I can identify it as a bunch of statements", "I can identify a sub-set of those statements as operating on a particular set of data embodied by a class", "I can identify that this bunch of statements form an algorithm that does such and such", etc. I'm not sure we should stick to just one tool (or set of tools), though it would create a lot more work for us if we didn't . However, the people reading it should always be clear on what is pertinent to the set of tools they're using. I think to start with, we're going to have to try out a few ourselves anyway.

I think that you need to decide which way to go then. Things should really either be written giving some instructions relevant to a set of tools which have been recommended or they should be written without referencing any set of tools in the tutorials themselves but just saying "compile this"/"build that" etc. and there should be various bits written on a variety of different tools which can be read by the people learning or referenced. I suppose the second option might be a good idea but it can sometimes be useful to give explicit instructions on how to implement something (especially using something like Visual Studio). But I think it's important that most of the tutorials are written in the same style regarding tools either the first kind of option or the second (or the second but referencing one in particular throughout). As for teaching design, it is useful to use pseudo code so that people can relate what they have been doing in the early stages of learning design to later stages where they should be designing then implementing things. If only it was a Java tutorial, UML is so useful

Why can't you use UML with C++? And to be honest, I'm not sure about the use of UML, unless in a very informal way. But let's keep that discussion for another thread and/or time. I would like to keep the tutorial itself more or less tool-agnostic. We can just say "Compile x" or "Run y", and have separate "Compile" and "Run" pages that we link those words to that explain how to do it for various platforms. This would then be explained in chapter 0. Analysis, yes, that's another part. I think there will be some software engineering in here as well. A simple waterfall model of analyse/design/code/test could be used as the overall structure of each chapter. The analyse part would teach people to think about problems in programming terms. The design part introduces new constructs and concepts that will be used to solve the problem. The code part teaches you how to write it down. Testing shows some common mistakes and how to interpret compilation errors. Hmm, I'm actually starting to feel like I have an idea of what this thing is going to be like. Exciting .

Is the wikki going to cover things like ADTs? And for the maths section I think it would be a good idea to put some emphasis on the order of evaluation given the language as sometimes maths related statements don't evaluate them according to mathematical rules

Is the wikki going to cover things like ADTs?

What, like stacks? . It probably should .

Can you give an example of such a wrong-order evaluation Fluke? I don't recall encountering any problems, but then I usually wrap everything in parenthesis anyway. Also, if we explain classes we explain ADTs, unless we explain classes without explaining the concept of encapsulation, and if we do that, we can't claim to be teaching OOP. So yeah, of course .

OKay i can be stupid sometimes, and this is one of those times. Is the Wiki actually made or not? I'm very confused Also, will this Wiki appeal to people who want to learn C++ with practically NO coding background? I like the idea of coding in C++, at the moment AI coding sounds particularly interesting, but until i learn a language, i can't do squat :'(

Its being made, although the only one actually doing anything is Lourens.

 Quoting: OJKM2

Also, will this Wiki appeal to people who want to learn C++ with practically NO coding background?

Yes.

---

I have no idea what I am talking about

What about from Java - C++? We're learning Java in college, and we're making rather good progress I'd say. Already learning about polymorphism and other OO stuff.

Oh good, i hope somebody will let me know when the C++ Wiki is up, i don't frequent the programming boards often, i've practically given up on online C++ tutorials, they're all hard to understand or cost money :\ Make wiki soon! ^_^

Don't forget that if you have practically no programming background it will probably require a LOT of effort, if you're being serious.