Banana GameDevelopment journal
Designing fruit that can roll, stack, and still feel like fruit
Banana Game began with a familiar fruit-merging board, but the banana immediately created a different problem: its concave shape needed to matter without making the whole pile unstable.
By Mainu Studio · Published August 18, 2026 · Updated
Why one circle was not enough
Round collision shapes are attractive in a stacking game because they roll predictably and are cheap to simulate. They also make every fruit feel similar. A circle around the banana would leave a large invisible area inside its curve, so other fruit would appear to float. A smaller circle would let fruit pass through the tips. Neither result matched the picture players were reading.
The banana therefore uses a collision profile that follows the bent body closely enough to create a real concave pocket. The same principle applies to grapes and other irregular silhouettes: the collision should explain the visible contact, but it should not trace every pixel. Excessively detailed outlines introduce tiny edges that can catch another body and create vibration.
This balance is visible during play. A blueberry can settle inside a banana's curve, while a larger fruit may roll over the outer edge. That interaction is part of the game's identity, so replacing it with a hidden circle would solve a technical problem by removing a gameplay decision.
The crowded-board problems that changed the prototype
Early versions exposed several failure modes that are easy to miss on an empty board. Fruit could look stable with three pieces and then begin trembling when a larger stack transferred pressure through the same contacts. A newly created merge result could overlap a neighbor before the physics solver had room to separate it. Small fruit could become trapped inside a large concave profile. On slower devices, the same pile could behave differently because more motion happened between rendered frames.
The important lesson was that these were not four unrelated visual bugs. They all came from how contact geometry, merge timing, and crowded-space recovery interacted. Fixing only friction could stop one slide while making stacked fruit feel glued down. Increasing bounce could free an overlap while making the whole board explode outward. The work became a set of limits rather than one magic physics value.
Readable collision geometry
Profiles use smooth, intentional segments. Tiny pixel-level dents are avoided when they do not change the visible silhouette, because each extra corner can become a snag point under load.
Controlled merge replacement
The source fruit are retired as one transaction before the result becomes active. The new body is placed with nearby space in mind so it pushes outward instead of silently swallowing a neighbor.
Moderate friction and damping
Fruit should roll off an unstable peak, but a settled pile should eventually sleep. The target is a small corrective movement, not endless ice-like sliding or rigid stacking.
Bounded speed
Fast drops and merge separation need limits. Preventing extreme linear and angular speed reduces tunneling and keeps a single contact from injecting visible energy into the full pile.
Automatic merging changed the timing rules
The prototype originally asked the player to identify touching groups manually. The current game merges matching fruit as soon as valid contact is established, closer to the immediate feedback expected from this genre. That made the merge lifecycle more demanding: contact may be reported more than once, several possible groups can form during the same motion, and a fruit that has already been consumed must never remain as an invisible collider.
The merge system therefore treats a consumed fruit as unavailable immediately, not after a later animation finishes. Score, token reward, sound, visual replacement, and physics cleanup all refer to the same merge event. This prevents the ghost-fruit problem where artwork disappears but an old collision body remains suspended in the pile.
Special connected groups add another layer. Six strawberries or four apples should become one banana only when the whole group is connected. Counting every matching fruit anywhere on the board would reward unrelated clusters and produce results the player could not predict from visible contact.
The rule check gives a complete special recipe priority over a pair. If the group is too small, it falls back to the normal pair rule immediately. This has an important player-facing consequence: a guide must not suggest slowly collecting six touching strawberries, because the first pair would already merge. We now explain that timing explicitly in the recipe guide.
One portrait board, several rendering environments
The game is authored around a 720 by 1280 portrait reference. Web browsers, Android phones, and Windows displays all present different available rectangles, safe areas, scaling filters, and input methods. Letting each platform invent its own layout created bugs where a button looked correct on the web but moved or stretched on a phone.
The current approach keeps one reference composition and scales it uniformly. Extra space belongs outside the playfield; it does not stretch the board. Touch targets may be larger than the visible pixel-art button, but their centers stay tied to the same reference coordinates. Text and preview fruit use the same scale contract so they do not drift independently when the window changes.
Pixel art adds another constraint. Nearest filtering keeps edges crisp at integer scales, but most phone sizes are not exact multiples of 720 by 1280. The goal is therefore consistency first: the same relative size and position on every platform, with filtering chosen per asset type instead of changing the logical layout.
Performance is part of the physics design
A late board contains many contacts, but not every fruit needs continuous expensive work. Settled fruit can sleep until another body wakes them. Decorative animations and menu text should not rebuild every frame. Ranking rows and language previews are reused rather than recreated while scrolling. These decisions leave more of the frame budget for the pile that directly affects play.
Testing focuses on the failure cases that players actually notice: repeatedly fast-dropping small fruit, merging beside two large neighbors, stacking weight over a curved banana, pausing during motion, resizing the web window, and returning from menus without losing input animation. A board that behaves well only in an empty editor scene is not considered stable.
What remains intentionally imperfect
Fruit will not always land in the exact place a player predicts. A little roll, rotation, and transfer of motion is the point of the game. The design target is understandable surprise: the player should be able to look at a result and see which surfaces caused it, even when the outcome was inconvenient.
The curved banana will continue to be less predictable than a circle. That difference is kept deliberately, while tunneling, persistent vibration, invisible collision, and platform-dependent layout are treated as defects.