Soko Banana

Soko Banana started as a puzzle game demo created for the Byte Off! competition made with NESmaker and a custom module we made for creating puzzle games. The game is thought to be kind of a evolution of the old Sokoban (Boxxle etc.) game idea, hence the title. =) It was such a fun project that we have continue to work hard on it and decided to try a Kickstarter to fund the creation of a physical version, because that would be a dream come through. However, we will be releasing a version of the game for the community too, the game wouldn't exist without it. Both the nesdev and nesmakers forums has been invaluable. Our plan is also to release the puzzle module for NESmaker that we are making for the game.

Link to a short demo of the project and the kickstarter can be found below.




Kickstarter: https://www.kickstarter.com/projects/flipforfate/soko-banana-an-8-bit-puzzle-game

I just played through the demo. I found the "physics" confusing with regard to to what can pass through what. For example, in the first level, if the left block is pushed south, it gets blocked without moving far enough for the vertical face to be obscured by the wall, but if pushed east it will not be obstructed by the bottom block even though its face is obstructed by that block.

Also, if the monkey and four boxes are in a line, one of the objects will simply disappear. The normal remedy for such issues would be to have non-moving blocks be rendered as tiles rather than sprites; I don't know if that would be easy with your engine. Alternatively, flicker would be better than just having objects cut out.

The game is cute, and I think it has potential, but it definitely needs work as well.

Nice!



Yeah, as far as i remember NESmaker doesn't rotate the starting offset for either buffer uploads or OAMDMA. the simpler approach of rotating the starting address of OAMDMA should work nicely for this game. It's just a few lines that need to change.



I recommend replacing all NESmaker assets (the font used in-game, and some symbols), so it has more of its own identity in that regard.

Love the squished bananas. Maybe they could do with a little squish(ier) sfx? The current effect is fine for signalling, so not a biggie.

Getting all three bananas is very easy in this first world, but maybe that changes later on? At first i thought the goal was to squish all bananas in addition to moving the boxes haha


The in-game song is relaxing and playful. I like it.
Just a personal preference, but i think it'd be more polished if the music didn't restart when pressing select.

Nesmaker games have some limitations. Modifying them would require extensive ASM knowledge and hardware knowledge that I suspect few of the users would be able to do, given that all those details are hidden by the GUI interface.

Especially the "rendering objects as both BG and sprites" might be not possible with the engine.

Almost all of the NESmaker codebase is easily visible. Some few sections of it are gui generated such as most of the enumeration and init values for some of them. Also things like key input handling and AI sequences. But i can see the practicality of it. I wouldn't blame the gui for hiding code. There's even a built-in editor with highlighting, which is useful for quick edits or if you don't care for installing a 3rd party editor.

