ROBLOX made me think I sucked at making games.

Blanket — Sat, 15 Nov 2025 06:56:26 +0000

Before I begin, I want to say that this is just my experience with ROBLOX development, if ROBLOX clicks with you, great keep going. Everyone’s brain works differently.

Like many others, I developed an interest in making games on ROBLOX, a platform that claims to make game development easy. I had spent years developing on ROBLOX, and didn’t really make much progress, best work being a game in which you complete a small obstacle course for custom admin commands.

With actual games on ROBLOX, I’d always run into some snag that kept it from working how I want, like ROBLOX and its, in my opinion, terribly confusing UI positioning an scaling system, ‘udim2’, which for me, makes it impossible to scale menu systems to fit correctly on different devices as I don’t get it, or the cryptic puzzle that is attachments, welds, constraints.

I also want to mention that for 2D elements, like UI, all game engines that I know use a much simpler approach, similar to that of a Vector2.

I’m skipping a lot of in between here, quit game development for a while, tried Python and its amazing game engines, I tried the amazing LOVE2D, tried Godot recently. Godot really clicked with me, it reminded me of ROBLOX, but without my gripes I have with ROBLOX.

I’ve been using Godot to work on a 2D platformer where you play as a wizard who can only cast spells while moving, forcing you to attack when possible and dodge when you can’t.

Some might say I’m doing well because it’s a 2D game, but I’d like to point out that I’m also working on 3D games in Godot and still doing better than I ever did in ROBLOX. I shared my 2D game as an example because it’s the most complete. I just have to learn blender, which is a requirement for ROBLOX too depending on the game.

The point is to find or create tools that click for you, just because I can’t develop on ROBLOX doesn’t mean I can’t make a game or that I should give up.

Mini-Micro: http.post wizardry

Blanket — Thu, 13 Nov 2025 02:29:37 +0000

Today, I wrote what I am going to call a “protocol proxy,” a system that receives a request via one protocol (such as HTTP(S)), translates it into another, sends it, and sends back the response as the response for your request.

You might be wondering why anyone would need this. In Mini Micro, we only have HTTP(S) connections, and I want to create systems like live chat and a remote shell for my Mini Micro session so I can code anywhere in my house.

It works by sending specially crafted POST requests to my Python Flask server, the post request contains all of the necessary information to do the connection and sends it back as a response to our initial request.

An example request being something like:

http.post("http://127.0.0.1:5000", {"request_type": "socket", "dest":"192.168.1.157", "port":5050, "method": "send", "data": "Hello, world!"})

Unfortunately, I think we are limited to a system where we connect, send, disconnect then connect, receive.

The entire flow is like this:

Mini Micro makes its http.post request to 127.0.0.1:5000 with the correct info to send via a socket. ->
The server parses the request, performs it, target gets the request ->
Target does whatever, sends a response, web server returns the response as its response for the request we made ->
The response would be returned by http.post.

Few things I have to do before I am comfortable releasing it, it needs a cleanup under the hood, I want to write libraries that make the whole experience easy to use with your Mini Micro code, I want to support more protocols.

What would you do with this?

DEV Community: Blanket

ROBLOX made me think I sucked at making games.

Mini-Micro: http.post wizardry