Image
  • Writing
    • Andy Gavin: Author
    • About my Novels & Writing
    • All Writing Posts
    • The Darkening Dream
      • Buy the Book Online
      • Sample Chapters
      • Reviews
      • Info for Reviewers
      • Press Coverage
      • Awards
      • Cast of Characters
    • Untimed
      • Buy Untimed Online
      • Book Trailer
      • Sample Chapters
      • Reviews
      • Info for Reviewers
      • Press Coverage
      • Awards
      • Cast of Characters
    • Scrivener – Writer’s Word Processor
    • iPad for Writers
    • Naughty Dark Contest
  • Books
    • Book Review Index
    • Favorite Fantasy Novels
    • Andy Gavin: Author
    • The Darkening Dream
      • Buy the Book Online
      • Sample Chapters
      • Short Story: Harvard Divinity
      • Reviews
      • Info for Reviewers
      • Press Coverage
      • Awards
      • Cast of Characters
    • Untimed
      • About the Book
      • Buy Untimed Online
      • Book Trailer
      • Sample Chapters
      • Reviews
      • Info for Reviewers
      • Press Coverage
      • Awards
      • Cast of Characters
    • Naughty Dark Contest
  • Games
    • My Video Game Career
    • Post Archive by Series
    • All Games Posts Inline
    • Making Crash Bandicoot
    • Crash 15th Anniversary Memories
    • World of Warcraft Endgames
    • Getting a Job Designing Video Games
    • Getting a Job Programming Video Games
    • Naughty Dark Contest
  • Movies
    • Movie Review Index
  • Television
    • TV Review Index
    • Buffy the Vampire Slayer
    • A Game of Thrones
  • Food
    • Food Review Index
    • Foodie Club
    • Hedonists
    • LA Sushi Index
    • Chinese Food Index
    • LA Peking Duck Guide
    • Eating Italy
    • Eating France
    • Eating Spain
    • Eating Croatia
    • Eating Vietnam
    • Eating Australia
    • Eating Israel
    • Ultimate Pizza
    • ThanksGavin
    • Margarita Mix
    • Foodie Photography
    • Burgundy Vintage Chart
  • Other
    • All Posts, Magazine Style
    • Archive of all Posts
    • Fiction
    • Technology
    • History
    • Anything Else
  • Gallery
  • Bio
  • About
    • About me
    • About my Writing
    • About my Video Games
    • Ask Me Anything
  • Contact

Archive for BASIC

So you want to be a video game programmer? – part 5 – The Method

Sep11

…CONTINUED from PART 4. Or start at Part 1.

This post is presents an algorithm of sorts for learning to program. It applies not only to the fundamentals, but to all aspects, including the acquisition of small component skills. Thirty years after learning, I still follow the same basic procedure. To tell the truth, modified, it works for leaning most things.

Step 1: Goal. Invent some manageable goal that excites you (in a later context as a profession “excites” is often replaced/supplemented by “need”). My first program was a text-based dungeon master (see here). If you want to be a video game programmer, there’s nothing better than a game. If it’s one of your first programs, make it damn simple. Copy some REALLY REALLY old and simple game like anything from before 1981 (Pong, Breakout, etc.). Truth be told, using text only for a couple weeks/months might not be a bad idea. Graphics just complicate matters. They’re awesome — and you’ll need them soon enough — but first the fundamentals, like variables, flow of control, scope, etc. Any individual task should take no more than a few days. If your goal is bigger than that, subdivide.

Step 2: Environment. All programming is done in the context of some environment, and you must learn about it. You need to start with a simple one. In my case it was mostly AppleSoft BASIC. For learning interpreted is good. Some decent starter environments today are Python, Ruby, Flash, Lua. DO NOT START WITH A LANGUAGE LIKE C. I will elaborate on this environment question in a separate full post, as it’s a large topic and highly religious for programmers.

Step 3: Research. This means reading. If you don’t like to read, either learn to or find yourself a new career. I’m serious. Reading separates the Neo Cortexs from the gibbering marsupials. I’m serious. Be a New Cortex. Your love of reading must be so extreme that you can stomach slogging through 900 page Library Reference Manuals (maybe not at first). Programming is full of details.

Step 4: Theory. Get out a pad of paper, a text file, Evernote, or whatever. Design what you are going to do. Later, you might or might not skip this step (and do it in your head), but it’s useful for the beginning programmer. You don’t need to write out the entire program, but you should design your data-structures and modules or functions. If it’s one of your first programs, you should hardly HAVE data-structures. You might instead write down the modes and loose flow chart between them.

Step 5: Code. Actually try coding your program. This is best done in an iterative way. My advice is generally to start with creating your core data-structures, and then the functions or methods that support them. Test each of these individually. Interpreted languages with a listener are the best because you don’t have to write test suites, but can just test the components as you go at the listener. Time spent debugging individual functions and groupings (say all the methods that belong to a data-structure) pays for itself 100-fold. I still do this. The less code you are testing, the easier it is to spot and find bugs. If you know that your functions are reliable (or semi-reliable) they provide robust building blocks to construct with.

Step 6: Debug. See above in “code” because they are heavily intertwined. Coding and debugging happens together in small loops. Again. The less NEW code you have to debug, the better. Debugging is hard for novices. Do not write an entire big program and debug it all at once. If you are using a language that syntax checks, check each function after you have written it. Fix the syntax errors (typos) and then test and debug the single function (or component of a program). Baby steps. Baby steps.

Step 7: Iterate and improve. Just keep adding things to your program to get it to where you want. Add a new feature. Improve an old one. Rip out some system and replace it. Add graphics. Upgrade them. Try to keep each of these changes as small as possible and test after each change. The longer it has been since it ran, the harder it will be to make it run.

_

I can not emphasize how important baby steps are. They are the key to avoiding fatal frustration. I have a law that helps define the size of subtasks: DO NOT EVER LEAVE THE COMPUTER IF YOUR PROGRAM DOES NOT RUN. You can take a piss or stretch. That’s it. I lived by this rule my entire programming career. You can’t always follow it, but try. Get your ass back in that chair. Mom wants you for dinner. Shrug. Your co-workers call you for a meeting. Snarl. I always think of a program like a car engine. You can sometimes merely tune it up, but a lot of times you have to take apart the engine to fix/add something new. That time when the engine is apart (the program does not RUN!) is very important, and should not be very long. If it is, you are not subdividing your tasks enough. I write all sorts of custom code to allow the engine to run again (even if in a half-assed way) while big changes are going on. These intermediate constructs are intended as throw-aways. But they save time. Having your program broken, writing more than a couple hours of new code that has not been tested, is a recipe for disaster. You could easily reach the point where you have no idea where the problem is. If you test in small bits as you go debugging is MUCH easier. Bugs are perhaps 80% likely in the most recently stuff. It’s the smoking gun you goto (haha) first.

You can do a lot with ASCII graphics!

A starter example of this whole process: My first game was a text based D&D type RPG game. I wanted to include a number of “cool” (to a 10 year-old) encounters. So I structured it as follows: There was the “character.” This was to be just a number of global variables (this is long before object oriented programming) like G (gold), HP (hitpoints) etc. I wrote a couple “methods” (functions – but they didn’t have names in BASIC, just line numbers) like “takes a hit.” This subtracts from HP, and if <= 0 branches to the “you are dead” part of the code (not really a function in those days). Then I wrote a number of “encounters.” These were the main flow of control in that program. It popped from encounter to encounter. They might be like: You have met an orc. draw orc on screen with text graphics (aka print statements). present options: “attack,” “run,” “use magic,” etc. wait for input and apply logic. If you are still alive send the player back to the main navigation loop (the place that doesn’t have a particular encounter).

That’s it. I expanded the program by doing things like: Adding more encounters. Adding resurrection as a pay option when you died. Adding an actual map to the main loop. Moving the “combat” logic from individual encounters into a function. Then adding to the character attributes like strength and dexterity which influenced combat. Beefing up character creation. Etc etc. These are all tasks that can individually be accomplished in a few hours. This is key. It keeps your program running most of the time. It provides good feedback on what you are doing.

The entire above “goal” -> “debug” loop can be repeated endlessly. Example: “add a save game.” You now have to save and restore the state of your player (various global variables). But to where? Disk presumably in those days. So you crack the BASIC manual and read about file I/O. First you go simple. There is one save game. It’s always named “adv.sav”. You write a function to open the file and write the vars into it. You examine the file to make sure it put them there the way you want to. You write another function to read the file. You add options to the game menu to call these functions. Then test.

Next baby step. Allow multiple save games. You add “filename” (or save slot or whatever) to the load/save functions. You hardwire it to something and test again. Then you add interface to the game’s main menu to specify which slot. You test that.

Iteration is king! Good luck.

_

Parts of this series are: [Why, The Specs, Getting Started, School, Method]

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

Related posts:

  1. So you want to be a video game programmer? – part 3 – Getting Started
  2. So you want to be a video game programmer? – part 2 – Specs
  3. So you want to be a video game programmer? – part 4 – School
  4. So you want to be a video game programmer? – part 1 – Why
  5. Making Crash Bandicoot – GOOL – part 9
By: agavin
Comments (78)
Posted in: Games, Technology
Tagged as: Andy Gavin, BASIC, Breakout, Computer program, Control flow, Data structure, Debugging, Game programmer, Languages, Learning, Programming, Programming language, pt_career_advice, Python, Ruby

So you want to be a video game programmer? – part 3 – Getting Started

Aug30

…CONTINUED from PART 2. Or start at Part 1.

Some kid is always asking me, “I love video games, how do I learn to program them?”

First of all, a warning. Reaching the skill level to be a professional video games programmer takes years. There are no shortcuts. You can not possibly go from nothing to professional grade skills in less than perhaps 2-3 years — and for that you’d have to be an uber-genius — usually it takes 5-10.

The good news is that you can start very young (8-10 — I started at 10) and you can do it on your own with common equipment and readily available information.

There are two basic approaches: home training and school. And while I personally recommend both, I’m going to use this post to give my own “origin story.” In followups we can apply these lessons to the present (programming itself hasn’t changed all that much in 30 years — there are just more libraries).

[ BTW, if you’re new to the blog and wondering who the hell I am in this context, click ]

Rewind to 1979. Some of my favorite things in the world were Dungeons and Dragons and arcade games. I was really too young to actually play D&D accurately, but I loved reading the books and modules (besides my regular diet of fantasy novels). I went to the Apple Store (not actually owned by Apple or nearly as glamourous as they are today — in fact, the owner resembled Gandalf) and saw the game Akalabeth running on an Apple II (not a + or an e, but an old school II). Boy did that set me to dreaming!

Then in 1980 my science teacher brought into class a Heathkit H8 her husband built (yes built). This early computer ran a lousy version of BASIC and possesed the world’s worst storage device: the audio tape drive. Actually punch cards were worse, but with the tape drive, saving your program bordered on impossible (at least for the sharing audio tapes with the rest of the class) and so you had to type it in repeatedly. We were given a single mimeographed sheet of paper with the BASIC commands. I read this a couple times and then wrote out longhand the first draft of a text-based RPG where you wandered around and fought orcs and trolls for gold and tretchure (this is how I spelled treasure at 10). During lunch I typed in and debugged the game, editing my paper copy as needed. I used my friends as beta-testers. It may seem overly ambitious to try and recreate D&D as one’s first program, but it illustrates the programmer principle of: program what you love.

Then my best friend got himself a brand new Apple II+ (just released). This was a slick update of the Apple II. It had a whole 48k, came with BASIC, and was often (but not always) accompanied by a 143k floppy disk drive! Low low price of $900 just for the floppy drive! In any case, the II+ was so much more awesome than the Heathkit. It even had graphics!

So I began pestering my father for an Apple. This took 9-10 months of continuous harassment — the machine was expensive — and all sorts of creative techniques to convince him. I offered to mow the lawn for free. I explained how various accounting software would make balancing his checkbook a breeze, etc. Once I was victorious (Jan 1981) we got the accounting software, but he never used it, leaving me to my own devices on the machine. And I think I kept getting paid for the lawn. Still, this episode illustrates another important programmer principle: persistence.

After the Apple arrived, I spent nearly all of my free time (perhaps 6-8 hours a day) on the thing for years. This is essential. You must offer up blood onto the alter of the programming gods. Principle: sacrifice. I used this time in many ways. I played a lot of games. I used every piece of software. I taught myself to program. I hacked. Principle: market research. But I couldn’t afford as many games as I wanted and in those early years the available library was small, so I was always trying to make my own.

I wrote totally lame versions of nearly every arcade game ever made. In BASIC at first (we’ll get to the issue of environment later). I would generally spend a day or three banging these out until they were marginally playable and then move on to new projects. Lesson here: practice. I chose more and more ambitious games and would use each one to teach me something new. I did this in incremental steps, mostly 1-2 day projects. By way of example, I might upgrade something or I might add a load/save system (requiring learning about I/O). My early games didn’t have much in the way of collision, later ones did. I started with text, then moved up to lores graphics, then highres, then shape tables, then bits of assembly language subroutines for blitting. Principle here: baby steps.

Baby steps are incredibly important. You can’t learn everything there is to know in computers in one shot. Each little area takes multiple projects and days — at least — to learn and master. Take file I/O. I’m sure I got something up and going the first day or two back in the early 80s when I decided to add a load/save system, but I was still learning about file I/O 25 years later on Jak 3 (of course then I was inventing new ways of doing stream I/O, but it was learning nonetheless). Your first pass might work, but often you barely understand any of the principles involved.

You have to start simple, build up blocks, and go from there. That’s why interpreted languages and text programs are a good way to begin. You need to learn about variables, scope, and flow of control before you can jump into 3D graphics. And forget about complex unforgiving environments like C/C++ or assembly to begin with. Those come later and are just one more thing to spend a series of baby steps on. Just learning about makefiles or projects and compile options could stop a novice dead. So don’t — yet. Each task (and thing to learn) should be broken into some chunk that only takes a couple days at most to digest — or at least make some headway on. This leads to a virtuous feedback loop of progress and learning.

I kept writing those lame little games for about 3 years (100s of them). Of all my friends with computers (we all programmed in that era because computers didn’t do much if you didn’t program) my games were the coolest. I used them to invent all sorts of excuses to develop new skills. I wanted to learn about interpreters so I made an engine to allow the creation of text adventure games using a custom scripting language. Once I got this going I upgraded it to graphic adventures, which proved to be a perfect excuse to implement an idea I had seen in the Sierra games where line drawing and fill commands were used to compress images to a fraction of their raw size. On the Apple II a raw graphics screen was 8k. So a floppy only fit 17. A normal compressor (ancestor of zip) might squeeze this to 3-4k but that is still only 30-35 images. This “save the drawing commands” style made them a fraction of that. But for it to work I not only had to create the “renderer” (including an assembly fill routine) but I also a whole “paint program” to allow the recording/creation of these proprietary images.

However, each of these sub-steps resulted in satisfying progress on its own. Principle: chunking. For example that fill routine. It took several days, and my mastery of recursion in assembly wasn’t the best so it left little corners unfilled, but it was cool in of itself. My first fill routine (in BASIC) took 5 minutes to do a fill, and the assembly one only a second or two. Plus, I was to keep using it in all sorts of programs for years (with improvements). Principle: reuse. Building on the tools you make is essential to programming.

In 1982, I met Jason Rubin. He also programmed. He was an amazing (by the standards of the time and our age) artist and his games LOOKED REALLY COOL. But they crashed a lot. Mine rarely did. From the beginning I hated crashing. Still can’t tolerate it. I have trouble leaving the keyboard if a crash bug is still outstanding. Principle: perfectionism. My programs also did much cooler “programming” stuff. They just didn’t look cool. When we combined our talents, things really took off! Our games now looked cool AND ran decently. Impressive stuff. Lesson: partnership. Not everyone can be good at every aspect of computers. Nor even of programming itself.

CONTINUED with Part 4 – School!

_

Parts of this series are: [Why, The Specs, Getting Started, School, Method]

If you liked this post, follow me at:

My novels: The Darkening Dream and Untimed
or the
video game post depot
or win Crash & Jak giveaways!

Latest hot post: War Stories: Crash Bandicoot

Related posts:

  1. So you want to be a video game programmer? – part 2 – Specs
  2. So you want to be a video game programmer? – part 1 – Why
  3. How do I get a job designing video games?
  4. Matsuhisa – Where it all started
  5. Making Crash Bandicoot – GOOL – part 9
By: agavin
Comments (27)
Posted in: Games, Technology
Tagged as: Andy Gavin, Apple, Apple II, Apple II series, Apple Store, BASIC, Computer Programming, Dungeons & Dragons, Floppy disk, Game programming, Heathkit, Origins, Programming, pt_career_advice, Steve Jobs
Watch the Trailer or

Buy it Online!

Buy it Online!

96 of 100 tickets!

Find Andy at:

Follow Me on Pinterest

Subscribe by email:

More posts on:



Complete Archives

Categories

  • Contests (7)
  • Fiction (404)
    • Books (113)
    • Movies (77)
    • Television (123)
    • Writing (115)
      • Darkening Dream (62)
      • Untimed (37)
  • Food (1,481)
  • Games (100)
  • History (13)
  • Technology (21)
  • Uncategorized (16)

Recent Posts

  • OOToro Double
  • Robo Eats – Anarbagh
  • Fred loves N/Naka
  • Major Major Major
  • Far East – Beijing Tasty House
  • Home Sweet Spicy Home
  • Quick Eats – Bafang
  • Quick Eats – Peking Restaurant
  • Quick Eats – MK BBQ
  • Wolfing it Down

