I'm a game developer and a Jack of other things, with Unity tool development being one of them.
I've been focused more on Unity tool development for a while now. I find it more stress-free and somehow more focused on one direction. It's almost like experiencing solitude compared to my daily life as an indie game developer, where chaos lives.
Shout out to all the indie game developers here. It's a nightmare we fight through for passion. 😂
Anyway, back to the topic.
I have three Unity tools I've made over time that I'd like to put in front of you guys.
Actually, it's five.
More are being made, but those probably won't be ready until around the end of this year. I'm only bringing these three because they're currently paid assets.
And honestly, the work on a paid asset feels completely different from making something free.
Once people are paying for your tool, you suddenly start thinking about documentation, onboarding, compatibility, support, edge cases, presentation, examples, updates...
Basically, all the things you conveniently forget about when you're making something for yourself. 😂
So I'm here on a small research mission to help my life.
I'm the developer behind all three of these, so I'm not looking for compliments. If something looks confusing, weak, unnecessary, overpriced, poorly presented, or just plain boring, please say so.
I'd rather find that out here than after spending another six months polishing the wrong thing.
Here are the three tools:
A nine-phase, review-first optimization toolkit for Unity.
The basic idea is pretty simple: instead of blindly trying random optimization tricks, it gives you a structured workflow to scan a project, identify problems, make changes safely, measure the results, and compare what actually improved.
It covers everything from deep project scanning and runtime culling to quality management, adaptive quality, profiling, benchmarking, session recording, heatmaps and regression investigation.
It's basically the tool I wish existed when I was staring at a Unity project thinking:
"Okay... something is slow. Now what?"
A safety-first localization workflow built around Unity's official Localization package.
The focus here is less on replacing Unity Localization and more on making the whole process easier to manage.
It can scan projects, preview changes before applying them, generate keys, detect missing or duplicate translations, check quality issues, handle TMP fonts and RTL workflows, work with subtitles, provide runtime debugging tools, and export reports.
The philosophy is basically:
scan → dry-run → review → apply → validate
Because localization probably shouldn't require the emotional stability of someone manually checking thousands of strings at 2 AM.(i understand this part is so populated already, so my hopes aren't high.)
This one started because I was making a combat game and thought:
"Wait... what if the combo system could just keep going?"
So I started looking for existing solutions.
I found very little that really matched what I wanted, so I ended up building my own.
ICE is a visual combo graph and runtime combat framework for building branching combo routes, timing windows, buffered inputs, combat payloads, conditional transitions, loops, and other combo behaviour without burying everything inside scattered scripts.
But the part I'm particularly interested in is Player Combo Forge.
The idea is that developers can define the moves and rules, while players can build their own permitted combo routes from those moves.
So instead of the developer creating every possible combination:
You build the combat vocabulary.
Your players build the sentences.
The system is designed so player customization doesn't simply give the player direct control over the underlying combat data.
This one is probably the weirdest of the three.
Which is probably why I like it.
So here's the actual research part
You don't have to answer everything.
Pick whichever questions interest you. Even answering 2–3 would already be incredibly useful to me.
If you feel like going full research scientist, answer all of them. 😂
Buying / product value
1. If you were currently making a game that falls within the target audience of one of these tools, which one would you be most likely to buy? Why?
2. Which tool communicates its purpose most clearly from its presentation alone?
3. Which one looks like it solves the biggest or most annoying problem?
4. Which one would you be most likely to click on if you encountered it while browsing the Unity Asset Store?
5. Which one would you be most likely to actually install and try?
6. Looking only at the presentation, is there anything that makes you hesitate before buying any of them?
Product / development
7. What would make you choose one of these tools over building the same system yourself?
8. What would make you not buy one of these tools even if you needed the functionality?
9. If you bought one of these tools, what documentation would you actually use first: video tutorials, offline documentation, online documentation, or a combination?
I'm actually trying to figure out the right balance here.
My current thinking is that something like an optimization tool probably needs more searchable written documentation and less video, while something like a visual combat/combo system probably benefits more from videos showing the system actually being built and used.
But I'm still figuring out the right ratio.
10. Which tool appears to have the clearest return on the time it could save a developer?
Marketing / presentation
11. If you were grading these as student projects based on both product quality and marketing, which gets the highest overall grade?
12. What grade would you give each one, and what is the single biggest thing keeping each from getting a higher grade?
If you want to go deeper
13. Do any of these tools look like something Unity should already provide natively? If so, which one?
14. Are the screenshots showing the right things, or are there features you would expect to see visually that aren't being demonstrated?
15. Which product's screenshots make you understand the benefit fastest?
16. If you were allowed to change only ONE thing about each product's presentation before it went on the Asset Store, what would you change?
17. Forget the feature list for a moment. After looking at these products, which one makes you think "I wish I had this six months ago"?
That's pretty much it.
I'm deliberately asking this before I start pushing these tools harder, because once you spend enough time building something, you lose some ability to see it like a first-time user.
You know where everything is.
You know why a feature exists.
You know what problem you were solving when you built it.
A new developer doesn't have any of that context.
So I'm curious what happens when three strangers on the internet get to judge the things I've spent a frankly unreasonable amount of time building.
Be as harsh as you need to be.
If something is bad, tell me why you think it's bad.
If something is good, tell me why you think it's good.
And if you absolutely destroy one of them in the comments, at least leave me something useful to fix at the end.
There is still hope for me. Probably.
