Jump to content

What type of Game maker would you like for your Atari ?  

50 members have voted

  1. 1. Would you like Game maker to be more user friendly or coder friendly ?

    • User friendly
      40
    • Coder friendly
      14
  2. 2. What game genres would you most like it to support ?

    • Platform games (Manic Miner like)
      39
    • Beat'em up (Double Dragon like)
      13
    • Shoot'em up (Zybex or Commando like)
      26
    • 3d Isometric (Head over Heels like)
      18
  3. 3. How important would scrolling be?

    • Not at all.
      6
    • It could be useful option.
      35
    • Won't play a game without it!
      9
  4. 4. Would you like to use it on PC or to have native 8-bit Atari version ?

    • PC version would be easier to work with.
      37
    • Atari version would rock!
      23

  • Please sign in to vote in this poll.

Recommended Posts

ps. Maybe it's far out in the future, but I'm thinking about ways to get custom made games, graphics, music out there in the 'cloud' so anyone can pull them down and use in their own projects.

 

I like your idea, keep it simple initially and then build it up. If you aim too high at the start, with respect, you (and anyone else) will fail. I love the expression "bit by bit" which is what you will do here.

 

As for putting things into the cloud, I've been thinking similarly of late. I have lot of ideas but not enough time/expertise to complete my ideas. My idea is to have a website which allows you to upload your work, whether it be code, graphics or sound/music and you can then share with others. People then come along and select what they need.

 

My other ideas was to use this for online code generation... I'll explain...

 

In your code (lets say MADS), you could have a new command which says....

 

inco myAtariShares /fonts/animals.fnt

inco myAtariShares /graphics/elephant.til

 

'inco' = include online : So at compilation time, it'll look up a pre-configured link for 'myAtariShares' which might point to www.myAtariShares.com or something like that. It will then download the font and the tile data as it is compiled. It could even keep a local copy in-case that it is removed from the internet.

Just caught up to this thread, and IMHO a "game maker" for a machine as capable as the A8 should combine tools for creating/scrolling/animating character and pixel background graphics, composing music/FX and creating/moving/animating/multiplexing PMGs with a high-level language (with a syntax akin to BASIC/ACTION!/QUICK - or perhaps one of the latter could be used directly?) for the game logic.

 

I don't know whether this is even realistic.

  • Like 1

Well, code and assets could be pulled down directly from GitHub I guess... Or a ftp server.

We'll think about it when the time comes. Same goes for multiplexers and other more complex routines.

 

Extra padding bytes would be useful for left-right side, although I think it shouldn't be too difficult to adjust addresses and counter values before calling core sprite routine so one routine would cover all.

 

Today I've managed to make shifted sprite routine (one pixel horizontal movement) and clear-sprite area routine. Want to make nice demo with multiple sprites and circular paths and then I'll show it. Till then, good night!

  • Like 2

Just caught up to this thread, and IMHO a "game maker" for a machine as capable as the A8 should combine tools for creating/scrolling/animating character and pixel background graphics, composing music/FX and creating/moving/animating/multiplexing PMGs with a high-level language (with a syntax akin to BASIC/ACTION!/QUICK - or perhaps one of the latter could be used directly?) for the game logic.

 

I don't know whether this is even realistic.

 

It's a lot of work but I think it can be possible if he doesn't try and take on everything at once.

 

For example, there can be a restriction that all music has to be in .rmt format. A copy of RMT can be bundled into the package.

 

Popmilo "only"(!) needs to create the glue that links everything together.

 

As for things like multiplexing, perhaps the first version will not support that? That could be added in versions 3 or 4.

  • Like 1

As for things like multiplexing, perhaps the first version will not support that? That could be added in versions 3 or 4.

Multiplexing with PMs won't be supported as PMs won't be used at all :)

At least in first version.

 

Shouldn't be a big problem as you should have plenty of soft sprites to make a game. Don't exactly know how fast routines will be but first tests look good.

Here is a simple example of sprite drawing (with simple "fill previous position with background" erasing).

 

14 sprites, 8x16 pixels in 9 colors at 25fps:

post-14652-0-54492600-1447088469_thumb.png

 

 

For something faster with less sprites here is an example: 6 sprites in same mode at 50fps

post-14652-0-48498300-1447088556_thumb.png

 

Here are executables for testing on emulator or even better on real thing. Any feedback on how it looks like on real screen would be much appreciated !

agd6.xex

agd14.xex

 

Cheers!

Vladimir.

 

  • Like 5

Shouldn't be a big problem as you should have plenty of soft sprites to make a game. Don't exactly know how fast routines will be but first tests look good.

 

Well, as long as you make your routines as fast as they can be, that is good enough. Then the developer has to see if it is fast enough for their game. Some games might only update the screen 2 times a second and so your routines are good enough. People who need high speed action might then decide to have fewer software sprites. 14 sprites (8x16) at 25 fps is more than fast enough though.

 

I suspect that your gamemaker may be able to be "misused" to create a puzzle game.

  • Like 1

