Jump to content
IGNORED

Making an atari 800 game: how to start exactly?


Recommended Posts

Outside of magazine listings (though I appreciate those too), what other ways are there to make a game nowadays? I'd do assembly (not that I know much TBH) but frankly, I much prefer the Final Cart 3 way of doing things (namely, it's automatic, no need to do it manually) because otherwise it's too much margin for error.

 

regardless, any help would be very much appreciated. I can carve together something on the spectrum or zx81 (within limitations of course) easy, but the Atari is...weird to say the least. You need to open a file to save anything, no commands for sprites? I get that there are extensions and Altirra basic but what i'm looking for is this:

 

A sprite editor 

A tool to help with animation

An easier way to save to disk (don't want to deal with error 130 constantly)

 

ideas?

Link to comment
Share on other sites

15 minutes ago, Frozone212 said:

An easier way to save to disk (don't want to deal with error 130 constantly)

I don't understand why you would get this error, saving to disk is easy and under normal circumstances

should work without errors.

 

21 minutes ago, Frozone212 said:

You need to open a file to save anything

Not to save programs you've written, it's just a command. i.e. in BASIC SAVE "D1:MYPROG.BAS"

For data, then yes, you have to open a file and save the data, same as it is today for any program.

 

As for the game, first you need to decide what type of game it is as that will probably decide

if you can use BASIC, C, or any other high level language of that type.

 

Or if you need a mix of the 2.

 

Or finally pure machine code.

 

You can develop code using Windows applications for cc65 for C, ca65 for assembler

Eclipse Editor has a plugin for the MADS assembler (my favourite choice).

 

I also use Altirra to develop code (like so many here), using one of the previous editor/compilers, you can have your code running in seconds.

 

I'm sure others will help with sprite editors (I wrote my own :) ) and animation tools.

 

 

Link to comment
Share on other sites

A good start will be basic, but most of the times you really want to make exeptionell games- 6502 assembly is the way to go. Atari basic doesn't support sprites directly- but you can work around this by loading some machine code.

Most of the times it's not 6502 assembly which (sounds)is difficult, but knowing to work with the hardware. if you can do 6502 on the C64 it will be much different to do thesame game on the A8.

 

A book which was a great help for me was Atari Graphics And Game Design: https://www.atariarchives.org/agagd/

 

Link to comment
Share on other sites

18 hours ago, Frozone212 said:

Outside of magazine listings (though I appreciate those too), what other ways are there to make a game nowadays? I'd do assembly (not that I know much TBH) but frankly, I much prefer the Final Cart 3 way of doing things (namely, it's automatic, no need to do it manually) because otherwise it's too much margin for error.

 

regardless, any help would be very much appreciated. I can carve together something on the spectrum or zx81 (within limitations of course) easy, but the Atari is...weird to say the least. You need to open a file to save anything, no commands for sprites? I get that there are extensions and Altirra basic but what i'm looking for is this:

 

A sprite editor 

A tool to help with animation

An easier way to save to disk (don't want to deal with error 130 constantly)

 

ideas?

 

If you intend on moving 4 Players/Sprites my USR or VBI does a good job of automating the joystick reads, handling max and min X&Y boundaries, even animating based on direction etc.

 

https://atariage.com/forums/topic/333155-my-vision-for-automating-4-player-sprites-realized/

 

MAC/65 source code included that you can modify to add more attributes if you wish.

 

Edited by Astra2001
  • Like 1
Link to comment
Share on other sites

22 hours ago, Frozone212 said:

the Atari is...weird to say the least. You need to open a file to save anything, no commands for sprites? I get that there are extensions and Altirra basic but what i'm looking for is this:

 

 

Error 130 means 'no such device'. Do you have a disk drive of some sort? Many of us use an adapter to use our PCs as the disk drive, or use the Altirra emulator and it will take care of that for you.

It would help us help you if you could explain what action you are taking that generates the error 130.

 

It's not weird to need to open a file to save anything - what else would you expect? Every system I have ever worked on needs the same kind of thing.

 

The Atari is a little different because it has what was for the time a sophisticated OS, that uses IO handlers that can be mapped onto different devices. It also has custom screen handling hardware and does have sprites called Player/Missile graphics. They just take a bit more of extra control than you might expect, but many languages have support for them. It also uses a 'display list', which is a small program for the screen generator hardware. Lots of flexibility, but adds some complexity.

Read https://www.atariarchives.org/dere/ and other books at that same location.

 

Link to comment
Share on other sites

BASIC XE has sprite commands but isn’t significantly faster than standard Atari BASIC.

 

Action! is superfast and you can basically define your own sprite functions. It is a bit like a mix of BASIC, C and others but reasonably easy to learn and certainly easier than assembler while a LOT faster than BASIC. Afaik it will leave you with less usable memory than pure assembly but that would only restrict very ambitious projects.

 

You will have to deal with some stuff that requires PEEKs and POKEs (or other machine level manipulation) anyway as some of the Atari magic like display lists can’t be used without.

 

There are loads of documentation online. The Compute! books and De Re Atari contain excellent examples.

Link to comment
Share on other sites

2 hours ago, slx said:

BASIC XE has sprite commands but isn’t significantly faster than standard Atari BASIC.

Getting close to 50% faster, that's not to be sniffed at and given support for the extra keywords i.e. DPEEK,DPOKE etc.

which speed things up even more 

 

for example A=DPEEK(88) gets you the screen address in BAISC XE

in normal BASIC A=PEEK(88)+PEEK(89)*256

 

a thousand iterations of each shows BASIC XE  runs it in 2.83 seconds (NTSC)

A thousand using normal BASIC 15.73 seconds, significantly faster.

  • Like 1
Link to comment
Share on other sites

On 6/29/2022 at 1:52 PM, danwinslow said:

To be fair, that's a pretty simplistic test...needs to cover more ground to really be able to say "In general, this is x% faster than that". I agree with you though - if you want Basic, then its hard to do much better than Basic XE in my opinion.

If you wrap your head around sprite programming Turbo BASIC XL is faster afaik, has the DPEEK/DPOKE as well plus MOVE for P/M.

Link to comment
Share on other sites

Hi!

8 hours ago, Synthpopalooza said:

... and it can be compiled.  See my Tetricize game from 1991 for an example.

And of course, you have FastBasic, that is faster than TurboBasic XL, has P/M and DLI statements, an can be compiled directly from the IDE :) 

 

Have Fun!

  • Like 4
Link to comment
Share on other sites

7 hours ago, dmsc said:

Hi!

And of course, you have FastBasic, that is faster than TurboBasic XL, has P/M and DLI statements, an can be compiled directly from the IDE :) 

 

