Hi, first off, great job Teej! The tutorials have really gotten things rolling for me. I am now trying to make a tetris clone but I am trying to make a GUI for it that is reusable and I am having some trouble getting started. I was hoping that you might do a article on game GUIs at some point.
"Fall seven times, stand up eight."
-Japanese Proverb
01.03 - Comments and Suggestions
Author
Hi,
It''s fairly obvious that everyone wants to get into 3D, as that''s where today''s games are, but I''d like to emphasise that since the heart of game development is the design, implementation and development of algorithms, it really doesn''t matter how the game looks. The fundamentals of game development consist of the skills one needs in order to write any type of game, regardless of genre or technology. We all need to learn how to make games by taking challenges and conquering them, and that''s the type of skill I''m trying to teach -- when you look past the 3D graphics, it''s just a game, the same as any 2D game.
Here''s how I see it... we need to get our ''feet wet'' by creating smaller, simpler games in the tradition of the arcade classics, and slowly (and strategically) incorporate larger, more robust games that highlight various aspects of game development. This journey will ultimately end with you having the ability to envision, design and create any game imaginable, as you will have ''collected'' all of skills fashioned from such a comprehensive journey. Getting to 3D is an eventuality, but you''ll have to realize that 3D is just a graphical interface -- nothing more. It lies lower on my list of priorities than, let''s say, proper data handling techniques and speed vs. functionality trade-offs.
So, in a nutshell, yes we''ll be getting to 3D. Not because 3D is the ultimate goal though -- just because it''s an asset to certain types of games.
Teej
It''s fairly obvious that everyone wants to get into 3D, as that''s where today''s games are, but I''d like to emphasise that since the heart of game development is the design, implementation and development of algorithms, it really doesn''t matter how the game looks. The fundamentals of game development consist of the skills one needs in order to write any type of game, regardless of genre or technology. We all need to learn how to make games by taking challenges and conquering them, and that''s the type of skill I''m trying to teach -- when you look past the 3D graphics, it''s just a game, the same as any 2D game.
Here''s how I see it... we need to get our ''feet wet'' by creating smaller, simpler games in the tradition of the arcade classics, and slowly (and strategically) incorporate larger, more robust games that highlight various aspects of game development. This journey will ultimately end with you having the ability to envision, design and create any game imaginable, as you will have ''collected'' all of skills fashioned from such a comprehensive journey. Getting to 3D is an eventuality, but you''ll have to realize that 3D is just a graphical interface -- nothing more. It lies lower on my list of priorities than, let''s say, proper data handling techniques and speed vs. functionality trade-offs.
So, in a nutshell, yes we''ll be getting to 3D. Not because 3D is the ultimate goal though -- just because it''s an asset to certain types of games.
Teej
Hello, Teej;
Considering the skill level that most of the participants in this forum seem to possess, your approach to game development is bang on. The only change that I might be inclined to make would be to use object oriented programming principles a little more. But, at this level, it probably doesn''t matter all that much.
I do have two suggestions -- one for the people who are following this tutorial series and one for you. (I apologize in advance if you find these suggestions a little harsh, but they have been bugging me for months.)
1. For the people following the tutorials: Although Teej says that there is no such thing as a stupid question, I have to disagree. When the same question has been answered twenty times, it is pretty obvious that the questioner is just too lazy to go back and review previous installments. I don''t think that it is asking too much for people to review the material that Teej has written BEFORE posting questions. This could save an awful lot of space in some of Teej''s later tutorials which presume that you have mastered what came before (see, for example, 04.09 - Game States and Variable Scope). Also, you should supplement Teej''s material with the articles from GameDev.net and perhaps from one or two books (e.g, Andre LaMothe).
2. For Teej: You are doing a fantastic job - I love your style and enjoy everything that you''ve written, whether it is new to me or whether I am already familiar with the material. BUT, could you please stop promising to post new material. Promising more that you can deliver is a real turn-off and it detracts from the wonderful job that you are doing. It would be better if you simply said that you will post new material when (and if) you have the time to do it.
Keep up the good work!
PS: one minor point -- could you please use a spell check on your articles before posting
Considering the skill level that most of the participants in this forum seem to possess, your approach to game development is bang on. The only change that I might be inclined to make would be to use object oriented programming principles a little more. But, at this level, it probably doesn''t matter all that much.
I do have two suggestions -- one for the people who are following this tutorial series and one for you. (I apologize in advance if you find these suggestions a little harsh, but they have been bugging me for months.)
1. For the people following the tutorials: Although Teej says that there is no such thing as a stupid question, I have to disagree. When the same question has been answered twenty times, it is pretty obvious that the questioner is just too lazy to go back and review previous installments. I don''t think that it is asking too much for people to review the material that Teej has written BEFORE posting questions. This could save an awful lot of space in some of Teej''s later tutorials which presume that you have mastered what came before (see, for example, 04.09 - Game States and Variable Scope). Also, you should supplement Teej''s material with the articles from GameDev.net and perhaps from one or two books (e.g, Andre LaMothe).
2. For Teej: You are doing a fantastic job - I love your style and enjoy everything that you''ve written, whether it is new to me or whether I am already familiar with the material. BUT, could you please stop promising to post new material. Promising more that you can deliver is a real turn-off and it detracts from the wonderful job that you are doing. It would be better if you simply said that you will post new material when (and if) you have the time to do it.
Keep up the good work!
PS: one minor point -- could you please use a spell check on your articles before posting
hey teej
i just wanted to say thanks for the great site im really learning alot and am well on my way to making my first game
i wanted to let you know that the link to your site under the animation anticipation string is dead i guess your adress changed anyways thanks for everything =D
i just wanted to say thanks for the great site im really learning alot and am well on my way to making my first game
i wanted to let you know that the link to your site under the animation anticipation string is dead i guess your adress changed anyways thanks for everything =D
Author
Weatherman: Thanks for the comments. I totally agree with you -- it''s a little psychological game I play with myself (and tend to lose), figuring that if I promise a due date, I force myself to meet it. In the future, I''m going to do exactly as you''ve mentioned. Maybe with the self-inflicted stress removed, I''ll (ironically) get more accompished!
Teej
Teej
hey teej i wanted to say again your doing a great job this is by far one of the best tutorials ive ever seen! !=o)
i have knoticed also that there are multiple posts in almost every string of this forum informing you of problems with your web site. so i was thinking maybe it would be wise to make a dedicated string for reporting problems so that way it would clear the articals up for posts relivent to the topic and make the forum a little more organized.
but after all its up the postee to make sure his/her post is in the right place.
and just to reiterate, good job man!
i have knoticed also that there are multiple posts in almost every string of this forum informing you of problems with your web site. so i was thinking maybe it would be wise to make a dedicated string for reporting problems so that way it would clear the articals up for posts relivent to the topic and make the forum a little more organized.
but after all its up the postee to make sure his/her post is in the right place.
and just to reiterate, good job man!
Hey Teej can you give us a tutorial on how to make MENUS for our games in MSVC++? I have a couple books that talk about it but none of the ways they show me seem to work and the "helpful, simplified" wizard they provide to make resources in MSVC++ ISN''T so helpful and simplified.
That and I''d like to see us make games in a resizeable window on the desktop.
That and I''d like to see us make games in a resizeable window on the desktop.
Menus the VC++ way tend to make large use of MFC, which is bad form for game programming, due to MFC having way too much overhead to have decently-sized games be playable. MFC stuff is much more valuable in the game programming world for things such as tools and editors, which perhaps the forum will get to eventually.
As for windowed applications, that involves making a few necessary tweaks to the way DirectDraw is set up, and the way the window is set up, which maybe Teej will also get to in a future article. Windowed games are nicer for debugging (especially with VC++...when you can actually USE its debugging features).
Speaking of debugging, before most people get too entrenched in coding larger games (Blocks ''n Lines should be fine without good debugging practices), but might I suggest an article on debugging, that perhaps takes into account windowed DirectDraw, or keeping variables written to the screen, so that people may not get as frustrated when trying to get something working? I can''t count the number of times good debug code has helped find the errors I''ve made in practice.
As for windowed applications, that involves making a few necessary tweaks to the way DirectDraw is set up, and the way the window is set up, which maybe Teej will also get to in a future article. Windowed games are nicer for debugging (especially with VC++...when you can actually USE its debugging features).
Speaking of debugging, before most people get too entrenched in coding larger games (Blocks ''n Lines should be fine without good debugging practices), but might I suggest an article on debugging, that perhaps takes into account windowed DirectDraw, or keeping variables written to the screen, so that people may not get as frustrated when trying to get something working? I can''t count the number of times good debug code has helped find the errors I''ve made in practice.
quote:
Menus the VC++ way tend to make large use of MFC, which is bad form for game programming, due to MFC having way too much overhead to have decently-sized games be playable. MFC stuff is much more valuable in the game programming world for things such as tools and editors, which perhaps the forum will get to eventually.
You don''t need to use MFC to create menus for your games. Also, when the player uses a menu, he/she probably doesn''t need blinding speed at that particular moment.
By the way, MFC isn''t quite as slow as some people have tried to make out -- unless you have a very old computer (e.g. a 80486). You could even program "Blocks and Lines" without DirectDraw and still get very good response times with most computers.
You are right that MFC comes into its own for programming tools and editors.
Can anyone walk me thru how to make a MENU RESOURCE in VC++? Just a quik menu with FILE and EXIT under file to exit the program[&FILE->E&xit]. I understand about the ID''s and how WndProc interpret''s them.
Or point me in the right direction to find info on it. Help is confusing.
Any help greatly appreciated.
Or point me in the right direction to find info on it. Help is confusing.
Any help greatly appreciated.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement