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

Do you think there's a path where you can pregenerate popular paths of dialogue to avoid LLM inference costs for every player? And possibly pair it with a lightweight local LLM to slightly adapt the responses? While still shelling out to a larger model when users go "off the rails"?

Not the founder, but having run conversational agents at decent scale, I don't think the cost actually matters much early on.

It's almost always better to pay more for the smarter model, than to potentially give a worse player experience.

If they had 1M+ players there would certainly be room to optimize, but starting out you'd certainly spend more trying engineer the model switcher than you would save in token costs.


I agree, trying to save on costs early on is basically betting against things getting better. Not only that but in almost every case people prefer the best model they can get!

Not only that but I think our selling point is rewarding creativity with emergent behavior. I think baked dialogue would turn into traditional game with worse writing pretty quick and then you got a problem. For example, this AI game here does multiple choices with a local model and people seem a bit mild about it.

We could use it to cache popular QA, but in my experience humans are insane and nobody ever says even remotely similar things to robots :)

[1] https://store.steampowered.com/app/2828650/The_Oversight_Bur...


Yep, SAR stands for "specific absorption rate". These sensors are typically used to change how the antennas on the phone transmit (like how much power they use) by detecting whether the phone is held close to your body vs. sitting somewhere like on a table.

Most phones have them.


Like the coulometer they mention. This is a battery discharge sensor, nobody would mention this in the specs. SAR sensor and coulometer are standard by now.


Which leads to a conclusion, either the makers don't know enough to know it's standard (which suggests they aren't well informed enough to make a modern smartphone), or they do know but decided to include it to pad their spec sheet (which suggests disingenuous marketing).


They could just be transparent and know their techy customers are interested in these sorts of things. Possibly, they want to assure customers that their off-brand phone includes such features.


That would also be my reading. I'm the type of nerd who's interested in minute details of his devices. I'm looking for a new phone currently and my spreadsheet includes columns like the UFS version, minimal brightness (as measured by some independent news site), whether it has a barometer, dual-frequency GNSS, etc. It always requires retrieving info via third parties such as https://docs.google.com/spreadsheets/d/1jXtRCoEnnFNWj6_oFlVW... (GPSTest database), https://phyphox.org/sensordb/, the video mode list on gsmarena.com, etc.

I haven't yet found a manufacturer that publishes sufficient detail such that I can fill out all relevant columns from their official spec page. They're never detailed enough so I can only applaud including more details. There will always be fields that aren't relevant to different subgroups of the audience...


> by detecting whether the phone is held close to your body vs. sitting somewhere like on a table

Wow, so it basically measures the material that it's near to! That's cool. I know that microwaves are well-adsorbed by water (such as in bodies), is that how this works, does it piggyback on the 2.4 GHz antenna? Can I read this sensor's output via some Android API or a device file (with root perhaps)?


Is it a product though? So far they've just released all their code as open source (which Dynamicland did not do) and helped people set up their own Folk systems in other cities. I don't think they're selling anything.


Erlang's use in the telecom sphere has primarily been focused on switching, routing, and real time voice processing on the backend. Beyond just handling cellular traffic, many internet switches are written in Erlang too. It's only recently that Erlang has been used for more of the type of code that could run on the frontend. (The niceness of writing Elixir is a big part of that too.)

The primary blocker to running Erlang on mobile has been the lack of portability of the BEAM VM itself, which is why this project is so exciting!


I looked at using this for a client project a few months ago. We use Erlang and Elixir at work, and it's my go-to for anything serious.

Be aware that parts of their stack use a custom license for some components... but a large portion of it is OSS Apache 2.0, which is nice if you can stick to those parts!


Another comment mentions MinecraftForFree.com...

In middle school, in an attempt to get around the school firewall, I copied the HTML code from that website to my own to play Minecraft at school. Since my domain wasn't on the blocklist, it worked! But when my friends started using it to play, even after they hadn't bought the game, I resolved to add a login wall.

I built a backend proxy in PHP that would POST their credentials to the Minecraft API to make sure they had purchased the game. I still think it's funny to think I had no ethical qualms about circumventing the school firewall, but piracy was where I drew the line.


This book is a fantastic introduction to Erlang in very approachable language. It introduces the reader to both language syntax and design decisions that led to Erlang's strengths as a highly reliable programming language for realtime applications.

If you're learning Elixir right now, I can't recommend enough to also learn a bit about Erlang. The OTP and BEAM VM sit underneath both systems, and learning about what's going on under the hood helps a ton when troubleshooting production issues!


Were you at all inspired by the work of Bartosz Ciechanowski? My first thought was that you all might have hired him to do the visuals for this post :)


Bartosz Ciechanowski is incredible at this type of stuff. Sam Rose has some great interactive blogs too. Both have had big hits here on HN.


> OTP in Gleam is what took me the most effort to figure out. The hexdocs cover the basics but that wasn’t enough for me to get the concepts right, especially where they differed from their Erlang counterparts.

This was the biggest thing I noticed as well- core OTP concepts like gen_servers and supervision trees aren't covered in the language tour, the docs, or even the "Gleam for Erlang Users" page... it makes sense that it's missing if it's pre-1.0, but I was very confused when I didn't find anything about it at all.


Came here to comment this as well! TiddlyWiki uses this as it's default storage format.


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

Search: