Sorry I had meant to get to answering these questions a little earlier, but with work and what not, it had to wait until my day off. And, good suggestions from Marcus. I think I will follow his lead, and just jump into answering the questions one by one.
What math topics do you not know that you feel would help you get to the next level?
I have to agree with Marcus42 on this point. All the 3D math required for creating and maintaining a functioning 3D environment in game. The funny thing about all this math these days is that with the internet, all of the formula's are already out there. All of the explanations of how they work are out there too. My most recent problem since I'm already pretty good with the theories is simply implementation. I think a quick primer on geometry basics (what is a point, a vector2, a vector3, a matrix, etc as well as some explanations of how the computer 'sees' this information ie: line segment, polygon, face, etc) would be a great start for those who have been out of school for a little bit, or are just coming into things and need an introduction. From there I would talk about the formulas and briefly describe how they work (detailed information can always be referenced online), and then do a fairly in depth section on the projection, view, and world matrix set up, how to implement them, and then delve into the very basics of moving and rotation of game objects. For instance in the recent collab, I knew that I needed to create a rotation matrix and multiply that by the world matrix to get the asteroids rotating, but I didn't realize where to put the results. It wasn't until you actually did the work for that, that I saw the results, or the current world space for the asteroid, was implemented in the actual Draw code. That's due mostly to me not having much 3D experience but I guess that's the target audience, eh? So, I think maybe a chapter each on liner game object movement, object rotation, and object scaling (include explanation of normalization here) would be good. I say a whole chapter on each, because I think each chapter should pretty much go through each line of code AND include a working demo focused only on that particular task. And collision detection of course in all its glorious forms.
That being said, I think you should do a whole 'section' on 2D stuff as well. I've been working on learning game programming for a number of years and since I've been here I've learned a lot in that area - stuff I hadn't even realized I was missing. It's a good starting point for noobs, remains relevant with the advent of all the cell phone gaming, and helps build a solid programming foundation before moving into more advanced code where the same knowledge can be carried over into another dimension! Topics in this section would include basic coordinate systems, liner asset motion, using trajectory and velocity to track objects, collision detection, and using lerps for collision detection on a slope. Maybe a little bit on transparency, alpha-transparency, and preferred file formats. I would also include a chapter specifically on the render window. Or, more precisely, the spriteBatch.Begin() method. For a long time all the demo code I was looking at simply moved objects around the screen. I knew there was a better way, but once again I wasn't quite sure how to implement it, so every one of my side scrollers until recently have simply moved the player character around in the world, and then moved the world itself around. The correct way to do this,of course, is to simply move the player character around in the world, and then move the render window to the point in the world that needs to be onscreen at the moment. So, something like this:
spriteBatch.Begin(SpriteSortMode.Immediate, null, null, null, null, null, Matrix.CreateTranslation(-(offsetX), -(offsetY - 33), 0));
with a detailed breakdown of whats going on and how it works would be awesome! On reflection, it would probably be best to split this into 2 sections - basic 2D math (linear movement) and advanced 2D math (velocity, trajectory, lerps). Maybe in the advanced 2D stuff, or right after it, you could do a short chapter on special effects. Stuff like blending alpha transparencies with multiple renderings to create the trail effect, particle engines, and using a particle engine to create an animated explosion or smoke trail. That stuff might seem a little off topic, but it's really all just math.
What things did(do) you know now that you wish you had known sooner?
Kind of hit on this in the previous answer. The use of the Begin() method to move the render window within the game world, and specific implementation of basic 3D motion and/or rotation using the world matrix. How Lerps can be very useful outside of 3D (calculating alpha transparency levels and colors for the trail effect, collision detection on a slope).
What topics would you tell a beginner they should learn about?
*See question 1
The C# Player's Guide is (so far) only in black and white. I'm debating whether to go with color for this one or not. Color (for syntax highlighting, diagrams, and screenshots) would add to the value of the book, but it adds to the cost quickly as well. This would make the cost of the book jump from something in the range of $20-$30 up to $60 or $80. I might have a second option that might get me something in the middle. The question here is, how much value does color add for you personally?
While the issue of color or black and white is debatable, I have to side with Marcus on this as well. If the impact on the overall cost of the book is going to be as significant as you indicate then I would definitely go B&W. I don't know if this is doable, but it seems like you should be able to offer the consumer the choice. Like, you can make a full fledged color version as a 'deluxe' edition for those who might like that, and then offer a B&W version at a discount. Seems like the only difference would be making a separate copy once complete and running it through a grey scale converter. Of course I'm not as familiar with the printing process as I should be so that might introduce more complexities than it's worth. One thing I will say is that (if possible) including a CD with the book is an awesome feature. It's something programming books used to do years back and when I'm looking to purchase a book, that's actually a HUGE deal for me. It may not necessarily be a deal breaker but I am definitely more inclined to purchase one with the CD since I can pop that sucker right in, take a look at the actual completed working code and jump right in where there's something I need to know. Alternatively, you could do some kind of cheap USB stick since that is ubiquitous these days.
What kinds of things help you learn the most? Quizzes? Problems to do? Other things?
Completed. Working. Code. I always jump right into the code and try to process everything that I'm focused on. If I can do that, and pop back to the book where things get a little fuzzy I seem to be able to move along pretty quickly. Still, the quizzes that concentrate on items that are important for you to pick up from the previous chapter are great as well. I can actually start there and if something isn't familiar, I know I need to go back through and reread (or just read) that part. The problems/challenges are excellent as well… gives you something to strive for and test if you're really ready to progress to more advanced sections. I hate to admit it, but even considering my programming experience, the FizzBuzz exercise caught me up a little. The only thing I would probably add (and forgive me if it's in there, it has been a while since I read your book) is a vocabulary reference either at the beginning or end of the chapter with terms you should know. I've found hanging out in the chat room and working in the collabs that communication is key, and if you need help on something, knowing the correct way to describe your problem (and understand the answer) is a must. Subtle mistakes in the way you describe or think about an issue can have dramatic consequences on getting it resolved.
Is this the kind of book that you (or a beginner friend of yours) would want to read cover-to-cover, or would you envision more of a "recipes" style book, where you read the topics only as there's a demand?
Definitely cover-to-cover with a slow but steady progression from simpler topics to more advanced situations. At the end of each chapter, you could have the code listing (as well as on the aforementioned CD) and in essence provide the 'recipe' feeling in a cover-to-cover setting.
Should I focus on a particular programming language (C#) or leave it more abstract (pseudo code)?
Again, to quote Marcus: I think you should absolutely focus on C#. Pseudo code can be helpful in some instances but I think having code that you can literally type right in and fire up is a huge plus. For beginners, it's sometimes hard to understand what Position may be if they haven't had experience using a Vector2. You can tell them all about the vectors and how they are used, but until they see it put down and implemented, it's still kind of vague theory. Nailing it down to C# gives them some good solid code fundamentals and something they can see working as opposed to 'if you set this up to this, and that up to this, and call the blah method you should get blah results'. On a related note, it is much easier to convert actual code to another language should they want to, instead of having an outline and having to figure out a new implementation. Plug (or type) and play, baby!
Are you interested in why a formula works, or would it be better to just give it to you and explain how to use it? (In other words, how much effort should be spent developing concepts?)
Whoa now, this is kind of a big subject. Whole volumes of encyclopedia-like book collections could be devoted to this topic, and it would just scratch the surface. Personally, I do like understanding why and how a formula works. With that in mind though, I can't say that I spend a tremendous amount of time going into all the details. Personally I think it would be best to throw the formula out there, explain how to use it, and then do an abbreviated explanation of how it works. The end user can then follow up if they feel they need more on a specific topic. So, in other words, some time should be devoted to providing a basic overview, but I'd leave an in-depth exploration up to the reader.
Other input
I would include a full chapter on world space vs pixel space. Go into some detail about what it is, why we should use it, and a couple different implementation examples. That's a must for the newer people and I feel bad I never spent much time considering it instead of all the pixel based stuff I've been doing for years.
Code practices and standards: Definitely dedicate a little section for this. I know we've discussed this issue in the past, and you've expressed that you didn't want to address it because you didn't want to impose your 'rules' on others since no one way is right or wrong. Still, I think a basic outline would be a great idea, make the book code easier to understand, and would be of great value if the reader decides to join us on the website/forum/chat/collab/competition. It doesn't have to be full on Hungarian notation but some best practices can't hurt.
And finally, a glossary of terms based on the vocabulary exercises at the end of each chapter. Something that the reader could look to quickly to find a definition if they're unfamiliar with that particular term and then go to the page and chapter where the details are located if they need further information.
Ok, sorry for the essay as a response. Hopefully it'll provide some helpful ideas!
