How to program a chess: a forum based tutorial

llvllatrix · 2005-04-02T02:01:34

Introductions (ie what the heck is this thread about): This thread was born when da_grat1 asked me about model loading. After a bit of discussion it turned out that he was trying to program a chess game and wondered if I had any advice. The result; a good excuse to talk design. Although this may seem off topic on this forum, I think nehe is best for several reasons. This forum has a wide variety of visitors, both advanced and beginner (you'll see why this is important later...keep reading :) ). I also dont have to go over OGL, which we will be using to do our graphics. Most of you have also already taken a look at some general demo design as well as loading and playing sound, which is a bonus. Also note that da_grat1 will be trying to implement this, so I'm going to try my best to keep us on topic and drive us through the end. k, so its obvious that i cant tell you that if you follow steps 1 - X you'll successfully complete your project, or game 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 feel you cannot contribute because you dont have the experience, asking questions is just as valuable (they determine where this discussion will go). 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. 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 when you open the door, 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 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 (http://www.gamedev.net/reference/list.asp?categoryid=45#115) 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. 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 (think MFC). 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". Keep your interfaces clean and whatever you build with them will look ok...irregardless of what is behind the interface. What are we going to do? So we're making a chess game. It will have 3d pieces that move accross the board (as apposed to appearing where ever you clicked), an animated 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 track 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 (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 (our requirements). 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 to my next post (which ever comes first). will post later, - llvllatrix

da_grat1

122

March 16, 2005 11:46 AM

llvallatrix.. anything about dragging the piece....

da_grat1

122

March 17, 2005 10:00 AM

Any good news about moving the pieces.. I think it's quite difficult because need to detect the errors if we move the piece to the wrong position... :)

llvllatrix

Author

340

March 17, 2005 04:17 PM

Hey guys,

...so my development computer is officially dead...but no worries. I've managed to get new parts shipped here and they should hopefully arrive soon. In the mean time I'll have to use another computer for development.

After some thought, I dont think this project is really big enough to warrant any significant design document. With that said, I'll continue with the code as is.

So far I have an SDL window setup. This means we can scrap the gl basecode and move our stuff into source. I'm currently working on adding viewport creation tools, a lighting loader, and finally adding our user input subsystem.

With this in mind, we should have the project ready for beta testing by the end of next week. Here's our tentative schedule:

20th - viewport creation, lighting load and input system are completed
22nd - Game start screen context is complete
23rd - Game menu is complete
27th - Main game is complete, let beta testing start

Quote:
After some thought, I don’t think this project is really big enough to warrant any significant design document.

This particular project has been all about the engine design. The main components of the chess game have handled by Beowulf. All we really have to do in terms of a game is provide an interface wrapper for the engine.

With that said, I still really want to take you guys through what it means to design and develop a video game. I'm thinking of reusing the engine we've developed to produce yet another set of tutorials. Tell me what you guys think :)

Cheers,
- llvllatrix

da_grat1

122

March 17, 2005 04:39 PM

Quote: 20th - viewport creation, lighting load and input system are completed
22nd - Game start screen context is complete
23rd - Game menu is complete
27th - Main game is complete, let beta testing start

Is this for real.. that means.. the game really can be played on the "27"of march.....when you write the schedule, my eyes open really wide... just want to know ..the moving pieces take place in what date...? :) is it on the 20th..?
I will try my best to support you.. llvllatrix..

Quote: With that said, I still really want to take you guys through what it means to design and develop a video game. I'm thinking of reusing the engine we've developed to produce yet another set of tutorials. Tell me what you guys think :)

do you mean another set of new game.. :)

[Edited by - da_grat1 on March 17, 2005 10:39:57 PM]

Videege

122

March 19, 2005 08:50 AM

I've got to tell you, matrix, this is awesome what you've done here. I'm really interested in using this engine when it's done.

Thanks for all your work, especially your "design" posts, they've really furthered my understanding of project management, etc.

"Honesty, hard work, and determination are the keys to success in life...if you can fake that, you''ve got it made. " -- Groucho Marx

llvllatrix

Author

340

March 19, 2005 12:33 PM

Quote:
I've got to tell you, matrix, this is awesome what you've done here. I'm really interested in using this engine when it's done.

Thanks for all your work, especially your "design" posts, they've really furthered my understanding of project management, etc.

haha, thanks :) I actually feel a bit ashamed. I recently reviewed all of the past posts and I constantly found myself saying:

Quote:
Sorry for the late post...

Sry about that guys. I should probably do post on how to keep a project on schedule :)

Heres more info on the future of our new engine:

About the publication (FYI: there is a publisher interested in publishing this set of tutorials into a text book): It looks like I'll have to postpone the publication for about five months. I have about one month until I go back to the university, which gives me enough time to wrap up the chess project and get started on another game. Unfortunately, thats not enough time to write a text. I should have enough time after I finish my study term, which should be over at the start of september.

