[Atari 2600] RoboMechanik - a puzzle/action tile-based game

[Lillapojkenpåön]

This is awesome!!! I thought the occasional easy level you could just move fast through was good and like a pause for your brain and gave it a nice tempo.

I will play this more later and record a video and give some feedback.

Great music to, makes me think of big spinning 3D letters for some reason

[Thomas Jentzsch]

Any updates?

[KK/Altair]

I've been sick recently, so I had to make a break in this project. I hope to start producing at least #ScreenshotSaturday updates again soon.

I'm really greatful for all your level assesments, Thomas.

It will still be a major challenge sorting all these levels correctly (I have more than twice than in WIP), though.

 

And while the second boss might be f-hard, it's still by far not the hardest level I designed.

[Brian O]

This game is really cool. I love the gameplay, looks, etc. I can't wait until this is finished.

[iesposta]

I've been sick recently, so I had to make a break in this project. ...

 

 

Get well soon!

This is excellent.

 

You could probably adapt your skills to use AtariAge's latest bankswitching format and make a game with graphics better than this:

 

To sell your games, if you don't want to do any assembling, printing, etc. and leave the release up to AtariAge's discretion, AtariAge can do all the work if you provide artwork and the final game binary. You will get $5 for every copy sold. It adds up quickly.

Or you could have AtariAge build a small run of labeled carts which cost around $20 each. Make your own instructions or booklet and sell them yourself in small runs of 10 or how ever many you can afford to put your money upfront. ?

[KK/Altair]

@iesposta: I'm in touch with AtariAge almost since first version of this project.

Also while ARM-based hacks sound fun, I've decided to go full retro and make most of the old plain F4 format.
I might try ARM hacks at some point, as it sounds quite fun, especially with all the logic you can do on the ARM.

[Brian O]

 

 

Get well soon!

This is excellent.

 

You could probably adapt your skills to use AtariAge's latest bankswitching format and make a game with graphics better than this:

IMG_1572.JPG

 

To sell your games, if you don't want to do any assembling, printing, etc. and leave the release up to AtariAge's discretion, AtariAge can do all the work if you provide artwork and the final game binary. You will get $5 for every copy sold. It adds up quickly.

Or you could have AtariAge build a small run of labeled carts which cost around $20 each. Make your own instructions or booklet and sell them yourself in small runs of 10 or how ever many you can afford to put your money upfront. ?

 

I actually like the game's graphics as they are. I feel like I'm playing an old Game Boy game.

[KK/Altair]

 

I actually like the game's graphics as they are. I feel like I'm playing an old Game Boy game.

That's actually as much as the original VCS CPU can handle. And way more than the chip designers imagined. And I'm not really sure the ARM "bankswitching" format for the colorful tiles came into production, because IIRC it involved forcibly changing the bus state while the CPU was driving it, making it incompatible with some of the console variants.

[+SpiceWare]

Correct, some systems didn't work correctly with it which is why I switched to CDF for Draconian.

cd-w figured out an arrangement to get 128 pixels across instead of 96, which would give you 16 tiles instead of 12. I'm not sure if that could be updated using just 6507 code, or if you'd require the DPC+ or CDF coprocessors' data fetchers to assist.

[MemberAtarian]

Correct, some systems didn't work correctly with it which is why I switched to CDF for Draconian.

 

cd-w figured out an arrangement to get 128 pixels across instead of 96, which would give you 16 tiles instead of 12. I'm not sure if that could be updated using just 6507 code, or if you'd require the DPC+ or CDF coprocessors' data fetchers to assist.

I don't think KK would like to use any co-processors, he's more interested in surpassing the limitations of the original hardware.

[+SpiceWare]

Which is why I pointed him to the player arrangement, so he could determine if it was compatible with his design goals.

[Thomas Jentzsch]

cd-w figured out an arrangement to get 128 pixels across instead of 96, which would give you 16 tiles instead of 12. I'm not sure if that could be updated using just 6507 code, or if you'd require the DPC+ or CDF coprocessors' data fetchers to assist.

I don't think this is even remotely feasible for stock 6507 code.

• we have to update 8 sprite registers, plus a dummy write, so that's 3*9 = 27 cycles
• an index load needs at least 4 (here 5) cycles, so 5*8 = 40 cycles
• then we have 3 RESPx, 3*3 = 9 cylces
• an immediate load and writes to HMP1 and HMBL, 2 + 2*3 = 8 cycles
• an immediate load and write to NUSIZx, 2 + 3 = 5 cycles
• a write to HMOVE, 3 cycles
• and immediate load and write to ENABL, 2 + 3 = 5 cycles
• a branch check, 2 cycles (minimum)

That's already 99 cycles, I think in the end we would need almost twice as many cycles as DPC+. Actually I would be happy if we would be able to just get one extra sprite per line (2*56 =112 pixel) for a stock 6507.

Edited April 24, 2018 by Thomas Jentzsch

[KK/Altair]

I don't think KK would like to use any co-processors, he's more interested in surpassing the limitations of the original hardware.

 

At some point I'd like to try pushing the limits of ARMari 2600, too, but not for this title, as it's already close to being done.

 

 

Which is why I pointed him to the player arrangement, so he could determine if it was compatible with his design goals.

 

Right now I have tons of levels developed for 12x9 tileboard, and not enough stock RAM (no SuperCHip used) for anything larger, so the core design is already closed. It's just the levels, maybe some more tile types/logic and general polishing at this point.

 

But I'd love to try using the ARM at some point to try pushing boundaries of 6507+ARM combo.

[Thomas Jentzsch]

Right now I have tons of levels developed for 12x9 tileboard...

That sounds very good. Please let us know if you need tests and opinions.

 

And maybe some people would be interested to help by designing levels.

[KK/Altair]

That sounds very good. Please let us know if you need tests and opinions.

 

And maybe some people would be interested to help by designing levels.

 

That would definitely help.

 

@Everybody:

 

If anyone is interested in helping, this way or another, just let me know. Proper testing of all maps against more or less unsuspecting players would really help getting learning curve right*.

And right now I don't have the level editor documented (some numbers and behaviors are hard-coded), so that would take some time (especially that I'm leaving for a week now), but it should be doable, too.

Still, because this is zero-budget side project, I won't be able to offer any compensation for this... but if anyone is willing to help, you still could have whole lot of fun in the process.

 

 

*) Remember that this is a retro game, so expect at least some levels of that "f****** brutally hard" difficulty in the later game. Or a bit above that.

 

[Thomas Jentzsch]

You could offer credits in the manual, they don't require any budget.

[KK/Altair]

You could offer credits in the manual, they don't require any budget.

 

I will definitely do that. Even if I would have to reserve a whole page for that (I have an option to switch to 64k cart, which would fit about 500 levels total, in case of a massive response).

[Thomas Jentzsch]

Maybe, when you are ready, start a new thread just for the level design. The easier accessible the required info and tools are, the more and better results you will get in return. Best would be a framework, where the level designers can directly test their creations.

[KK/Altair]

Maybe, when you are ready, start a new thread just for the level design. The easier accessible the required info and tools are, the more and better results you will get in return. Best would be a framework, where the level designers can directly test their creations.

 

It's a WYSIWYG tile editor and a normal Windows application. And you can test levels instantly - just hit F5 and the editor compiles the map, patches BIN file with it and runs it with Stella. The game even detects it was patched and skips all menus straight to the gameplay, so the whole process is almost instant, and dying/winning while in this mode restarts the map immediately.

[+SpiceWare]

Based on the dracsec downloads, being Windows only will cut your response quite a bit.

[KK/Altair]

Based on the dracsec downloads, being Windows only will cut your response quite a bit.

 

Well... porting command-line tool is one thing, and porting editor made with DirectX is completely another. Will the result be worth the effort?

[+SpiceWare]

That's your call, just wanted you to be aware that I only saw about 40% downloaded the Windows version of my level tool.

 

You might be able to do something similar for non-windows user, a simple text file like this would be easy enough for a user to create and your tool to parse:

WWWWWWWWWWWW
W.Y.WW#..#.W
W...WW.##T#W
WW#WWW...##W
.W...W#WWWWW
.W.W.W.W...W
.WT......S.W
.WWWWWWW...W
.......WWWWW

---

where:

W = wall
. = space
Y = You
T = Screw
# = crate
S = Ship

---

for this level:

[KK/Altair]

That's your call, just wanted you to be aware that I only saw about 40% downloaded the Windows version of my level tool.

 

You might be able to do something similar for non-windows user, a simple text file like this would be easy enough for a user to create and your tool to parse:

 

There's a bit more to that. The game has 16 tile slots for unique tiles. Some are reserved, while other have hardcoded restrictions or special meaning in some cases (like certain monsters dropping "item" of hardcoded tile type), which are only partially automated. Also every monster has some customizable properties (speed, initial direction, behavior, etc), depending on its type. And there is a scripting system in place, allowing game to respond to certain events (pulling a level, breaking a tripwire) in quite a programmable way. So personally, I wouldn't like to approach this without a proper editor.

 

But you have a point here. I'll look into some options - I have a framework ready, which compiles even to web, but it uses OpenGL, so I'd have to estimate the effort required.

[TheHoboInYourRoom]

I love the progress that's been made on this game.

As I was playing World X yesterday, I noticed the screen rolled a couple times as the game transitioned between levels. Not a lockup, just a time overrun.

[KK/Altair]

I love the progress that's been made on this game.

As I was playing World X yesterday, I noticed the screen rolled a couple times as the game transitioned between levels. Not a lockup, just a time overrun.

 

Thanks for the info - I'll try to reproduce it. There's not much overscan time in NTSC, but I do my best not to roll (especially during gameplay, where it's a priority). But during transitions avoiding rolling is usually as simple as adding one blank frame devoted to processing. Thanks!