DEV Community: Manasa Jayasri

Building Real-Time Features with Node.js and Socket.IO

Manasa Jayasri — Thu, 29 Jan 2026 20:08:17 +0000

Before the internet, communication looked like this: you’d write a letter, drop it in the mailbox, and wait days for a reply. Early websites weren’t that different. You sent a request, waited for the server, and refreshed to see what changed. The web used to be that simple. But today, users expect instant updates. Be it chat messages that appear in real-time, live notifications, dashboards that update without hitting refresh.

Then came AJAX in the early 2000s, and suddenly pages could fetch bits of data without reloading. That opened the door for features like live search suggestions and background updates.

But as users demanded more live chat, multiplayer games, collaborative tools, developers started to hack together “real-time” with long polling and other tricks. These worked, but they were clunky, unreliable, and hard to scale.

Enter WebSockets: a protocol that let browsers and servers keep a persistent two-way connection. Real-time communication was finally possible. And on top of WebSockets, libraries like Socket.IO emerged to smooth over the rough edges, handling fallbacks, reconnections, and cross-browser quirks so you could just focus on building.

What is Socket.IO?

Socket.IO is a JavaScript library that enables real-time, bidirectional communication between clients (usually browsers) and servers. It’s built on top of WebSockets but adds important features like:

Automatic reconnection
Event-based communication (you can define custom events)
Support for rooms and namespaces
Fallbacks when WebSockets aren’t available With Node.js on the backend and Socket.IO handling connections, you can build highly interactive applications with just a few lines of code.

In the next part, I walk through setting up a Socket.IO server, handling events, and building a simple real-time feature step by step. Read the full post here: https://manasajayasri.github.io/Building-with-Socketio.html

Behind the Scenes: Designing a Beat Saber-Style Game with Godot

Manasa Jayasri — Sat, 26 Oct 2024 03:30:35 +0000

Playing Beat Saber on the Meta Quest 2 is a total thrill ride, but honestly, more than 20 minutes gets me jittery with a headache that sticks around for a while. Still, that didn't stop me from diving into crafting my own version in Godot. I aimed to capture that same intense slice-and-dice rhythm. The challenge was to mimic the gameplay and to imbue it with my own technical interpretations.

The Build:

Laser Swords Setup

I started by crafting the laser swords for the VR controllers. Utilizing Godot's LineRenderer, I drew the swords extending along the negative z-axis of the controllers. Each sword's visibility toggled with the respective controller buttons—'A' for right and 'X' for left—making sure they interacted with game elements only when I wanted them to.

Dynamic Cube Targets

Then, the cubes. These guys start off in the distance and zoom towards you, putting your reflexes and rhythm to the test. I programmed them to poof into thin air when hit by a sword—just as satisfying as the real Beat Saber.

Recentering the Player’s View

A cool feature to add was recentering the player's perspective. Hooked into OpenXR's "On Pose Recentered" signal, pressing and holding the Oculus button now snaps the player’s view directly to an incoming cube, centering them perfectly for the action.

# Handle OpenXR pose recentered signal
func _on_right_controller_button_pressed(name):
    if name == "primary_click":
        XRServer.center_on_hmd(XRServer.RESET_BUT_KEEP_TILT, true)

Adding Audio Feedback

Sound effects were crucial. I went ahead and integrated funny boing sounds to accompany each cube destruction, because, why not? I'm just having fun. Digging through free sound databases provided me with the perfect clips that I then synced with the cube hits.

Cube Spawning Mechanism

To keep the game lively, I implemented a CubeSpawner script. This little piece of code works to randomly generating cubes at intervals between 0.5 and 2.0 seconds, ensuring the gameplay stayed unpredictable and engaging.

extends WorldEnvironment

var cube = preload("res://SceneInstances/cube.tscn")
var second_cube = preload("res://SceneInstances/second_cube.tscn")
var timer = Timer.new()

# Called when the node enters the scene tree for the first time.
func _ready() -> void:
    timer.wait_time = randf_range(0.5, 2.0)
    timer.autostart = true
    timer.one_shot = false
    add_child(timer)
    timer.timeout.connect(_on_Timer_timeout)

# Called every frame. 'delta' is the elapsed time since the previous frame.
func _process(delta: float) -> void:
    pass

