Jump to content
IGNORED

Piñata (2600)


Cybearg

Recommended Posts

Thank you, and yes, but at present he is busy filling other orders. I need a label artist before I can make any more progress toward a cartridge release.

 

In the meanwhile, consider this thread a "release candidate testing phase," so if anyone notices anything that seems off, and especially any blatant bugs, please let me know so a cart release can be as polished as possible.

Ah thanks. I've been needing to update add some ROMs to my Harmony cart anyway! ;)

 

Since I mentioned I only tried out Fix It Felix so far, I noticed there is no way to see where the broken windows are without hovering over them. This will make higher levels extremely difficult. I was thinking you could add playfield pixels to denote which windows are broken so I don't have to hover over it and watch for the status bar to change colors. You already used them for pies so I think broken windows would work too.

post-33189-0-58169200-1382472999.png

Edited by stardust4ever
Link to comment
Share on other sites

Ah thanks. I've been needing to update add some ROMs to my Harmony cart anyway! ;)

 

Since I mentioned I only tried out Fix It Felix so far, I noticed there is no way to see where the broken windows are without hovering over them. This will make higher levels extremely difficult. I was thinking you could add playfield pixels to denote which windows are broken so I don't have to hover over it and watch for the status bar to change colors. You already used them for pies so I think broken windows would work too.

Yes, you would think so, and I dearly wish this was the case, but it leaves me with a difficult trade-off that I see no way around:

 

I'm not using the standard kernel. I'm using the multisprite kernel, which not only has a mirrored playfield (so I couldn't show a broken window on just one side without implying it's on the other side of the building as well), but there is also no way to write directly to the playfield (you can only load in pre-set playfields from the ROM, but they can't be modified after that).

 

Now, theoretically, the game could be remade in the standard kernel, but there are a few complications:

 

For one, the sprite for Ralph is actually two sprites wide, and that would be impossible, so he'd have to be lower-res and stretched out to fit the space, which probably wouldn't look as good.

 

Another issue is that there would be less variation in difficulty. Currently, there are ducks that fly back and forth on each row, adding some additional challenge. That is only possible because of the multisprite kernel's 6 sprite limit, while I would have only 2 sprites available at a time in the standard kernel, meaning those ducks would have to be cut. So it would then only be a game about dodging falling bricks, with not much more to increase the difficulty.

 

Finally, even if I was able to fill in the windows, they wouldn't be able to be filled in with any color besides the background or foreground colors, So if a window was fixed, it would be filled in, making it difficult to tell that there is a window there at all. I worried that this would make navigation difficult, because you couldn't tell where you would snap to when you moved your character.

 

So, to summarize, in order to make those windows fill in like that, I would need to simplify the gameplay, simplify the sprites, and possibly make the play area difficult to navigate. I felt that my alternative--using a little indicator--while not as elegant and possibly a bit confusing initially, was a reasonable sacrifice for all the benefits that come from using with the multisprite kernel.

 

For reference, the indicator in the lower-left displays the row you're currently standing on, with three blocks on either side of a gap (the gap being analogous to the gap between the two columns of windows on the playfield) to denote the status of the row's windows. If a window is broken, one of those blocks will be blank, showing you that the row isn't fully filled in. It's true, you can't see which windows are broken everywhere at a glance, but you can check the status of the rows fairly quickly by moving up or down.

 

There is probably a more elegant solution that could be coded with raw Assembly, if the game was re-made from scratch without using batariBasic, but I do not know how to do it. If there is a talented Assembly programmer who is willing to work with me, I'd be fine remaking the game for the compilation if they were able to build me a custom kernel that could do everything I need (namely, change the background's color mid-scanline before each window is rendered while displaying 6 sprites on-screen without flicker). In lieu of that, however, I think we'll have to stick with the window indicator.

Edited by Cybearg
Link to comment
Share on other sites

Have you thought about missiles or ball sprites for window cracks? Even if it's just a little dot or blip, it needs something there to visually check if the window is cracked without hovering over it. If you must use a symmetrical playfield, try the missiles/balls. I understand you can only have one per line, but it can be moved around between scanlines. Actually you could use up to three dots on a single line if you mixed the missles and balls. The dot could even be placed at different heights for windows on the same row. The placement of the "crack" would appear at a seeming random vertically, but at least the player would know the window needed repairing.

 

post-33189-0-28049000-1382679853.png

Link to comment
Share on other sites

Thank-you for sharing these great games. My new favorite game to play with my girl friend is Flip side.

That's fantastic to hear, thank you! Flipside's multiplayer was very uncertain for me because neither myself nor any of the testers were able to actually test it out in multiplayer mode, beyond me trying to get my parents to give it a shot with me (and they were just baffled by the Atari controller, haha). If you notice any problems or areas for improvement, please let me know!

 

Have you thought about missiles or ball sprites for window cracks? Even if it's just a little dot or blip, it needs something there to visually check if the window is cracked without hovering over it. If you must use a symmetrical playfield, try the missiles/balls. I understand you can only have one per line, but it can be moved around between scanlines. Actually you could use up to three dots on a single line if you mixed the missles and balls. The dot could even be placed at different heights for windows on the same row. The placement of the "crack" would appear at a seeming random vertically, but at least the player would know the window needed repairing.

 

