Tech demo of my game

[Karlos]

One of my kids had this odd 2D Minecraft type sandbox game for a while. This engine would be perfect for something like it, especially with the snazzy lighting variations.

[saimon69]

You COULD do a Gauntlet-style game, but to make sure it shows fine will need to move like Boulder Dash in ZX spectrum or C64:tile by tile

[Tigerskunk]

Thinking about it, I see a bit of a problem turning this into an actual game with the current engine, as everything except the player is static at the moment.

Or maybe I am just not a good game designer and don't see the possibilities here...

Add/edit: well, thinking about it, you could move objects horizontally without the need for a dynamic copper list. That would already give some nice gameplay. Damn, I need a coffee before writing here.

[alexh]

Originally Posted by Tigerskunk

Thinking about it, I see a bit of a problem turning this into an actual game with the current engine, as everything except the player is static at the moment.

I was under the impression that most objects were sprites like the main character and could move by changing the sprite-sheet they just don't in this demo? Are you suggesting that dynamically changing the sprite-sheet per frame would have a big overhead?

[Tigerskunk]

Originally Posted by alexh

I was under the impression that most objects were sprites like the main character and could move by changing the sprite-sheet they just don't in this demo? Are you suggesting that dynamically changing the sprite-sheet per frame would have a big overhead?

As I understand it these are non attached 3 color sprites.
In which palette entries are changed every line to give them a much more colorful appearance.

My educated guess is, that at the moment this is done by a prerendered Copper list where the start adress is changed dynamically as the screen scrolls up and down, so objects other than the character need to stay in their place or the colors would look distorted.

Moving sprites up and down would also need some logic which objects can cross lines with other objects, because as you can only have one 3 color palette per sprite pair, this puts some further restrictions on the mingling of sprites in one line.

[carlosgod]

Originally Posted by ross

Yes, most likely this engine could be used.


Not that in the Amiga there are any limits in the use of sprites, as long as they are not more than 8 on the same video line, so if you limit their vertical movement and set a maximum per line...

I see. So my understanding of Amiga sprites is wrong.... makes sense that vertical movement would be difficult.

I wonder what kind of game you can make with this game engine and with these restrictions then. I guess HAM mode jumper frog? Puzzle games? Street fighter 2 with no jumping?

I hope the author can prove us all wrong and do vertical movement of all these multiplexed sprites without destroying frame rate or glitching all over the place. I mean, even if it runs at 25FPS it would still be a major breakthrough in OCS gaming. Imagine the plethora of 256 color (or more) OCS games appearing everywhere. It would literally make the Amiga a computer that is 10 years ahead of its time!

[ross]

Originally Posted by carlosgod

I hope the author can prove us all wrong and do vertical movement of all these multiplexed sprites without destroying frame rate or glitching all over the place. I mean, even if it runs at 25FPS it would still be a major breakthrough in OCS gaming. Imagine the plethora of 256 color (or more) OCS games appearing everywhere. It would literally make the Amiga a computer that is 10 years ahead of its time!

Temper expectations, please
It was the same reason that I told the author not to exaggerate, to avoid messages like this (of course it's not a criticism of you, dreaming is the first step to succeed, but there are things you can do and others you can't).

With several precautions you can also make the sprites move vertically, limiting the presence of fixed (but animated) ones or making play areas in which a few objects are free to move (for a maximum of 6 + player), or limiting recolouring.
Being an 8-way scrolling game there are many possibilities to create special subzones in which manage sprites with greater freedom.
But forget about seeing the sprites from the demo move freely around the screen (so a Gauntlet-like game is not possible).

I'm sorry to dampen the enthusiasm, but I do it for the sake of this game engine, which I repeat is technically and visually excellent.

[Samurai_Crow]

If you look at the horizonally multiplexed image with more than 8 sprites, every 8th sprite is the same shape. The colors are the same for every pair of sprites. I think @Tigerskunk was right about the 3 color sprites and the copper.

Finally, in this day and age, every Amiga should have real Fast RAM. That frees up bandwidth for the chipset to do a lot more work. HAM mode especially needs bandwidth.

