Not rocket science – part 1

Debunking Oh, that would be *very* difficult! – part 1

In this series of articles, I plan to look at simple building blocks of games programming, leading to programming a simple game.

Since the author has minimal experience of writing games he isn’t the best person to be trying to “teach” others.

I was amazed to hear about this programming series, but I didn’t know exactly how the game was going to be written, or implemented on SEVEN different platforms, each with a different BASIC, and two different processors.

Your correspondent knew that BASIC probably wouldn’t be involved from the first episode simply because one of the target platforms was a console. On top of that, the stated aim was to use the design of the Intellivision game Astrosmash – an action game based loosely on Asteroids – as a base, trying to implement that kind of high speed action game from BASIC wouldn’t produce a favourable outcome.

I’ve now found out that, although this course will be using Z80 Assembler and 6502 Assembler, it’s not really a case of learning to program in those languages, but how to use an extensive game template linked with another two files, where most of the code has been prepared. It could be a bit like a game making package, such as “Shoot ‘Em Up Construction Kit”, although in this course you actually type in or modify a few lines which represent a small percentage of the total code and you don’t have to learn many Z80 or 6502 instructions.

Again, the author’s arrogance means that he has no information to work from but still wrongly believes that he’s equipped to make guesses at how the Electric Adventures course will play out.

Obviously, there were no such templates around in 1984-1985 when I was being driven slowly round the bend by Commodore BASIC V2 on the C64.

But there were books with programming examples with some of them offering simple frameworks to work from; the author either didn’t read them or wasn’t really looking properly, but that’s his failing rather than anything else.

I asked him how to make the sprites bounce off each other as well. His now legendary reply was “Oh, that would be VERY difficult!” and that was the end of this programming session. This was the point where I gave up on the C64, and decided to look around for a replacement which could also play polyphonic music.

And this is why the author failed to program the C64 – because he gave up. Trying to blame the machine itself, the “C64 group leader”, Jack Tramiel or anyone else for that matter is pointless because they’re not to blame. If the author had really wanted to program like the tens of thousands of people who managed quite happily he would have stuck with it.

And the idea that anything said to the author at a computer club in 1984 is somehow “legendary” is amusing and, again, demonstrates the author’s arrogance.

We’ve already got a big building block for a simple game, which is the program I recently posted in a de debunk. My opponent, the C64 fanatic TMR, has criticised my program as being “cack handed”

Your correspondent actually referred to it as “ham-fisted” rather than “cack handed” and the author not being able to directly quote from one blog to another is just another example of his incredibly poor comprehension.

The revised program appears to use a better solution, but until we see how it handles sprites colliding from different angles it’s hard to be sure it properly solves the problem.

and even refused point blank to convert this listing into Commodore BASIC V2 for the C64. I’m not sure why this is, but it’s probably for some really nasty and devious reason, such as gaining a feeling of superiority by actively trying to prevent other people from learning to program.

The author may not be sure but a reason was clearly stated: your correspondent isn’t here to entertain the author by jumping through the hoops he specifies and the author needs to grow out of his childish sense of entitlement if he believes otherwise. There are no “really nasty and devious” reasons involved in the real world, all of that is merely inside the author’s head.

Of course, PEEK and POKE commands can’t be used with the same memory locations, or in the same way on MSX as on Tandy/Dragon. Even some of the numbers to PEEK and POKE are different on the Dragon and Tandy, which was to avoid legal problems because the Dragon was based on the Tandy Colour Computer.

Your correspondent has to wonder why the author hasn’t whined about the use of PEEK or POKE on these machines but presumes it’ll be because he isn’t trying to blame them for his own previous failings.

This entry was posted in Debunking and tagged , , , . Bookmark the permalink.