There are many ways - it all depends on how you setup your engine. Unfortunately, I dont have the time to go into a lot of detail right now, but I'll post how I would do it when I get home (currently @ work).

The problem with this type of question (glad u asked btw :) ) is that it has a lot more to do with design (game design in particular) than opengl. Ideally, the code that positions the king (ie on a given square) on the board should not even use (or be remotely near) your gl code. As far as OpenGL is concerned, all you are actually drawing is triangles.

Here's a bit of reading on this kinda stuff:
http://www.gamedev.net/reference/list.asp?categoryid=45#115

Will post later,
- llvllatrix

[Edited by - llvllatrix on December 22, 2004 2:27:15 PM]

Sorry for disturbing you at work.. I didn't know that over there is daytime.. The time I sent you this message is nighttime :).. different time zone.. :D
But now it's morning already here...
Now I am going out while waiting for your valuable information.. :)

Quote:
Sorry for disturbing you at work..

No problem; I do this stuff for fun :)

Quote:
...valuable information...

lol, well I dont know if its that valuable...just remember that the stuff i say is not set in stone. Feel free to do things differently (its actually to your advantage to do so because you learn a lot more).

Quote:
Do you know how to draw 8x8 opengl chessboard and place the king.obj on the chessboard?

Based on your question I'm going to make a few assumptions. Please correct me if I make a mistake so that I can help you the most :) I'm assuming that you're making a chess game and thinking of using opengl to do it. I'm also assuming that you have no base engine for the game developed, so we're going to have to cover that in our discussion. There are a few ways I can answer your question. I could tell you how to draw a king and board and all you could do with it is look and it and see how cool it is (you couldnt move the king around or play chess in general). I could help you make a quick chess game because chess is small enough that you could do it without any planning. The way I want to help however is to go through how to make a professional engine. Our example is going to be chess which is fairly simplistic, but the principles I hope to discuss should also scale to a game like quake. Why take such a long time discussing and planning a project that is easy to make? Because you will learn a lot more from the experience...trust me, its worth it :) Sorry if my first post is a bit general :)

k, so its obvious that i cant tell you that if you follow steps 1 - X you'll successfully complete your project ect. (lol, its just not possible) Instead, what I want to do with this thread is to start a discussion about game design from start to where ever we take it. Consider this an online, dynamic tutorial with many authors. You guys should feel free to tell me that I'm wrong (giving a reason for your decisions is very important because we are all of different expertise in different areas). Remember that even if you (the general reader) feel you cannot contribute because you dont have the experience, asking questions is just as valuable (they determine where this discussion will go). As we discuss we are hopefully going to decompose things to a point where they can be implemented. Questions you guys ask will determine what issues get addressed and in what order. So sit back and get ready for what will hopefully be a long and productive discussion.

I think the best place to start is at the beginning (you'd be surprised how many people dont start there, but more on this later). Imagine how terrible it would be if you hired a company to build you a corporate headquarters for your multi-million dollar game development studio and you open the door and the thing crashes down on you. Then, when your in your hospital bed you find out that its because the guys who built the place didnt do any planning or draw any blue prints and just started building the place without thinking twice. The reason this kind of thing doesn't happen with building companies is because architects and engineers design and test the building long before anyone uses a hammer or saw. However, this happens all to often in software engineering; people just dont start at the beginning. They just jump into projects and start coding without design documents. Remember your friend who said he would make an amazing game and ended up not finishing it? Its because when he was nailing some code together, the structure fell straight down on top of his head and he couldnt continue...anyway I tink I made my point...design twice, build once...so lets get to some code design...that and I ran out of building analogies ;) ...

Programming is like chewing a pack of bubble gum. If you chew it all at once you're going to die. Its best if you divide the pack into pieces and chew each separately. There’s no guarantee you're not going to choke on a small piece but at least if you do you can probably spit it back up. So the first thing to do is establish exactly what we hope to accomplish and then keep breaking it down till we can implement it. To break it down on a business level, the "what are we going to do" is the project proposal. The "break down" is the design document/feasibility study and the implement it is "code till it works".

