Launch HN: Rosebud (YC S19) – Turn game descriptions into browser games

We're utilizing AI Agents on two fronts. One is to generate actual games, which is how the user-created game you're playing there was made. And our next step is to enable creators to leverage those agents inside the game itself. When we arrive at that point the scenario you're showing above will be much more dynamic.

I quickly escalated the tavern starting area by convincing it not only were we in Faerûn of the Forgotten Realms. I then managed to get Elminster summoned and initiated a duel. And to do that I managed to convince it that the only reason Elminster was willing to accept was because I was actually an ancient sorcerer-king of Netheril.

Unfortunately for this AI fantasy world, this meant I possessed access to epic level spells like Tolodine's Killing Wind which I successfully cast. At that point Elminster expressed grave disappointment and noped out of the area.

One of our beta-testers created a variant of a tower defense game using no code! It's not snapped to a grid, but definitely shows the power of what's possible on the platform :)

This kind of "do whatever you want" system is what we're hoping will open an exciting design space over time, but it definitely adds a lot of complexity and opportunity for things to go wrong :joy:

We're using our own custom AI Agents to generate the games and what we'll do next is expose them for the games to leverage too. At that point you should be able to have the game self-generate based on rules.

For example, there are different patterns if you want a simulation that has time as a factor, versus a classic choice-based VN.

A lot of people building games struggle with where to start for their specific idea; it's a lot of research and if you make some wrong assumptions, you may have a really hard time executing on your game. Also, a lot of creative people/tinkerers aren't familiar with software design patterns generally.

Would this export the code so someone could edit it manually after the initial creation?

Sounds like you're conflating things. Minecraft is a game but Roblox is a platform for building games and I don't think it's any less versatile than Dreams.

In the same vein, Rosebud AI initially gives more people the opportunity to turn their ideas into games. Then, through rapid iteration, both users and we grow together, continuously improving the quality of the games

So a new easier way to create games won't really make things meaningfully worse, I don't think. Especially because the quality bar will be quite low, it's not really going to crowd out the 'good stuff' that people are generally looking for. The store shelves (so to speak) are already so crowded that they are no longer how people find good games.

I think some confusion may be arising from just going to rosebud.ai and seeing the demo video. Instead go to https://play.rosebud.ai/home to make games and play the games other people already made to test it out! Love to hear your comments about the development experience there!

You are right that there is a developer tool angle here, but I think what's interesting to experiment with respect to the business model is whether developers want to be charged first by using the tool (like unity) versus only when they are successful (like unreal). Roblox is able to collect rent because they help the developers build an audience. What we have to show is that our platform can also help developers build an audience to justify collecting rent.

Annoying that the text box doesn't scroll as the chat overflows the visible area, I had to keep helping it along. Especially given how chatty YCombinator the character is, it seems worth fixing. Question is how easy was it to find the relevant piece of the generated code's whereabouts.

Our aim is to make development on Rosebud as easy as possible, which means we are handling various external integrations that are being used by the platform. With that said, some devs may want the flexibility to change what models are used, including switching out internal models we developed with various external ones. If that is true, we’d want to support devs providing their own keys, but only for added flexibility, not as a default. Put it simply, if you don't want to be forced to provide your own keys, we got you covered.

Right now we will try our best not to charge developers for developing on Rosebud. So we will try to optimize on our backend different ways to control costs. With that said, if we have to create some premium tier because the AI inference gets too high to support, we will likely provide options to reduce inference costs in various ways (such as running smaller models for different interactive generative features of a game).

We’d want to provide as much support as possible so that our devs are successful. So if something is not working, let us know! Our devs succeeding is a necessary pre-requisite for our platform succeeding.

As of right now you still need to be familiar with the code that it gives you. But personally even when I work on a game I resolve bugs by chatting with the AI about it. We're also trying to surface any kind of actual errors that happen so you can feed it back to the AI. So far I haven't seen a bug I can't fix in this way, but then I've been coding for 20+ years.

As for the "//...rest of the code" stuff, yeah it's my white whale. We're just limited by the context size. We have a bunch of things coming up to separate the code into multiple files and various tricks to squeeze more of the context size. It's a constant battle.

Another thing we're toying with is automatic debugging that lets it go back and forth on bugs until it actually works.

Having a debugging assistant that is that good, in my opinion, alone makes Rosebud a better option than most 2D game development environments for most people.

The issues with the incomplete code get in the way, but the team has already identified them, so they shouldn't be a problem for too much longer.

"I found getting assets into the game a bit tricky. Sometimes it would try updating the code to reference assets that we hadn't created yet. After that I couldn't get it to generate assets for me."

This is an known issue we are trying to solve. But to give more color on why it's been tricky, since we are relying on a chat interface, our agent has properly determine is your ask includes an ask for asset generation, and if so, it has to determine whether an asset exists, and if it does not, whether to generate an asset, after which it needs to determine where to insert it and whether to modify other parts of the code when inserting. For instance, in the character templates, the AI can successfully modify an asset and character's description in one prompt, but sometimes it doesn't correctly interpret the instruction and pulls existing assets from the Phaser JS library. In short, it's quite finicky to get agents in prod to behave reliably 100% of the time. But we are working on it! Have many ideas of how to improve and are experimenting.

"I thought this would be a useful tool for prototyping, but as a programmer I would probably never use this to release a finished product. Maybe it would be better to target this kind of tool for prototyping instead of being able to make a full game that people will want to pay money for." & "I tried making a simple turn-based (american) football game. It's pretty good for getting some boilerplate set up, but sometimes it felt like it would have been easier to modify the code myself at times than try to explain what I wanted modified to the AI."

For users who already know how to develop, we've definitely heard similar validation that this is better for prototyping currently than for final games. I think this stems from the fact that 1) currently we don't have multi-file support and more advanced features like multiplayer yet, which makes it hard to compare with what's achievable by a more advanced game dev. And 2) the chat based approach is not always reliable, so it's frustrating sometimes to get what you want versus coding it up yourself. This is why we are also targeting less technical users, because they don't have many options available to them that can be as flexible as Rosebud. We have been delighted to see what these users create because some of the stuff gets very creative and addictive, even with our current limitations.

"It seems like whenever I did try to modify the code by hand, my changes would get wiped out by the next iteration generated by the AI. Maybe it was referencing the old code?"

This is a bug. If you don't mind sharing in the feedback channel specific cases when it does this, that would be super helpful. We've been fixing aspects of this bug over the last few week.

"Sometimes the AI would get stuck on something (e.g. generating an asset), or it would make a mistake. In that case I couldn't figure out a way to "go back" to a previous iteration of the game."

We have a history feature we are shipping in stages. Right now you can only regenerate, but we want to let users go back to different states of their game. Many users have wanted this feature and we just have to make some choices about what gets saved in the history (all llm changes or also manual, ... etc).

"At one point I tried to get the AI to make a change, which it did, but the code it generated had a large portion of the original code based removed and replaced with something like `// The rest of your code here.` which obviously broke the game."

This stems from a context length issue and is definitely annoying. We also have plans to implement diffs and other solutions that should let users run into this issue less.