Identical Games

Name:	Fracturoid
Version:	0.0
Author:	noway and Dennis Payne
License:	MIT
Operating System:	Linux, Windows, and Mac

Fracturoid

Breakout/Arkanoid games are not a genre I particularly like. I was asked about putting one on an arcade machine. There are numerous clones of those games. A great resource for open source clones is osgameclones.com. The Arkanoid clones included a javascript version and a python game designed with a circular playing field. Breakout clones include LBreakoutHD which is more of an Arkanoid clone but I didn't look at those clones.

This repository by Chevifier had a resonable base using the Godot engine. The graphics didn't appeal to me and I initially thought it didn't have power ups. The game is using a tiny screen size which might make improving the graphics difficult. It's hard to know if anything is hardcoded to depend on that screen size.

After a little more searching I found noway's Arkanoid tutorial for the Love engine. Using this as a base seemed ideal. It had multiple powerups. If I had any questions about the design I could look at the tutorial. That's not to say everything was perfect. The game used the mouse for movement which wouldn't work for an arcade machine especially if you want two players simultaneous. It didn't have the weapon powerup which I consider kind of iconic about Arkanoid. Since the arcade machine has multiple buttons, it would be best to have some use for them.

Controls

As usual the game was written with an old version of love so some changes were needed to get it running again. Next I created a controller to handle keyboard input and modified the game to use this instead of the mouse controls. This worked although I left the main menu and other screens as needing the mouse.

Along with this, I switched the game resolution to a 16:9 ratio. Granted this just added black boarders. Fullscreen became the default mode.

Two Players

For two player support, I pulled in a class library by Matthias Richter. Interestingly there was already some code by Matthias Richter. The vector implementation was written by him. With the class library to simplify implementations, I converted the platform and controller to classes. The code organization made it easy to implement these changes. As something designed as a tutorial, easy to read code was a priority.

The two players had the same graphics initially. Adding a new graphic for the second player was the first oddity I found. The game had two sets of graphics files, a set of svg and png. The svg were the original graphics and were exported to png for use in the game. This should have made it very easy to add a second player image. Copy the player images, change the colors and export.

When I tried to export the new player images, I discovered that the existing player image is not the size of the image shown in the game. The code used love.graphics.newQuad with four parameters for the quad as you would expect and two parameters for width and height of the texture. You could instead pass just the texture as the fifth parameter so it can get the width and height from it. In this case, the width and height parameters were not the size of the texture. Why would you do this?

The vector image was exported to a raster image bigger than needed. The game engine loaded the raster image and resized it. Maybe this could make a crisper image but it makes it very hard to modify the images. After trying to find the right setting to continue with the current design, I gave up and exported the image at the size used in the game. Unfortunately many of the images in the game used this setup so I encoutered it with later changes as well.

Weapon Powerup

To add the weapon powerup, I needed new graphics for a powerup, the player, and the blasts. All the powers are circles with a letter and a color. I chose F for the letter. For the blast I created something simple in inkscape with red and yellow gradient. If I created a new image for the player I would need to create two new images for each player as they have normal and sticky mode. Or I could have made it that getting sticky or weapon powerup removes the other powerup. I decided to make a grey star that would be drawn over the current image when the weapon powerup is active.

For implementation, I created a new fire.lua file to contain the logic. As the image was added to the ball.png, I ended up loading that file twice. Eventually that should be corrected. The blast simply go straight until they collide with a block or the top of the screen. Currently it uses the same logic as a ball collision which means no separate sound effect or different chance of powerups.

Expansions

At this point I started thinking about the experience on an arcade. I implemented support for 1 player and 2 player buttons instead of relying on a mouse to select a menu item. I moved the platform down when someone mentioned it seemed very high up. It makes the game easier and may require increasing the speed of the ball.

The playfield enlarged so the black borders on a 16:9 display would be relatively minor. This requires new levels to be built or expanding the current levels. Only two have been updated with the new screen size. I looked at Arkanoid levels and found their design very different than expected. Akanoid relies on a lot on unbreakable blocks to force you hit the ball into specific areas. It doesn't mean levels of Fracturoid need to follow that design but it is something to consider.

For next steps, replacing the start screen is top priority. Obviously more levels are needed. A high score list for single and two players would be a good addition. Arkanoid had a cut scene with a story before and at the end of the game. Something similar could be added to Fracturoid. Moving enemies or blocks are a possibility. Perhaps allow the player to move up to the original height and earn more points for the additional challenge.