Just in case you were worried about the copyright issues sorrounding a publication; I'm going to make sure that our engine stays open source. This means that you will be able to freely use and distribute all and any source from this project under the GNU; the engine officially belongs to the internet. Unfortunatly, the tutorial section of the text will be copyright. What does that mean? It basically means that any tutorials that come out of the text will not be avaliable on the internet. However, the tutorials that are currently online will stay in the public domain.

About the next game (FYI: I'm thinking of using the current engine to produce another game): I'm still taking suggestions on what we should do for our next game. It will be produced using our current engine. We can also ammend to the engine to produce the next project. Here is a list of things we can add for our next project:

- Resources streamed from disk as needed (this is quite important if you plan to do a large game with many resources...that said, I'll probably tackle this irregardless of whichever game we do :) )
- Networked Multiplayer (via SDL)
- Animated models (again, probably going to tackle this)
- A bunch of GL effects (because you can never have enough in game graphic effects :) )
- Various types of LOD (depending on how much we have to send to the frame buffer)

So what are we going to make ? Well, its up in the air right now. The perfect candidate for a game should demonstrate several things:

- It should be unique enough to take us through the entire game development process (ie 3 completes: http://www.gamedev.net/reference/design/features/3completes/)...this means we will be doing a formal design doc for the game before we even touch code)
- It shouldn't be a board game; I want to demonstrate how to implement a different type of genre, like a real time strategy game, rpg, or fps.
- The levels should be modular, making it easier to test. I dont think we have the time to go through the creation of all our game's assets. Realisticly I think the best we can do is a test level. I'll leave the rest up to the community (or perhaps a nehe contest :) ).

So far the best candidate for a game IMO is a real time version of this game:
http://www.wizkidsgames.com/pirates/pirates_article.asp?cid=38943

Cheers,
- llvllatrix

da_grat1

122

March 19, 2005 12:49 PM

Quote: - 20th - viewport creation, lighting load and input system are completed
22nd - Game start screen context is complete
23rd - Game menu is complete
27th - Main game is complete, let beta testing start

This schedule is correct right..?

[Edited by - da_grat1 on March 19, 2005 1:49:05 PM]

llvllatrix

Author

340

March 19, 2005 12:55 PM

Quote:
This schedule is correct right..?
that means today we should be able to view the viewport creation, lighting load and input system..

Yup; I should have it done by tomorrow.

da_grat1

122

March 19, 2005 01:15 PM

Quote: - Resources streamed from disk as needed (this is quite important if you plan to do a large game with many resources...that said, I'll probably tackle this irregardless of whichever game we do :) )
- Networked Multiplayer (via SDL)
- Animated models (again, probably going to tackle this)
- A bunch of GL effects (because you can never have enough in game graphic effects :) )
- Various types of LOD (depending on how much we have to send to the frame buffer)

Yeah..the above ideas should be implemented in the next game...
that means after we have done with this game ...we should come out with a new documentation design for the new tutorial or game... is that what you mean llvallatrix?

[

It shouldn't be a board game; I want to demonstrate how to implement a different type of genre, like a real time strategy game, rpg, or fps.

the game should be a board game.. what I have in mind right now is "Othello game".. have you heard it before? ...lol.. I better think of rpg game or something else :)

Quote: Yup; I should have it done by tomorrow

this is the first time I receive a very fast reply.. :)
this is really great that we could follow up the schedule... I think for out next game.. we should create a gantt chart or something lol.. :) like wat I have learnt in project management..

Quote: 27th - Main game is complete, let beta testing start

just want to know one thing.. here in beta testing, we should be able to test playing the game already.. am I right? :)

[Edited by - da_grat1 on March 19, 2005 1:15:20 PM]

llvllatrix

Author

340

March 19, 2005 05:54 PM

Quote:
just want to know one thing.. here in beta testing, we should be able to test playing the game already.. am I right? :)

Yup :) (I'm very excited about it as well :) )

Quote:
we should create a gantt chart or something lol.. :) like wat I have learnt in project management..

Yah, we larnet gantt charts, PERT and the whole lot in first year and have never touched it since. I think this really only applies on a macro level. That is, really only project managers ever use these tools. Otherwise, you get a situation where most of your time management info is not centralized.

Currently, one of my favorite time management tools for life in general is this:
http://sourceforge.net/projects/progect (provided you have a palm pilot)
It graphically represents your tasks in a hierarchy, listing tasks, their priority, and when they are due. Its also a good place to get your ideas organized because you can leave little info notes around the appropriate task. Very handy :).

Quote:
the game should be a board game.. what I have in mind right now is "Othello game".. have you heard it before? ...lol.. I better think of rpg game or something else :)

Othello is fun :) But I think after having done a board game, we should tackle something a bit different.

Cheers,
- llvllatrix

How to program a chess: a forum based tutorial

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

How to program a chess: a forum based tutorial

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines