Originally posted by mrmike
Also - real important - please with every post please say something nice to my wife Robin - without her permission I don't do squat!

Pffft, Robin kicked me in the butt two years ago at GDC while I was chatting with some super-important tech director! You don't just forget a thing like that!

In all seriousness though, Robin is awesome.

-Rez

I'm a little surprised no one's weighed in on this yet. I was waiting to see what people said before I posted my opinions since I'm one of the authors, but here goes...

1) Refactor the pathing system. I'd like to go back and update the pathing system so that it can spread the path generation across multiple frames (basically turn the AStar functor into a CProcess). This can be tied into the multithreaded stuff so that all pathing happens on another thread. I'd also like to integrate it with the C# level editor so you can build your own graphs and maybe even write a simple generator to generate simple graphs that are easy to hand-tune.

2) I'd like to expand on the state machine quite a bit. In a real game, those states would mostly be written in Lua and the transition logic between them should be nice and interchangeable (probably just Lua functors).

3) I'd like to go a bit deeper into more advanced AI. I think state machines can get you a good part of the way, but it'd be nice to go a bit deeper into utility theory, decision trees, weighted probabilities, fuzzy logic, etc.

4) Update the graphics stuff to DX10/11.

5) More scripting and data-driven techniques. We have a nice Lua integration but I think one place where a lot of inexperienced programmer tend to stumble is when & how to make things data driven.

6) Gameplay techniques! We spend most of the book talking about architecture and how to write a great engine, but we don't really go into much detail about general gameplay.

I have another idea about how we might approach this, but it's too crazy to post here. I'll give you call this weekend about it.

-Rez

PS: All praise to Robin, bringing of awesome.

I should be starting the 3rd edition by next week and I can't wait. Hopefully I'll have more to say about this as I progress through the book.

Just wondering, though. If you were to create a 4th edition, do you have any idea when it might reach bookshelves?

I'd also just like to throw in a general comment that I think it'd be neat if the hard copy of the book came with an "e-book edition" so that we could search and reference it while working on the computer.

Look forward to many future posts on the forums.

I'd like to see some of the stuff talked about in the current books implemented, like a memory manager.

Use of the XNAMath or something similar.

Maybe some talk on porting the engine onto mobile devices.

And a big thank you to Robin for her support of Mike, and inadvertently us. Please let Mike write another book, I'm sure you don't want him moping around the house and kicking the cat for the next couple of years.

Definitely would like a 4th Edition, praise Robin. Regarding the existing content, I have two main interests.

First, abstracting the graphics portion to be easily swapped between OpenGL and DirectX. Ideally with a project for building each, shared .h's, but different .cpp's, unless there's a better way that I'm un-aware of. Due to personal preference I try to avoid just using #ifdef and compiler flags for such large implementation differences.

Secondly, cleaning up the project/file structure on the source a bit. This may just be me, but I think it's best to try to keep one class per file, and let the directories/filters keep it organized, rather than having a massive Event.h that declares 30 event types. Overall the code base is good, I just think it could be a bit tidy'er.

Mike, if you actually are looking for content suggestions for the 4th Edition, as opposed to just going into further depth on the existing content, I'm sure I can come up with a few ideas

James

I didn't buy the 3rd edition because I have the 2nd and couldn't justify buying the same book twice. However if a 4th edition is written, I will be happy to buy it and read the whole thing as I did with the 2nd edition.

It's not a real book unless we're crunching at work AND on the book content at the SAME TIME. Again.

*ducks*

-Rez

Originally posted by rezination
5) More scripting and data-driven techniques. We have a nice Lua integration but I think one place where a lot of inexperienced programmer tend to stumble is when & how to make things data driven.

Thumbs up to this.

Component systems would tickle me also

Please Robin, can mrmike comeout and play?

Clearly, I've fallen out of the game programming mindset, but even so:

Personally, I would like to see the emphasis being on a 2d game, and then having the 3d game engine parts being more separate.

Like, "here's how to make a complete 2d game", followed by "and then you can replace your view layer with this awesome way of doing 3d rendering."

Mobile devices have given 2d games a new life, and I think being able to get A GAME up and running without all the 3d crap to worry about can be immensely valuable.

