Tutorial for developing a game from scratch

[+SpiceWare]

I've been blogging about of Collect, a 2K Atari game, that I plan to use as part of a presentation next month.

 

The blog follows the development of the game step by step, from just a static screen to a fully playable game. The game utilizes all objects (both players, both missiles, ball and playfield) via a 2 Line Kernel, has sound effects, multiple game variations, "screen saver" color cycling, etc.

 

I'm just about done, probably 2-3 more blog entries to wrap it up, and would appreciate any feedback. The source code has way more than normal comments, so be sure to review it as well as how it changes with each revision.

 

Thanks!

Edited July 13, 2014 by SpiceWare

[SmileyDude]

I've been following along with these posts for the past few weeks while you have been posting them. I think they have been really good so far, but I think it might be helpful to have everything you need inside the post rather than having to download the source each time. I was able to get up to step four on my own by working off what was in the post, but I had to download the source to see what you had done in regards to positioning the objects. But I also have a little bit of history with hacking on the 2600, so I would guess that others might have to look inside the source code even sooner.

 

Otherwise, I think you've done a fantastic job. Would love to see more after you are done with this one where you do a deeper dive into a topic -- perhaps a more complex game or a different game type. It's nice to have a tutorial where you end up with an actual game at the end vs a tech demo. I think most people start running into problems when they go to make a finished product vs just getting something small up on the screen.

[+SpiceWare]

Thanks for the feedback!

 

 

I think it might be helpful to have everything you need inside the post rather than having to download the source each time. I was able to get up to step four on my own by working off what was in the post, but I had to download the source to see what you had done in regards to positioning the objects.

It actually was my expectation that people would look at the source after (or maybe even while) reading each blog entry. To that extent I've commented it way more than I usually would. Things like this:

;===============================================================================
; Initialize dasm
;===============================================================================
 
    ; Dasm supports a number of processors, this line tells dasm the code
    ; is for the 6502 CPU.  The Atari has a 6507, which is 6502 that's been
    ; put into a "reduced package".  This package limits the 6507 to an 8K
    ; address space and also removes support for external interrupts.
        PROCESSOR 6502
    
    ; vcs.h contains the standard definitions for TIA and RIOT registers 
        include vcs.h       
    
    ; macro.h contains commonly used routines which aid in coding
        include macro.h

 

as well as tips like this

Score:          ds 2    ; stored in $80-81
    ; CODING TIP - The : is optional. However, if you remember to include the :
    ;              in all of your labels you can then easily find where
    ;              something is defined by including : in the search.
    ;              Find "Score:" will bring you here, find "Score" will locate
    ;              all places that the variable Score is used.

 

and this:

    ; D7, 1=Game Active, 0=Game Over
GameState:      ds 1    ; stored in $A9
    ; CODING TIP - There are 8 bits within a byte.  Dx notation is used to
    ;              specify a specific bit where x is 0-7.
    ;              D7 is the high bit, D0 is the low bit.
    ;              D7 and D6 can be quickly tested without trashing any CPU
    ;              registers by using the BIT command.  You can see this in
    ;              action in OverScan where TIA's collision detection registers
    ;              are tested using the BIT command.

 

Perhaps I should modify the first entry to reflect that expectation?

Edited July 15, 2014 by SpiceWare

[+SpiceWare]

Otherwise, I think you've done a fantastic job. Would love to see more after you are done with this one where you do a deeper dive into a topic -- perhaps a more complex game or a different game type.

This is a big part of why I've blogged about the development of all my other games (with the exception of the holiday Stay Frosty games). The homebrew topics were for people interested in just playing the game and providing feedback while the blog entries were for the technical details. An example of one that goes into detail on how the walls in Frantic are drawn

 

Blog Entries:

• Medieval Mayhem
• Frantic
• Space Rocks
• Draconian

Homebrew topics:

• Medieval Mayhem
• Frantic
• Space Rocks
• Draconian

 

It's nice to have a tutorial where you end up with an actual game at the end vs a tech demo. I think most people start running into problems when they go to make a finished product vs just getting something small up on the screen.

 

That was my thinking behind doing a very simple 2K game as an example.

[+Gemintronic]

I'm done! Where's my prize?

 

CollectbBAnim.bin