[faz]

Congratulations to your first 'C/ASM Amiga game' or let's call it first glimpse at your tech/engine! Quite a bummer, letting idea flow and expectations skyrocket

Now that some limitations have been pointed out I guess an important next step would be at looking how these limitations can be soothed and at which costs.

Basically I see "just" two major things:

a) can some sprites be released for vertical&horizontal or, best-case, free movement without losing the benefit of 3 col/line
b) how to most efficiently blit into ham6 without friction.

I'd also concentrate on the stock experience. Sure everyone has fast ram, 680x0++ or emulators but since it seems to be very well in reach to make a fantastic game for stock hardware, why aim for anything else.

When I first saw the screenshot I *immediately* thought of three games, each with some hurdles to take. So there's lays the challenge mentioned, if you want to explore further possibilities before thinking about your own game build around what you've already archived.

a) Worthy. Some of your sprites instantly remind me. While already looking gorgeous, ham tiles and sprite animations might make it shine even more. Not too many objects on screen and no scrolling needed. However multiple objects can move vertically and horizontally.

b) Dynablaster. Classic. Challenge pretty much same as above.

c) Total Chaos AGA. The blobs remind me of TCs "gooey blobs" growing across the map if not engaged. Eagerly waited for the original authors new vision called "Chaos Reborn", which turned out dull and boring. Total Chaos is really chaotic in every sense, yet fun to play, but also quite beefy (hires laced + lots of blits). No scrolling needed (in hires laced at least, but might be an option here), tile based map and non-moving player/NPCs/enemies. Perfect usecase? Unfortunately no, each tile in a row eventually hosts it's own item, so I guess no change without blitting.

[Samurai_Crow]

Originally Posted by faz

Congratulations to your first 'C/ASM Amiga game' or let's call it first glimpse at your tech/engine! Quite a bummer, letting idea flow and expectations skyrocket

Now that some limitations have been pointed out I guess an important next step would be at looking how these limitations can be soothed and at which costs.

Basically I see "just" two major things:

a) can some sprites be released for vertical&horizontal or, best-case, free movement without losing the benefit of 3 col/line
b) how to most efficiently blit into ham6 without friction.

I'd also concentrate on the stock experience. Sure everyone has fast ram, 680x0++ or emulators but since it seems to be very well in reach to make a fantastic game for stock hardware, why aim for anything else.

...

c) Total Chaos AGA. The blobs remind me of TCs "gooey blobs" growing across the map if not engaged. Eagerly waited for the original authors new vision called "Chaos Reborn", which turned out dull and boring. Total Chaos is really chaotic in every sense, yet fun to play, but also quite beefy (hires laced + lots of blits). No scrolling needed (in hires laced at least, but might be an option here), tile based map and non-moving player/NPCs/enemies. Perfect usecase? Unfortunately no, each tile in a row eventually hosts it's own item, so I guess no change without blitting.

Unfair comparisons abound. Total Chaos requires 32 megs of Fast RAM, a hard drive and a 68030 minimum. Recommended is an '060 50 MHz. It uses about half of the AGA palette for palette cycling and custom CPU blitting blitting routines for a 20× speed improvement over the slow AGA blitter. It runs at 50 fields per second interlaced on PAL high-res.

I knew James Conwell. We discussed Total Chaos development quite extensively. Your remark about stock configurations has him turning over in his grave. His next version was supposed to be for graphics card models because he had pushed AGA to its limits.

[Tigerskunk]

Originally Posted by carlosgod

Imagine the plethora of 256 color (or more) OCS games appearing everywhere. It would literally make the Amiga a computer that is 10 years ahead of its time!

You are going overboard there a bit...
There are some other ideas and tricks around to make HAM mode more usable for games and get rid of the bleeding, though.

But it's a huge give and take there.
Simply not usable for every kind of game.

[krackout]

Spectacular achievement, I always was under the impression that HAM mode could show only still images.

[rothers]

Originally Posted by krackout

Spectacular achievement, I always was under the impression that HAM mode could show only still images.

This is the current best HAM demo IMO:


