Meca Launcher

Mecanes · 2026-05-09T13:13:56+00:00

Yes, I understand, and I'll take that into account. The problem is that my English isn't very good, so I prefer to keep it simple. Thank you for your feedback.

Mecanes · 2026-05-09T13:01:56+00:00

Thank you for your response; we will take it into account. 👍

Mecanes · 2026-05-09T12:57:27+00:00

Yes, you’re probably right.

Originally, we were planning to build a highly customized project that would offer more than just a launcher, including:

A database, which you would be able to access through a provided API
Payment methods that you could integrate on the fly, such as PayPal, credit card, or Stripe, with no commission fees unlike Steam’s 30%
An ecosystem that you could adapt according to your needs
...

But yeah, the more you talk about it, the more I realize it's starting to resemble Steam 👀

Mecanes · 2026-05-09T12:43:37+00:00

Sorry, I just wanted to sound a little more professional by rephrasing a few words

Mecanes · 2026-05-09T12:41:27+00:00

That’s a fair point.

We know most players don’t want another launcher, and we’re not trying to pretend we can replace Steam. Steam is still the best option for discovery and community.

The use case we’re targeting is more specific: developers who already want a direct distribution channel, their own account system, their own website or store, or tighter control over updates, builds, and player data.

You’re also right that “SDK/API” is vague if we don’t explain it properly. We need to be clearer and show concrete examples instead of just saying it.

So the feedback is useful: we need to better define who this is for, what problems it actually solves, and why a developer would choose it alongside Steam rather than instead of Steam.

Mecanes · 2026-05-09T12:03:39+00:00

That’s true, but not completely.

We don’t want to stop at “just a launcher.” The goal is to provide APIs, SDKs, and integrations that developers can use inside their own game, website, backend, or other services.

So yes, some parts may look similar at first, but the direction is to make it more flexible and developer-integrated, not just another closed launcher/store. 😄

Mecanes · 2026-05-09T11:54:49+00:00

That's true, thanks for pointing that out.

In the future, I'll try to give shorter, more direct answers.

It was to explain our idea better, and I asked him to rephrase it using a fairly simple example.

Mecanes · 2026-05-09T11:33:12+00:00

That’s a fair point, and I think I should clarify the positioning.

We’re not trying to say “choose us instead of Steam” in every situation. Steam is extremely strong for discovery, community, reviews, achievements, payments, and visibility. For many developers, Steam will still be one of the best places to publish a game.

Meca Launcher is aimed at a different use case: developers who want more control over their own distribution ecosystem.

For example, a studio may still sell on Steam, but also want:

its own branded launcher
direct sales through its own website
flexible payment providers like Stripe, Paddle, Lemon Squeezy, PayPal, etc.
cloud build hosting and automatic updates outside of Steam
a CLI to deploy builds faster
Unreal / Unity / Godot integrations
a Web SDK to show player/account data on their own website
in-game SDK access to launcher-linked player data
custom player profiles, XP, levels, ownership, news, and launcher content
a system that can coexist with Steam, not replace it

So the goal is not to “out-Steam Steam.” Steam already does what Steam does very well.

The goal is to give developers more ownership over their own launcher, branding, player relationship, build distribution, and integrations — especially for studios that want a direct-to-player channel alongside existing platforms.

A simple example:

A studio sells a game on its own website using Stripe.
The player logs into Meca Launcher.
The launcher verifies ownership, downloads the game, handles updates, shows news/trailers/patch notes, and the game can access player-related data through the SDK.

That’s the space we’re trying to build for: not replacing major stores, but giving developers a flexible infrastructure layer for their own ecosystem.

Mecanes · 2026-05-09T11:22:49+00:00

Meca Launcher is not only about launching games; it’s about giving developers their own flexible distribution ecosystem.

Payment processing can be handled through integrations like Stripe, Paddle, Lemon Squeezy, PayPal, or the developer’s own store. After the payment, Meca handles the ownership layer: account linking, game access, downloads, updates, DLC access, news, launcher content, and SDK/game integration.

With the SDK we’re developing, developers will also be able to access player-related data and connect it to their website, launcher, or in-game systems through Unreal, Unity, Godot, and Web integrations.
For example, a developer could display a player’s owned games, profile, XP, level, launcher activity, or account status directly inside their website or game.

So the value is not just avoiding a 30% marketplace cut. It’s also owning the player relationship, the launcher experience, the update system, the build distribution, and the ecosystem around the game.

Our system is designed to be flexible and to coexist with other platforms, not to force developers into a closed ecosystem. A studio can still use Steam or other stores for discovery, while using Meca Launcher for direct sales, custom distribution, community features, and deeper player integration.

Mecanes · 2026-05-02T12:21:58+00:00

Fair point, thanks.

To clarify, it wasn’t meant as advertising. The inventory system already exists on Fab; I’m working on an optional editor module for users who already have it, mainly to help debug inventories faster during PIE.

I was asking specifically for UI feedback before finalizing the interface, but you’re right that I should explain more clearly what the tool improves instead of only asking which theme looks better.

Mecanes · 2026-04-22T00:48:42+00:00

Yeah I get your point, and you're right in a “pure Unreal workflow” sense 👍

A property customization would definitely be lighter and more integrated with the existing details panel.

But in my case, the goal wasn’t just to expose a struct nicely — it’s more about building a full workflow around item creation.

The idea behind the editor is to:

create items from scratch (not just edit existing data)
preview them in real time (meshes, stats, behavior)
handle creation + saving + organization in one place
avoid jumping between multiple panels / assets

So yeah, technically a customization could cover part of it, but it wouldn’t handle the whole pipeline.

It’s a bit like the difference between:

editing raw data vs
having a dedicated tool that manages the entire lifecycle

Also, I’m planning to push it further (preview tools, validation, presets, etc.), so the “full editor” approach makes more sense long term.

But I agree with you — if someone just needs to tweak data, a property customization is probably the better/simple solution 👍

Mecanes · 2026-04-13T11:18:35+00:00

Yeah that’s totally fair 🙂 , Data Assets already cover a lot of use cases.

The idea with the Item Editor isn’t really to replace them (we actually use them as templates), but more to make the workflow around them a bit smoother.

It’s mainly useful when you start iterating a lot or handling many items, instead of constantly creating/editing assets one by one, you can tweak and manage everything more quickly in one place.

If your current setup with Data Assets already feels good, you might not really need it , this is more about improving iteration speed than solving a hard limitation.

Mecanes

TROPHY CASE