func _on_Timer_timeout():
    var red_cube = cube.instantiate()
    red_cube.set_script(load("res://Scripts/CubeMovement.gd"))
    red_cube.get_child(0).set_collision_layer_value(10, true)
    add_child(red_cube)

    var blue_cube = second_cube.instantiate()
    blue_cube.set_script(load("res://Scripts/CubeOnMove.gd"))
    blue_cube.get_child(0).set_collision_layer_value(9, true)
    add_child(blue_cube)

Efficient Game Object Management

I then tackled potential performance issues by ensuring cubes that weren't hit didn't linger—they auto-destruct to keep everything running smooth. And just like the original, only a sword of the right color can smash its corresponding cube.

The Result:

Building this Beat Saber-inspired game in Godot was fun. It pushed my understanding of VR capabilities in Godot. For now, that's where I'm pausing, but I'm excited to enhance the game further. Next steps include integrating a music track for players to interact with, and adding directional textures to each cube to indicate the strike direction—arrows will point up, down, left, or right. Additionally, I want the cubes to break into smaller pieces that scatter and disappear when hit.

Got any killer ideas to make this better? Drop them in the comments!

Here's the complete version on Git.

Unity vs. Godot: A Game Developer's Guide

Manasa Jayasri — Wed, 16 Oct 2024 15:21:00 +0000

Hello, hello! I'm so glad to be finally making my first post on Dev.to with a topic that I've been obsessed with these days. Being a full-stack developer who has recently delved into the realm of game development, it has been quite a balancing act between Unity and Godot projects. I just completed a simple side-scroller game, 'Flappy Bird' and am now working on a casino game for deployment as an APK (soon to push a Git repo out!). It all started with the creation of a Beat Saber clone APK in Godot for a class assignment. Honestly, I would have never explored Godot if not for this. Here's my take on these two powerful game development platforms.

Starting with the UX: Unity’s user interface is intuitive, especially if you come from a coding background. The best part is, no matter where I got stuck, there were tons of resources out there to help me out. But then again, the ease of use was pretty smooth. Godot, while also user-friendly, took me some time to understand the environment (I wonder if that's because I was used to Unity?). I guess I can say this now that I understand it better: the interface is lightweight and provides an organized environment for developers. It’s designed to be straightforward, with minimal distractions, which helps developers focus on their projects.

Both Unity and Godot allow for customization of the editor interface, including the ability to rearrange and resize panels according to your workflow needs.

Scripting: Although the background physics and rendering are done in C++, Unity uses C# for game logic. It's a well-established, robust, and versatile programming language known for its power in game development. The scripting environment for Godot, GDScript (syntax being similar to Python), offers a seamless method for objects and components within your game to communicate through its feature for signals.

I knew this and also gathered more opinions on which is better in terms of development time, and it's safe to say Godot is way faster than Unity when going from code to running your game back and forth.

Graphics and rendering: Unity is an integrated program with some of the best graphical and rendering capabilities, integrating some of the latest technological advances into real-time rendering. It can support high-fidelity graphics that are vital in creating visually demanding games and simulations which are proving to be suitable for high-scale projects.

Godot has made attempts to improve its rendering engine, with enhancements like better shader capabilities and visual effects. Although it may not achieve the high-end level of detail offered by Unity, it is more than adequate for most indie and medium-scale projects. There are some challenging aspects too. For instance, you need to manually adjust camera settings for each scene, which can be time-consuming and error-prone, particularly for beginners or when transitioning between scene types. This can be daunting if you’re working on a large-scale project.

Platform support: Unity excels in cross-platform support, compatible with over 25 platforms including emerging VR/AR systems. Godot, being open-source, also supports multiple platforms and benefits from community enhancements, particularly in VR development.

All in all, I believe while Unity is well appreciated for allowing in-editor game running and adjustments, Godot also excels by enabling developers to run individual scenes, facilitating faster iterations and minor adjustments. Unity is ideal for high-end, large-scale projects due to its comprehensive features and superior graphics, whereas Godot excels in medium-scale projects with its simplicity and rapid prototyping capabilities. This distinction is essential for developers looking for efficiency in development cycles and scene refinement.

I say both are winners but I happen to be a fan of Unity for it's vast capabilities and robust support on many platforms.

Feel free to share your thoughts in the comments!