Thanks BiNMaN for your perfect analysis about technical issues discussed by our friend Alessandro Grussu...
I'd like to take this opportunity to emphasize the decisions that led me to choose the gameplay.
First of all, as we can see, the map rooms in that AGD game, are far more detailed than some standards: here, walls, rocks and vegetation have represented the greatest task, trying to be as accurate as possible - let me say - differently from many other platform games, where whole screens are made by a couple of simple bricks. In other words, i tried to avoid the classic "Manic Miner" graphical style, in order to increase the "Ultimate Play The Game" feeling.
And that "feeling" which i tried to convey was a necessary step, because this one, it's a game dedicated to a major title (read: legend) like Mire Mare.
Obviously it has to be considered a very modest and simple tribute, where i had to sacrifice some choices, like some sprite animations. But finally, i feel happy with the result, because at the beginning i never thought to reach it as it is now.
The "AGD" logo drawn with the Ultimate fonts, which appears in my cassette cover art, is not accidental: it warns someway that the game is modest, with some limitations if we want to criticize negatively, but made with a great passion, and that's everything for me.
Other choices are related to how i meant the game and differentiate it from other well-known Sabreman stories.
Anyway, i'll still be happy to make improvements (memory limitations permitting), and here's the next:
* * * v.1.05
- Added few seconds of invulnerability at player's respawn: this way, player doesn't lose all lives when killed close to a Guardian respawn point;
- Countdown timer added: volcanoes cannot wait forever, so now a time limit is shown over the frame. Countdown timer refreshes every time a jewel is thrown into the pit.
Thanks for the answer Binman, that explains it all quite nicely. About the large block count, I've used them up on all of my games (you can have a maximum of 254), yet by using the tip described below I managed to obtain 35 locations in both Apulia-13 Director's Cut and Cronopios y Famas - not counting text lines, objects etc.
...made with a great passion, and that's everything for me.
You are not alone, mate: I believe this is the main motivation behind writing games, or any other software for that matter, for a 32-year-old home computer ;)
Anyway, i'll still be happy to make improvements (memory limitations permitting), and here's the next:
Will be waiting for that, then!
In the meantime, if I may give you a tip... in order to avoid excessive use of memory with AGD, try to restrain frames to 3 per sprite whenever possible. If you design the sprite graphics carefully you can save a lot of memory without making the sprites themselves look awkward. I employed this trick with my latest games (Funky Fungus, Al's Double Bill and Cronopios y Famas) and it worked wonders - less memory means more room for locations, objects, other sprites etc.
Thanks for the answer Binman, that explains it all quite nicely. About the large block count, I've used them up on all of my games (you can have a maximum of 254), yet by using the tip described below I managed to obtain 35 locations in both Apulia-13 Director's Cut and Cronopios y Famas - not counting text lines, objects etc.
Yet another one misspelling my surname... :roll:
You are not alone, mate: I believe this is the main motivation behind writing games, or any other software for that matter, for a 32-year-old home computer ;)
Will be waiting for that, then!
In the meantime, if I may give you a tip... in order to avoid excessive use of memory with AGD, try to restrain frames to 3 per sprite whenever possible. If you design the sprite graphics carefully you can save a lot of memory without making the sprites themselves look awkward. I employed this trick with my latest games (Funky Fungus, Al's Double Bill and Cronopios y Famas) and it worked wonders - less memory means more room for locations, objects, other sprites etc.
I can beat that, how about a way to reduce a 4 framed sprite from 514 bytes of memory to 130 bytes. Works best with platform games on sprites that move along the horizontal axis. Although it could be used on any game. It also stops the AGD dancing on the spot when you press left and right at the same time.;-)
Hmm... Just 130 bytes for 4 frames? How can it be done?
I must add that I came up with that 3-frames-per-sprite idea by examining the fan sprite you kindly allowed me to put in Apulija-13 while experimenting for the Director's Cut version which ultimately (no pun intended ;)) ended up in Al's Double Bill. I thought that if such a convincing animation could be done with a frame less, it would mean sparing 128 bytes per sprite - and in games where you have 20 animated sprites and more, that means something ;)
It's not useful everywhere, especially if you use frame as a counter like Luca did for sound and movement. I'll need to put some pictures together to illustrate what I mean. And it's no good for a static animation like the fan, when I managed to get that fan from 4 frames to 3 I was pleased I must admit. Never occurred to me to try 2 frames though, must try.
ok here we go, I may start to waffle and repeat myself :wink:
When I first started to use AGD I'd noticed two things, sprites and screens took up a lot of memory.
I'd spoken to Jonathan about the screen issue and from that discussion he implemented a screen compression routine along the horizontal axis, so the more you repeat a block and the less detailed the screen the better the compression.
Sprites were a different matter, from my work on HomeBrew I'd noticed that all the sprites are preshifted along the horizontal axis. Also Jonathan moves his sprites 2 pixels at a time, I later discovered the same would be true for AGD. What this allowed me to do was to increase the number of sprites in the game (as long as they dropped vertically or were static) without an increase in memory (this became the Cronosoft release). So instead of one explosion each preshift became a different one, so now I had 4 instead if just 1.
So in AGD each sprite should take 32 bytes (+2 bytes additional data) but because every frame you draw AGD produces an additional 3 frames of the same sprite but rotated to right by 2 pixels, it now takes up 128 bytes (+2). So if you end up with a 4 framed sprite it's now 512 bytes (+2) with addition of the 3 preshifted sprites produced for each frame.
So the trick is just draw the first frame on AGD then use Spectrum Graphics Editor (SGE) to load in the tap file you have created, then change the 3 preshifted frames to the other 3 frames of your animation but remembering to rotate them.
Now there's a few things to note, firstly you may get the R:Tape loading error the first time you load, ignore it and save the data back out. The new save will be fine, also the sprite will no longer animate if it moves only vertically, you won't need the animate and animback (introduced after I another chat to Jonathan) commands. Finally you won't be able to use the frame count anymore, say if you have a specific sound triggered by a frame number or if you have a sprite move on a specific frame number (well there is only one frame now after all), if you do you will have to do it with a variable instead.
v.1.05
- Added few seconds of invulnerability at player's respawn: this way, player doesn't lose all lives when killed close to a Guardian respawn point;
- Countdown timer added: volcanoes cannot wait forever, so now a 'lava hourglass' is shown over the frame. The hourglass countdown refreshes every time a jewel is thrown into the pit.
v.1.04
- Increased difficulty by changing Jewels Guardians dangerousness for deadly (so beware, a life is lost at first touch with them);
- Enhanced fire effect by applying colours to weapon images.
v.1.03
- There was a cheat with the doors that deliberately left in where you could, if timed correctly, pass through a door without a key or the axe, that has now been locked out.
v.1.02
- Player's respawn fix: player should respawn and not disappear.
v.1.01
- Changed fire performance: player changes colour instead of perform movements while shooting (Thanks BiNMaN!);
- Player's respawn fix: player will respawn in the exact death point.
I think this game is well made within the limitations of the tools used, but I feel that many of the suggested improvements are simply not possible in it's current form. I was thinking of writing such a game myself a while ago, but as this now exists probably won't, but I think it needs it's own engine to truely do it justice (larger main character, larger map / puzzles, weapon animation etc)
I think this game is well made within the limitations of the tools used, but I feel that many of the suggested improvements are simply not possible in it's current form. I was thinking of writing such a game myself a while ago, but as this now exists probably won't, but I think it needs it's own engine to truely do it justice (larger main character, larger map / puzzles, weapon animation etc)
Thanks Bobs, i totally agree. Actually i wonder why in decades there hasn't been any skilled programmer (which i don't consider to be) who ever attempted to end the Sabreman saga...
Anyway i've never had mania of grandeur, and i feel satisfied with the latest release. Now i'll look forward to my next AGD title ;)
Actually i wonder why in decades there hasn't been any skilled programmer (which i don't consider to be) who ever attempted to end the Sabreman saga...
The reason is probably that it's a daunting task to do just that. I certainly wouldn't want to do it.
And I'm sorry to say, that while I think the game itself is good, it should never have been given that title. AGD just isn't the right tool for a Mire Mare game and I feel it cheapens the Sabreman legacy and produces a game that is a lot less than it should have been.
Had it been called "The quest for the Wolf amulet" (or some similar rubbish) :lol: then it would've just been an Ultimate style game and I'd be okay with that, but this is a bit like putting Volkswagen engine into a Rolls-Royce chassis - it's a car and it'll get you from A to B, but it's pretending to be something it isn't.
Sorry. But like I said - the game is good. An awesome game for a first game, just in my humble opinion - mistitled.
Had it been called "The quest for the Wolf amulet" (or some similar rubbish) :lol: then it would've just been an Ultimate style game and I'd be okay with that...
Exactly for this reason the title has been (partially) changed from the original. But the purpose was to materialize someway BiNMaN mockups, and the story was built around some Stamper's trails (volcanoes, locations taken from Land of Ultimatum map)... references to Mire Mare are enough to "dare" a reference to the original title, but it's clear (at least to me), that this is only a modest tribute (as i said many times and specified in game instructions too).
It was released as a perk on a kickstarter, then some spares were sold then some of those perk/sold games ended up being sold on ebay for a small fortune.
Comments
I'd like to take this opportunity to emphasize the decisions that led me to choose the gameplay.
First of all, as we can see, the map rooms in that AGD game, are far more detailed than some standards: here, walls, rocks and vegetation have represented the greatest task, trying to be as accurate as possible - let me say - differently from many other platform games, where whole screens are made by a couple of simple bricks. In other words, i tried to avoid the classic "Manic Miner" graphical style, in order to increase the "Ultimate Play The Game" feeling.
And that "feeling" which i tried to convey was a necessary step, because this one, it's a game dedicated to a major title (read: legend) like Mire Mare.
Obviously it has to be considered a very modest and simple tribute, where i had to sacrifice some choices, like some sprite animations. But finally, i feel happy with the result, because at the beginning i never thought to reach it as it is now.
The "AGD" logo drawn with the Ultimate fonts, which appears in my cassette cover art, is not accidental: it warns someway that the game is modest, with some limitations if we want to criticize negatively, but made with a great passion, and that's everything for me.
Other choices are related to how i meant the game and differentiate it from other well-known Sabreman stories.
Anyway, i'll still be happy to make improvements (memory limitations permitting), and here's the next:
* * *
v.1.05
- Added few seconds of invulnerability at player's respawn: this way, player doesn't lose all lives when killed close to a Guardian respawn point;
- Countdown timer added: volcanoes cannot wait forever, so now a time limit is shown over the frame. Countdown timer refreshes every time a jewel is thrown into the pit.
Soon available!
You are not alone, mate: I believe this is the main motivation behind writing games, or any other software for that matter, for a 32-year-old home computer ;)
Will be waiting for that, then!
In the meantime, if I may give you a tip... in order to avoid excessive use of memory with AGD, try to restrain frames to 3 per sprite whenever possible. If you design the sprite graphics carefully you can save a lot of memory without making the sprites themselves look awkward. I employed this trick with my latest games (Funky Fungus, Al's Double Bill and Cronopios y Famas) and it worked wonders - less memory means more room for locations, objects, other sprites etc.
I can beat that, how about a way to reduce a 4 framed sprite from 514 bytes of memory to 130 bytes. Works best with platform games on sprites that move along the horizontal axis. Although it could be used on any game. It also stops the AGD dancing on the spot when you press left and right at the same time.;-)
I must add that I came up with that 3-frames-per-sprite idea by examining the fan sprite you kindly allowed me to put in Apulija-13 while experimenting for the Director's Cut version which ultimately (no pun intended ;)) ended up in Al's Double Bill. I thought that if such a convincing animation could be done with a frame less, it would mean sparing 128 bytes per sprite - and in games where you have 20 animated sprites and more, that means something ;)
When I first started to use AGD I'd noticed two things, sprites and screens took up a lot of memory.
I'd spoken to Jonathan about the screen issue and from that discussion he implemented a screen compression routine along the horizontal axis, so the more you repeat a block and the less detailed the screen the better the compression.
Sprites were a different matter, from my work on HomeBrew I'd noticed that all the sprites are preshifted along the horizontal axis. Also Jonathan moves his sprites 2 pixels at a time, I later discovered the same would be true for AGD. What this allowed me to do was to increase the number of sprites in the game (as long as they dropped vertically or were static) without an increase in memory (this became the Cronosoft release). So instead of one explosion each preshift became a different one, so now I had 4 instead if just 1.
So in AGD each sprite should take 32 bytes (+2 bytes additional data) but because every frame you draw AGD produces an additional 3 frames of the same sprite but rotated to right by 2 pixels, it now takes up 128 bytes (+2). So if you end up with a 4 framed sprite it's now 512 bytes (+2) with addition of the 3 preshifted sprites produced for each frame.
So the trick is just draw the first frame on AGD then use Spectrum Graphics Editor (SGE) to load in the tap file you have created, then change the 3 preshifted frames to the other 3 frames of your animation but remembering to rotate them.
Now there's a few things to note, firstly you may get the R:Tape loading error the first time you load, ignore it and save the data back out. The new save will be fine, also the sprite will no longer animate if it moves only vertically, you won't need the animate and animback (introduced after I another chat to Jonathan) commands. Finally you won't be able to use the frame count anymore, say if you have a specific sound triggered by a frame number or if you have a sprite move on a specific frame number (well there is only one frame now after all), if you do you will have to do it with a variable instead.
v.1.05
- Added few seconds of invulnerability at player's respawn: this way, player doesn't lose all lives when killed close to a Guardian respawn point;
- Countdown timer added: volcanoes cannot wait forever, so now a 'lava hourglass' is shown over the frame. The hourglass countdown refreshes every time a jewel is thrown into the pit.
v.1.04
- Increased difficulty by changing Jewels Guardians dangerousness for deadly (so beware, a life is lost at first touch with them);
- Enhanced fire effect by applying colours to weapon images.
v.1.03
- There was a cheat with the doors that deliberately left in where you could, if timed correctly, pass through a door without a key or the axe, that has now been locked out.
v.1.02
- Player's respawn fix: player should respawn and not disappear.
v.1.01
- Changed fire performance: player changes colour instead of perform movements while shooting (Thanks BiNMaN!);
- Player's respawn fix: player will respawn in the exact death point.
v.1.00
- A first release to test the audience!
https://twitter.com/bobsstuffgames
https://www.facebook.com/bobs.stuff
http://www.bobs-stuff.co.uk
Thanks Bobs, i totally agree. Actually i wonder why in decades there hasn't been any skilled programmer (which i don't consider to be) who ever attempted to end the Sabreman saga...
Anyway i've never had mania of grandeur, and i feel satisfied with the latest release. Now i'll look forward to my next AGD title ;)
The reason is probably that it's a daunting task to do just that. I certainly wouldn't want to do it.
And I'm sorry to say, that while I think the game itself is good, it should never have been given that title. AGD just isn't the right tool for a Mire Mare game and I feel it cheapens the Sabreman legacy and produces a game that is a lot less than it should have been.
Had it been called "The quest for the Wolf amulet" (or some similar rubbish) :lol: then it would've just been an Ultimate style game and I'd be okay with that, but this is a bit like putting Volkswagen engine into a Rolls-Royce chassis - it's a car and it'll get you from A to B, but it's pretending to be something it isn't.
Sorry. But like I said - the game is good. An awesome game for a first game, just in my humble opinion - mistitled.
My games for the Spectrum: Dingo, The Speccies, The Speccies 2, Vallation, SQIJ.
Twitter: Sokurah
Exactly for this reason the title has been (partially) changed from the original. But the purpose was to materialize someway BiNMaN mockups, and the story was built around some Stamper's trails (volcanoes, locations taken from Land of Ultimatum map)... references to Mire Mare are enough to "dare" a reference to the original title, but it's clear (at least to me), that this is only a modest tribute (as i said many times and specified in game instructions too).
If so is it still available and where from ?
Yes it was.
http://www.ebay.co.uk/sch/i.html?_odkw=mire+mare+spectrum&LH_Complete=1&LH_Sold=1&_osacat=0&_from=R40&_trksid=p2045573.m570.l1313.TR0.TRC0.H0.TRS0&_nkw=mire+mare+spectrum&_sacat=0
Ex-Ocean Software graphic artist -
Download my FREE PDF 'LOAD DIJ DIJ' (180,000+ words): https://ko-fi.com/i/IG2G3BEJZP
ZX Art page: https://zxart.ee/eng/authors/m/mark-r-jones/
https://twitter.com/MarkRJones1970
https://www.facebook.com/OceanSoftwareLtd/
https://www.facebook.com/ultimateptg/
Ex-Ocean Software graphic artist -
Download my FREE PDF 'LOAD DIJ DIJ' (180,000+ words): https://ko-fi.com/i/IG2G3BEJZP
ZX Art page: https://zxart.ee/eng/authors/m/mark-r-jones/
https://twitter.com/MarkRJones1970
https://www.facebook.com/OceanSoftwareLtd/
https://www.facebook.com/ultimateptg/
story of the zx spectrum in pixels I think