Permission (formerly Ion Rush and Ion Deluge) is a game about…permission. With very few differences from its beta, Permission is still a game about waiting for the opportune moment. The most significant and recognizable change to occur in this version is the code structure. Now entirely legible, customizable and malleable, beams can easily be placed in any location with any rate of change. They can even move on their own! I feel that porting this to the tablet worked wonders, as the simple back and forth movement of the player is made for touch controls. The only real vulnerability of this update is the lack of changing background colors. Nonetheless, Permission remains a product I’d happily defend and continue to develop in the the future.
Updraft, formerly known as Rightfully Yours, is still a game of patience, cunning, and perseverance, only now it’s a lot more aesthetically sound and even more difficult. With the addition of five fans that alternate in two directions at entirely random intervals, the player finds themselves being launched upward or drawn back down. As it is even more difficult to maneuver the enemy’s projectiles at a close proximity, I tried to make the beneficial fans a vibrant color that would stand out against the harmful ones. This lets the player make decisions out of the corner of their eye, since most of the action takes place at the center of the screen. My code is a lot cleaner than its initial state, yet there are definitely changes and clarifications to be made. My conference project is a lot more consistent and logical, while Updraft has no real continuous code style. That said, it functions flawlessly with no known bugs. The controls are much tighter and more responsive in this version. The color palette of this game is derived from a Paul Klee painting. A trophy is indeed again bestowed upon the player on completion. In retrospect, I am highly content with this project and am not afraid to present it to others. I really feel like I’ve developed a game!
Spare Me is a conventional platformer with a bright palette and a whole lot of bowling balls. Make your way to the tiny star to advance to the next level, but proceed with caution. If you get smacked, it’s back to the start of the level. Trying to get the most variety out of my enemies, these bowling balls can fall at left or right angles, vertically, or directly left or right. Each bowling ball is assigned a random color at startup, so no two playthroughs will look identical. What cannot be shown in these screenshots is the wild activity and motion paths of these bowling balls. At a glance, the screens are terrifyingly chaotic. Yet with a little attention and patience, exploitable gaps in their trajectories become more and more apparent. This was an extremely fun project to code because the platformer lab offers a clean and manipulable archetype that is easy to build upon. I used a total of 8 arraylists to get the job done – one for platforms and one for enemies per level. Far and away my largest difficulty with this project stemmed from the player’s jump physics. Through a bit of crafty (and a little muddled) circumvention, I found a good solution with very few exploits. I’ve been told that the translate() function works well for jump animations, but I couldn’t get it to work. Hopefully in the future I will find a more reliable solution. And of course, if you can manage to make it through to the end, you’ll find recompense in a greasy bowling alley burger.
The enemy showcases three distinct states – dodging, advancing, and recharging. When it is not doing one of these three, its “idle” state is steadily moving back and forth and firing shots at a rhythmic pace. The enemy’s total health in conjunction with its quantitative distance from the player act to determine the frequency of when its states are called. For example, if the enemy’s health is low, it will attempt to recharge and strafe more frequently, but its distance from the player has the final say in whether the state is even executable. With both variables interacting with one another, the state probabilities are in constant flux, simulating spontaneous behavior. I’m still unsure of what my exact formula will be to determine frequency, but I’m pointing in the direction of either a modulo timer with a changing limit or a randomizer with a changing scale (or a combination of the two).
Rightfully Yours requires a bit of focus and practice in order to trump your enemy. An ominous shape fires missiles from above while you return with a steady fire of your own. If the player succeeds at striking the enemy with a bullet, the enemy loses some opacity. If the player makes three successful hits, the enemy changes form. With each form change, the enemy gains speed and increases its rate of fire. The player is given three lives. Starting in green, a hit from the enemy turns the player yellow. Another hit – red. If the player is struck by three shots, it’s game over. The game mechanic is therefore quickly recognizable as a one-on-one match to the death. Standing still is obviously not an option. The player is forced to duck and weave between the falling shots, learning which tactics make the greatest difference along the way. It’s no easy feat to land 9 shots total on a target that gets harder and harder to hit. Simultaneously, the stage becomes more and more dangerous to freely traverse. Suspense builds the longer you play. The design of the enemy is loosely influenced by the mechanics of bullet hell games (flooding the screen with obstacles, drastically constricting the players movement). The enemy’s class is built as a single object whose methods are triggered by the actions of the player. While there is no contested object that the player and enemy fight over, there is a sense that both are fighting to overcome one another, and hopefully make it to the rewarding finish… I have loads of room for improvement and advancement. My strongest urge is to vary the enemy’s bullet pattern and design more demanding dodge tactics. I also wish to implement upgrades to throw a bit of chaos into the mix. I feel confident in the structure of my game and my use of ArrayLists and collision.
IonRush (click for .zip) Ion Rush is a game of patience and timing. It forces the player to pay attention to the enemies’ patterns in order to proceed. Each “laser beam” flickers (at a constant rate) between two colors – green indicates a safe passage and red a sudden death. I programmed the beams to be re-positionable, which gifts them the ability to section off the terrain and force the player into smaller and smaller “beamless” territories. The significance of the beam colors becomes immediately apparent once contact is made. On a collision with a red beam, the player is sent back to the start. This form of failure instructs the player to pay attention to the flashing colors and gives them the choice to either hastily rush into the beams or take their time. This game has been constantly rewritten and is currently built for even more revisions and features. The major jumps so far have been: – Code structure to support beam width and location- Multiple beams – Backgrounds that change color with player movement – Clean(er) gui that indicates level completion I’m looking to implement the following points: – Revise code structure to accommodate for different color patterns/speeds/durations – Have the beams move around – Less rigid player movement (especially on a touch screen) I have many ideas for this project and hope to continue working on its evolution! – Dean Russo