Let’s Make a Game!

As anybody involved in writing software can tell you, project specifications will often change when new information becomes available.

 

When I started working on Collect, my plan was to use it for my presentation at Classic Game Fest. As I've progressed I've come to the realization that a full blown game is going to be just too much information for a one hour presentation. I decided that I'm going to leave the existing example in place and just add a few slides about Collect with a link to these blog entries for anybody who is interested.

 

Since I'm no longer planning to fit this project into a presentation, I've decided on a few changes:

• Make Collect a 1-2 player game
• Add the Ball object to draw an additional box, especially useful for 2 player games
• Change Timer display to the right player's score
• Add a Timer Bar to indicate time remaining

 

Mockup of two player game with new timer bar:

Timer has decreased:

One player variation will hide right player's score and use player1 as an additional box:

The Ball Object has a vertical delay feature. When used, the ball should be updated on the same scanline as player0. Due to this, I've revised the 2LK to be like this:

1. update player1, update playfield, precalc player0 data for next scanline
2. update player0, update playfield, precalc player1 data for next scanline

 

This was done to plan ahead for when the playfield is no longer updated on every scanline. Updating the playfield and ball will make the 2LK look something like this:

1. update player1, update playfield, precalc player0 and ball data for next scanline
2. update player0, update ball, precalc player 1 data for next scanline

 

I'll also need to add in updates for the missiles. Ideally we want to update them on every scanline like this:

1. update player1, update missile0, update missile1, update playfield, precalc player0 and ball and missile data for next scanline
2. update player0, update missile0, update missile1, update ball, precalc player 1 and missile data for next scanline

 

It's possible the timing won't work out for that. If it doesn't, then a change like this should work:

1. update player1, update missile1, update playfield, precalc player0 and ball and missile0 data for next scanline
2. update player0, update missile0, update ball, precalc player1 and missile1 data for next scanline

 

That would make it so that the missile objects can only start on every-other-scanline, but that's an OK compromise for our game.

 

In this build I've revised the Arena to be a little bit shorter to make room for the new timer display. The timer currently "ticks" once every 64 frames. Whenever it ticks, a bunch of byte rotations are done to shorten the length of the timer bar.

DecrementTimer:
        lsr TimerPF+5   ; PF2 right side, reversed bits so shift right
        rol TimerPF+4   ; PF1 right side, normal bits so shift left
        ror TimerPF+3   ; PF0 right side, reversed bits so shift right
        lda TimerPF+3   ; only upper nybble used, so we need to put bit 3 into C
        lsr
        lsr
        lsr
        lsr
        ror TimerPF+2   ; PF2 left side, reversed bits so shift right
        rol TimerPF+1   ; PF1 left side, normal bits so shift left
        ror TimerPF     ; PF0 left side, reversed bits so shift right
        rts

Since there are 40 playfield pixels, the total playtime would be 40*64/60 = 42.7 seconds. We might decide that's too short of a play time. If so, we'll just change the tick to occur every 128 frames for 40*128/60 = 85.3 seconds of game time, or maybe even once very 256 frames for 40*256/60 = 170.7 seconds.

 

SetObjectColors has been modified to add a color for the timer bar. The Timer Bar and the Arena are both drawn using the playfield, so to make the Arena a different color than the Timer Bar I store the current Arena color in a RAM location.

SetObjectColors:        
        ldx #4          ; we're going to set 5 colors (0-4)
        ldy #4          ; default to the color entries in the table (0-4)
        lda SWCHB       ; read the state of the console switches
        and #%00001000  ; test state of D3, the TV Type switch
        bne SOCloop     ; if D3=1 then use color
        ldy #9          ; else use the b&w entries in the table (5-9)
SOCloop:        
        lda Colors,y    ; get the color or b&w value
        sta COLUP0-1,x  ; and set it
        dey             ; decrease Y
        dex             ; decrease X 
        bne SOCloop     ; Branch Not Equal to Zero
        lda Colors,y    ; get the Arena color
        sta ArenaColor  ; save in RAM for Kernal Usage
        rts             ; ReTurn from Subroutine
        
Colors:   
        .byte $46   ; red        - goes into COLUPF, color for Arena (after Timer is drawn)
        .byte $86   ; blue       - goes into COLUP0, color for player0 and missile0
        .byte $C6   ; green      - goes into COLUP1, color for player1 and missile1
        .byte $64   ; purple     - goes into COLUPF, color for Timer
        .byte $00   ; black      - goes into COLUBK, color for background
        .byte $0A   ; light grey - goes into COLUPF, color for Arena (after Timer is drawn)
        .byte $0E   ; white      - goes into COLUP0, color for player0 and missile0
        .byte $06   ; dark grey  - goes into COLUP1, color for player1 and missile1
        .byte $04   ; dark grey  - goes into COLUPF, color for Timer
        .byte $00   ; black      - goes into COLUBK, color for background

