I guess the best idea is to just try stuff and get practsie. Which language you choose to program in is entirely down to your own personal choice. Try a few and see which ones you like. For example, you might get totally confused by C but might take to (say) Lua. But the good news is for almost every language out there, there's going to be a free version avaliable somewhere.
I's not like the "bad old days" (I'm thinking of the 386/486 PC and to a lesser extent Amiga worlds) any more when unless you wanted to just do print "HELLO WORLD" (e.g. AmigaBASIC, GWBasic, Qbasic) a programming language would cost an absolute fortune, and even if you could afford it there were all kinds of restrictions on its use. It wasn't so long ago that almost every language cost a fortune, and once you bought it if you compiled something with it, you either had to pay royalties to some company, or you couldn't distribute it at all. Sometimes programming languages could be had from elsewhere, but they were either shareware or just very simple, or lacked lots of features.
Going back even further into the 80s I remember the type-ins from magazines from the old 8-bit computers of yesteryear. I had a commodore 64 myself, and it has been said since the commodore 64's built in basic was so bad (which it was!) many opted to go straight to assembly language! I was a kid at the time back then
!
On the type-ins from the 80s computer magazines my mileage varies. Sometimes the typeins wouldn't work at all, at other times they were quite a spectacular success. The typeins could be hard work sometimes since in the later years all you saw (especially if you had a commodore 64) was page after page of DATA statements (e.g. DATA 1,154,0,2,6,241) - page after page. But then sometimes it was easy (usually when you were typing in another part, not the DATA statements) if you were typing in a program you would sometimes notice repitition in the program, so sometimes you could guess what number, variable, command etc. was about to turn up next.
Reliability wasn't helped by some magazines accientally or purposely reducing the print quality so that the type ins themselves were hard to read. Some things seldom worked at all, for example to move the cursor down on a commodore 64 you could use the PRINT command followed by an inversed letter "Q" in quotes. Ok, sounds great - but if your program uses several of them and the print quality is bad, it is hard to count them. And if you get it wrong, any text ouptut on the screen won't look right. In the early days of typeins too, and especially on the Commodore 64 - which also had little graphics symbols amoungst the normal text characters magazines would print these too. But it could be very hard to count spaces in-between the graphics symbols! Is that 1 space, 2 spaces...? . Later on, some magazines replaced these symbols with stuff, for example [SHIFT Q] instead of a little ball (You pressed the shift key and the Q key to get the ball graphic), but then strings of [SHIFT Q]s and their ilk can get unreadable.
As for the data statements many of these were actually or in at least part assembly language. So if you got even the slightest thing wrong and you tried to run your program - *crash* ! (therelin lies a lesson applicable even to today -- always remember to save your work!). Looking at the first 3 or 4 lines of a pagefull of DATA statements isn't hard, but by the time you got to the 20th line, your eyes could wander or you'd forget where you were in the line. One old trick was to use another magazine or book to partly cover the magazine page, and after typing in each line you moved the book down a bit. Not good if you or someone else knocks it flying and you forget where you are!
To be fair however some magazines did try to remedy the situation by having "checksum" programs. The typein (listing) would be accompanied by (say) an 8 digit number. You typed in the checksum program first (or loaded it!) and then started work on the typein. As you finished each line, the checksum program would give you a checksum based on what you just typed. The idea was that if you made a mistake, the checksums wouldn't match so you could find any errors easier.
Some limitations were imposed by the hardware of the day. Most people like me with those old 8 bit computers, such as the ZX Spectrum, Commodore 64 and soforth often used a TV as a display. The TV display could be very fuzzy, and you could always misread stuff on your own screen. Fortunatly most computers of the era (for example) had a "0" (with a line through the zero) to make it look completely different from a capital "O", as without it they would look very similar onscreen. Or then there was the ZX Spectrum's odd way of entering BASIC commands into the computer - one key on a ZX Spectrum could contain many commands, and there weren't all that many people who managed to master this odd system. Another problem (unless you managed to remember or had books on the subject) was that many of these systems were memory-mapped (computers these days are not so memory-mapped as yesteryear). For example on the Commodore 64, could you remember memory location 646 was the text/cursor colour?
On programming more modern games, I wouldn't neccecrially say that programming them is boring. But it might not also be exciting. It depends on who is writing the game. If you like games and coding, chances are you'll like doing both.
I just wish these days we had some playable games! I'm not going to say "all old games are good and all new games are bad", but I must admit a large portion of modern-day games are a bit samey; they are drempt up by focus groups or their equivilent and programmed by some corporation somewhere. Result? A corporate toy - the same sort of soul-less rubbish that you get in other areas such as films and TV. Graphics have vastly improved since the 80s, but arguably some things got a lot worse since then too.
Some of the most enjoyable games, ones you can't put down and which will be remembered are the most simple. It's all very well being able to plot x million polygons on the screen, but if it's a you've-seen-it-a-million-times-before style of game (as are a large portion of modern games - different graphics, same everything else, almost aka hollywood!), well .
In programming, the magic is in the programmer, not the language.
ljones
I's not like the "bad old days" (I'm thinking of the 386/486 PC and to a lesser extent Amiga worlds) any more when unless you wanted to just do print "HELLO WORLD" (e.g. AmigaBASIC, GWBasic, Qbasic) a programming language would cost an absolute fortune, and even if you could afford it there were all kinds of restrictions on its use. It wasn't so long ago that almost every language cost a fortune, and once you bought it if you compiled something with it, you either had to pay royalties to some company, or you couldn't distribute it at all. Sometimes programming languages could be had from elsewhere, but they were either shareware or just very simple, or lacked lots of features.
Going back even further into the 80s I remember the type-ins from magazines from the old 8-bit computers of yesteryear. I had a commodore 64 myself, and it has been said since the commodore 64's built in basic was so bad (which it was!) many opted to go straight to assembly language! I was a kid at the time back then
!On the type-ins from the 80s computer magazines my mileage varies. Sometimes the typeins wouldn't work at all, at other times they were quite a spectacular success. The typeins could be hard work sometimes since in the later years all you saw (especially if you had a commodore 64) was page after page of DATA statements (e.g. DATA 1,154,0,2,6,241) - page after page. But then sometimes it was easy (usually when you were typing in another part, not the DATA statements) if you were typing in a program you would sometimes notice repitition in the program, so sometimes you could guess what number, variable, command etc. was about to turn up next.
Reliability wasn't helped by some magazines accientally or purposely reducing the print quality so that the type ins themselves were hard to read. Some things seldom worked at all, for example to move the cursor down on a commodore 64 you could use the PRINT command followed by an inversed letter "Q" in quotes. Ok, sounds great - but if your program uses several of them and the print quality is bad, it is hard to count them. And if you get it wrong, any text ouptut on the screen won't look right. In the early days of typeins too, and especially on the Commodore 64 - which also had little graphics symbols amoungst the normal text characters magazines would print these too. But it could be very hard to count spaces in-between the graphics symbols! Is that 1 space, 2 spaces...? . Later on, some magazines replaced these symbols with stuff, for example [SHIFT Q] instead of a little ball (You pressed the shift key and the Q key to get the ball graphic), but then strings of [SHIFT Q]s and their ilk can get unreadable.
As for the data statements many of these were actually or in at least part assembly language. So if you got even the slightest thing wrong and you tried to run your program - *crash* ! (therelin lies a lesson applicable even to today -- always remember to save your work!). Looking at the first 3 or 4 lines of a pagefull of DATA statements isn't hard, but by the time you got to the 20th line, your eyes could wander or you'd forget where you were in the line. One old trick was to use another magazine or book to partly cover the magazine page, and after typing in each line you moved the book down a bit. Not good if you or someone else knocks it flying and you forget where you are!
To be fair however some magazines did try to remedy the situation by having "checksum" programs. The typein (listing) would be accompanied by (say) an 8 digit number. You typed in the checksum program first (or loaded it!) and then started work on the typein. As you finished each line, the checksum program would give you a checksum based on what you just typed. The idea was that if you made a mistake, the checksums wouldn't match so you could find any errors easier.
Some limitations were imposed by the hardware of the day. Most people like me with those old 8 bit computers, such as the ZX Spectrum, Commodore 64 and soforth often used a TV as a display. The TV display could be very fuzzy, and you could always misread stuff on your own screen. Fortunatly most computers of the era (for example) had a "0" (with a line through the zero) to make it look completely different from a capital "O", as without it they would look very similar onscreen. Or then there was the ZX Spectrum's odd way of entering BASIC commands into the computer - one key on a ZX Spectrum could contain many commands, and there weren't all that many people who managed to master this odd system. Another problem (unless you managed to remember or had books on the subject) was that many of these systems were memory-mapped (computers these days are not so memory-mapped as yesteryear). For example on the Commodore 64, could you remember memory location 646 was the text/cursor colour?
On programming more modern games, I wouldn't neccecrially say that programming them is boring. But it might not also be exciting. It depends on who is writing the game. If you like games and coding, chances are you'll like doing both.
I just wish these days we had some playable games! I'm not going to say "all old games are good and all new games are bad", but I must admit a large portion of modern-day games are a bit samey; they are drempt up by focus groups or their equivilent and programmed by some corporation somewhere. Result? A corporate toy - the same sort of soul-less rubbish that you get in other areas such as films and TV. Graphics have vastly improved since the 80s, but arguably some things got a lot worse since then too.
Some of the most enjoyable games, ones you can't put down and which will be remembered are the most simple. It's all very well being able to plot x million polygons on the screen, but if it's a you've-seen-it-a-million-times-before style of game (as are a large portion of modern games - different graphics, same everything else, almost aka hollywood!), well
. In programming, the magic is in the programmer, not the language.
ljones
