newspaperAbout
infoAbout s&box newspaperLatest News published_with_changesChanges mapRoadmap monitoringMetrics
gamesGames
sports_esportsBrowse Games rocketDiscover Games
business_centerWorkshop
sports_esportsGames landscapeMaps chairModels textureMaterials apparelClothing constructionMore..
forumForum docsDocs
docsDocumentation dashboardApi Reference
Sbox UI Designer
Released
by kikozl
library
updated today
3.4MB
thumb_down_alt0 favorite6 library_books0
homeDetailsnewspaperNewsreviewsReview
Sbox UI Designer
News
SUI Designer Roadmap for s&box
SUI Designer Roadmap for s&box
calendar_today 5/14/2026 people KiKoZl chat_bubble 0 visibility 55

SUI Designer Roadmap

By 
KiKoZl
SUI Designer shipped its first public version a few days ago, and the response was way warmer than I expected.

I started this as a tool to solve a problem I personally felt while learning s&box: UI is powerful, but the workflow is very code-first. Coming from Unreal / UEFN, I immediately missed having something closer to UMG or Widget Blueprint  a place where you can build layout visually, test quickly, and still keep control over the final code.

The first release proved that the idea works.

Now the goal is to turn SUI Designer into a serious visual UI workflow for s&box.
2

Why SUI exists

By 
KiKoZl
Razor is powerful. SCSS is flexible. The s&box UI system gives developers a lot of control.

But when you are trying to build actual game UI, control is only one part of the problem.

You also need speed.

You need to move panels around, test proportions, align elements, experiment with anchors, build HUDs, create inventory screens, tweak buttons, adjust modals, and quickly see how everything feels in-game.

Doing all of that purely by hand can be intimidating, especially for people coming from visual workflows like Unreal UMG, Unity uGUI, Roblox tools, or even Figma.

That is the gap SUI Designer is trying to fill.

The goal is not to hide Razor.

The goal is to give s&box a visual authoring layer that still outputs real Razor and SCSS.

1

What shipped in the first release

By 
KiKoZl
The first release focused on visual layout.

You can create a native .sui asset, double-click it, and open a visual editor inside s&box.

The current version includes:

  • visual canvas editing
  • element palette
  • hierarchy panel
  • details inspector
  • drag, resize and edit workflow
  • 16 UI element types
  • anchor presets
  • pivot offset
  • Flexbox controls
  • text sizing modes
  • custom color picker
  • multi-select
  • alignment tools
  • snap-to-grid
  • undo / redo
  • Razor generation
  • SCSS generation
  • .User.scss sidecar files
  • one-click Test in Play
  • sample UI files
  • documentation

The most important part is the output.

SUI does not generate a black box.

It generates real .razorand .razor.scss files that land in your project and can still be edited manually.

That matters because I do not want this tool to trap developers inside a custom runtime system. I want it to speed up the boring parts of UI authoring while still letting people take control when they need it.

1

Patch fixes

By 
KiKoZl

The first updates v1.0.1 after release are focused on feedback.


Small issues are already being addressed, and I want to keep those patches frequent and focused.

Current patch priorities include:

  • inline rename polish
  • anchor resize behavior clarity
  • runtime preview fixes
  • naming conflict validation
  • generated Razor edge cases
  • community-reported bugs

Tools like this live or die by workflow details.

If renaming feels bad, if a field is annoying to edit, if a generated file is confusing, or if a common action takes too many clicks, that matters.

Before adding too many large features, I want the foundation to feel solid
1

The next big focus

By 
KiKoZl
The first release lets you design UI.

The next major step is making that UI talk to your game.

This is the point where SUI Designer starts moving from a visual layout tool into something closer to a real game UI workflow.

The next focus includes:


  • - variables
  • - bindings
  • - converter chips
  • - reusable composition
  • - ActionGraph integration
  • - input widgets
  • - output modes
  • - infrastructure for larger projects

This is probably the most important step for the future of the tool.

Designing UI visually is useful.

But designing UI that can connect to game state visually is where things get much more powerful

An inventory screen might expose:


Items
SelectedItem
HoveredItem
Gold
Weight
MaxWeight

These variables should support simple types like string, int, float, bool, and Color, but the system is also being designed with more advanced cases in mind, such as textures, enums, component references, and lists.


The generated PanelComponent will expose those values as properties, so gameplay code can stay simple:

Hud.Health = 75;
Hud.Ammo = 30;
Hud.PlayerName = "Kiko";

The UI should react through bindings instead of requiring manual glue code everywhere.


Bindings


Bindings connect UI properties to variables.


For example:

ProgressBar.Value -> HealthPercent
Text.Text -> PlayerName
Panel.Visible -> IsInventoryOpen
Image.Texture -> SelectedItem.Icon

The goal is to make this visual.


Click a bind icon next to a field, choose a variable, pick a binding mode, and move on.


The planned binding modes are:

  •  one-time 
  •  one-way 
  •  one-way-to-source 
  •  two-way 

This matters for interactive UI.


A health bar only needs to read state.


A settings slider needs to read and write.


A search box needs to update a variable as the player types.


A good UI tool should make those patterns easy.


Converter chips


Real UI data rarely matches perfectly.


A common example is health:

Health: int
MaxHealth: int
ProgressBar.Value: float from 0 to 1

Instead of writing the same conversion logic over and over again, SUI should support converter chains.


Example:

Health -> Divide(MaxHealth) -> Clamp01 -> ProgressBar.Value

The planned converter library includes common categories:

  •  math 
  •  range mapping 
  •  type conversion 
  •  logic 
  •  string formatting 
  •  color operations 
  •  collection helpers 

This would make a lot of common UI work faster:

  •  health bars 
  •  ammo counters 
  •  rarity colors 
  •  formatted values 
  •  conditional visibility 
  •  progress percentages 
  •  empty states 
  •  list counts 

For custom cases, the goal is to allow either C# converters or ActionGraph-based converters.


The point is not to avoid code forever.


The point is to avoid writing glue code for obvious UI transformations.


Composition


Composition is one of the biggest parts of the roadmap.


Real UI needs reuse.


You should be able to build an InventorySlot.sui once and reuse it inside:

InventoryScreen.sui
LootBox.sui
CraftingPanel.sui
Hotbar.sui
VendorScreen.sui

The child document can define accepted properties like:

Icon
Count
RarityColor
IsSelected
IsHovered
TooltipData

Then the parent passes values into it.


This makes UI more modular and easier to maintain.


It also opens the door for list rendering.


Instead of manually placing 24 inventory slots, you could eventually bind a list and let SUI instantiate repeated elements.


Conceptually:

ForEach Items -> InventorySlot

That kind of workflow is important for inventories, loot bags, crafting recipes, quest logs, scoreboards, shops, ability lists, and many other game UI patterns.


ActionGraph integration


I want SUI to support both programmer-focused and designer-friendly workflows.


Some people want to write C#.


Some people want to wire simple behavior visually.


Both should be valid.


For events like button clicks, slider changes, toggles, dropdown selection, and custom converters, the planned direction is to support two authoring paths.


Code path


SUI generates a stub in a .partial.cs file.


You implement the logic manually.


This keeps user code outside generated files.


ActionGraph path


SUI exposes an ActionGraph slot that can be wired visually.


This would allow simpler behavior to be authored without opening Visual Studio.


Same .sui document.


Same generated Razor output.


Different logic authoring path.


That flexibility is important if SUI is going to be useful for teams, not only solo programmers.

1

How the community can help

By 
KiKoZl

The best roadmap feedback comes from real use.


If you try SUI Designer, I want to know:

  •  What felt confusing? 
  •  What slowed you down? 
  •  What did you expect to exist? 
  •  What generated code felt wrong? 
  •  What kind of UI are you trying to build? 
  •  What would make the tool useful for your game? 

There are three main places to help:


Bugs


Ideas and feature requests


Show what you built


If you build something with SUI, I genuinely want to see it.


The best features will come from real projects, not just from my assumptions

1

Final thoughts

By 
KiKoZl

SUI Designer started as a personal tool because I wanted a visual UI workflow while learning s&box.


But after the first public release, I think it can become something more useful for the community.


s&box already gives developers a powerful foundation. My goal with SUI is to make UI creation easier to approach, faster to iterate on, and more friendly to different kinds of creators.


Programmers should still own the code.


Designers should still be able to shape the interface visually.


Beginners should have a way to start without being buried in Razor and SCSS on day one.


That is the balance I want to build toward.


Thanks again for the support, feedback, testing, and encouragement so far.


More soon.

1
people
Log in to reply
You can't reply if you're not logged in. That would be crazy.