I also would imagine you are going to need to touch on what developers actually use for mobile games. I know you can use stuff other than Java for Android, and I know you can use C++ directly for iOS, but what do the big developers actually use?

It seems like focusing on just consoles or PC will make the 4th edition feel old.


The other option is to just make a new book. Mobile Game Coding Complete.

Mobile gaming definitely brings a very different set of challenges. Some stuff will translate well from GCC, other stuff won't, but it's an interesting idea. If we do it, I would suggest titling the book differently since we'd be delivering different content.

To answer your question about language, I did iPhone games for a few months and we used C++ almost exclusively, with a few Objective-C source files to deal with the OS. I think it's the same for Droid, except replace Objective-C with Java (I left before they got their droid stuff going). Most companies I know do the same thing because it's nearly impossible to find anyone who really know Objective-C. Also, Objective-C is kind of terrible.

-Rez

You also have Unity... But I don't know if the big companies use it. I know a lot of indie developers do.

First, since this is my 1st post here - I'd like to thank Mr Mike and all the Co-authors for a great book. It was very educational, useful and fun to read. A rare combination.

My opinion is that this book is about how AAA games are developed (even if these methods can be used for casual games), and not mobile/social games (which usually require a very different framework and technology). But that's just my opinion

On-topic:
- I'd like to see how to develop a framework which is not based on DXUT. This mainly includes input, UI and device handling.
I found tidbits all around and got a very simple system going, but joining it all to a complete framework has a lot of pitfalls (how exactly does the input manager work? How does the UI sends the events internally? and probably many more).

- Another thing, although not directly related to programming, is what kind of talents you need to assemble to create a game.
Since this book is written for programmers, it would be helpful to add information that programmers don't necessarily know, such as some kind of a checklist (which can of course change depending on the game, but something basic) along the lines of:
For the 3D graphics, you need 3D modelers, and animators (are they the same people? How can I tell how many I need?) but you also need other artists to create the textures, and level designers (what do they need to be able to do?) and someone to tweak all the values in the configuration files (is it the level designer? Should it be someone who knows programming?) (etc. etc.).
I might be writing complete nonsense here, but that's mainly because I have no idea about this... Hey, I'm a programmer

