Hacker Newsnew | past | comments | ask | show | jobs | submit | closedl00p's commentslogin

Thanks for sharing! I found an amusing math bug in the basic calculator:

0 + 0.00000001 gives 1e-8 (I see you’re displaying in scientific notation, hmm— I wonder how you’re storing it internally…)

Then multiplying that by 5 gives… -39.

Somehow 1e-8 * 5 is being parsed as 1 + (-8 * 5)?


Hi, nice snappy interface (even after making the HN front page...) and I like the gentle highlighting of possible moves for a piece.

In two games against the bot I _think_ I had the luck to run into a corner case bug with the rules engine: in the position shown in this screenshot https://ibb.co/dQ3HsM4 I'd rolled a 4-6, but the UI would not let me move my piece on 9 four spaces to hit the opponent on 5 -- the UI only wanted to let me move that piece six spaces.

I can imagine how this bug could happen-- all my pieces except this one are in my inner table, so it looks like my piece on 9 is the only piece that can legally use the rolled six, and you're required to fully use your roll if possible... except in this particular case, once I move that piece four spots, I'd be fully in my inner table and could use the six to bear off a piece.

[sidenote: I realize I don't know the best 2024 way to host a temporary image for posting on a text-only forum like HN... but imgbb looked reasonable...]


Thanks for reporting this and including a screenshot. I appreciate it.

I've just resolved this on the server and in the web client (now v1.3.5p1, displayed at the lower right when the game loads).


While we're on the topic of ancient link-based sharing websites, here's a pastebin of the Typescript code I wrote years ago that I just dug up to see if it'd handle this case. It does! It uses an actually-pretty-fast backtracking implementation to check for valid moves - validating Backgammon moves is a harder problem than you'd think, especially doing so quickly enough to effectively run monte tree search with. Even with all the thought I've put into it, I still don't have a quick explanation I can give a human trying to learn that game what the valid moves are, especially in the endgame and with blocked moves.

https://pastebin.com/QeSdnQpM

And the test cases I have for it: https://pastebin.com/vmMEjSMz


Interesting project, thanks!

Quick reactions from trying it out: One of my questions about this is the same as my question about "low-code" tools-- how they enable novices to debug errors or edge cases in the generated code.

Example: I played the tower defense style game example you linked in the comments for a few minutes, and found a bug (or perhaps a gameplay edge case I'd want to treat differently: a second bullet gets fired in the direction of an enemy that just died, wasting a shot). I cloned the project and poked around in the code to try to fix that, though without knowing the language and generated code that wasn't trivial.

Next, I thought-- I'll use the chat interface to explain this bug / edge case and ask for a suggestion. I was impressed, the conceptual explanation of how you might fix this seemed reasonable! However, the suggested generated code seemed incomplete and was full of "// ... rest of the code ..." comments, and when I clicked "Apply suggestions" that seemed to overwrite the existing program, so the application no longer runs (chunks of the program are just "// ... rest of the code..." lines). And I didn't see an obvious way to undo or get back to the previous code.

Anyway, that's feedback on my initial experience, I could see this being useful to generate the skeleton of a program or as an interface to get how-to suggestions that I'd then more carefully implement/integrate myself.


I appreciate the candid feedback!

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.


Your reaction was almost exactly the same as mine. The very first thing that made me realize that Rosebud was a big deal was how consistently accurate the AI was when it came to figuring out what was wrong with a project.

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.


This comment says the exact opposite of what you're praising Rosebud for. The debugging not only wasn't helpful, it actively made the game unworkable and unrecoverable.


Thanks for the great feedback! There are currently a couple of ways to address this. You can simply ask in the chat, for example, by saying, 'please provide the code for the full program.' Or, you can ask a specific question with instructions, like 'how to change the color of the asset.' This approach will prompt the provision of the correct code snippet and detailed action steps, including where and how to implement it in the code tab. Ultimately, our goal is to streamline this process to make the experience smoother for users


Thanks for trying it! One of the more impressive things we have seen so far is how some beta testers with no coding background were able to get deep into debugging by having our AI explain what the issues are and how to fix them. However, as you pointed out, it does not reliably provide working code all the time for the user to apply directly. This is something we are aware of and are trying to make the generated code better and more reliably provide working solutions with no formatting errors. It is basically quite a hard (and thus fun technical) problem we are solving.


I agree about the rough taste in general. I've made it a habit to try as many different canned coffees as I can when visiting Japan (and every "black" coffee I saw), and looking back at my notes, I felt like "Premium BOSS Black" was quite good, and "UCC Black New Grounds Fruity Blend" and "UCC Black Wholly Brewed" were both decent, compared to most of the other black coffees.


I used to buy liters of Drink It Black (unsweetened black coffee) or Tasty Club (sweetened black coffee) which I chugged on the 203 bus that I took to Japanese school. Good times!


These are outdoor roadside vending machines, sometimes out in the middle of nowhere (or at least, not near any convenience stores). Driving down a quiet rural road on a cold morning and stopping for a hot coffee in a can is a nice break.


Anecdotally, a few people I know who moved to New England (where it can get down to -20F at night, though rarely) have installed heat pumps and been happy with the performance through the past few winters, though I don't know which models they bought (one mentioned the Mitsubishi H2i).

I believe all of them also have a woodstove for backup heat and general coziness, but no separate fossil fuel backup.


Yeah, we live in northern New England; (air source) heat pump + wood stove is getting to be a very popular combination around here.


do you live in a well insulated (net-zero or passive home)?


Agreed-- as someone who is also later-career and personally enjoys WFH, I realize in retrospect that I learned a lot (both technically and in terms of how to be productive in a larger team environment) from less-structured in-person collaboration with more senior peers and mentors. And I feel that really set me up for growth and future success / leadership.

Some of that is possible remotely, but I don't think it would have been the same as there was a lot of on and off collaboration and chatting over the course of a month sitting side by side. Especially with someone senior who worked on a parallel team where we might not have talked as much if we'd only been meeting through meetings.

And as someone who's managed teams during the pandemic, I'll say that I saw WFH be especially challenging for some earlier-career folks and new hires, who I've seen trying to learn everything "on their own" and feeling a bit adrift. I went out of my way to have more 1:1 check-ins with them, set them up with other senior peers for regular video "coffee chats" and mentorship opportunities, and so on. But it was challenging.

I've also seen Slack be a powerful force for new or junior people asking questions about how to use a tool or the history of some decision (once we built a culture of "it's fine to just ask questions to this channel, no question is dumb"), especially across teams or offices, so async digital collaboration is powerful as well, of course.


It's hard for me to imagine my first job in tech as a PM being remote. Modest apartment, not knowing people in the area, and general lack of spontaneous contact. OK, the communication tools were much more limiting and the social/cultural norms were different too. (Actually had email but way too many sales reps and SEs liked to call anyway to ask some question that could (sometimes) be resolved in a one minute email.)

So maybe it would be just different. But hard for me to wrap my head around.


I'm more on the introversion end of the spectrum, and as someone who's been both an engineer and a manager I'm a big believer in big unbroken chunks of silence and concentration for focused engineering ("makers vs managers schedule", etc).

And... I would say a majority of the major project setbacks / failures I've seen over my career have not been due to engineering failures, but have been due to either:

1) Misalignment or lack of agility about priorities / goals and inter-team dependencies. Situations where people and teams put their heads down and do a lot of engineering... that ends up not being the right engineering.

2) Interpersonal conflicts that simmer, escalate, and aren't defused early enough and harm collaboration.

In theory, both of these could be addressed well in fully remote environments, with careful product, product, and people management.

In practice, I have personally seen it be much easier to head these problems off in environments where people are having regular informal face-to-face and non-transactional interactions. The lunch / coffee break / hallway-chat-after-the-meeting sort of discussions. Even being in separate buildings across a large tech campus has been a barrier to this.

Again, I would be personally happy to WFH, but I do feel I've multiple times seen significant project and company-level benefits from shared workspace interaction, so there are tradeoffs.


I recently saw a retro (PICO-8) demake of the 1992 game: https://liquidream.itch.io/undune2


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: