Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

arwez

Help, I dunno how to game program!

This topic is 6638 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I got Lamothe''s Game programming guru, and read it all the way through the direct draw stuff. I learned about surfaces,page flipping, animation, etc. I feel I wasted my money because I have no idea what to do now! Any ideas on what I should do next?

Share this post


Link to post
Share on other sites
Advertisement
Hi,

It depends on how good you are. If you are a newbie you maybe should try to DO something instead of just reading.
Many people talk about programming but never do anything.
First try to make a little object flying around using the mouse.

After a few improvements and other progstuff you may start doing a PacMan/tetris game.

Remember to actually DO stuff, not only reading!

Good Luck on your quest for a better programmer.

/DDnewbie


Newbie

Share this post


Link to post
Share on other sites
Haha, that''s the exact same problem I have. The book is packed with information, but the one thing I miss from his other books is little "homework" assignments at the end of earch chapter. It''s also pretty frustrating that you don''t get to slap a sprite (or BOB I guess) or bitmap on the screen until almost page 400! Well, this is the reality that is "I don''t know how to program in windows but want to write a windows game".

I haven''t quite figured out what to do next either. I want to get started writing something, but I feel like if I don''t read all the way to the end of the book I might miss something that''s going to make me have to back track and re-write all my code.

Probably the real dilema I have right now is wanting to fly before I can crawl. Like DDnewbie said, write a game that''s so bleeping primitive you wouldn''t show it to your dog. Write a game about the magic dog that disappears off the screen when you push the "d" key. Woo, how amazing. But if you can do that, you''re learning something.

If what you''re looking for is say, how to write a tile based zelda looking game, go find a tutorial on writing a tile based game, and use the LaMothe book for referense. That''s how I stumbled across gamedev.net today. It doesn''t even have to be a windows tutorial, that''s what the book is good for. When I finished taking my final for C programming, I ran home all pumped to write a game. I had no idea where to start. I ended up finding a tutorial for writing a dungeon crawl game for Macintosh, but I was able to translate the ideas and implemented them in a text based DOS environment (made something that looks like rogue).

I dunno, like I already said, I''m stuck too. If someone''s got a better suggestion, shout it out. (please!)

Share this post


Link to post
Share on other sites
Can I give you some suggestion?

1)Reading some book it''s important but in my opinion it''s better to read and play with source codes.
If you are interested in OpenGL, DirectX or other platforms you find a lot of free examples on the net.

2)You cannot write a game (or other applications) from zero...you need to create some functions that resolve simple problems and link them together to create more complex ones (blitting functions -> sprite functions).
Remember: try to recycle every line of code you write!

3)Be patient and dont start with too complex projects.

Share this post


Link to post
Share on other sites
This reminds me of a kid... he read though that very same game programming book, memorized most of the code from the book, and decided it was time to make the game. He figures, ''well, since I read his book, I can program! haw haw!" well, boy was he wrong! He couldn''t program- all he could do was regurgitate the source code from LaMothe''s book, ignorant of what each line of code actually does, and expect to call himself a game programmer. That kid, was me! I later learned that game programming doesn''t consist of you actually reading a game programming book and memorizing the source code with a blind eye to what it actually does- those books assume that you already know C, or C++. Thus, you must learn all the concepts behind C++ before you can truly program a game. Otherwise, you''re not game programming! I''m not sure if this applies to you arwez, but if it does, you MUST learn the concepts behind the actual language before you can actually understand the concepts taught in those books, as well as program fluently. I suggest buying a REAL C++ book. Check out some cool reviews in the book section of this site! Again, this my apply to you, but I felt it needed to be addressed...

Programming::~Fredric(const Annoy_Ance)

Share this post


Link to post
Share on other sites
Heheh, you are just like me. I am in the exact same spot as you are, I have read the same book and I am stuck, But what I am doing is reading " Sams Teach Yourself C++ in 21 Days" on www.informit.com after that I well read "C++ Reference Edition". Then i well read the book over again and it should be a breeze. The two books were recomended from one of the gamedev.net.

--ARCHIGAMER

Share this post


Link to post
Share on other sites
Hehe, do we all have the same history
About 10 years ago I got my first computer (an ATARI 1040), and only had one disk containing some tools and a basic interpreter. Well I read the manual and memorized a little program for a countdown from 10 to 0, not a clue what those lines really did
(Am I starting to get totally offtopic ?)

-Markus-

Share this post


Link to post
Share on other sites
Ok, I am a professional game programmer (I''ll admit they are simple little video slot machine games, but run on Win98 using DirectDraw and DirectSound, and require all the basics of a normal game except network support), and I''m here to help you all out.

First, there are MANY different areas to be mastered to become a GOOD programmer, game or otherwise. And most of these skills work WITH each other. There is not a certain order you must tackle them in, but you must realize that you will never be able to say, I''m done learning how to program, now I''ll put my knowledge to work. You will ALWAYS be learning how to program, by using what you know and adding to it each experience you have. Programming is problem solving, and the whole basis of problem solving is that each problem is somehow different than the last, but they can be solved by using similar approaches.

Step 1: Learn the BASICS of some programming language. This means learn the syntax enough to generate some output, and UNDERSTAND it enough to be able to PREDICT the output correctly. For this, I think that a school text book is best, not an over-the-counter reference. Everyone who has posted on this thread has already passed this stage.

Step 2a: Learn the concept of Abstract Data Structures. These are linked lists, stacks, queues, etc... Once again you need an academic style book for this. No matter how well you understand DirectDraw''s Blt() routines, or how to play sounds, you will never be able to actually solve a problem with a program until you understand data structures. These are the common building blocks of ALL computer programs.