Side trackin':
In this quick paragraph I'm going to describe my tendencies when it comes to game programming. Most of the reasons for this stuff comes from code on the cob and we'll hopefully see it used and justified further on in the discussion. Game programming (unlike word processors) are made using synthesis. We are going to take elements like graphics, audio ect and put them together to make a product as apposed to making an abstract document and deriving different instances of it. To do the synthesis I typically use function libraries as the glue that holds my program together (think OpenGL's interface). Classes and inheritance usually dont work for this kind of thing. I'm not saying to totally abandon classes, I'm saying "use them to do a job behind a function library so that whatever uses the library doesn’t have to know about them".

What are we going to do?
So we're making a chess game. It will have 3d graphics which animate, a fully functional camera, ai which you can play against (not good ai, but ai none the less), a console for testing (not as complex as you think, but it will just take a long time to implement), sound for coolness, and the ability to save your game. That sound good to everyone?

How are we going to do this?
Well, first step is decomposition, but what exactly does that mean? If you refer to my side tract up there, why are we decomposing, shouldn’t we be synthesizing? In truth, there are actually two different phases here that use different techniques to get their jobs done. The first phase is the design phase where we decompose our problem into sub problems till we are satisfied we can tackle them. Then we go to the implementation phase where we take the easiest sub problems, solve them, and their solutions to solve larger problems till we have a final solution; our game (this is what i mean by synthesis).

So what is this design thingy all about?
Decomposition is the answer to the question, "how the hell am i supposed to do that?" Design is about making a decomposition that works both now and in the future (kinda tough, but you'll see what i mean). Pop quiz: what did a software blue print look like back when king tut was writing security software for his sarcophagus (namely the 7 Egyptian curses of death)? Ans: Same as they look today ; a pyramid. On the top of the pyramid is our goal (namely, a game) and on the very bottom is stuff we know we have to use to achieve our goal. I our case, we have stuff like OpenGL, Windows, and fmod on the bottom. At the top of our pyramid is our chess game.

Let the designing begin:
A quick way to start is by listing a bunch of stuff you're probably going to need. In any game, we're going to need a main screen (the thing people see when they start the game), a game screen(the game itself), a menu (drawn over the screen), a way to tell if the game is over, a way to tell what screen gets input, a way to get the input, a way to keep track of time, a way to draw objects as apposed to triangles, a way to easily play a sound, a way to load files, a way for the ai to think, a way to control the camera, and a whole bunch of other stuff. The next thing to tackle is to organize this stuff in a pyramid and then fill in the gaps where we need to. We then keep doing this (decomposing these subsystems) till we can implement each subsystem without having to decompose it.

So the next thing to tackle is to rearrange the subsystems i've listed (as well as others you guys come up with) into the pyramid and this i'm going to leave to anyone with time on their hands (this is a good exercise to do) or my next post (which ever comes first).

will post later,
- llvllatrix

Thank you for spending so much time to write so much thing in this forum. I think you can be my lecturer :)
You are right, I really want to make my own 3D chess game(opengl chess game using visual c++).But to set up an openGl windows requires many codings. I cannot remember all the codings and I don't know whether I really need to use all the codings just to create an opengl windows.
I hope we can start coding the game together.
Thanks.

man, ||v||atrix, I work with someone who looks EXACTLY like the character in your sig. weird....

anyways, continue, I'm all ears.

Quick question: Should we start another thread? The problem with starting another thread is that the direction of this project might not go as you would like, da_grat1. If we do then you shouldnt feel obligated to implement anything you dont want to (or anything at all for that matter...i dont mind if you decide not to do it :) ). I'll try to address any issues you have directly tho, if we get too side tracked. As long as you have questions, I'll try to answer them :)

Cheers,
- llvllatrix

Yeah, it is a little off topic.
Might be a good candidate for the beginners forums.

Quote:
Might be a good candidate for the beginners forums.

lol, actually I know a few "experienced" programmers who cant program at this level. I think its a good candidate for this forum in particular because you get a good mix of levels.

Cheers,
- llvllatrix

Yeah, I think I should start a new thread. :) But I don't know what the title should be.. :)

Will do :)