Ello, I am the programmer and the producer behind Brickbreak, a new Breakout-style videogame. I'm the one in charge of approving and paring down the content to meet deadlines and capabilities, though I did do a fair bit of developing new ideas as well. Being the programmer of the team simplified the role as the game’s producer. Whether a feature was added, put on the back burner, or scrapped oftentimes came down to whether I could brew up a way to augment the existing system, or whether I would have to make significant revisions to already-existing code. To some extent, I think being the producer also made programming work more efficient, since I didn’t necessarily need to turn to someone else for final approval and revisions, and I also established and prioritized the timeline for project components.
The project began initially as just something everyone on the team (of two) would be familiar with conceptually: Breakout. I pulled a lot of inspiration from an old Breakout game I used to play on the iMac G3 in elementary school during recess. Simple, clean UI. Colorful and fun visuals. An intuitive interface that let players learn the game by observing the information being shown to them, not necessarily told to them. The game started out with placeholder visuals, and one by one, objects were added. Once the first level had the barebones objects, the Title screen was produced. Shortly after, most of the initial graphics were developed. From there, the main behind-the-scenes framework for the game was born out of necessity. I grew up learning The Games Factory, and Game Maker Studio 1.4 is significantly more powerful, but it is not without its flaws. The room editor's workflow is garbage. There is no drag-selection of objects, and no way to easily manipulate objects within the room. Game Maker Studio 1.4 is littered with counter-intuitive hotkeys as well. For a variety of reasons, I turned to rely on the coding portion of the engine. Because the game largely functioned on a grid, it was quite easy to define levels with text, then develop an algorithm that processed the text to construct the level on-the-fly. It was much easier to build and revise levels in a basic text editor, as opposed to precision-dragging hundreds of individual objects per level. Once the basic game became playable, the rest of development was focused on smoothing out glitchy behavior, improving player experience, and adding new content. Some easter eggs were added to the game, as well as a secret way to reveal some debug data in-game. The debug data easter egg existed as a way for me to integrate and hide debug information into the playable release, so I wouldn't need to regularly comment-out and uncomment mid-gameplay variable-checking solutions.
During playtesting, I did revisit and ask players about their thoughts on certain aspects of the game. The two most prominent questions were: How was the pacing of the game? A fast game is more difficult to control (difficulty can be fun, but not necessarily), but a slow game is less entertaining. Where does the player stand on the balance between letting the player explore and learn versus hand-holding and spoon-feeding information.
As it stands, just two weeks after the decision to begin the project, the game is almost entirely ready for release. Some code is expected to be refactored to patch rare unintended behavior of game objects. Additional powerups, hazards, and levels are planned to be added. Although the game is playable with a keyboard, I am aiming to include intuitive support for console-style game controllers and DIY arcade cabinets.
BakaChibi out.
The project began initially as just something everyone on the team (of two) would be familiar with conceptually: Breakout. I pulled a lot of inspiration from an old Breakout game I used to play on the iMac G3 in elementary school during recess. Simple, clean UI. Colorful and fun visuals. An intuitive interface that let players learn the game by observing the information being shown to them, not necessarily told to them. The game started out with placeholder visuals, and one by one, objects were added. Once the first level had the barebones objects, the Title screen was produced. Shortly after, most of the initial graphics were developed. From there, the main behind-the-scenes framework for the game was born out of necessity. I grew up learning The Games Factory, and Game Maker Studio 1.4 is significantly more powerful, but it is not without its flaws. The room editor's workflow is garbage. There is no drag-selection of objects, and no way to easily manipulate objects within the room. Game Maker Studio 1.4 is littered with counter-intuitive hotkeys as well. For a variety of reasons, I turned to rely on the coding portion of the engine. Because the game largely functioned on a grid, it was quite easy to define levels with text, then develop an algorithm that processed the text to construct the level on-the-fly. It was much easier to build and revise levels in a basic text editor, as opposed to precision-dragging hundreds of individual objects per level. Once the basic game became playable, the rest of development was focused on smoothing out glitchy behavior, improving player experience, and adding new content. Some easter eggs were added to the game, as well as a secret way to reveal some debug data in-game. The debug data easter egg existed as a way for me to integrate and hide debug information into the playable release, so I wouldn't need to regularly comment-out and uncomment mid-gameplay variable-checking solutions.
During playtesting, I did revisit and ask players about their thoughts on certain aspects of the game. The two most prominent questions were: How was the pacing of the game? A fast game is more difficult to control (difficulty can be fun, but not necessarily), but a slow game is less entertaining. Where does the player stand on the balance between letting the player explore and learn versus hand-holding and spoon-feeding information.
As it stands, just two weeks after the decision to begin the project, the game is almost entirely ready for release. Some code is expected to be refactored to patch rare unintended behavior of game objects. Additional powerups, hazards, and levels are planned to be added. Although the game is playable with a keyboard, I am aiming to include intuitive support for console-style game controllers and DIY arcade cabinets.
BakaChibi out.
No comments:
Post a Comment