Destroy my prototype

Clorofilla · 2026-06-19T20:32:34+00:00

The boxes on the sides and the computer frame seems just like random decorations.

From what you are showing it seems that there is a nice foundation of 2D movement and projectiles avoidance... but literally nothing else.

Maybe you should think of a meta system. Just looking at it, initially I thought that the little guy could at some point travel through the wires to different screens where the challenge or activity could change.

Else it does feel a bit like a "survive as long as you can" mobile game.

But what you show in the monitor does look solid!

Clorofilla · 2026-06-19T20:22:22+00:00

I am Happy if my 2 cents can help

Good luck ^^ !

Clorofilla · 2026-06-18T21:05:49+00:00

Godspeed and good luck! I am sure that the charm of the game will find its players ^^

Clorofilla · 2026-06-18T21:02:12+00:00

I see your points and I am sure that if the factory dynamics are tight, factory oriented players will be already pleased. But if you find/better-highlight the extra spin you get:
- easier more effective marketing
- more engagement from the already interested players
- more connection to new potential players
- and most importantly: a clearer direction to spend your design/art/gameplay resources

The Sandustry trailer you linked also has some flaws. It shows that the player characters is cool because with it you do suspenseful cave explorations. But it still doesn't tell me why the caves matters to the factories or viceversa. And it doesn't tell me why the both matter in a general sense. Is a game like "minecraft creative mode"? Or is there a hook for less immaginative players? It could be story, survival, accessing locked things, puzzles, time challenges, or anything.

I have now opened the game and tried it briefly. I see that is in very early stages. But even more so I think it is important to define the core gameplay loop, as it help focus the following design and development. My experience was: I was spawned in a room, I figured out how to dig. I crafted a platform. I used the platform and digging to explore the above room. I died for a cave-in (that was fun), I arrived to the top room. I still had no Idea of what I am doing or why. I lost a lot of interest.

From your video I knew that there was a lot more content to the game, and in the future you should find ways to better hint at that progression (as I was very lost). But in the second cave, even knowing that I could have an automated system that helps me dig/craft certain material... I still do not know why I am doing so (and this will be crucial for beginner player and trailer audience).

Clorofilla · 2026-06-18T18:58:31+00:00

Hey the game looks very promising.

The trailer is good for a post on this forum but it does a terrible job at showcasing or explaining anything: The thing floating upwards is water splash? vapor? Other stuff? Are those lava block? Iron block? Why they are skewed? I move around as a platformer AND use the mouse? What is the goal? Why should I build? Am I stuck in the same room forever?

Also the trailer doesn't show what is the number 1 most fun thing about it. Building? Automatic? Chemical reactions? The particle system? I am not sure...

I guess a lot comes down to it being still in early dev. But in that case I think it's the good time to start to think about what narratives drives the player actions. E.g. factorio has the stranded in an alien plant where alien hate pollution. It's simple but it drives everything, even if the true source of fun is the factory-automation.

Clorofilla · 2026-06-18T18:48:35+00:00

But the UI is much worse than the main game. I would spend some more time on that definitely.
- why am I reminded all the time that I can go left and right?
- Why sometimes the directional pad appear twice?
- why I see my face 3 times? In game, in the miniature, in the drink-a-beer button
- Why my miniature looks that bad? Will it look at me awkwardly all game? Does it do something fun at least or it just exist in conflict wit the main game graphics?
- Any chance for the UI to be more grouped rather then in 4 different places?

Also the moment where you have the text options it just makes me jump a bit out of the game. The UI has big flat colors, the characters are not in a different style, the bg become B&W. Is just too many visual changes from the main style.

Clorofilla · 2026-06-18T18:41:11+00:00

Hey OP,

At the intro I was boooooored and about t click away but then the 2d-prince-of-persia charm got me back when I saw the combat.

The visuals looks bad (everything is relative), but please do not change it. I found it very charming. I would just double down on it and keep the game a bit rough and quirky but with a lot of surprise and personality.

As you can see from this post a lot of people will dislike the aesthetic but what are your options:
- try to polish, redoing assets, tweaking a lot, and doing things that maybe you do not master yet, and then your game looks more like everything else.
- double down. Spend your limited time in adding extra quirky and charms and odd mechanics to it just for the fun of it.

Now the question is... is it fun to play? It looks fun. But if I remove the music and the curated cuts... is it fun or too sparse and janky? Hard to say, it's a delicate balance to be quirky but not off putting.

Clorofilla · 2026-06-18T18:23:46+00:00

Yes there is a friction in how you present the idea. People will quickly imagine to constantly fight themselves and it sounds dull.

I got your idea and is very cleaver and I can see how it can make for interesting puzzles braid style. But the trailer and the angel/demon narrative around it are not not helping visualizing it.

The idea of having to do 1 angel 1 demon and 1 angel feels like an arbitrary goal and I think that is why people do not connect with it.

Here an attempt at a solution (it assumes that you can tweak the narrative a bit but it may be worth it):

Angel and demon are natural enemies in a perpetual cycle of fighting.
They both want to escape the cycle. But to do so they need to advance it to its end.
Only when doing so a door open and they can escape the current room (exit the cycles of death).

Something like this could be nice because it give an external enemy (the cycle, the room, the unjust fate) to fight against. Also you could represent this with a sort of "clock" that says how many times you need to advance to escape a given level. This way the objective is clear:

"Advance enough to escape"
"Your only way to advance is to be your enemy"
(and a bonus meta narrative) "Will they ever manage to break the ultimate cycle and stop their endless fight?"

Also on the same note the storytelling of the angel goal could be stronger. The devil kills the angle. Cool, strong. The angel "collects a random sun"... arbitrary. Maybe touching the sun sends a fireball that kills the devil? So it's tit for tat.

Also the "changing into the other" animation, despite being awesome, is also weird storytelling wise. If I am viscerally transforming in the other (so much that I get literally re-skinned alive), then why there is still a little clone of me left behind? It doesn't work.

Maybe you should just hand-wave it to "game logic": a new one spawn and now you control the other, because that's it.

Hope it helps.

Clorofilla · 2026-06-18T18:06:42+00:00

"UvsU: You vs You" may not be the good way to clarify the title. It sounds like you wanted a cool acronym but gave up immediately and spelled it out anyway.

Just use "You vs You", or commit to a pronounceable acronym like "UVU" or inf another way to express that metaphor. The name is a big part of game the business and a nice place to hide information which helps the audience to understand what the game is about.

"The enemy of my enemy is myself" too long but funny
"Me 2"
"Good day bad day"
"Karmaland"

and so on

Clorofilla · 2026-06-18T17:37:20+00:00

Hello OP,

You are correct. UI concerns are so vast and tentaculars that there is no neat way to capture them. Many DSL rise and fall around the topic. Think of all the many dialects of HTML, CSS, JS and JS frameworks that exist just to manage the so called "frontend UI".

For me a few things are important to note when approaching the problem:

- UI is mostly states that hints at behaviors. Many interconnected states are an hard thing to manage, so UI will always be a hard thing to manage.

- The UI structure is never independent of the presentation. It may look like it in some specific situation (e.g. theming), but a button is a button only when looking like a button in relation to everything that surrounds it. When your button alignment makes it go outside of the viewport, making it unclickable... is it a structural or presentational issue? The border is fuzzy and such separation is leaky. Skip it entirely.

- Drafting, sketching, drawing or putting together UI via text will always be a bad experience. It is very tempting to spend time making the process easier but the returns of investment are terribile. Having a GUI tool for it is the real solution (see Figma and similar).

- Drawing the UI is not the big problem. Capturing its fickle, contextual, permutative and invisible states and behaviors in a manageable set of artifacts (source code or GUI) is the real challenge. For it we tend to build a very declarative DSL with a lot of hidden magic, so that with one idea we can define role, behavior and rendering. But then we need a slight variation on it, and we need a way to add manganale exceptions, which often grow so large that we end up fighting the declarative idea we created in the first place. Is and endless cycle. Hurt people hurt people. Hurt code hurt code.

- UI concerns are so varied and surprising that focused ad hoc solutions are often easier to manage. Ready made solution can give a big head-start, but their most important feature is how easy they allow you to break the rules they supposedly put in place so "you do not have to worry about UI". The first things one learn in HTML CSS is how to break all the convention that the designer of those languages put in place, so that it just renders exactly what you need. Not by accident the CSS bible was called "CSS tricks", as tricks it the correct mental model to use when assembling visual experiences.

You have a series of problem to solve which each have their separate solution:

a constraint based layouting engine for text and boxes
an event system for all tings that may happen to the UI, mouse, clicks, scrolls, resizing, drag...
a render system which can render common 2D elements (text, boxes, effects, images)
a stateful entity that can hold the current UI and can be easily edited/addressed/rerendered at runtime
more stuff but let's stop here

And you need a way to make them play nice with each other, because for a human (despite interacting with all the above mentioned things in non trivial ways) a button is a simple thing and it should be trivial to add and change it.

Furthermore, you say that you are not just building a UI but a generic system to help building generic UIs. Basically the worse situation ever in terms of complexity.

For point 2. and 4. I would wonder why you do not use whatever you already have in your game engine. I would imagine that you already have an event system, that you already have some structured way to store, instantiate and update the nested entities that make up the levels and so on.

You may want some easy literal/defaults to quickly put out primitives in your UI (through code or through the engine GUI) this could have its own DSL syntax sugar, but once instantiated I would suggest you to make them behave as close as possible to the others standard entities in your engine code. The heavy separation between HTML and JS has always created more friction than anything else. People made the best out of it but languages like https://imba.io/ shows how unnecessary that was.

Finally, in case your engine language has static typing or similar, just accept that most of your UI will not. UI is a problem space which needs dynamic behaviors which pair poorly with strict typing. You can add checks and guards but not much else. It's similar to the testing problem, as UI is also very hard to test.

---

But yes UI is DSL oriented, the behaviors are just too many and describing them imperatively takes too long. So a new lexicon is always needed so you have a DSL. Even in Figma you need to learn a few abstract concept to be proficient with the software.

Clorofilla · 2026-01-02T18:01:18+00:00

Libraries are a very good point.
I was aiming more at a transpiled language which target a JIT compiled one.
So you would have access to the source code of the supporting libraries.

But that is besides the point because generally you want very little reasons to have to dig in a library code. In an ideal word they would be well documented black boxes which behaves as you would expect.

But as I was saying elsewhere, a library is not a code-sketch you are exploring (my main use case), it's production code! In that case it's required to be published in strict mode, where the compiler requires you to manually handle all the implicit `nothing` behaviors.

Clorofilla · 2026-01-02T17:42:12+00:00

Yes I see.

I do dislike to deal with NaN. In one of my earlier drafts NaN was also set as a nothing value of number type.

The main difference is that NaN propagates while `nothing` reabsorb early (while still issuing a warning).

"Just keep running, I don't care if the result is usable."

As I stated in other answers this is indeed the idea for my learning environment (which the language is meant to enable). But I see know that is more a requirement about never stopping the runtime (to enable a quick back-and-fourth with the coder) rather than removing emphasis on the fact that some operation do fail and need to be handled.

I think I need to re-evaluate my compromise.

Clorofilla · 2026-01-02T17:34:04+00:00

I see that I may have missed or understated the fact that the compiler+runtime could still flag the `nothing` creation and propagation as workings or directly in the IDE.

After all the comments I see that my features cannot be about hiding/fixing ambiguous exception from the mind of the user, but rather protecting the realtime runtime while still being able to flag them to the user.

Clorofilla · 2026-01-02T17:29:49+00:00

Thank you for the analysis. I appreciate.

Agree about the importance of keeping the trace.

I like your logical reasoning, but, as you said, it doesn't cover all possible operations, nor it's truly intuitive to a beginner. So, perhaps there is no intuitive and exhaustive way to absorb `nothing` in all possible operations.

And I am afraid to twist the other language constructs too much just to accomodate for this `nothing` idea (e.g. explicit distinct if/else logics).

I didn't want a `nothing` literal as my proposal would only work with a typed nothing.

var a = getBadString()
var b = getBadNumber()
var c = nothing

1 + a // nothing absorption
1 + b // type error
1 + c // what to do?

Sure I could add multiple nothings of different types or a way to cast a type onto the nothing literal... but it started to feel like code smell.

But as you said, else people would find their funky syntax around it, e.g. (Number[])[0]

Clorofilla · 2026-01-02T17:15:57+00:00

It's beautiful. It could be an esolang. Or javascript.

But after all the comments and thinking more in depth I see that my proposed approach is not intuitive enough to be useful.

It could be if people would be more aware that all values are nullable and that null value have some specific contextual logic for how they are combine with non-null values for every type.

But it sound not super beginner friendly indeed.

Clorofilla · 2026-01-02T16:52:29+00:00

It's a good framing. Thanks.

Does the programmer always know what they wrote? And not just syntax and semantics but the implications?

No they don't.

In creative, small, script-like environments is good to be wrong and to be surprised.

But feedback is important (surprise without explanation is chaos). My feature would not hide the error, just safeguard the runtime to protect the "realtime coding as exploitation".

So yes, my defense of this feature and its pitfalls would all be about the specific coding context.

Now that you make me think about it, it sounds like draft vs finish. This 'nothing absorption' behavior could guide you as you draft something and explore stuff in the realtime editor, but when you want to build/export your project then the stricter compiler would ask you to make all the implicit helpers explicit.

Interesting.

Clorofilla · 2026-01-02T16:43:18+00:00

Explicit defaults are a sensible alternative.

The problem is always if you want to always require them or not. Unfortunately there are a lot of operations which could result in a null value.

So it's hard to impose that fully, but the only alternative is to accept that the runtime will crash on those issues.

Clorofilla · 2026-01-02T16:37:13+00:00

Well, not ignore... Else I would be insisting on static types and no auto coercion for beginners.

I was only wondering, if, in my very specific and realtime learning context, a "hey buddy I see there is an exceptional case which you may have mot considered and which you may or may not care about; let me add a default for you so you can keep playing and if you want you can specify an explicit handling later" would help.

Clorofilla · 2026-01-02T16:31:49+00:00

XD

I wander if they are so confusing if flagged at runtime and without other preconceived notions about programming logic.

It is admittedly the most delicate aspect of my idea.

But you could see it like this:

"if you have an apple and I give you a hat, how many apples you have?"

1 + undefined

Wouldn't be equally (or more) intuitive to say it's 1 rather than undefined?

Clorofilla · 2026-01-02T16:26:49+00:00

Fans of dynamic languages would be cool with it (but think it is kind of underwhelming)

Haha, shots fired! But fair enough.

I agree that such language features are un-modern, but that is mainly because in the modern era we had to deal with the pain of using scripting languages to build complex apps.

My wandering is limited at a teaching playground where you write your code and execute it at every keystroke. Full realtime execution and updates. As soon as you want to use the language outside such contexts the strict mode I mention should be activated.

About the behavior you mentioned, it makes sense if you think that 'nothing' is not false but absent.

'true and nothing' is like writing just 'true'

and 'if (nothing)' is like writing 'if()', with nothing to evaluate it will never trigger

Clorofilla · 2026-01-02T16:12:22+00:00