attachicon.gif broken windows.png

That's a good idea, but it's entirely possible that all 9 windows could be broken, and there are only 2 missiles and 1 ball at my disposal. Also, they are being used for other things. The bricks that fall when Ralph beats the roof are the missiles, and that happens frequently enough that they would be falling (and thus, not indicating broken windows) almost as often as they were in place on the windows. As for the ball, that's used as the "pie," which randomly appears in a window to give you bonus points and an extra life.

 

Even if I had the missiles and ball at my disposal and they weren't occupied doing other things in the game, the fact that I can only show 3 at a time out of potentially 9 broken windows makes me worry that it would be more confusing than helpful on account of being inconsistent. I'm not sure how I would even be able to display the broken-ness of those windows with just the three objects. Furthermore, in the multisprite kernel, the ball and missiles are capped at 1 pixel tall, which works fine in the context that I use them, but that means that I couldn't create vertical "cracks" in the windows--either just a dot (which would look more like a power-up than a crack) or a horizontal line (which, personally, I wouldn't recognize as being a crack from seeing a short, fat horizontal line in a window).

 

As I said, there ~is a way to check if windows are broken without being in front of them. The indicator in the lower left shows you which windows are broken on the row you're standing on. It's far from perfect, but it at least allows one to get an idea of how many windows are broken and which column they are in.

Edited by Cybearg
Link to comment
Share on other sites

I'm not sure of the limitations of the multisprite kernel, but I know that all objects can be manipulated between scanlines, and in the case of playfield tiles, are often rewritten halfway across the screen to create asymmetrical playfields. Only the earliest games such as Combat and PONG did not attempt to rewrite everything between scanlines. And I think that's part of the problem with prefabricated kernels, they're great for beginners but they all have tradeoffs behind what is possible and what is not. This is all coming from someone with little programming experience.

Edited by stardust4ever
Link to comment
Share on other sites

I'm not sure of the limitations of the multisprite kernel, but I know that all objects can be manipulated between scanlines, and in the case of playfield tiles, are often rewritten halfway across the screen to create asymmetrical playfields. Only the earliest games such as Combat and PONG did not attempt to rewrite everything between scanlines. And I think that's part of the problem with prefabricated kernels, they're great for beginners but they all have tradeoffs behind what is possible and what is not. This is all coming from someone with little programming experience.

Well, it's true. As I said, it MAY be possible with a custom kernel, but it would not be easy. It would take an Assembly programmer who knew how to squeeze every drop out to make it happen, at least from my half-way understanding.

 

Unfortunately, I am not that programmer, so Fix-It Felix is going to have to be as is unless someone with the time and experience steps up as willing to create a custom kernel to handle all that extra stuff.

Link to comment
Share on other sites

I think that's part of the problem with prefabricated kernels, they're great for beginners but they all have tradeoffs behind what is possible and what is not. This is all coming from someone with little programming experience.

Even with assembly language you need to make trade-offs. Knowing how to code assembly kernels won't allow you to have all the features of the multisprite kernel and more - it just allows you a finer grain of detail of which features you don't implement (or just partially implement) to allow for other features.

 

One could also say that the problem with non-prefabricated kernels is they take a lot of experience to produce. If cybearg had to create a custom kernel for each of his games, he'd likely still be in the learning phase right now and we wouldn't have this very fine game collection! :thumbsup:

  • Like 1
Link to comment
Share on other sites

  • 5 weeks later...
  • 1 month later...

Thanks for the support, people! I can't promise a cart release, though. It realistically probably won't happen.

By the way, for those with an Android mobile device who wanted to play Heartbreak, I recently recreated it in Gamemaker as part of a mini-Ludum Dare. You can get the .apk here.

Edited by Cybearg
Link to comment
Share on other sites

^^Didn't Albert say a cart was a possibility? On issue I have playing on Harmony is because there's no true "reset" function on the Atari, I have to switch the console off and reload the ROM to swap games. An option to get back the main menu would be nice.

Hitting reset + select will return you to the main menu.
Link to comment
Share on other sites

  • 2 months later...

recently got back on the Internet ..although still borrowed so no guarantee how long I will be connected this time ...

 

snagged v1.05 & put on my Harmony mostly play Heartbreak & the colors look fantastic ... still using on my imperfect TV but got the highest score I had ever gotten 027,100 both difficulty switches were set to "b" or beginner so the ball didn't speed up til 14k or so

 

thanks to all that helped with this project some great original games here !!!!

Link to comment
Share on other sites

  • 1 month later...

Best news I've heard all day!!! :D :D :D Al, any hope we still get Star Castle Arcade and Byte Before Christmas too? You've been sitting on those games for far too long, IMO.

 

Yes, we have a new board design that I'll be using for those two games. :) Manual is nearly done for Star Castle Arcade (and it looks fantastic!), with a box design coming next.

 

..Al

  • Like 3
Link to comment
Share on other sites

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