What is the best game for beginners to start with?
There''s not much simpler than the towers of hanoi. After making that game, make tic-tac-toe (player vs computer... it''s not that hard), then try programming tetris.
I''ve written a few games, my most recent being a 3D racer, but now I''ve started uni, its back to basics, and our assignment for this first year is to write a tetris game, so I would say yeah, its a pretty good first game, but IMO pong is easier.
----------------
Freeride Designs
----------------
----------------
Freeride Designs
----------------
Author
quote:Original post by Beer Hunter
There''s not much simpler than the towers of hanoi.
What is that?
Towers of Hanoi is more of a puzzle than a game. If I remember correctly, you have three pegs with 3-7 disk of decreasing size on the peg at far right. Objective is to get all the disk over to the far left peg without ever having a larger disk on top of a smaller disk. I think this is it. It was more to show how a seemingly simple problem can quickly take forever (literally) to solve. In mythology once the Tower of Hanoi was finished, the universe would end...gives you an idea of how long it takes with more and more disks.
Just to add my $0.02. I agree with what someone else said, it depends on your level of skill. Definately try not to start off to big, or you will just be dissappointed. If you are just starting to code, try a game of high/low. You type in a number, the computer tells you whether your high or low. Or vice versa. Get the computer to guess your number.
If you''re wanting to do graphics, keep it to a single screen. My first semi-arcade game was in VB where I just blitted all my bitmaps into a picture box. You can also work on smaller projects by not working on a game, but parts of a game. Get a bitmap moving on the screen. Then make it collide with something. Then add animation. A score for killing. Incremental improvement is the way to go...
The important thing is to finish whatever you start. One game guru once said "Your first 10 games will suck. Write them and get them over with." I''ve got at least 8 more to go...maybe more.
Ut
Just to add my $0.02. I agree with what someone else said, it depends on your level of skill. Definately try not to start off to big, or you will just be dissappointed. If you are just starting to code, try a game of high/low. You type in a number, the computer tells you whether your high or low. Or vice versa. Get the computer to guess your number.
If you''re wanting to do graphics, keep it to a single screen. My first semi-arcade game was in VB where I just blitted all my bitmaps into a picture box. You can also work on smaller projects by not working on a game, but parts of a game. Get a bitmap moving on the screen. Then make it collide with something. Then add animation. A score for killing. Incremental improvement is the way to go...
The important thing is to finish whatever you start. One game guru once said "Your first 10 games will suck. Write them and get them over with." I''ve got at least 8 more to go...maybe more.
Ut
I read that same article and made a tetris clone as my first game using C++ and DirectDraw. It was actually quite a bit easier than I thought it would be - but it really helped me to seperate what I thought I understood from what I truly understood. The lack of AI helped me get right down to what I needed to learn - DirectDraw.
I don''t think it matters so much WHAT you program, as long as you make something. And like the article says, complete whatever you start. I almost didn''t bother to make menus because they seemed like a waste of time, and that I would have no problem implementing them in any games in the future. Well it turned out that my concept of how I would design menus was quite a bit different from how I actually managed to get them working. The extra knowlege from adding the menus will help a LOT in my next game (a turn based strategy), where menus will be much more important. Experience is experience - whatever you decide to make, you will be getting experience, and that is all that matters.
I don''t think it matters so much WHAT you program, as long as you make something. And like the article says, complete whatever you start. I almost didn''t bother to make menus because they seemed like a waste of time, and that I would have no problem implementing them in any games in the future. Well it turned out that my concept of how I would design menus was quite a bit different from how I actually managed to get them working. The extra knowlege from adding the menus will help a LOT in my next game (a turn based strategy), where menus will be much more important. Experience is experience - whatever you decide to make, you will be getting experience, and that is all that matters.
quote:Original post by Tom
Geez, you guys don''t know anything. Your first game is supposed to be a massively-multiplayer real-time strategy game with role-playing elements and a true 3D graphics engine.
That seems to be the trend, anyway.
Umm, heh. That may have been a joke... but this is actually what I''m err doing err
Well not entirely true though coz I did do some games on the amiga a while back, heh. Seeing you write that kinda freaks me out and leaves me rather stomped. Nige
I think that, rather than write a game first up, you should write a cross-platform (at least Windows, Dos, Amiga, Mac OS 9.0/X, Linux, Solaris, IRIX, XBox, PS2, PSX, Gameboy, N64, SNES and QNX), which uses highly optimised generic 3D graphics pipelines on each platform, which automatically utilize all hardware optimisations for the selected platform. It needs industry-standard debugging support, a robust object-oriented API, use unbreakable encryption for piracy protection, allow for users to play without lag over the internet, even while using a 9600 baud modem, automatically optimise itself for hardware which hasn''t been developed, modify the OS it''s running under so that it runs more efficiently, even when not running your engine. It''s all hard-coded in assembler, with machine code optimisations. Oh, and it makes you coffee too! :-)
On another note: I''ve recently returned from Hanoi (Viet Nam), and I couldn''t find one single "Towers of Hanoi" game anywhere! They were selling just about everything else - from Hongda motorcycles (direct copies of Honda''s) to Cigarette lighters supposedly from the Vietnam War (or the "American War" as they call it).
Seriously? Ok, I''ll try that for a change :-)
I think you need to make a game you''ll enjoy playing and working on. Because that''s exactly what you''ll have to do in order to finnish it -- you''ll fisrtly need to be excited by the idea, then you need to keep that motivation when you''re lost hopelessly trying to fix some stupid mistake which you''ve missed so many times. Once it''s playable, you''ll need to play it over and over again (unless you have your QA department), coaxing out all those gremlins from your code. When it all works, you should want to play it more... if you''re ashamed of your work, then you really haven''t finished the game, have you? I know I still play the stupid games I wrote in VB3 ages ago, and they crack me up still -- (good) humor always makes the project seem more "completable".
I definately agree that the incremental approach is the way to go -- I still use it today. Start off by creating your structures and classes (I think it''s an awful lot easier with C++...). This is a good time to practice making classes and structs. Once you''ve done this, find out how to create the really basic Win32 stuff that you''ll need - WinMain, Windows and Window Classes, WindProc and message loops. Then, with your empty member functions, start putting the basic logic in. Use comments to remind yourself what you''ll be doing in the function. Once you''ve got the logic happening, start replacing (You might want to leave the comments in, it helps when you''re finding problems or re-reading the code later) the comments with code.
If you don''t know how to replace a comment, write down what it is you need to do. Once you''ve got a list of things you can''t do, find the most fundamental things and go grab info on them. Find everything you can on that thing -- print out websites, buy books, save IRC transcripts, bookmark appropriate message board topics... eventually you''ll have the all the knowledge you need to solve the problem. But before you jump in and write the code, and particularly before you implement a rather complex concept, grab another piece of paper (you should see my desk :-) ) and work is all out on paper. Flow charts are good for designing whole systems, and then take each block and write the code AND comments down. Check your work for any logic errors, then start a NEW project. See if you can implement your idea on its own. Make sure the paper reflects the changes you make in the code.
Now you have a working test, zip up the project and delete the folder. If you haven''t mastered the problem yet, then creating it again might do the trick. And, by implementing it a second time, you might just find a novel way of optimising or performing a certain function. Once you''ve solved this problem, cross it off and start on the next.
heeheehee... Long post by crazy Australian :-)
However, I hope this may help somebody, and yes, that''s the way I solve problems. And I don''t see why I couldn''t use them for a huge project in a field in which I know nothing about. I grab a piece of paper, think about the structures and interoperability of the seperate components of a system, then create a list of problems and away I go.
Well, I''ve waffled on for long enough... it''s bed time :-)
Best of Luck!
Simon Wilson,
XEOS Digital Development
On another note: I''ve recently returned from Hanoi (Viet Nam), and I couldn''t find one single "Towers of Hanoi" game anywhere! They were selling just about everything else - from Hongda motorcycles (direct copies of Honda''s) to Cigarette lighters supposedly from the Vietnam War (or the "American War" as they call it).
Seriously? Ok, I''ll try that for a change :-)
I think you need to make a game you''ll enjoy playing and working on. Because that''s exactly what you''ll have to do in order to finnish it -- you''ll fisrtly need to be excited by the idea, then you need to keep that motivation when you''re lost hopelessly trying to fix some stupid mistake which you''ve missed so many times. Once it''s playable, you''ll need to play it over and over again (unless you have your QA department), coaxing out all those gremlins from your code. When it all works, you should want to play it more... if you''re ashamed of your work, then you really haven''t finished the game, have you? I know I still play the stupid games I wrote in VB3 ages ago, and they crack me up still -- (good) humor always makes the project seem more "completable".
I definately agree that the incremental approach is the way to go -- I still use it today. Start off by creating your structures and classes (I think it''s an awful lot easier with C++...). This is a good time to practice making classes and structs. Once you''ve done this, find out how to create the really basic Win32 stuff that you''ll need - WinMain, Windows and Window Classes, WindProc and message loops. Then, with your empty member functions, start putting the basic logic in. Use comments to remind yourself what you''ll be doing in the function. Once you''ve got the logic happening, start replacing (You might want to leave the comments in, it helps when you''re finding problems or re-reading the code later) the comments with code.
If you don''t know how to replace a comment, write down what it is you need to do. Once you''ve got a list of things you can''t do, find the most fundamental things and go grab info on them. Find everything you can on that thing -- print out websites, buy books, save IRC transcripts, bookmark appropriate message board topics... eventually you''ll have the all the knowledge you need to solve the problem. But before you jump in and write the code, and particularly before you implement a rather complex concept, grab another piece of paper (you should see my desk :-) ) and work is all out on paper. Flow charts are good for designing whole systems, and then take each block and write the code AND comments down. Check your work for any logic errors, then start a NEW project. See if you can implement your idea on its own. Make sure the paper reflects the changes you make in the code.
Now you have a working test, zip up the project and delete the folder. If you haven''t mastered the problem yet, then creating it again might do the trick. And, by implementing it a second time, you might just find a novel way of optimising or performing a certain function. Once you''ve solved this problem, cross it off and start on the next.
heeheehee... Long post by crazy Australian :-)
However, I hope this may help somebody, and yes, that''s the way I solve problems. And I don''t see why I couldn''t use them for a huge project in a field in which I know nothing about. I grab a piece of paper, think about the structures and interoperability of the seperate components of a system, then create a list of problems and away I go.
Well, I''ve waffled on for long enough... it''s bed time :-)
Best of Luck!
Simon Wilson,
XEOS Digital Development
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
