Devlog 1: Devlopment and Playtesting

Game Development Process 

Overall, the development of this game was a learning experience. It definitely took many long nights and lots of communication between our team, however the 3 of us prevailed through the creation of Ninja vs Robots. We used a trello board to organize our tasks and communicated on discord when working to push our work on GitHub. The development began with a simple conversation- what is our theme? Our inspiration for this game stemmed from movies like Blade Runner, Tron, and games like Cyberpunk. The team discussed several ideas, initially landing with two options: a space theme with “astronaut vs aliens” and a haunted house theme with “trick or treaters vs ghosts”. We ended up doing a cyber ninja theme with cyberpunk as the inspiration.

Juliana’s portion of the project consisted mostly of art/animation and level design. When creating the ground and platforms, she initially tried a tilemap to implement it, but found that it was easier to just use pre-existing platforms. The ninja’s fire shooting animation and melee attack was actually the easiest to create while the running/jumping animation took a few tries. She settled on a purple and blue theme to fit the concept of cyberpunk, and created the mobs to be consistent with a futuristic city. Since the ninja was dark blue, they kept getting lost and it was hard to focus on while navigating the map. This was solved by giving them a red headband and a green sword. The shooting attack was inspired by firebending in Avatar the Last Airbender. To keep consistent with the theme, the two enemy mobs were a robot inspired by Terminator, and a drone. Each of these mobs were given an idle animation. Her portion of the project also consisted of fixing bugs associated with the preliminary level design after beta tests. Players found a few inconsistencies where the ninja could phase through walls or platforms and use a wall jump to fly themselves through the map. These bugs were fixed by using invisible boundaries to keep the player in the main playfield, and turning off wall jumping for certain walls. Certain cosmetic related issues were also fixed where the background needed to be redrawn to fit the size of the camera. 

Kevin started out by setting up the project, with the github repository, from the base template developed during the lecture of the fourth session, which included the main screen, player + enemy characters, animations, and shooting, all of which were later redeveloped with better art by Juliana. Kevin’s portion of the project consisted of implementing the logic for several features such as melee mechanics (for ninja sword) when the player hits the left click, the ninja will swing and check if the enemy (either drone or robot) is hit. Kevin added the background music as well as the sound effects. Kevin also added the UI and logic for mechanics such as health, which included dealing damage and implementing the health bar with hearts to update as the player loses or gains health. Another portion was the key/door mechanic, where Kevin implemented the pickup of the key logic and the opening of the door mechanic to open up vertically. 

Ethan’s portion of the project was building the levels. Based on Juliana’s artwork, Ethan worked on the placement of various objects Juliana created/animated onto the levels. For instance, Ethan worked on placing enemies and platforms on the levels. The first two levels Ethan designed were meant to be easy. They mostly consisted of jumping between platforms with enemies on them. The next two levels were designed to be harder by implementing ideas such as well climbing and avoiding drones in mid-air. The last level was designed to be the hardest by adding many enemies, as well as removing the ground floor. The enemies were sped up to make them harder to avoid. Almost all the levels (except level 2) Ethan designed also implemented doors and keys to add a bit of an extra challenge to the game. In addition to level design, Ethan also worked on the code for the enemy AI. Ethan wrote the AI code to automatically move back and forth between two invisible barriers. When the enemy hits the barrier it turns around and goes the other direction. Ethan also wrote code to implement menus. These menus included options to read instructions on how to play, quit, or start the game. Finally, Ethan worked on fixing bugs in the game such as enemies going over platform edges and sprites disappearing randomly. Overall, Ethan’s primary work involved level building, menu creation, AI coding, and bug fixing.

Playtesting 

Once our game was in its “90% done” state, it was ready for playtesting for the class. One thing that our professor mentioned was that the last 10% always took the longest. Let’s just say we now know the meaning of it. The valuable thing about playtesting, is that other players will always try to find ways to shortcut/ find game breaking issues. Luckily, ours were easily fixable, mostly just by creating invisible boundaries. It was enjoyable to hear that our peers were commenting on ways to improve the story/art, for example adding a sound somewhere, or changing the fireball to a shuriken. This meant that our game mechanics in their current state were pretty solid since they chose more “aesthetic based” feedback. For the submission of the project, some of this feedback would take too long to implement by the due date, however it will be addressed in the Possible Future Revisions section of Devlog 2.