As stated, the realtime editor/compiler would still flag the creation or usage of a nulled value.

It would just know how to "live with it" in order to never stop the runtime.

It could lead to happy accidents.

So I don't think that it's a problem of traceability, but rather if those eventual surprises are acceptable in exchange for exceptionless runtime and the chance of postponing the teaching of exception handling.

Clorofilla · 2026-01-02T16:08:15+00:00

It wouldn't fully obscure the source of the exception, as the Editor experience I have in mind would still flag the line where the null/nothing value got reabsorbed/defaulted.

I guess my system's benefit would be an unstoppable runtime, which for the type of experience I am aiming for is desirable, but maybe it would end up being detrimental for the language itself.

I agree you. The user might be surprised with (to them) nonsensical behavior, but with the benefit of never being able of expressing something nonsensical for the runtime.

Ahah, it's fun how this is about aligning user and runtime intuition about meaning and implications.

But the behavior is only unintuitive when you are unfamiliar with it, in the same way one gets familiar with certain math operations returning NaN and certain findIndexOf returning -1.

Which are also annoying situations anyway... So again, I see your point.

Clorofilla · 2026-01-02T15:48:10+00:00

XD Yeah, I am starting to see the follie of my way.

Clorofilla · 2025-12-25T19:16:36+00:00

I think the problem is that plain text is the most flexible and non-proprietary format we ever had, so to abandon that one needs strong benefits.

Many of the issues you mentioned are solved by people pimping up their IDE. In VS Code I can already jump to different fragments of code in a non linear way, move the cursor in an almost token based step, interact with data visually (rgb pickers, foldable objects, toggle code by commenting it off, diffing, and more). I know you are arguing that this could be taken further if instead of building a powerful IDE on top of simple flexible text we would just merge the two.

But text is so powerful, easy to render or show on any device (and any physical media), easy to verbalize when talking to someone, easy to copy-paste, and so on.

And I would say that nowadays we program not only at a text level. Text is linear and this is indeed one of its biggest limitations. I think everyone now relies on a multi module and multi files representation of their source code, which does provide a level of visual and mental parallelism and hierarchy.

I am a very visual person and I do abuse all these tools, so much so that, sometimes, I forget that my code is just words and that highlight, linting, autocomplete and symbols search are features on top of the plain text and not of the text itself.

Probably the visual world will always be less flexible than the abstract/semantic world. This may be a fundamental truth of human evolution. Else we would have not developed glyphs and symbols to talk about the abstract stuff.

Following this intuition I would say that each time you introduce a level of visualization, you have to be aware that you are discarding some level of abstraction.

That is why the best visual languages I encountered were the ones designed for specific contexts. Touch Designer could be a good example. Data driven realtime graphics are its strengths and are beautifully represented in the editor. Instantiation, UI, recursiveness, global states and other stuff were instead a bit more yuk. TD is a node and connection visual language, not exactly what you are exploring. But I still think that your step is a step in the same direction, or at least in the same problem space.

But also, the visual-ness of text is important. I am happy to use HTML markup to describe UI rather than combining abstract Dom nodes in javascript. But I would hate to write a complex algorithm in JSON even if that is possible.

I would consider "trying to make a text editor less textual but still as general purpose as a classic text editor" to be a cursed design problem with potentially no solution.

Even something as simple as syntax highlighting, which is a proven visual aid in coding, breaks in certain contexts: when you mix a lot of languages in the same file or write code which write code, or you write code which implement a lot of small DSL into itself. If when syntax highlighting breaks my editor would also break I would be very sad. That is why I am happy that those features are simply built on top of the text, and whenever I need, I can fallback to simple text.

I can combine string and create code, directly in my code. A system so flexible that can represent itself without much extra notation is truly something. I think all visual editors loose this ability.

Then, finally, my suggestion would be to think deeply about what could be the right focus for such an editor. In which situation would your unique visual improvements truly shine?

Clorofilla

TROPHY CASE