Tony - Born for adventure

[RafalDudek]

Vladimir, please add the version number to the file name (TONY_DEMOx006.atr)

[Beeblebrox]

@popmiloInterestingly I've noticed some direct comparrisons with Blinky's scary school in term of the jumping and getting snagged/stuck on the stepped flag stones on screens.

 

Blinky is one of my favourite A8 games, but one of the frutrations is you can jump onto a stone which has one step up next to it, and when trying to jump up onto it, it doesn't let you unless you move a little away. I can be immensely frustrating. 

 

Case in point in Tony I've gotten stuck and unable to jump up onto the next flagstone and out of danger several times on this screen:

Here: 

 

This happened repeatedly thoughout Blinky's especially here: 

 

For platformers, getting snagged on a perceived invisible thing on a flagstone can mean you lose a life at key times. 

 

I wonder if it's something that will be able to be rectified in Tony? I guess it's a collision detection parameter? 

 

Also, tying in with this, and possible a fix for the aforementioned collision detection - will being able to control Tony in mid air during a jump be something that might be possible? Or is the fixed jump, (once committed), part of the intended jump engine and game design?  Totally understand if it is. Just thought I'd ask.

 

Edit: so case in point in Albert, you can very quickly control Albert in mid air, after you have committed to a jump, which imho makes for nice fluid gameplay for a platformer:

 

 

Loving the speed of play.

Edited February 5 by Beeblebrox

[+MrFish]

29 minutes ago, popmilo said:

Sorry for that. Game's not guaranteed to work in that framerate, but I sure will try to make it work in the future.

17 minutes ago, popmilo said:

We'll see... If I can I'll make it 60fps even if I have to drop some enemies from busier screens. If not  I can go for 30fps, should be playable still.

Yeah, the old NTSC compatibility issues. We're such a pain to PAL-focused developments.

 

[+MrFish]

Probably not necessary to see more at this point, but flickering is an issue on NTSC too.

 

 

[Beeblebrox]

@popmilo hope you don't mind me reposting this here from atarionline.pl(?), but I thought it would be nice. Very interesting information about how it has been approached from a coding perspective, and origin/background.

 

https://atarionline.pl/v01/index.php?ct=nowinki&ucat=1&subaction=showfull&id=1707163785

 

Quote:

 

More than a year ago, when at AtariOnline.pl Rafał Dudek, the designer and graphic designer of the beautiful game Tony: Montezuma's Gold, was looking for a coder to finish this game for Atari, it was not known who would be it and whether it would be possible to find someone like that at all. Ultimately, it was Vladimir Janković who led the project to a playable demo, just published today.

A few words from the coder regarding the technique of creating the game, especially for AtariOnline.pl (own translation):

"I try to code retro games as best as I can. Coding the game "Tony" was like taking a breath of fresh air. Because creating a game based on single screens, with monochrome graphics is liberating! You don't have to use any tricks, think about how many colors can be displayed in a scanning line or in a single character, what limits in sprite width, etc. The only limitations are: available memory and processor speed.

In the game code, I used the "chasing the raster beam" method, used mainly on ZX Spectrum, to avoid image flickering without using double image buffering, because there is no memory left for it. The entire game runs on an Atari with 64KB of RAM and takes up almost every free byte. Since the Atari doesn't have 256 characters in the character set like the C64 version of Tony, I had to use bitmap mode, which takes up almost 8KB for the screen alone. It's similar with sprites. For each sprite moving horizontally, like Tony, bats, etc., I had to use arrays with every possible byte value shifted in multiple horizontal positions. Then there's sprite masking, vertical movement, sprite priorities, etc. On the other hand, since it's all done in software, it's easy to modify the data, and that means coding the remaining four levels of the game shouldn't take much time and effort. I hope that Atari fans will like "Tony" and will play it for many years.

"Chasing the beam" is an expression dating back to the Atari 2600 console. It didn't have much memory for graphics, so all such things were drawn in assembly code - the instruction put something on the screen and the electron beam drew the image on the screen. screen. In the case of the game "Tony" (and most ZX Spectrum games) this means that I wait until the raster beam intersects a specific position of
Tony's sprite's foot, then I start erasing the old position (drawing the background at that point) and then draw Tony's sprite ego in a new position. The same applies to the rest of the enemies and objects on the screen. If the code finishes this one cycle of drawing graphics effects before the raster beam "catches up" to this spot, everything is fine and there is no flickering. In a few rooms I had to remove several enemies that exist in the C64 version because the Atari's processor simply couldn't handle it all at 50 frames per second. This could be done if I had more time to write more optimized code, or by simply using 128K of RAM to speed things up.

Rafał Dudek also made a special comment for the readers of AtariOnline.pl:

"I am the originator and author of the game that you can now play. While creating this fascinating adventure, I had the opportunity to meet many extraordinary people. Some of them joined the team of creators of the game "Tony". Also the community fans of the Atari computer turned out to be extremely kind and supportive. I met with great enthusiasm and warmth from people who share the love for retro games for 8-bit computers. Thank you for your patience and support - it is extremely important to me. I cordially invite you to take part in this adventure that we have created together. I hope that the game will provide you with many emotions and moments of entertainment.

So far, a demo has been released for Commodore 64 and Amiga. But I treat Atari XL very specially and that's why I really wanted Tony to appear on Atari. As in the case of the C64 demo, in which the reported errors in the demo were corrected, here I am counting on players to report any problems so that the final game will be free of them. I will add that the Amiga version is slightly worse than the 8-bit version, because it was made in Blitz Basic, and the 8-bit version was written in assembly language. This can be seen in the appearance of the chambers - on the Amiga, for example, the number of flames had to be changed, the jump is also different, on the C64 and Atari the parabola is better. So 8bit prevails!

At the beginning of this novelty there is the cover of the collector's version box, which will be published by Jerzy Dudek from Retronics (the similarity of names is accidental, it is not a family!).

Edited February 5 by Beeblebrox

[ALEXANDER]

11 hours ago, popmilo said:

Well, d-day is here

 

First public release of the playable demo level of "Tony - born for adventure" is here

 

I'm proud to present to you this game we've been making during last year. Think we've done a good job, and it all started by great design and gfx that Rafal created.
When I saw awesome monochrome pyramids, jungle and Indy like player character I just got to get involved  After making a proof of concept bitmap soft sprite engine there was no real obstacles left, we just didn't knew how much time it will take.
Well, now the waiting is over, game engine is pretty robust, entire gameplay including title screen etc fit into single load, so the rest of levels will be much easier to produce.

Big thanks to Rafal Dudek, Michal Brzezicki, Maciej Malecki, Marcin Nowak, Jacek Malik, Bocianu and all the others whom I can't remember right now.

Here's small video of me playing it, hope you'll have as much fun as I did while playing it for thousand times during development

Game files in attachment. Third version with added fire button for skipping demo parts and fixed music.

 

tony.xex 39.09 kB · 13 downloads

 

tony.atr 90.02 kB · 9 downloads

 

Please let me know if you find any serious bugs or issues with gameplay. Be gentle as it is the first version released

And of course if anybody is interested about tech used, details about code, feel free to ask.

 

Cheers!
Vladimir

You are awesome guys ! Congrats in advance.

 

[TheNameOfTheGame]

Great work!  Even at demo stage of dev the game is showing very nicely!

[+MrFish]

4 minutes ago, ALEXANDER said:

You are awesome guys ! Congrats in advance.

 

Framerate on that video does not reflect actual gameplay at all.

 

[pps]

7 hours ago, popmilo said:

@MrFish It's even worse than I thought
Take a look at comparisson between free cpu cycles on Pal system vs how many scanlines are "overflow" (little over full ntsc screen height, so it skips a frame because of only couple scanlines.... ufff).

We'll see... If I can I'll make it 60fps even if I have to drop some enemies from busier screens. If not  I can go for 30fps, should be playable still.

 

Maybe a solution to get some more time would be to make the visible area a bit smaller (1 or 2 gfx0 lines) if 60Hz machine is detected. 

[popmilo]

9 hours ago, Beeblebrox said:

@popmiloInterestingly I've noticed some direct comparrisons with Blinky's scary school in term of the jumping and getting snagged/stuck on the stepped flag stones on screens.

..Case in point in Tony I've gotten stuck and unable to jump up onto the next flagstone and out of danger several times on this screen:

Here: 

 

Also, tying in with this, and possible a fix for the aforementioned collision detection - will being able to control Tony in mid air during a jump be something that might be possible? Or is the fixed jump, (once committed), part of the intended jump engine and game design?  Totally understand if it is. Just thought I'd ask.

I can jump easily from that spot. Hold joystick right, press fire you jump right... Right into your death
So it is game design thing. Jumps are fixed for a reason, so you need to learn levels and where you can die or not.
To be honest I hated it at start, even when I was coding it. But then I've realized Rafal designed the game with that jump style in mind and it totally makes sense.

For example that screen with potion on the top right makes player think "ha! I'll just go up there and grab that free potion!" - Wrong! Not easy at all
And you don't need that potion at all... plenty of easier to get on previous screens. So it's a trap for greedy players

 

[Beeblebrox]

43 minutes ago, popmilo said:

I can jump easily from that spot. Hold joystick right, press fire you jump right... Right into your death
So it is game design thing. Jumps are fixed for a reason, so you need to learn levels and where you can die or not.
To be honest I hated it at start, even when I was coding it. But then I've realized Rafal designed the game with that jump style in mind and it totally makes sense.

For example that screen with potion on the top right makes player think "ha! I'll just go up there and grab that free potion!" - Wrong! Not easy at all
And you don't need that potion at all... plenty of easier to get on previous screens. So it's a trap for greedy players

 

Thanks, although it's not quite what I mean. I know how to jump in either direction and time it right(😁). It's rather the case with both games that it snaggs/catches in those instances when you are trying to jump up from one flagstone to another, where you don't expect it. Watch the blinkys video and you'll see it illustrated more clearly. Being able to control Tony after he has committed to a jump would get around this, but if that is not intended in order to make the game more challenging then fair enough.  If you could control Tony after he jumped and was still in the air, here you would be able to jump vertically first, then move to the right. 

 

I think it's just at this early stage, especially with a platformer, it's worth raising/providing feedback on any gameplay/game engine mechics that players feel hinders or frustrates them.

 

Also just to say it's not a case of me just wanting an easier game btw. I play the A8 prince of Persia after all, which can be frustrating but rensoup nailed the collision detection and that is a different kinda platformer altogether.  Also love Henry's house, which relies on pixel perfect jump timing. In the latter game you don't have the same issue in terms of getting snagged between platform jumps. 

 

No worries either way, just wanted to convey the point. The number of times I've died in blinkys unnecessarily when this has happened and isn't expected is such a pity. Would have made the game less frustrating. 

 

Keep up the good work.

 

[popmilo]

Same as you, I've played Blinky to the death (till I've managed to finish the bloody game ) and know your pain with jumping.

That's exactly why I've tried to code "no control jump" to be fair as much as it can be. If you press fire without holding left-right Tony jumps up. If you hold left-right and then press fire he jumps to left right.
The only way I could maybe improve that would be to add another check on frame after jump starts (or couple maybe), if then you turn joystick to the side, rest of jump would be to the side.. We'll see.
I know Maciej who coded c64 version also added kind of lag to joystick control so it's easier to perform jumps for people who don't have precise control of joysticks, and I would really like to support that and give option for better gameplay experience to everybody.
 

 

[jvas]

I like the way how it is done in Bounty Bob Strikes Back: you can add horizontal direction to your jump even after a straight vertical jump had been started, but not allowed to change the direction afterwards. This way you can adjust the length of your jump, still not as "un-natural" as in Albert.

More tricky levels can be done if the length of the jump is not fixed (remember in the prequel, in Miner 2049, there was only fixed length jumps).

[Rybags]

Well done.  I just gave it a go, controls nicely.  Didn't get really far so this looks like another one of those epics like Marbled, RGB and Ridiculous Reality.

[matosimi]

@popmilo, nice work!

 

I have encountered just 2 small glitches in the sprite deletion...

1)

tony_x1.atstate2

 

The bat on this screen can kill you when climbing the ladder, when it's removed (either by killing you or you killing it) it deletes the 1px wide area from the ladder together with the bat sprite. I assume this is the only place where bat or other flying enemy can kill you while climbing the ladder.

 

2)

tony_x2.atstate2

The skull on this screen leaves couple pixels (1 line) when killed... it needs couple tries to succeed to leave the mark.

 

I'm not sure whether it is worth chasing these bugs, nothing that important...

I think 1st could be fixed simply by removing last position from bats path. However I'm not sure whether it remains lethal to the player climbing the ladder.

 

2nd could be caused by the fact that the skull, two bats and Tony overlap single vertical position, so sprite drawing routine does not handle all the redraws at the same time.

 

Good luck with the rest of the project!

[_The Doctor__]

I sometimes wish dead things left signs they were there and died leaving a mark or a mess where they were.

That said, the ladder edge going away is one to fix. Leaving goo behind would add to the thickness of the ladder.

 

NTSC detect and correct that was suggested sounded reasonable. No need to remove stuff. The coding runs are indeed shorter but there are more of them in a given time period. That means a refactor for when some things get placed in each of those to keep it in order if doing perfection. Or if just taking away a line or two, changing delay times and types etc.

[pseudografx]

I have also encountered one occassion where the skull was not completely deleted when it touched you and a few pixels stayed on the screen. I did not take a screenshot though.

[popmilo]

2 hours ago, pseudografx said:

I have also encountered one occassion where the skull was not completely deleted when it touched you and a few pixels stayed on the screen. I did not take a screenshot though.

Yeah it's a known bug, some stupid mismatch between memorizing old position of sprite and actual erasing it when new frame is drawn (or enemy is removed). Will fix it as soon as I can.

 

[amarok]

Bravo! You made it! I'm happy you were able to make this amazing project a reality on 8-bit Atari computers.

The game already looks great and I'm sure that any minor problems will be easily solved. @popmilo, congratulations especially to you, as I suspect the project is a challenge from the software development perspective. @RafalDudek, you chose a great coder to bring your unique and outstanding work of art to life.

I am keeping my fingers crossed for your success!

[dhor]

Great effects so far. I love details of the graphic elements, 1bit color minimalism. I can even live with fixed jumps I would love to see possibility to jump from standstill though. Sometimes there's no place to 'get speed' to jump. Being able to jump in place then move left/right should help definitely.

 

There are also leftovers occasionally on the screen, what was already mentioned about. I was able to generated them by dying from enemy while jumping - then part of enemy wasn't removed properly.

[+DjayBee]

21 hours ago, popmilo said:

The only way I could maybe improve that would be to add another check on frame after jump starts (or couple maybe), if then you turn joystick to the side, rest of jump would be to the side.. We'll see.
I know Maciej who coded c64 version also added kind of lag to joystick control so it's easier to perform jumps for people who don't have precise control of joysticks, and I would really like to support that and give option for better gameplay experience to everybody.

Great idea!

[+MrFish]

2 hours ago, dhor said:

I would love to see possibility to jump from standstill though.

You can already do that. You need to hit the button and a direction simultaneously; but you need to actuate the direction just a split second before the button.

 

[Yautja]

The graphics are simply stunning! And the music is not far behind. A couple of questions:

- What is the "official" name of the game? "Tony: Montezuma's Gold" or "Tony: Montezuma's Treasure"?
- What percentage of progress has this playable demo compared to what will be the final version?

[RafalDudek]

35 minutes ago, Yautja said:

The graphics are simply stunning! And the music is not far behind. A couple of questions:

- What is the "official" name of the game? "Tony: Montezuma's Gold" or "Tony: Montezuma's Treasure"?
- What percentage of progress has this playable demo compared to what will be the final version?

I want Tony to be a series of 3 games.
Tony - Montezuma's Gold (that's the part we're doing now)
Tony - Ark of the Covenant
Tony - Shimazu Masamune's Katana

[dhor]

3 hours ago, MrFish said:

You can already do that. You need to hit the button and a direction simultaneously; but you need to actuate the direction just a split second before the button.

 

Right. I'm not that fast anymore

1 hour ago, RafalDudek said:

I want Tony to be a series of 3 games.
Tony - Montezuma's Gold (that's the part we're doing now)
Tony - Ark of the Covenant
Tony - Shimazu Masamune's Katana

Great Idea @RafalDudek ! However I would add some kind of puzzles to it. Like moving stones in right order to open doors, parchment with ancient text to match the symbols on the moving ring and so forth.  Sure I aware that due to enormous amount of graphics those riddles need to be simplified to fit the memory... But who knows