Step 2b: Learn the basics of input and output in you desired programming system. This step can be learned before 2a, but 2a must be conquered before you can do anything truely interesting. NOTE: my first 2 programs were in GWBASIC, and I had NO understanding of programming in general, they were an AD&D NPC generator, and a program that simply played a piece of music (that I had from Junior High Band) when the user pressed the ''P'' key. These are BABY programs, they in no way taught me how to write real programs, because they were mearly simple syntax memorization exersises, but without them I would never have continued on as a programmer. So feel free to spend as much time as you want writting simple little applets that do silly things with the screen or speakers (or mouse, or whatever), but realize that ALL of these little exercises do not add up to the ability to program. They are the fun things you do cause you WANT to program. But understanding program logic, data structures, object oriented design, etc, THAT is programming.

HERES WHERE I THINK YOU ALL ARE
Step 3: Once you have played around with some technical experiments, and learned enough programming concepts to be dangerous (you should know about as much as taught in the first college or high school programming class), then it''s time to think in terms of GAMES. I highly recommend you advance your knowledge of technical details AND your understanding of general programming, in parallel. Here''s how. When you don''t know what to do next...look for problems that meet following criteria:

1. Something you are familiar with (ie Checkers, Tetris).
2. Extremely simple in its most basic form. (such as as the ability to create a text based checkers game, or a simple 2d tetris with no sound).
3. Able to be spiced up by increasing / changing graphics or sound.

Here''s a sample development path.
1. You decide to program an Othello game.
2. You analize the rules and write them out by hand.
3. You decide on an internal representation (data structure) for the game information (board, score, etc).
4. You code a simplified version of these structures, which impose few rules on the game.
5. Add code which allows you to set (place) a piece onto any square of the board.
6. Add code to follow the games rules upon placing such a piece (don''t allow overlapping, change opponents pieces when captured .. etc)
7. Add a simple routine to draw such a board on the screen using DirectDraw.
8. Add a simple mouse or keyboard interface for clicking a squre to place a piece on.
9. Add logic to change players after each valid move.
10. Etc ... Etc ... etc...

You see? Choose a SIMPLE game, that could be played in either a text-based or 2d enviroment. And then simply GROW a game. Simply get a very crude game into place, and then systematically improve the pieces.

Slowly, as you grow in skill, your game of conect-four, can go from s cheesy little text based experiment, to a 3D game with rotating cameras, dynamic lighting, and a physics engine. The whole point is to choose a game where the additional levels of refinement are not NECESSARY, but instead are COOL ... that way instead of creating a really crappy imitation of Quake, you can create the COOLEST version Backgammon ever made. You will find that this allows you to use your simple game as the vehicle to learn whichever technologies interest you most. If you want 3D, it''s 3D backgammon, if you want to create onlines games, it''s now a 6 player internet version of Chinese Checkers.

Trust Me, stick to the games you know and understand while learning the basics, THEN, as you master the details of dynamic memory managerment, client server architectures, 3D rendering algorithms, or whatever, you can begin work on whatever original ideas you''ve built up as you were learning to program.

Share this post


Link to post
Share on other sites
Oh, I also really wanted to say this:

DO NOT attempt to reuse all of your code. When learning to program you should not attempt to reuse code between projects if you see a better way to do things.

I have coded 4 different windows skeletons, each one significantly better than the last. If you worry about reusing your code, you will stagnate on solutions that are below your current level of experience. During my first 2 years of coding I found that the half-life of my code was just over 2 months long, meaning that looking at code more than 3 months old was USELESS, because I had since gained a much better understanding of programming and the issues at hand.

It is only AFTER you have gained the experience to understand what you are writting, usually on you second or third attempt at solving a particular problem, that you should attempt to create a modular and reuseable design. My current project (my third total) is built about 60% on the modules I wrote for my last project, but only about 10% of those modules did not benifit from any new improvements during the development of this project. As you gain more experience you will notice a funny paradox:

1. You will build up a library of modules that help you create programs much more easily and quickly.

2. You will have the skill to rewrite or improve those same module in less than half the time they originally took to create.

My solution is to keep my library of modules, but allow my self to improve and replace them constantly, therefore there are much more like a living growing entity, than a completed set of off-the-shelf components.

P.S. Never grow too attacted to just one way of doing things, there is ALWAYS a better way. By coralary - don''t waste all of your time trying to achieve a perfection that cannot be attained, make everything good ENOUGH, or perhaps a little bit better, and then move on to other problems that are not yet complete.

Share this post


Link to post
Share on other sites
There is no reason to rush into windows. Think about this, why do schools always start beginners with DOS? They do this so you can learn how to perform functions without the windows overhead. Windows programming is not hard, but if you are starting go DOS. Honestly, do you think that you are going to be able to sell your first game? Who cares if noone uses DOS anymore, because you will be the only person to run the game, and if you want to show it off here, I am sure that most of the people here can run DOS programs.

Video game programming is not easy. There is a reason why CS majors have to take a lot of math classes. They have to learn how to think like a programmer. You have to carry the problem solving skills that you use in Calculus and Stat, and Discrete Math classes into programming. You have to learn how to break problems down into smaller problems, and then break the small problems into smaller ones. Programming is a very creative field. I think good programmers are more creative than artist, designers, and musicians put together. Think of it this way. When doing 3D, there is one basic way to render a 3D world, but there are an infinite number of optimizations(portals, bsp, etc) that can be made. It is the good programmers, the creative ones that come up with new ways to doing things.

Domini

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!