Author: Joshua Rand

This was the second day that we worked on the game jam. My group decided upon Soshi Shinobi, and started development on it. It was originally Alex Wisdom’s pitch. It is a two-player game where each person controls one half of the player. The premise behind the game: “Soshi Shinobi” is that the ninja possesses fire and water elemental powers, that they would assign to either their legs or arms. “Soshi” means “element” in Japanese. One player would pick water, the other would pick fire, and one player would pick control of the arms, or the legs, and the two would work together to control the single ninja; moving them to avoid hazards with the lower body, and using the upper body to shoot fire or water waves to damage enemies. The elemental ability of each player is pre-set at the beginning of the game and cannot be changed afterward, but the players can switch between controls of the legs or the arms, keeping their abilities with them. The player will behave differently and be vulnerable to different obstacles throughout the game. For example, the player can only walk over fire or water floors if their legs have the correct corresponding element, or they will take damage. The same goes with shooting elemental enemies with fire or water waves. The players must cooperate and decide when to switch body parts and use the correct abilities on body parts at the correct times.

Today we finished and presented our games for the game jam. In my group’s game, Soshi Shinobi, I worked mainly on the user interface, including the pause menu, title screen, and player’s HUD, as well as the player’s controls.

I created virtual keys for keyboard and Xbox controls, in which a single function that can be executed by multiple buttons would only need to be checked with one condition. (For example, I can check if a “down” button is pressed with a single statement, instead of needing if P1 Joystick is held down, or if P2 Joystick is held down, or if Down on P1’s D-pad is held, or if the actual down arrow key is held, or if the S key is held (down for WASD controls)). I also fixed a small bug with the timer, which the fellow programmer on the team designed. The timer is perfectly functional, except it displays certain numbers in a way that’s not consistent with an “alarm clock” fashion, where 4 numbers are always displayed. For example, before 1 and 1/10 of a second would be displayed as 1:1, instead of 01:10.

Here are some of the other teams that presented:

The team that presented this game didn’t expect the credits to shrink so much. I explained to them why that was happening. By default, Unity canvases have their scaling setting set to “Constant Pixel Size”, which means if you start developing the game in a resolution like 720p, then build the game and run it at 4K resolution, the canvas will appear much smaller. This can be fixed by setting it to “Scale with Screen Size”, so the canvas will stretch accordingly. This is what I had to do with the UI for Soshi Shinobi.

The last game, a blob-based game with custom Unity shaders, I forgot to take photos of.

Of all the teams that presented, Professor Jörg commented that our game, along with two other games that the teams developed, with a little more work would be ready to be launched on platforms such as the Switch, Nintendo 3DS, or Steam.

Today we met up at the University of Paderborn where we split into groups for the Game Jam. There ended up being enough American students for one to be on each of the teams. First, we broke into small groups of 2 to come up with a game pitch. My pitch was the idea of a 2D puzzle platformer in which one player would control two characters on screen, represented by shapes. The player would have to switch back and forth between characters, which vary in size and shape throughout levels; circles, squares, large and small shapes, controlling one at a time to guide them to the exit of each level. If either of the players took damage from an enemy or fell to their death, the player would have to restart the level. Each group then joined together with two other groups of 2, making a total of 6. The students discussed which of their three pitches they would go with, and they ultimately decided on mine. One person from each newly-formed group then wrote their pitches on the whiteboard, with a title and up to 6 short bullet-point descriptions. We narrowed down some of the pitches, and unfortunately mine did not make the cut. Students then decided which pitch they would like to work on, while the faculty would ensure there was an even distribution of programmers, artists, game designers and sound designers on each team. The team I am in is going to work on a 2D puzzle game, in which two players control part of a player. One controls the legs and handles movement, while the other controls the upper body and handles attacking. Players can also switch roles as they please, but will keep using a preset element; fire or water, which not only gives each player a turn to control each half of the body, but adds variety in gameplay. A fire-elemental player controlling the upper body would use fire projectiles, while a water-elemental player controlling the upper body would use close-range melee attacks.

Today we traveled to the small town of Bielefeld, where we took a tour of the Sparrenberg Castle, which was used in the Thirty Years’ War, as well as part of World War II. One of our guides, Volker, was kind enough to translate the tour guide’s sentences to English.

Down here is where enemy soldiers would run up to try to raid the castle. Because of the curved floor, soldiers could easily roll grenades downward to stop them. As our tour guide explained, there were no fragments of grenades found in the walls, which means that the enemy soldiers never got far when invading.