Bingleball is an open-source multiplatform game designed and developed by Ethan Jucovy.

The code is written in C++ using SDL.

The game that I would like to develop this summer could be described as a cross between chess and billiards. It would involve two players (one of which could be computer-controlled) each with a team of four different kinds of pieces: around five each of triangles, blocks, and balls; and a single flower (sample graphics can be found here).

Players would take turns shooting their pieces across the court at varying speeds and angles, as in billiards, to hit enemy pieces. Each piece has its own weight which affects its speed when shot; and each piece has particular strengths and weaknesses, which, when combined with a few special rules, determine the result of a collision between two pieces.

For example, when a triangle hits a block, the block breaks and turns into a triangle; when a triangle hits a ball, the ball pops and is destroyed; when two balls collide they both bounce off and continue moving; and so on. I've drawn up full chart of piece interactions, which can be found here.

From these simplistic rules emerges a complex system of interaction between pieces: a block could knock into a triangle which then collides with a ball and destroys it, while the block continues moving and hits into another block and breaks it, or ... etc.

The flower is a special piece which must be protected. Like your king in chess, if you lose your flower piece you lose the round. The flower has five petals; when it loses all its petals through collisions with other pieces and the flower's center is then hit by another piece, the flower is destroyed. Alternatively, players can compete for points, which would be gained in different amounts depending on your accuracy and complexity in shooting your pieces. (These objectives can be selected as different game modes, eg, "Strategy" vs "Style" modes.)

So, players have to consider where their pieces will land and how well-protected their flower will be at the end of their turn, while at the same time bouncing their pieces off of walls and around corners to hit their opponent's pieces.

There are a few additional features of the board to increase the difficulty: "gravity" and "antigravity" centers which respectively attract and repel pieces in motion; spiked objects, which will pop a ball if it bounces into them; soft objects, which a triangle can get stuck in; and hard objects, which will shatter a block. These objects can be destroyed only by a collision with a flower and are only present on some gameboards, so the players can choose whether or not to play with these additional features.

With a good physics system (modelling weight, friction, linear and angular momentum, transfer of energy, and elasticity) I think this game will be quite unique and more importantly very fun to play. It will be simplistic enough to learn the rules quickly and effortlessly, but still more than complex enough to provide for unique and exciting matches with each game played.

Additional variety will be provided by the various game modes available. Specifically, players will select three things before entering a game:

• Players (human vs AI; human vs human)
• Game mode (Strategy; Style)
• Game board (choosing among a number of boards of varying size and complexity and each containing varying numbers of special objects, gravity centers, and antigravity centers as described above)

I have made a (fake) sample screenshot of the board layout which can be seen here and also an animated GIF showing a possible sequence of a turn which can be viewed here. This sample board contains four of the "gravity" centers mentioned above (depicted here as swirling grey circles). In this sample animation, the blue player shoots a ball toward one of the red player's ball pieces, which in turn begins to move, pulled toward the gravity center; the red ball knocks into the flower, which is then pulled into the gravity center and destroyed, winning the game for the blue team. Of course this is just an example without any of the physics modelling described above, but it gives a sense of the possible complexity and strategy involved from a relatively simple layout. When I have finished writing the code I will do some playtesting to determine the specific parameters of the game: physical constants, number of pieces to start, board size and layout, etc.

As mentioned above, I will program this game in C++ using SDL. I expect to be able to complete the bulk of the code, as well as the relevant graphics and sound, before the end of July, which would leave me with at least a week for playtesting, adding and modifying board layouts, and tweaking various settings and rules to improve the gameplay.