Things that i think do get in the way of hand modifications are:
-code is modularized into too many, too small text files. Most users are windows users and windows search is not suited to this style of code organization. Text search is off by default (i'm assuming for performance reasons). Rather than rebuilding my search index and restarting, i use a 3rd party search tool to mitigate this problem. I didn't feel like i needed one until i started modifying the NESmaker codebase.

So, i ended up with maybe 40-60 tabs open at any time for one project. If you close some of them down you'll have to search for them again sooner or later. I wound up with organizing some of them in notepad++ and some in sublime for quicker/easier to remember browsing.

Things like tile and AI behaviour obviously need to be modular, but i'd go as far as to organize texts per bank elseplace if it was me. My first impression was the opposite; that the modularization made for easy browsing. But after half a year with it, i found it more bothersome than convenient.

-numerous unused text files with previous versions of this or that function laying around, or unused code within a file. Sometimes you find yourself modifying the wrong version. It's hard to keep track of what exact file is linked where and when. Some cleanup of unused code is in order.

-overuse (to my taste) of macros. hides away what is actually happening behind cryptic labels and argument passes are sometimes without comments. Some of the macros are too large to be useful as such. It sometimes hides bugs from plain view, or eats space where a subroutine would fare better.



yes.. there's no support for 8x16 sprite mode (a reasonable tradeoff), and it's tough fitting the extra tiles otherwise needed into the background chr table with the current direct metatile scheme. Furthermore, you can't conveniently disable individual metasprites (ie detatch collision position from sprite position) for an object. best you can do conveniently without mods is use a 1-tile, no-pixels sprite for an animation.



Anyway... i can't for sure tell if the engine has been modified or if it's all clever use of the preexisting pieces. Screen transitions look more stable than what the vanilla code allows. In any case, good work!



The answer is that you can walk behind sprite based objects, but not background based ones. NESmaker allows for walking behind background, but the handling is minimal. You're manipulating the sprite object as a whole, rather than individual component sprites, for one thing, meaning you need a fairly big area of non-solid pixel to not look glitchy. I made a quick and dirty replacement for the "behind tile" script for increasing the fidelity on the y-axis but it's only a solution to some particular situations. - it wouldn't solve the current southwest/east corners in this game.

I don't know what concepts the NESmaker scripts support easily, but one of the things that distinguishes good games of this style from mediocre ones is the effort spent handling the cases where one object is partially obscured by another, and moving objects to/from the background when needed to avoid having objects flicker or disappear.

If the bottom two thirds of a stationary box are within a metatile, they'll completely obscure it unless there's another box just below it. Thus, having "bottom two thirds of box" and a "parts of two boxes" metatiles would eliminate the need to use any sprites on stationary boxes except for the top third. Any time the top third of a stationary box is visible within a metatile, it will completely obscure the bottom half of that metatile, meaning that one could either draw the background as normal or use a background metatile for the crate and sprites for the portion of the background above it. Splitting those approaches would free up sprites.

Moving crates would be a little harder, but in the case where two horizontally-adjacent crates are being pushed downward behind walls, one could use higher-priority sprites with the shapes of the top halves of the walls to obscure the pushed sprites. If a sprite is being pushed horizontally behind a wall, one could use sprites for the left or right half of the wall in question.

These sorts of details are tricky to get right, but I would consider them necessary if one wants to use this style of isometric 3d.

Hmm... one thing you can exploit more easily in NESmaker is that each animation cycle carries its own tiles height/width definition . so you can for example create copies of all your animations that lack the two bottommost two tiles and hook these up to an object state, or an alternative animation that fills one of them with a blank tile. Then manipulate object state based on a special southward collision check. objects have an abundance of collision checks, which is normally trouble in an action game but could actually be useful here. iiirc you can check south, southwest, and southeast, and from that, you could probably extrapolate more in detail what animation type to show (ie what metasprite/s).

But in the case of the player character which has a lot of animations, i'd probably explore splitting it into two objects, displace one of them, and have the bottom/feet looking for collisions. the top object just tags along.

It can even be drawn in the "sprite pre-draw" phase and not be an object at all (in the NESmaker sense), and save cycles & ram, but at the expense of having to write something of a handler for it.

I would agree to some extent. Tinkering with what can be done would probably be helpful to the overall reception of the game once it comes out in its final form which in turn can help building a name for a second title, but also feel as though the quality of a sokoban game lies more in the puzzle challenge designs themselves? After a while, i simply accepted the discrepancy between visuals and physics. As long as i know the rules, it works for me.

What a great read, thanks for the input. =)

Yes, we will implement some kind of flickering routine, for more than 8 sprites in a row, is the simple answer. We are working on multiple improvements for the engine considering things like this. It's a little bit tricky because the crate sprites are 1 and a 1/2 meta tile in height.

Hiding the boxes behind partially behind the front walls would be tricky, and we think even more confusing to the player. We have gone with the "classic" nes rpg look, where this incorrect physic was kind of the way it was handled.

Personally I use Visual Studio Code when coding the ASM to be able to search all files and get kind of a better environment than NESMakers code editor. I really advice this (or any other good IDE) for anyone doing a lot of modification or you go crazy. =)

Thanks again for the great responses. We are working hard to solve some of this issues and I look forward to discuss different approaches.

I like the game and think that the graphics and animation is great as well as the music. The only con I would say is that the perspective was sometimes hard to understand, which is important in puzzle games, but the graphics do look nice. If you did an overhead style then the puzzles would be more clear but the visual presentation may not be as nice....... idk.

Anyway, I played the demo and posted a video of it on nesmaker facebook page. I don't know if you saw this but I was able to "step out of bounds" in this one level and you might want to fix/be aware of this.



youtube video link

https://www.youtube.com/watch?v=VFC-5voxEro&t=4268s

Congrats on the kickstarter!

That seems to be an older build of the game. Note that the HUD is not as developed as the one attached here, and the grass and obstacles are different.