[ Show youtube player ]

[faz]

Originally Posted by Samurai_Crow

Unfair comparisons abound. Total Chaos requires 32 megs of Fast RAM, a hard drive and a 68030 minimum. Recommended is an '060 50 MHz. It uses about half of the AGA palette for palette cycling and custom CPU blitting routines for a 20× speed improvement over the slow AGA blitter. It runs at 50 fields per second interlaced on PAL high-res.

I knew James Conwell. We discussed Total Chaos development quite extensively. Your remark about stock configurations has him turning over in his grave. His next version was supposed to be for graphics card models because he had pushed AGA to its limits.

If I had compared apples to oranges here, for which fruit would that have been unfair?

Tiles in this tech demo reminded me of TC:AGA (blobs and walls) and I put some emphasize on it idd because I think this techs strength and limitations match well for an OCS-game heading this direction.

In a "Chaos-like" game every object is perfectly aligned in a square tiled grid. Just some effects are applied across tiles, like drawing a single line when casting a spell for instance. It's turn-based and you can take 'the time you need' to build/reorder copperlists or do calculations.

HAM-tiles! You could build *incredibly* good looking maps with literally hundreds of colors, colorize or shade tiles around objects like generators, improve fog of war or even make it part of the gameplay as suggested.

You barely see half a dozen dragons on a map, but usually dozens of animated 'grows' or trees. Too much for the blitter to animate them simutaneously. But here sprites could probably do, additionally breaking the 3-col-pair/8-per-scanline limitation and there's would be no need to trade multiplexing for scrolling.

For the other objects: If being full tiles i guess you could do simple copyblits and I'm sure you gonna find some clever ways to fix bleeding when doing cookie-cut in HAM aswell.

Lots of tricks can be applied to keep memory footprint low. And you certainly don't need 20 megs of male&female voice samples, 150+ protracker mods from the demoscene and beyond, Candyfactory-baked UI background images which flip each turn for no reason, three Hires laced background images just for the options menu etc. pp. It's hilarious and chaotic, but that's TC:AGA.

About your remark on my 'stock' remark: I didn't know James, but we also had some conversation about his future plans and he also told me how his disease is hindering him from making desired progress. This was a very long time ago thou. Sad to hear he passed away. I guess TC:AGA is part of his legacy and will remain on of the best original amiga games in my book. RIP.

[TCD]

Originally Posted by faz

For the other objects: If being full tiles i guess you could do simple copyblits and I'm sure you gonna find some clever ways to fix bleeding when doing cookie-cut in HAM aswell.

Have you actually run the demo? It is far off an actual game, but I don't think those are problems that need to be addressed.

[faz]

Originally Posted by TCD

Have you actually run the demo? It is far off an actual game, but I don't think those are problems that need to be addressed.

Don't understand your remark tbh.

What needs to be addressed depends on the game/genre you have in mind in first place. And I was pretty detailed about what I was thinking.

Sure I did. What makes you think I did not? What do you think need to be addressed?

[TCD]

Originally Posted by faz

What do you think need to be addressed?

Game logic. The demo shows that the engine works regarding HAM and sprites. What is lacking is interaction.

Why do you talk about 'bleeding' then? Care to elaborate?

[Samurai_Crow]

Originally Posted by faz

If I had compared apples to oranges here, for which fruit would that have been unfair?

Memory: The units must all be loaded at once due to the utter randomness. Fast memory is required because Chip RAM cannot hold them all. TC:AGA has 1.5 MB of compiled binary for the code and variables alone. 128k of stack space for the recursion of the pathfinding algorithm alone.

Originally Posted by faz

Tiles in this tech demo reminded me of TC:AGA (blobs and walls) and I put some emphasize on it idd because I think this techs strength and limitations match well for an OCS-game heading this direction.

The sprites look similar, yes. To mandate no more than 8 unique images per tile row, would be a requirement that would limit the unique randomness of the game.

Originally Posted by faz

In a "Chaos-like" game every object is perfectly aligned in a square tiled grid. Just some effects are applied across tiles, like drawing a single line when casting a spell for instance. It's turn-based and you can take 'the time you need' to build/reorder copperlists or do calculations.

