Please forgive me, you see I saw the post, "Rookie in game development. Where should I start", I thought he wanted to know how you start out a project, you see, I am a 3d graphic artist, I really did not wish to make you upset about any of this. Maybe on day you will need some helpful pointers from my field and I will talk to you as warmly as you to me. It is still a very nice forum, and again, thank you for putting me in my place, after all, I am new here and you are the pro's.

i deliberately didnt mention stroustrop. theres not much in it thats not covered in easier to understand language in the other books mentioned. Sure its a good book, the info is there but the organisation of it and the language used and even the code samples are lacking. Its a good book, but I dont count it among the greats.

Kraken, if you're wanting to write a game you need a lot more experience than basic programming and 3D design.
You'd be surprised at the number of kids who come into places like this with no programming experience at all (or at most an introductory class) and state their intention to write the next great 3D game from scratch as their next (read first major) project.
Of course you never hear from them again as they quickly give up.
If we sound harsh it's because we've seen it all before and want to prevent people from getting on that path without the proper knowledge under their belt.

Stoned, Stroustrup is a must read. Other books may contain some of the same information but in a less formalised manner. They're often ambiguous or wrong in the tiny details. Stroustrup IS the de facto language specification, what he writes must work in any ANSI compliant compiler (which admittedly means it might need slight adjustments for different compilers as there's AFAIK no compiler that implements the complete ANSI spec fully).
It's not meant as a tutorial, which you seem to have tried to use it for causing your disappointment.

By all means use other books to learn, but always have Stroustrup at the ready as a reference and final arbiter.

Hello, jwenting

Actually, I am a 56 year old and have been retired from the industry for the last 2 years, I have 30 years experience in film and some in games. You are right, I am not a programmer, but I do managment, right now, others have baited me out of retirement for one last effort, so here I am. The reason they wanted me, though I really wish they did not, was to setup and get things organized, and the way to do this has always been the tried and true method of a plan, or Script. This is nothing less than a manual by which to work by. This is the way all of the production houses here work, this starts long before anyone is even brought on board, we take the idea, develope it and get a working plan together, then bring in those that will form management. Then we drink a lot of coffee, some drink other things, and figure out the staff and then the budget, then we get going. Where I am at now, we are just in the planning stage.
You also must under stand, that mroe than 65% of my projects, did not use programmers, CG is like that, but where I have, these were really good people, and proud of what they do, I see that in you two, and you were just doing what you think best. I really would like to be friends with you, thats why I use forums. Thank you

>They're often ambiguous or wrong in the tiny details.
Have you read any of the books that Stoned_coder recommended? Are you knowledgeable enough with C++ to expose these "tiny details"? I can't speak for Stoned_coder, but I have a very hard time finding legitimate errors in the books he talked about, and I like to think I know a thing or two about C++.

>what he writes must work in any ANSI compliant compiler
Wrong, unfortunately, because a lot of people are misled as you have been. "ANSI" compliant compilers must conform to the C++ standard, and nothing else. The standard isn't even based on TC++PL, it's based on the ARM. Even worse, there are quite a few places where the venerable Stroustrup has written one thing only to be contradicted by what the standard says, and the standard always wins. If you don't believe me, and feel confident that you can understand the differences, feel free to compare the formal definition of istream::sync() with what TC++PL tries to palm it off as.

>By all means use other books to learn, but always have Stroustrup at the ready as a reference and final arbiter.
The final arbiter is the standard, as any expert will tell you. Stroustrup is wrong in the "tiny details" with uncomfortable frequency, doesn't delve far enough into advanced features to my satisfaction, and the rest of the language is simple to understand. Therefore, while it was an invaluable tool when I was learning the basics, I rarely consult it anymore.

Hello, Narue
You must not understand me, I am a graphics artist, but first I am in management, I do not need to know code or the tiny details, the final product is the goal, management tells the coders this is how it will go and they make it, if they cannot, new coders. You can write all of the engines you want, but you still have to put it to use, we are not talking about a team of want to be's here, this is a company. People are to do what is expected of them, they have a time table by which to work on and that is that. No game company is made up of coders alone, nor with just graphics. It is all about the final goal, and takes a lot more people than just the coders. We really do not think of just coders and graphics, it is a team of one and all. After all, I do not think of myself any better that a coder, we are on the same team. Thank you so much for senting me straight on this though, what a wonderful world we live in. Tell me, just how have you started a game and made final product? How did you do it with just the code.

Careful, Kraken.
I know you mean well, but Narue's post was correcting jwenting.
This is a forum primarily for the language, and so when you ask a question, it's only reasonable to expect a technical answer. These answers, unfortunately, can be blunt or even acidic reactions to bad ideas.

You are correct; your experience in team-based development environments where many people have a vested interest in producing a product is the best way to approach development of a game.

Unfortunately, the original topic was not asking about teamwork as much as it was asking where to start.

There is, after all, a great deal of educational value in coding games that have been written before, so you can become familiar with how to fit pieces together. Once you have a good knowledge base (as a coder), then you bring in everyone else for graphics, sound, and story (if applicable) development, and start working together as you describe.
Or, once you have experience, something to show, then you (as a coder) are brought in to a team that needs coders.


But right now, Auto wants a place to start from in learning to be a game coder. The days of a single programmer turning out a game are almost gone, but the place to start is almost always alone with supervision and guides.

That's what the discussion is; It's helping auto by suggesting the best way to go about learning to code games, the mindset and techniques that work.
Jwenting brought up that the reference for C++ as a language is a vital book, but got a little overzealous. Narue corrected him.


EDIT: Of course, this is rather moot because of the thread was pretty dead after may. I wonder if Auto is still around...

Fare enough, thank you for the reply.