- Network: AFAIK, there are two general ways to do MP. First, LAN (or whatever local network you want), in which the server is one of the players. Second, An internet host which connects between players which are connected to it. The server in that case is not a player.
Maybe I'm missing something in the code (and please let me know if I have), but it seems that you have taken a hybrid way - a server with a host name which is also a player.
For my game I have implemented LAN MP using UDP sockets and broadcast (and I've taken quite a few ideas from your code, but with a slightly different design approach), and I would like to also implement an actual internet MP, but that would require the entire lobby programming.
Could you add a few sections in the network chapter about LAN games (it wasn't easy to find all the details I needed, and I'm sure I am still missing a lot) and about how to begin creating an internet host for server-based MP games?
I understand that expecting a fully functional system is a bit too much, but at least some pointers from the games you worked on would be nice

A few other minor comments:

- The debugging chapter is excellent. It really covers a LOT of good stuff. It is, however, missing the mentioning of VS data breakpoints (which are an excellent solution for some of the bugs mentioned there).

- (I'm not sure if this fits here; but it might be an issue to discuss in the next edition: ) Regarding C++ exceptions - are they used in games? I've talked to a former PS3 games developer that said that they never use them due to performance issues. Is this common? Is it true only for consoles? Is he just out of the business for too long?

Ummm... Maybe I should have split this post... Oh well. Your book was longer

EDIT: I completely forgot! Robin - I'd demand at least a co-author credit for the next edition if I were you.

You might also be able to get away with using C++ for some of the popular mobile devices. Nokia uses Qt C++ and Android has the NDK for compiling C++ code although this makes it platform specific.

Opengl would also need to be the main focus instead of DX. This might be interesting since we're now starting to have browsers that support WebGL.

When the fourth edition comes out I think I'll have to put my previous editions somewhere else, they're starting to take up a lot of space in my book case (having 1-3 and all).

Lately I've been using the concepts from GameCoding Complete, along with the event system and some other basics and changing it to Directx 11. I've also removed DXUT and started using C++0x features. The next step will be task based parallelism, so my suggestions are based on this.

---

1. Task based parallelism? I've listened to all the DICE presentations a couple of times (publications.dice.se/) and it seems like a good idea. I'm testing out the ppl library in vc++ at the moment.

2. C++0x. There are some nice features in the new c++ standard. Lambdas, smart pointers/make_shared taken into the std library from boost, the auto keyword is also quite handy for this purpose.
(Some good videos about C++0x and STL: channel9.msdn.com/Shows/Going+Deep?page=1)

3. DirectX 11. Shaders etc. Maybe a basic framework instead of DXUT?

4. Clean code? This is very popular with java programmers, and I've grown used to it, since I've been using java at work for over a year now. It basically involves writing self documenting code. I does lead to quite a bit of function calls/classes, and limiting function length for readability. This makes the code a lot easier to maintain.
(Based on this book: amazon.com/Clean-Code-Handbook…aftsmanship/dp/0132350882)

I'm sure I have some more ideas lurking in my head somewhere, but that's it for now.

Thanks Robin, for putting up with us programmers.

As mentioned above I would like to see LUA take a more central role in content and data creation in the engine.
If mobile game engine design would be too much of an undertaking (the book is already pushing 1000 pages after all), a discussion on abstraction of core systems may help readers with creating engines that are portable to such platforms.
I would like to see a whole chapter dedicated to shaders. In the 3rd edition there was a quick section in the 3D chapters some where. I would like to see a bit more.

Does Robin like flowers? because i can send flowers

A 4th edition would be great. The 3rd edition was fantastic. It was easy to read, funny
("Dood F=ma, you okay?" :)) and set at just the right level for beginner game programmers.

The game engine code was pretty fantastic too. I got it off the repository but had problems building the game. I never actually saw TeapotWars running but I just said to hell with it and ran with it anyway. I pretty much stripped all the windows and directx stuff out replacing that with OpenGL and GLFW. I left out parts I didn't want to use (AI, networking and game editor) for no reason other than my main interest was in graphics programming and low level game engine programming. I kind of merged the parts I wanted with a game engine I was working on myself. The aim was to make a cross platform 3D engine and a game so that I could get a games programming job (which I did - THANK YOU GUYS for the awesome book).

Heres what I would like to see in 4:

- Cross platform engine. With the way the industry is going lately it seems like OpenGL would be a better graphics API to start with. Maybe target the engine to run on both windows and mac for those interested in iPhone dev? I don't mean to start THIS debate, i think Directx is great, but cross platform might pick up that reading audience for you too.

- More robust build system so that beginners have an easier time running the example programs bundled with GCC4. Something like CMake rather than depending on Visual Studio as it seemed that every new version of VS broke something for people going by the forums here. Also it would be great if you could build it with a free version of VS and Xcode for all the poor game devs out there (I was using VS express).

- A rewritten EventManager. Whats there is nice but its horrible having to write a new struct or class every time you need to add a new event type. Event.h gets absolutely huge. It would be nicer to pack event data into chunks of data with an event ID so that events are not defined in headers, but created and packed at runtime. It also horrible having a big massive event handling function with if(event type == QUIT), else if(eventyype == PLAYER_SHOOT), etc. .....

- I love the scripting chapter, maybe expand it out, having some of the game engine scriptable? I did this in my game demo. I wrote my own GUI widgets and had them scriptable too. It made for really fast iteration and was really cool to write IMO.

- Physics chapter was great. Maybe change the architecture to have the logic layer running in a separate thread?

- 3D chapters were really good. Maybe next time, forget completely about fixed function pipeline stuff and write one chapter on shaders?

ps Robin McShaffry, you really need to let him do one more. He will get it right this time, I know it!

The Sims Medieval gameplay code was all C#. I have to say, it's a pretty neat little language, though my first true love is still C++. Yeah, I know, I have problems....

I give talks to college and high school kids about breaking into the game industry. A lot of times they ask me what they can do to start working on a game right now. I always point them to Unity. They seem to be getting better and better. They had a pretty big presence this year at GDC too, although they were trying to aggressively sell me on the product. Still, it's looking pretty sweet.

-Rez

Originally posted by rezination
I give talks to college and high school kids about breaking into the game industry.

It's too bad you can't post some of these talks, Rez. I'd be interested in hearing more about this and could always use some more motivation.