Have Fun!

YouTube example ?  A picture is worth a thousand words

Link to comment
Share on other sites

1. Figure out the kind of game you want to make. What will the player be doing? What is the story?

2. Figure out the core of what you want to happen. Plan your game from intro to setting up to play to conclusion.

3. Figure out how things should look. Draw it on paper. This planning is your ideal look for your game. Be willing to amend it for technical reasons but try to accomplish your vision.

4. Figure out any animation.

Notice how I'm suggesting doing this design work first and yet you haven't written any code yet. This is so you have a direction for your project. You have to know your game first. Understand the rules and write them down. You'll need to use this logic in your code because this is how you're going to teach the computer how to conduct your game and act as referee and don't let the player break the rules.

5. Try coding some of it in BASIC first. Perhaps a simple graphics routine. Maybe there are play mechanics involved like the effects of physics. Maybe it's menus in an RPG. Do it without fancy graphics first. This your rehearsal. Dress rehearsal comes later.

It's at this stage when you can decide if your idea is going to work in BASIC or you need more speed. You're going to need a library of stock solid bug free subroutines to perform common tasks. Good games are collections of task modules like performing a scroll or moving the player character sprite avatar. Even dynamically redefining the display list. See if you can use some tricks another programmer has put together like a sprite multiplexer.

Chances are old reference material has things you need to leap frog your development over common problems. It's all a matter of what you want to do and how did someone else solve that problem.

  • Like 5
Link to comment
Share on other sites

  • 2 weeks later...

One of these days I'll get off my butt and try this.  Between work and real life, it's hard, and although I was a hack as a programmer (not a professional, but have my master's degree in software engineering), I know enough to get in / out of trouble...or maybe just in trouble LOL.

 

Just sounds easier than it is.  There are a few things I'd love to try - maybe a Reactor type game...might be something to consider for a 10-liner type thing, but again, my limited knowledge vexes me.  All of you here inspire me - I'll hopefully get there eventually!

Link to comment
Share on other sites

1 hour ago, rdefabri said:

hopefully get there eventually!

Best thing to do in small doses (as you say you don't have a great deal of time at the moment)

is to get to know the machine, what the hardware does, how to manipulate it, these little amazing

machines can be made to do great things, the more you know about the chips and how to get the most

out of them, the easier things become.

 

When I first started back in the 80's I decided I wanted to write a fruit machine program in BASIC.

I soon learnt BASIC is far too slow for the "action" bit's i.e. spinning reels etc. so I learnt assembler

and incorporated it into the BASIC program.

 

I ended up having a custom character set, Player/Missiles, custom display lists, Vertical blank interrupt

routines. I never envisaged most of that at the outset.

 

Best of all it was great fun ?

  • Like 2
Link to comment
Share on other sites

IMHO rule #1 is to start with the game itself. Not the title screen, intro, music, fonts and even fancy sprites. Just placeholders until you have the game logic figured out. Then you can work from that.

 

In the 80's and 90's I have started several games and never finished them. Exactly because of the above reasons. I only finished a text adventure, which I finally recently released on this forum in English translation. After my Atari-hiatus I never started writing a game, but it's still something I'd like to do sometime.

  • Like 4
Link to comment
Share on other sites

1 hour ago, ivop said:

In the 80's and 90's I have started several games and never finished them

I know what you mean, this is one I started, put a lot of work into it but never completed it.

The artwork was done by a friend, the game was his idea, my job was to put his ideas into practice.

 

I have posted this before, but just in case you haven't seen it.

 

Maybe one day when I get the incentive to complete it :)

 

Boot without BASIC

cityboot.atr

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...