I am quite pleased that someone is thinking of creating a gamemaker on the Atari. Although we have -some- of these, we don't have many or any that I would like to use. I think that I'll like yours Popsmilo.

 

I get so excited though, I want to see lots of discussion on here. I wake up in the morning and it is European night time and I catch some people. Then I have to wait quite a few hours for anything while everyone sleeps (though there'll be some American input) and then at night (my night) you all come back to life again.

Well, as long as you make your routines as fast as they can be, that is good enough. Then the developer has to see if it is fast enough for their game. Some games might only update the screen 2 times a second and so your routines are good enough. People who need high speed action might then decide to have fewer software sprites. 14 sprites (8x16) at 25 fps is more than fast enough though.

Routines are sure not as fast they can be, but I'm working on it. If memory allows I'll go for preshifted sprite data and unrolled code.

 

I suspect that your gamemaker may be able to be "misused" to create a puzzle game.

Well I did thing about that :)

Have you seen Puzzlescript ?

http://www.puzzlescript.net/

 

From simple script files you can make a pretty good puzzle game.

Only need something that will make Atari exe ;)

Routines are sure not as fast they can be, but I'm working on it. If memory allows I'll go for preshifted sprite data and unrolled code.

 

Well I did thing about that :)

Have you seen Puzzlescript ?

http://www.puzzlescript.net/

 

From simple script files you can make a pretty good puzzle game.

Only need something that will make Atari exe ;)

Even if they are not optimal, they look more than good enough for version 1.

 

That was an interesting link. I have never seen it before.

 

Sent from my Ultra using Tapatalk

Puzzlescript is really cool. For example this is how you write "if player moves towards crate, move player and move crate":

[ > Player | Crate ] -> [ > Player | > Crate ]

And here is how to design sprite as a 5x5 grid:

Player
PINK YELLOW BLACK
.222.
.000.
22122
.222.
.2.2.

Which gives you this wee fella:

player.png

All in all, there are plenty good ideas out there, we just need someone to code them for Atari :)

  • Like 1

Many of the recent games offer excellent graphics and background music.

 

But, I really wish that the authors would spend more time on some creative sound effects to make the gaming experience more interactive & immersive. For example, I think that the sound effects of Pacman significantly contributed to the overall gaming interaction. I think that this experience would have been dramatically diminished if the same Pacman game was played over only background music. Let your imagination go and see where it can take you.

Many of the recent games offer excellent graphics and background music.

 

But, I really wish that the authors would spend more time on some creative sound effects to make the gaming experience more interactive & immersive. For example, I think that the sound effects of Pacman significantly contributed to the overall gaming interaction. I think that this experience would have been dramatically diminished if the same Pacman game was played over only background music. Let your imagination go and see where it can take you.

I do agree that the sound effects used in any game - are as important as the graphics. If you can have signature sounds present in your game, it does make a world of difference. However - not every programmer is into music and/or sound effects - that the programmer is fully capable of providing the sound support in/for the game - but you need the talent in designing/creating your own custom sounds.

So it's not really about time and effort - but having the talent/ability to create your own that are of a high quality.

 

Harvey

  • Like 1

I do agree that the sound effects used in any game - are as important as the graphics. If you can have signature sounds present in your game, it does make a world of difference. However - not every programmer is into music and/or sound effects - that the programmer is fully capable of providing the sound support in/for the game - but you need the talent in designing/creating your own custom sounds.

So it's not really about time and effort - but having the talent/ability to create your own that are of a high quality.

 

Harvey

And I agree, too. Most of us can pick out a Pacman game in an arcade room by just the sound effects alone. So, my comment is not about the ability of the programmers which widely varies as you said. I was trying to emphasize the importance of sound effects that seem to be mostly overlooked / forgotten by game designers these days. I'm hardly even see an attempt at some sound effects. I don't think I can pick out any of these games in a crowded arcade room. Nothing to stand out at all!

  • Like 1

For example, I think that the sound effects of Pacman significantly contributed to the overall gaming interaction.

Is there anything 'special' in Pacman's sfx routine or can it all be done in RMT for example ?

 

As I've used RMT for music and sfx in demos I can say it is pretty plug&play experience. It just works.

I guess RMT's sounds will be enough and offer enough freedom for that artistic feeling for making a game with recognizable sounds.

 

Later we could implement some kind of programmable sfx engine that would work with Pokey directly. Later like in a year or two ;)

Give 'em a means to put values into POKEY directly in their game loops. Great effects are to be had that way, and they autosync with the game events, because the event IS the sound.

 

:)

 

Doing this kind of thing works out kind of awesome on the VCS, as well as the computers. Some hashing and thrashing of game variables can result in distinctive sound that make intuitive sense, because they are related to the game state.

Edited by potatohead
  • Like 4

Give 'em a means to put values into POKEY directly in their game loops. Great effects are to be had that way, and they autosync with the game events, because the event IS the sound.

 

:)

 

Doing this kind of thing works out kind of awesome on the VCS, as well as the computers. Some hashing and thrashing of game variables can result in distinctive sound that make intuitive sense, because they are related to the game state.