Projectiles like arrows from elves, flames breathed by the red dragon, acid from the green dragon and the manticore's tail overlap the background tiles. The arrow launches over the top of friendly units as well.

Also, the optional summon magic and ball lightning project out of the wizard. That also overlaps background tiles.

Originally Posted by faz

HAM-tiles! You could build *incredibly* good looking maps with literally hundreds of colors, colorize or shade tiles around objects like generators, improve fog of war or even make it part of the gameplay as suggested.

James tried to make TC run in HAM mode before he upgraded from ECS to AGA. It was too slow. The closest you could hope for is Kalms' chunky to HAM8 but it's too slow even on an 060.

Originally Posted by faz

You barely see half a dozen dragons on a map, but usually dozens of animated 'grows' or trees. Too much for the blitter to animate them simutaneously. But here sprites could probably do, additionally breaking the 3-col-pair/8-per-scanline limitation and there's would be no need to trade multiplexing for scrolling.

This is partly true. If you knew there would be enough of the same type of image on the same line, you could stretch the sprites with the copper. In TC, you just don't know what objects will be covered by which other ones.

Originally Posted by faz

For the other objects: If being full tiles i guess you could do simple copyblits and I'm sure you gonna find some clever ways to fix bleeding when doing cookie-cut in HAM aswell.

Chunky to HAM8 has been slowly done on AGA. That might be possible without animation.

Originally Posted by faz

Lots of tricks can be applied to keep memory footprint low. And you certainly don't need 20 megs of male&female voice samples, 150+ protracker mods from the demoscene and beyond, Candyfactory-baked UI background images which flip each turn for no reason, three Hires laced background images just for the options menu etc. pp. It's hilarious and chaotic, but that's TC:AGA.

Only one sound is loaded into chip RAM at a time. Some of those are music modules but those are still not loaded into Fast RAM ever.

Originally Posted by faz

About your remark on my 'stock' remark: I didn't know James, but we also had some conversation about his future plans and he also told me how his disease is hindering him from making desired progress. This was a very long time ago thou. Sad to hear he passed away. I guess TC:AGA is part of his legacy and will remain on of the best original amiga games in my book. RIP.

Part of why TC:AGA was written how it was was to make Amigans want to upgrade their systems so they wouldn't appear so hobbled next to PC hardware. He wanted Amiga to win so he pushed the limits beyond stock configurations.

A discrete graphics card on a "BGPC" (thats Bill Gates' Personal Computer) is a non-stock confuguration. A sound card was also an upgrade back in the 90's. (Heard of the "PC Speaker"? That was their stock configuration back then.) Stock configured Amigas are behind Commodore's downfall.

[faz]

Originally Posted by TCD

Game logic. The demo shows that the engine works regarding HAM and sprites. What is lacking is interaction.

Why do you talk about 'bleeding' then? Care to elaborate?

Sure can do, although I might repeat myself a bit.

I guess you're looking at the demo and think about what's missing to make it a game while I was more looking at the tech behind and thinking for what kind of game the showcased technique can be applied and what are the obstracles.

For a turn-based strategy game in the sense of Chaos it's the amount of different objects to be possibly displayed in a row (=20) which requires to additionally make use of the amiga blitter (within a 'stock'(=512k+512k) environment).

Now using the blitter in this scenario is, I guess, kind of a no-go considering HAM display in general, additional bitplane+copper DMA and sharing slots with the 68k.

To the rescue comes, that it doesn't scroll, tiles are aligned and it's turn-based which I suppose enables distribution of load across multiple frames.

However, if you want to see the non-hidden part of the background tile behind the object and assuming you outlined the object with a base color you might still have HAM artifacts on the right side of the object until the next tile starts with a base color again.

This unwanted effect in general I know as 'HAM color bleeding' and shortened it here.

Hope this clarifies. And I'm sorry if that's technically incorrect, confused you or deemed inappropriate.

[saimon69]

Wonder if a turn based JRPG a la Final Fantasy or Shining Force is a good fit for this