Student Project
2017
This was a prototype project made for a class over 3 weeks. This game benefits from an arcade game vibe and a desire to make a fighting game for two players who are physically next to one another.
 BrickBash01 |  BrickBash02 |  BrickBash03 |
|---|---|---|
 BrickBash04 |
OBJECTIVE
Brick Bash was a small rapid prototype that inspired by a professor of mine. This professor would often speak of game design in simplistic abstract terms substituting concepts such as 'strength' with 'bricks'. This often led to my imagination interpreting it literally as we used this metaphor more and more. Trying to come up with an idea to pair with a fighting game I decided to make a Divekick clone where players use bricks instead of kicks.
INSIGHT
Since our class projects are almost always solo projects, I bit off more than I could chew with this one. All of the art in game is mine and was made from scratch. While the sound effects and IP are controversial from a copyright perspective, as a student I had no choice but to tweak some open source sounds I had available to me. The art took more time to complete than anything else. While I enjoyed it because I could customize every part of it, I also lost a lot of sleep trying to hit deadlines. I was infatuated with this project and it made me forget I was 'working' on it. I was also working in our schools custom engine (Zero Engine) which I was very comfortable in after using it for a year and a half. Zilchscript is a very strong language even for a scripter with no experience and it made testing myself that much easier. Using knowledge of action systems, event systems, input, and UI management I put up a less polished prototype of what I wanted within a few weeks. After 2 months, the game was done, all that was left was making it look and feel like a real game, rather than a prototype.
DESIGN
I often prefer a Top-Down approach to design, but with this game I had enough experience making the systems I needed that I was confident in going with a Bottom-Up architecture instead. As the dialogue above states, I felt that I had so much insight as to how I should go about making a game given my tools, but I never had enough time to really put them all to use. After so many projects that felt short-changed, I finally had a shot at creating a full-fledged experience. I started with a basic combat/platforming setup that allowed for infinite runner mechanics to begin to flourish. After getting my player animated and lined up with raycasting collision detection, I charged forward hacking away at rectangles nitpicking the combat until it felt fair to the the human eye.
Upon making some clunky AI for enemies to approach and shoot at the player, I began designing abilities for combat. I really didn't have to brainstorm much to figure out what I wanted; I'm a Star Wars nerd, I know what I want to see in a Star Wars fantasy. This led to the animating and tuning of special abilities. My structure for abilities made it super easy to plug-in and pull-out abilities as I tested them. With some handy cheat codes, I put together the core of the game which involved hacking, slashing, and spell-weaving to a rhythmic runner. Now that I had my mechanics in for the most part, I wanted to move onto the UI.
When I approach UI/UX, it can be difficult for me to see in my head an innovative and intuitive design that most triple-A titles flaunt at their leisure. However, I know what I expect out of an experience and I also know very well what players expect, even when they don't know what to expect themselves. While I won't proclaim to be a grand UI designer, my experience with UI and UX allows me to pick apart and slowly chip away at a template until I have an ideal UI that blends naturally with the theme and controls. For this game, I wanted simplistic menus, limited HUD elements, and appealing feedback. I threw some particles at my health bar, created an intense damage feedback mask that flashes when injured, and I put together some menus that are nothing special but are intuitive to use.
Then I came to the realization that I would need a dialogue system if I was going to write text to explain the story. While the story itself never got to be explored to its full potential, this was a great learning experience for designing dialogue based UI systems. I worked away at planning out how the text would type itself out, how it would wrap within the text box parameters, and how the event system would have to be tied in so that it knows when to start moving things around to create a cutscene. After all is said and done, I showed it off to my professor with my chest puffed out and my eyes sealed with confidence, only for him to trash the entire game because he couldn't skip any of the dialogue. There was no way I could rewrite the system to allow the player to skip through my action sequences before the turn in date, so I cheated as programmers often do. I used the engines time scale methods guess how long a given length of dialogue should take and had the game "speed up" long enough for the dialogue to type out, then return to normal. It is a hacky and extremely buggy flaw but it got the job done in time.I patched enough of the problems that the game would run smoothly consistently but definitely learned to account for this issue in the future.