Sonarogue Devlog (01.17-01.30)

Design & Dev & Test Dailys

Day 01-02: Initial Ideas, Basic 3C & Targets

Day 03-04: Minimum Demos

Day 05-06: Inviting Playtesters! (first-round playtest on Ins)

Day 07-10: Gameplay & System Implementation

Day 11-12: Add Polishment, Sounds, VFX

Day 13-14: Delivery! (second-round release on Itch)

Day 01-02: Initial Ideas, Basic 3C & Targets

I always want to create a roguelike game. Procedurally generated dungeons, turn-based gameplay, grid-based movement, and permanent death. It's kind of an old romantic fashion, huh? So why not just grab this two-week challenge from FIEA, forget everything else and sit down to make it a game? 

- Core Idea: Limited FOV

To me, the most exciting and intriguing part of a roguelike game is the field of view. Especially when the environment is randomly generated, the limitation of FOV creates mysteriousness and invokes the desire to explore. So I decided to design the core gameplay based on FOV. 

- 3C: Camera, Character, Control

• Camera: Fixed, 2D Top-down
• Character: A Sonar/Lidar Box
• Control: Move, Detect, Fight

- How to Win/Lose

• Dive into Dungeon
  
• Don't Die

- Personal Goals as Designer & Developer

• Designer: Implement playtests, inviting playtesters from the beginning, don't be a dead game
• Developer: Use only one Update() method in Unity since it's a term-based game

- References

• Scanner Sombre - Non-continuous Lidar Scanner, Point Cloud
• Batty Cave - Continuous Interactive Scanner, Minimum Vision
• Yet Another Roguelike - Hardcore Roguelike, Term Based, FOV

Day 03-04: Minimum Demos

So, after shortly wrapping things up, I made several super early minimum demos, and two of them are my favs. All of them are built around the core idea: FOV. One works like a Lidar system with color (just call it so for convenience); the other works like a Sonar device. 

Sonar one (the black and white) : 

• Pros: Very minimal vision, good aesthetic. The process of drawing the map out is quite interesting. 
• Cons: Can be hard to express what is an enemy, what is a skill, etc. The project can fail the two week time since I am the only creator. 

Lidar one (the colored) :

• Pros: Easy to understand. More like a traditional way to make a roguelike. I can 99% finish in two weeks. 
• Cons: Just not so cool. Needs more details and art to fill it up. 

Day 05-06: Inviting Playtesters! (first-round playtest on Ins)

Choose one (or zero) between the two? Invite some playtesters! 

I don't have thousands of followers on any platform, and I don't have a team. So, the easiest way to do so is post the gameplay video on my social media, and set up a poll for my friends to vote. 

And here is the result: 

The result is obvious, so I just trust my friends and take the challenge! 

Day 07-10: Gameplay & System Implementation

According to the poll result, I choose the sonar one as the core gameplay and FOV system. Everything in the environment discovered by the player should be settled down to a little point, which represents its position and direction according to the player. 

- Procedural Map Generator, Core Sonar System

I start on this one first because I think it can control the minimum result I can get after two weeks. Even if I did everything else badly, thanks to the core of roguelike, it can still be a game. 

- Basic UI, Basic Enemies, and Basic Fight

I don't want the fight to be escapable. Once the enemy sees you, it will chase you to the end of the world. The only ways you can fight back: exchange your health with it; use the sonar skills that will implement later. 

Also, I want to give the player some hints and a sense of oppression when enemies are approaching.

- Inventory System

No treasures, no roguelike. 

- Skills! Strategies! 

Surrounding the core Sonar System, I designed two skills: 

• Sonar Bait: Creates a fake you that makes some noise, to attract the enemy's attention. When the enemies walk, their location is exposed to you. Also, you can find a way by watching their movements. 
• Sonar Boom: Easy as it says. A high-volume boom that destroys almost everything in the area (including you).

The cool thing about this part is: the player starts to have some ways to build their strategy. You can use bait you attract enemies away and secretly go through behind, or you can attract plenty of them together and use a boom to end all this. 

And the variation in this part excites me the most. 

Day 11-12: Add Polishment, Sounds, VFX, Pack Up

To make the game more intriguing, I did several polishments: 

• Overall UI: I changed the overall UI to a more sci-fi feeling one. 
• Sounds: If I couldn't find one, then just create one using Bfxr.
• VFX, Particles: I added lots of particles and shakes to try to make the feedback more complicated but also more meaningful. 
• Main Menu: The main menu design is also surrounding the gameplay. You can trigger the character animations when selecting. 

Day 13-14: Delivery! (second-round release on Itch)

Simply click upload and... wait for bugs and feedback! 

After inviting many of my friends to give it a try, I received many meaningful feedbacks: 

• The player's movement was always too fast or too slow. This is because every term is set to the same delay time, however, when you want to do something more precisely, you need a longer term-delay; when you want to move a long distance, you want a shorter term-delay. So, I implemented a dynamic term-delay function, as you press the movement keys for longer, you can move faster. 
• The way to restart was so awful. Previously, you need to refresh the page to restart a dungeon. So I again implement something new in the UI, letting players have a quick rebirth. 
• The WebGL version's frame rate was very low on some browsers. To be honest, I don't know how to fix it. But luckily, I found an asset on the unity asset store: WebGL FPS Accelerator which uses a dynamic dpi system to fix the fps problem. Many thanks to the author Agnosia Games! 

And... that's pretty much for now! Feel free to leave any comments, cool ideas, critics, or bug reports below. Cheers! 

2023. 01. 30