Thank you! You're on to what I've been trying to convey - "Great effects are to be had that way, and they autosync with the game events, because the event IS the sound."

Edited by atx4us

 

Williams distinct sound came from a simple board that clocked procedural sounds into a DAC at high frequency. They would spend time plugging values into it looking for awesome sounds...

 

Only one sound at a time in this scenario too. Good priority on this really has an impact. Distinct sounds, keyed to game events and with some attention to where the player attention is, or what they really need to know kicks a lot of ass. Only one channel is ever needed. And, of course, 8 bits is enough.

 

Anyway, I'm linking this because the distinctive classic sounds are most often artifacts of the hardware used to create them. We end up with "Atari" sounds, "Williams" sounds, C64 sounds, etc... and Apple 2 sounds, many of which were just hits to the 1 bit speaker in the game loops.

  • Like 3
... which were just hits to the 1 bit speaker in the game loops.

 

Please excuse my naivety, has anyone emulated such a sound board on the Atari 8-bit?

 

It comes across as something which we couldn't 100% emulate due to its clarity but could probably do a 90% emulation in a short number of bytes... could be completely wrong though.

I guess it would make for an interesting review chart - if someone could do a ratings for the arcade sounds vs Atari home version of the classic videogames - and it'll give us the games to most listen to.

And are there any special A8 games that stand out for it's sfx - Encounter?

 

Defender the coin-op was always a stand out game for it's sfx - you could always tell if someone was playing that game nearby.

 

Harvey

  • Like 2

The Williams board was not a one bit board. It used a 6800 CPU driving an 8 bit DAC at a very high clock rate. Emulation is likely out of general reach of an Atari 8 bit computer, though the 4 bits pokey can provide would sound pretty good, given how loud the Williams sounds generally are.

 

It's all procedural on that 6800, and it's 1mhz or something in that range. An Atari, with screen DMA turned off or really limited, could probably do something similar by outputting the upper 4 bits of audio.

 

Maybe do it Williams style. Have one Atari doing the sound, connected to another one doing the game.

 

Chris Lamont had a page with C code derived from that board. Sadly, I think it is down.

  • Like 3

/// <summary>
/// This function reproduces an algorithm from the Williams Sound ROM, addresses 0xF503 to 0xF54F
/// It takes 7 byte parameters and one 16-bit parameter, and returns a list of sound values 0-255
/// sampled at 894750 samples per second
/// </summary>
public List<byte> Sound1(byte b1, byte b2, byte b3, byte b4, byte b5, byte b6, byte b7, ushort u1)
{
ushort count; // internal counter
byte c1, c2, t; // internal storage
byte sound = 0; // current sound level
var wave = new List<byte>();
// copy the current sound value this many times into the output
Action<int> dup = d =>
{
while (d-- > 0)
wave.Add(sound);
};

dup(;
sound = b7;
do
{
dup(14);
c1 = b1;
c2 = b2;
do
{
dup(4);
count = u1;
while (true)
{
dup(9);
sound = (byte) ~sound;

ushort t1 = (c1 != 0 ? c1 : (ushort)256);
dup(Math.Min(count, t1)*14 - 6);
if (count <= t1)
break;
dup(12);
count -= t1;

sound = (byte) ~sound;

ushort t2 = (c2 != 0 ? c2 : (ushort)256);
dup(Math.Min(count, t2) * 14 - 3);
if (count <= t2)
break;
dup(10);
count -= t2;
}

dup(15);

if (sound < 128)
{
dup(2);
sound = (byte)~sound;
}

dup(27);
c1 += b3;
c2 += b4;
} while (c2 != b5);

dup(7);
if (b6 == 0) break;
dup(11);
b1 += b6;
} while (b1 != 0);
return wave;
}



This code takes 7 byte parameters and one 16-bit parameter, and generates a sample at 894750 samples per second. To convert the raw data to a WAV for playback, perform decimation (or downsampling) to reduce to a easier to use rate, such as 44.1khz, and save the data as WAV or whatever format you desire. Here are some parameter sets found used in the game (click each to hear generated 44.1khz WAV files)

0x40, 0x01, 0x00, 0x10, 0xE1, 0xFF, 0xFF, 0x0080
0x28, 0x01, 0x00, 0x08, 0x81, 0xFF, 0xFF, 0x0200
0x28, 0x81, 0x00, 0xFC, 0x01, 0xFC, 0xFF, 0x0200
0xFF, 0x01, 0x00, 0x18, 0x41, 0x00, 0xFF, 0x0480
0x00, 0xFF, 0x08, 0xFF, 0x68, 0x00, 0xFF, 0x0480



And there you have the precise algorithm for a few of the Robotron, Defender, Stargate, etc. sounds. Hopefully one day I'll write up more of them for everyone to enjoy.



Note to lawyers: the above code is not Williams code, but completely new code I wrote. The sound files posted are not recorded from Williams arcade machines nor are they generated using any Williams hardware. They are generated mathematically from the original code I wrote above. Interesting, huh?
  • Like 1

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...