Favorite Posts

  • I, Author
  • My Novels
  • The Darkening Dream
  • Sample Chapters
  • Untimed
  • Making Crash Bandicoot
  • My Gaming Career
  • Getting a job designing video games
  • Getting a job programming video games
  • Buffy the Vampire Slayer
  • A Game of Thrones
  • 27 Courses of Truffles
  • Ultimate Pizza
  • Eating Italy
  • LA Sushi
  • Foodie Club

Recent Comments

Archives

  • March 2023 (9)
  • February 2023 (11)
  • January 2023 (14)
  • December 2022 (11)
  • November 2022 (13)
  • October 2022 (14)
  • September 2022 (14)
  • August 2022 (12)
  • July 2022 (9)
  • June 2022 (6)
  • May 2022 (8)
  • April 2022 (5)
  • March 2022 (4)
  • February 2022 (2)
  • January 2022 (8)
  • December 2021 (6)
  • November 2021 (6)
  • October 2021 (8)
  • September 2021 (4)
  • August 2021 (5)
  • July 2021 (2)
  • June 2021 (3)
  • January 2021 (1)
  • December 2020 (1)
  • September 2020 (1)
  • August 2020 (1)
  • April 2020 (11)
  • March 2020 (15)
  • February 2020 (13)
  • January 2020 (14)
  • December 2019 (13)
  • November 2019 (12)
  • October 2019 (14)
  • September 2019 (14)
  • August 2019 (13)
  • July 2019 (13)
  • June 2019 (14)
  • May 2019 (13)
  • April 2019 (10)
  • March 2019 (10)
  • February 2019 (11)
  • January 2019 (13)
  • December 2018 (14)
  • November 2018 (11)
  • October 2018 (15)
  • September 2018 (15)
  • August 2018 (15)
  • July 2018 (11)
  • June 2018 (14)
  • May 2018 (13)
  • April 2018 (13)
  • March 2018 (17)
  • February 2018 (12)
  • January 2018 (15)
  • December 2017 (15)
  • November 2017 (13)
  • October 2017 (16)
  • September 2017 (16)
  • August 2017 (16)
  • July 2017 (11)
  • June 2017 (13)
  • May 2017 (6)
  • March 2017 (3)
  • February 2017 (4)
  • January 2017 (7)
  • December 2016 (14)
  • November 2016 (11)
  • October 2016 (11)
  • September 2016 (12)
  • August 2016 (15)
  • July 2016 (13)
  • June 2016 (13)
  • May 2016 (13)
  • April 2016 (12)
  • March 2016 (13)
  • February 2016 (12)
  • January 2016 (13)
  • December 2015 (14)
  • November 2015 (14)
  • October 2015 (13)
  • September 2015 (13)
  • August 2015 (18)
  • July 2015 (16)
  • June 2015 (13)
  • May 2015 (13)
  • April 2015 (14)
  • March 2015 (15)
  • February 2015 (13)
  • January 2015 (13)
  • December 2014 (14)
  • November 2014 (13)
  • October 2014 (13)
  • September 2014 (12)
  • August 2014 (15)
  • July 2014 (13)
  • June 2014 (13)
  • May 2014 (14)
  • April 2014 (14)
  • March 2014 (10)
  • February 2014 (11)
  • January 2014 (13)
  • December 2013 (14)
  • November 2013 (13)
  • October 2013 (14)
  • September 2013 (12)
  • August 2013 (14)
  • July 2013 (10)
  • June 2013 (14)
  • May 2013 (14)
  • April 2013 (14)
  • March 2013 (15)
  • February 2013 (14)
  • January 2013 (13)
  • December 2012 (14)
  • November 2012 (16)
  • October 2012 (13)
  • September 2012 (14)
  • August 2012 (16)
  • July 2012 (12)
  • June 2012 (16)
  • May 2012 (21)
  • April 2012 (18)
  • March 2012 (20)
  • February 2012 (23)
  • January 2012 (31)
  • December 2011 (35)
  • November 2011 (33)
  • October 2011 (32)
  • September 2011 (29)
  • August 2011 (35)
  • July 2011 (33)
  • June 2011 (25)
  • May 2011 (31)
  • April 2011 (30)
  • March 2011 (34)
  • February 2011 (31)
  • January 2011 (33)
  • December 2010 (33)
  • November 2010 (39)
  • October 2010 (26)
All Things Andy Gavin
Copyright © 2023 All Rights Reserved
Programmed by Andy Gavin