Way back in 1998 or so, I played a game on the original Play Station. It was a rather traditional puzzle game à la Tetris, Columns, Super Puzzle Fighter 2X, etc. You drop colored pieces into a grid, where you need to line up matching colors to remove them. You play against an opponent, and pieces are added to your grid when the opponent scores, and vice versa. Wholesome fun for the whole family.
I just love puzzle games like this. The simplicity of the game rules, and the deep gameplay that emerges is really special.
I halfway wrote a clone in VB6, but I wasn't a very good programmer back then, and I never managed to implement multiplayer gaming properly. I started over again a few years later in C++, but nothing came of it. I blame over thinking it and the stupid linker.
I had a quick look at a few js game engines, most notably Cocos 2D. They didn't really seem like they would offer me much, since I don't do any physics, or a have a tile based world map. And the documentation just sucks.
Instead I decided to do it with plain Canvas.
I have made a few notable design decisions. The animations never stall the player input. Instead, they are treated only as effects. The player should be able to continue dropping pieces and have the game progress like if the animations didn't exist.
This makes it easier to add client/server multiplayer later on, since I have to run the game logic on booth the client (for responsiveness) and on the server (to prevent cheating). Only player input needs to be sent, and the game will progress identically on booth ends. Whenever there is a timing issue (like if the client think it dropped a piece first, but the server thinks the opponent scored before that, making you lose), the server will just send the correct board and the client will have to accept its ruling.
To achieve this decoupling, I use an animation queue, where you can just add animations with a interpolation, duration and optional delay. The animation of each piece is set to play something in the future, so the visual are nicely choreographed, while the logic happens instantly.
The next few issues on the map:
- Animation timing is tedious and tricky to get it all just right. Possibly switch to some other method.
- Pieces in the column above an exploding piece should fall immediately, not after the whole chain is gone.
- Try how it feels if the droppedd pieces can never land on top of each-other, but will disappear immediately when they land, making room for the piece above. That makes it possible to make the pieces shatter immediately when a chain is made, instead of waiting for everything to settle.
- The visual queue of pieces feeding the dropper feels weird when the dropper is vertical. The pieces und up upside-down compared to how they sat in the queue. Feed the queue from above, move the pieces straight to the side, or flip them in the opposite direction at the end.
- Add characters to choose from when starting the game.
- Golden idols!
- One pic for menu/gameplay + one broken for losers. When losing, shake the sprite .5 seconds, then switch sprite and play break sound effect.
- Small, simple animations by switching/moving body part sprites.
- Blinking eyes.
- Bobbing head to the beat of the music.
- Add a start and game over/winner screen.
- Make punishments (extra pieces added from below) depend on the score.
- Add a time limit to the piece-dropping. 5 seconds initially, and shrinking by a second per minute? After that, the piece will drop automatically whereever the dropper is at the moment.
- Add input for touch.
- Add a menu system. To begin with, just "Start". Then "Select Game Mode" and "Select Character" as they get implemented. DOM-based?
- Add alternative game styles; Single player (for points) with and without piece-dropping time limit. Implement as multiple "Game" objects that takes care of the gameplay mechanics and layout differences?
- Switch makePiecesFall to use breadth-first.
- Add sound effects.
- Add music with varying stress levels depending on how close you are to losing.
- Sync all visuals and sound effects to the music. Lock the most significant effects to whole beats, and smaller effects to 1/2, 1/4, 1/8, 1/16 of a beat and so on. (The game Rez did this, and it was awesome.) With the existing animation queue system, it should be relatively easy to implement.
I plan to build a websocket based server for multiplayer. MMO Puzzler anyone? Some notes about it:
Just send all input to the server, and broadcast to all players. The input don't affect the local board until they are echoed back. That way we can't get inconsitencies. Nice! If lag becomes a problem, do speculative anmations in parallell with an actual board and overwrite if they diverge.