Scrapping the light and adjusting boat movement. – August Demirsson

As mentioned in my other blog the game we chose to make was Umibozu. In the game, you are a fisherman in search of a mystic creature in this mystical water that is surrounded by thick fog. In order to see creatures in the original game concept you had to use a light stationed on the boat and aim at the creatures to fully see them instead of blurry moving objects.

During this week design process, me and my group decided upon scrapping the light on the boat in our game. We did this because of many reasons. One of the reasons is that in our game the enemies always spawn in front of the player. They spawn in front of you because the camera always moves upwards, if you stay stationary and touch the bottom part of the screen it will push you forward, therefore having enemies that spawn on the sides or from the bottom would be extremely difficult to cope with, as you are always forced to move upwards.
This would mean that the player would always aim the light facing the top of the screen where the enemies spawn, making in stationary. We though that an interaction like that would be pretty boring and not needed for the game that we are making.
Additionally, the fog we are making in our game will not be thick enough to make it difficult so see the enemies, but rather boost the mystical atmosphere. As it is simple enough to see through the fog we thought that implementing a light felt even less useful.

Now to another design tweak. After the playtest we recently had, we got a lot of feedback on the movement of our boat. Many described it as “moving a brick” and how it did not feel boat-like at all. To address this, we slightly decreased the response time of the boat movement when you press down an arrow key. Additionally, we made the boat slide a little bit after you release the arrow key to make the player feel like he/she is floating on water.

What is your thought? Feedback would be much appreciated!

4 thoughts on “Scrapping the light and adjusting boat movement. – August Demirsson

  1. I started reading this post with no context, so I appreciate the background you gave in the start of the post. It clearly explains what your group is doing, and I think would even be understandable to someone who is not in the game design program. I understand the choice you made of removing the light altogether from Umibozo. I playtested many of the Umibozo games during the alpha playtesting session, and found that several of the game’s light mechanic was very confusing and only remember a few where it made clear sense. It also became very distracting in the games where it was not well implemented. I think momentum in avatar movements is extremely important to realism. Even Mario in the NES title has momentum (where he slides a little bit after you stop moving). Momentum like this would be especially important since your avatar is a boat, where this movement is even more obvious. Overall, I like the choices you’ve made so far and think they will massively improve your game!

    Like

  2. Background information is a great way to start a post; it gives the necessary information but also invites you to read previous content. It’s always a considerate thing to do for the reader.

    It would be useful to have more images or footage of the game you’re talking about, so we can put ourselves in a better situation to understand the topic you’re talking about. It would also help the reader to have a clear idea of the issue you encountered during the playtesting session. Have you considered uploading a playable build somewhere for playtesting new features? It might prove useful to you in the future, in case you don’t want to wait for every playtesting session to get some feedback outside of your group.

    In regards of the lantern scrapping, I would say is a strong atmospheric element in the game. How do you compensate this loss? Has it proven a better solution than adapting some other mechanics in order to make it more useful? How? I assume these matters were considered already, but it’s always useful and interesting for other game designers knowing all the factors in a decision-making process.

    The “boatiness” tweak is reasoned and well described, although some demonstrations would considerably improve the post overall.

    Good luck!

    Like

Leave a comment