This is a two person game and controls are as follows:
for Player 1 Use 'W, S' to move, 'A' and 'D' to turn, and 'Z' to shoot!
for Player 2 Use 'O, L' to move, 'K' and ';' to turn, and 'M' to shoot!
once game ends, use space bar to restart.
Kyle Richards:
Our game loveBlaster is a 1v1, cover-based 2d shooter in which players attempt to frag one another in order to reach the kill counter limit before their opponent. Throughout its development, we decided to create a game that would expand on the classic Atari game Combat, where 2 tanks face off against one another in an arena. However, in order to flesh out more fast paced movement, we decided to change the characters into human soldiers, as tanks are not known for their nimbleness on the battlefield. Later, we added a moving environment in the form of vehicle based cover so that players would be discouraged from camping in certain areas, and to further differentiate the game from Combat.
At the conceptual stages of the game, before we even completed the interface, we desired to make a modern take on an Atari 2600 game, with added features. When we looked at the lists of options I researched and put on the table, many gameplay styles were considered, such as Platformers, SHMUPS, and even potential sports games. However, what captivated our minds was the infantile player vs player shooting games. After years and years of iterations, we finally have very good, competitive and skill based first person shooters in the modern day. But back in the 1980s, in the era of the arcades and the 2600, few games had shooting mechanics that did not revolve around a single player defeating waves of AI opponents through a series of stages. Our breakthrough came when we remembered the game of Combat our teacher displayed during a lecture on the 2nd day of class, and thought that it would be a great way to stand out from our peers. Most of our fellow students focused on platforming or SHMUPS, but a 2 player “combat” game (pun intended) could allow us to try new mechanics and styles without sacrificing precious development time on creating enemy behavior patterns. Instead, we could focus on controls and the environment the players faced off in, which we promptly did. Most of our development cycle and technique came from the lessons taught in class each week, which we applied every Tuesday during our meet up.
When looking back into the class concepts of mechanics and playtesting, we frequently relied on the data gathered from student testers and our own team to modify aspects that needed work. The aspect that we had to revise the most was the controls. Early on, the controls were very wonky: you couldn’t move and shoot at the same time, turning and shooting often resulted in your death, and so on. Thanks to player data, however, we changed the movement system and the projectile system to both prevent frustrating self-deaths, and brought more solid, acceleration based movement into the fray. Additionally, while we originally had more movement options such as both strafing and turning, our play testers got confused with the odd control scheme, so we scrapped it in favor of a 1 button fire, 3 directional movement system, which harkened back to the days of the Atari 2600.
In order to refine the rough edges of our initial ideas, our duo split into two categories. I became the sprite artist for the environment and a general QA tester which flagged important issues during gameplay, while my partner Uuribe was the one who helped structure the initial player design and movements. He decided to change the players from tanks into humans not only to cut down on animation issues, but also to make the movement mechanics we had planned seem less unrealistic. I helped refine the initial movement issues by referring to external help and modifying the alpha versions he sent me to work at my desk in my dorm. The same tactic worked when trying to finalize the moving environment within the game, which at the time suffered from various issues with collision. By sectionalizing our work this way, we managed to complete the game alongside our busy schedules while ensuring that any experimental tactics would get a complete pass-through by the time of our next play testing session.
The final, fully implemented gameplay of loveBlaster is still frag based. But gimmicks have been added to make the gameplay more unique. The environment, for instance, is constantly moving. The planes and tanks that serve as cover never stay in one place for too long, forcing players to constantly move from cover to cover in order to have good positioning against their enemy. This helps shake up the gameplay in comparison to Combat, where cover and obstacles are static, which leads to both spawn camping and predictable tactics as players gradually get more skilled. However, because the environment is completely unpredictable in loveBlaster, players cannot develop a foolproof tactic or a secure position to spam or spawn camp. Bullets CAN collide, and as such can be blocked by shooting, which entices players to try to attack their opponent from behind to catch them off guard, and thus, score a point. These innovations help differentiate the game from its source inspiration of Combat, but manage to keep almost all of its simplicity.
Ulysses Uribe:
Our initial thought process was to create a 1 v 1 shooter game that would operate similar to the game, Atari tanks. In the original game, two character tanks would roam around a map, that had walls randomly placed around, that the tanks could then use for cover as they attempted to shoot each other for points. Of course, we didn’t just want to remake the same game but there were aspects and concepts about the game play that we wanted to model our game after, such as the battle field like theme and the kind of pop out of cover shooting style that makes it fun. Furthermore, we decided to take the original idea and instead of using tanks, we made two characters that could roam around the map and target each other. Next, wanted to make the battle field more dynamic, and in order to do that we put up barriers in the arena that players could use for cover, like the original game, but with the added twist that the barriers would randomly disappear and respawn in different areas of the arena, at random intervals. Since we wanted to keep this as a sort of battle field theme, we created three different types of barriers for the players to use a cover which are themed as follows; in the shape of a tank, that is in the shape of a horizontal cover, a fighter jet, in the shape of diagonal cover, and a plane in the shape of vertical cover. We decided to make them this way in order to further randomize the type of cover that might a appear next to a player so that they can try to take cover or attack. When it came time to incorporate the theme, we decided to use Soulmate, while this felt difficult to do with a battle field theme, I felt like the incorporation went rather well. First, the controls for the players are designed in a way so that both players can sit down next to each other and operate them on a single keyboard. Second, after some testing, we found it best to simplify the control use so that both players can operate their characters with one hand. Third, since it is more a couples friendly game, we designed the bullets so that they look like a heart, and will either spawn a solid heart if it collides with a player or it will spawn an exploding heart if it hits another object.
Using some of the concepts in the MDA pdf and the Elements to Game Design, I started with looking for game mechanics that I found satisfactory for the style of game I wanted to implement, which were 2 characters that could move around an arena, barriers that can be used for cover, and characters could shoot projectiles at each other. Next, was the gameplay, which by using simple game mechanics meant making the characters roam around the barriers and attempt to shoot each other while also attempting to use the barriers as cover, to make the gameplay more intricate, I made the barriers move around at random intervals. Lastly, the I have play tested the game with people in order to get feedback on the functionality as I continued to modify the dynamics and aesthetics of the game.
Comparing this game to Atari Tanks, which was the inspiration of the game, this one has a more suspenseful nature to it since the barriers a player would use for cover aren’t fixed but dynamic. Moreover, the barriers will suddenly disappear and reappear at some random location and to add more unpredictability the barriers are set to respawn at random times. That means that a player could be running to a barrier for cover and all of a sudden, the barriers might reappear elsewhere leaving them fully exposed. A countdown timer is also added in order to bring up the tension as the clock runs down the players might feel the need to hide more, if they are in the lead, or to take more risk if they are at risk of losing.
The initial game was very rough around the edges and as time went on and the game was play tested, lots of bugs were squashed and I was able to find simpler ways of designing the gameplay so that the players can spend less time trying to figure out the gameplay and more time enjoying it. The game originally utilized 6 different controls on order to operate a player plus another one to fire, that’s 7 total, it was over the top to say the least, but after several playtest it went down to 5 the loss of two unnecessary controls but also a more refined control that can be operated with one hand.