For testing, I've set it up so the Right Difficulty switch is used to determine if the game is a one or two player game for which graphics to use for player1:

ldx #0
        bit SWCHB
        bpl TwoPlayer
        ldx #1
TwoPlayer:        
    ; Player1Ptr = BoxGfx + HUMAN_HEIGHT - 1 - Y position
        lda ShapePtrLow,x
        sec
        sbc Temp
        sta Player1Ptr
        lda ShapePtrHi,x
        sbc #0
        sta Player1Ptr+1
        
        rts
        
ShapePtrLow:
        .byte <(HumanGfx + HUMAN_HEIGHT - 1)
        .byte <(BoxGfx + HUMAN_HEIGHT - 1)
        
ShapePtrHi:
        .byte >(HumanGfx + HUMAN_HEIGHT - 1)
        .byte >(BoxGfx + HUMAN_HEIGHT - 1)

Right Difficulty = B:

Right Difficulty = A:

The ROM and the source are at the bottom of my blog entry.

 

 

 

Other Assembly Language Tutorials

Amazon Stuff

< Previous Step

Next Step >

 

 

 

 

Table of Contents for Let’s Make a Game!

Introduction

Step 1: Generate a Stable Display

Step 2: Timers

Step 3: Score and Timer Display

Step 4: 2 Line Kernel

Step 5: Automate Vertical Delay

Step 6: Spec Change

Step 7: Draw the Playfield

Step 8: Select and Reset Support

Step 9: Game Variations

Step 10: “Random Numbers”

Step 11: Add the Ball Object

Step 12: Add the Missile Objects

Step 13: Add Sound Effects

Step 14: Add Animation

 

 

 

 

Useful Links

Easy 6502 by Nick Morgan

How to get started writing 6502 assembly language. Includes a JavaScript 6502 assembler and simulator.

 

 

Atari Roots by Mark Andrews (Online Book)

This book was written in English, not computerese. It's written for Atari users, not for professional programmers (though they might find it useful).

 

 

Machine Language For Beginners by Richard Mansfield (Online Book)

This book only assumes a working knowledge of BASIC. It was designed to speak directly to the amateur programmer, the part-time computerist. It should help you make the transition from BASIC to machine language with relative ease.

 

 

The Second Book Of Machine Language by Richard Mansfield (Online Book)

This book shows how to put together a large machine language program. All of the fundamentals were covered in Machine Language for Beginners. What remains is to put the rules to use by constructing a working program, to take the theory into the field and show how machine language is done.

 

 

6502 Instruction Set with Examples

A useful page from Assembly Language Programming for the Atari Computers.

 

 

6502.org

Continually strives to remain the largest and most complete source for 6502-related information in the world.

 

 

Guide to 6502 Assembly Language Programming by Andrew Jacobs

Below are direct links to the most important pages.

 

 

Stella Programmer's Guide

HTMLified version.

 

 

Nick Bensema's Guide to Cycle Counting on the Atari 2600

Cycle counting is an important aspect of Atari 2600 programming. It makes possible the positioning of sprites, the drawing of six-digit scores, non-mirrored playfield graphics and many other cool TIA tricks that keep every game from looking like Combat.

 

 

How to Draw A Playfield by Nick Bensema

Atari 2600 programming is different from any other kind of programming in many ways. Just one of these ways is the flow of the program.

 

 

Cart Sizes and Bankswitching Methods by Kevin Horton

The "bankswitching bible." Also check out the Atari 2600 Fun Facts and Information Guide and this post about bankswitching by SeaGtGruff at AtariAge.

 

 

Atari 2600 Specifications

Atari 2600 programming specs (HTML version).

 

 

Atari 2600 Programming Page (AtariAge)

Links to useful information, tools, source code, and documentation.

 

 

MiniDig

Atari 2600 programming site based on Garon's "The Dig," which is now dead.

 

 

TIA Color Charts and Tools

Includes interactive color charts, an NTSC/PAL color conversion tool, and Atari 2600 color compatibility tools that can help you quickly find colors that go great together.

 

 

The Atari 2600 Music and Sound Page

Adapted information and charts related to Atari 2600 music and sound.

 

 

Game Standards and Procedures

A guide and a check list for finished carts.

 

 

Stella

A multi-platform Atari 2600 VCS emulator. It has a built-in debugger to help you with your works in progress or you can use it to study classic games. Stella finally got Atari 2600 quality sound in December of 2018. Until version 6.0, the game sounds in Stella were mostly OK, but not great. Now it's almost impossible to tell the difference between the sound effects in Stella and a real Atari 2600.

 

 

JAVATARI

A very good emulator that can also be embedded on your own web site so people can play the games you make online. It's much better than JStella.

 

 

batari Basic Commands

If assembly language seems a little too hard, don't worry. You can always try to make Atari 2600 games the faster, easier way with batari Basic.