Hello everybody, I'm here to present a software project I've been working on called
Nobody Who.
This is a structure of the talk.
First I'll give you a brief overview of what nobody who is, what it will do for you.
Then I'll get into the motivation of why nobody who is a good idea, why we actually
need this, and why we built it, how we built it.
Then I'll get into the details of how it works, and how you can use it, some of the
technology choices we made, and then at the end I'll get into some demos, I'll show you
some games that people built with nobody who, because nobody who, what is it?
It is a plugin for goodo, natively compiled written and rust for running local large language
models.
A common misconception that I hear all of the time when I present to nobody who like this is
people are going like, oh, so it'll write the GD script code for you and make the game.
This is not the point.
The point of nobody who is to run the large language models at runtime to provide an enriched
role-playing interactive fiction experience.
It's sort of the core use case, there's lots of different applications of it, but the core
use case is to have richer NPCs, it's 2025, that's not to multiple choice dialogue
in RPGs anymore.
This is sort of what the stack looks like in the middle there, just under my cursor,
so nobody who logo, we depend on LMS CPT, if you work with local LLMs, you're probably
familiar with this library, it's really cool, it goes really fast, and it has uses an open
specification for the language models, you can use all sorts of open weights models, not
just meta-slama.
We do hardware acceleration with Vulcan, so it'll work on your GPU, no matter if it's an
Nvidia or indeed or an IGPU, and if you don't have a GPU it'll go as fast as a camera
on the CPU, which is, in my experience, fast enough, it all works in good though, and
we sort of ship these pre-compiled binaries that are linked into the good though game, and
it's just one big fat binary.
We ship for Linux and Mac and Windows, both on Armin, X86, and we have sort of an experimental
Android build, it's kind of fun.
So why?
Now I'll try and convince you that this is actually a good idea, this is something
that games developers could make their games better with.
First of all, why would you want to use language models in games at all?
And I think my core argument here is that in real-playing games the state of the art is sort
of having these multiple choice dialog trees, and I think they kind of suck.
If I'm being generous, I would say it'd be very useful because you can force a character
into taking specific decisions, but that also takes out a lot of the fun of role play.
A comparison is you can sort of think of if you're playing Baldur's Gate 3, which has
D&D rules versus playing actual D&D, you can be much more creative in actual D&D, because
you could sort of bring more of your self into it, you could bring more role playing
into it.
It's a very, very common experience.
If you've ever played one of these RPGs with multiple choice dialogs, that you reach
a point where you're like, oh, but none of these three options are actually what I want
my character to do.
But if you have free text input or voice, if you want that, then you can sort of say whatever
you want, and the characters in the game will improvise along with you and sort of make things
work.
This is another case if you've ever played Skyrim, you are familiar with this dialogue option,
like it sort of gets very, very repetitive.
What we want is emergent gameplay, so you can role play in a universe for a long time,
and with pre-written dialogue, it takes a lot of time from games writers, and even when
it takes long time from games writers, with AAA projects like this, it still ends up
being sort of repetitive, and it doesn't feel that that immerses, and we want more
immersion in our games.
There's sort of the other thing around, I don't think we should be ever be applying
a lens just for the case of playing a lens, but games are also one of the best places
to apply a lens.
If you're thinking about harmful uses of a lens, it's sort of these things where the
risk of the LLM hallucinating can be very, very bad.
If you're looking at like parola provost for correctional facilities or screening job interviews
have you never want hallucinations, but interactive fiction hallucinations are not that bad.
I think there's actually a case to be made that you a lot of the time do want hallucinations.
I'm thinking of like, if I walk up to a character, the standing on the court of the street,
and then I say, what did you have for breakfast, right?
The character didn't have breakfast, and probably was standing on the court of the street
the whole time, but a sort of willing improvisational partner will say, oh, I should
yes, and then I should go over breakfast, I had big kinetics, right?
So we actually, actually, a lot of the time do want it to just go along with whatever
you're presenting.
Another case for why games are a good application of the lens is that machines that
are built for running video games have graphics cards.
This is exactly the kind of hardware you want if you want to run local elements in the
fast.
So when looking at like, oh, what's the compromise of local elements or the machines
good enough?
The machines that are good enough for the machines that are built for running video games.
So why do we want to do it local?
A big one is it fits really well with the current market of game development.
If you're sort of looking at how do games developers make money, what they do is they put
their game on Steam, you pay 10 euros, you get the game, and you as a consumer sort of
expect for this one-time payment to keep playing the game.
If you want to be able to play the game in a year or in 10 years, and if you're relying on
sort of the easy thing to do, which is to use like GBT4 and the OpenAI, it's to PAPI,
it's very quickly get something going, but you'll end up being paying for usage,
and this doesn't work that well.
The games that do this, they typically do it by keeping the product sales business model,
but then imposing a usage limit.
And then you sort of, the game just shuts down after you're playing it for five hours or something like this,
because the game developers can only afford processing this many tokens for one sale.
And that sucks. I want to be able to buy a game and then be able to keep running it.
There's a privacy aspect. If I'm a role-playing, I don't always want somebody to pick in, right?
This is a thing that's familiar to a pen and paper, a bunch of dragons players, right?
You're very, there's a lot of trust building in order to be able to improvise with other people.
So it can be uncomfortable this idea of other people peaking on your conversations.
Offline capabilities, just a great feature. When I go on the airplane home from Boston,
I want to be able to take out my steam deck and play a few games.
I can't play the games that require an online API.
So this is a cool new feature that you only can get with the alarms if you're doing local alarms.
There's reliability. If you're depending on an external API to run your game,
then that API can change. It's sort of a bunch of software that's out of your control.
If you look at the history of OpenAI's or OpenAI's APIs,
they've sort of changed how the models respond over time.
So there's something that the model might want to play along with one week.
Could in the next week it could just go like, oh, as an AI assistant, I cannot.
And you don't want this. You want things to keep working in the same way as they did when you shipped your game.
This one, I think, is really the big and important one.
Games are art, games are culture. We want to be able to preserve this for future generations.
Games are a cable. There's people working with games are a cable professionally,
and they have a really, really hard time making things running or keeping things running.
Players Rocket League will notice that they've dedicated Linux support a few years ago,
and then like, oh, this game that I bought, it doesn't even run on my computer anymore.
Well, it will, but I can't play with my friends because it requires a server for online play.
So that kind of sucks. But with local elements, we can sort of make the type of game that I can
put on my laptop with my laptop and a vacuum chamber and pull it out a hundred years later,
and it'll still work. So I think that's cool.
Okay, so how are we building this? I'll get back to this slide that we saw before.
This is Lama CBP with Vulcan Acceleration, so we get good hardware support and runs fast.
You'll sort of notice, if you know Codell, well, you'll notice that's a C++ project,
and Lama CBP is a C++ project from home, but then we wedged some rust in there.
That sort of gives us a lot more confidence in writing correct code and it runs fast like C++ does.
Another thing that sort of sticks us out a little bit in the ecosystem is that
looking upwards in the stack and downwards in the stack, and everything is.
It might see lessons. We cover left license, nobody who.
For reasons I don't have to explain to this obvious.
I think that we notice a lot of the time with new people picking up this project is that they
are going like, oh, copy left license, that's scary because I want to make a proprietary game.
So we have to be sort of very explicit in the read me saying like, you can link into this
copy left dependency, you just can't make proprietary forps. It's not something that the
game dev communities totally privy to.
Yeah, so because of we're using Lama CBP, Lama CBP exposes or increments an open
specification for the model files, which means that we can use lots of different models.
Whenever a new fancy model comes out very quickly, there's a GDUF, which is a file format,
a quantization available for it, and you can sort of just pull these down from the internet.
So we don't ship a specific model. We're expected developers to sort of figure out what model
suits their needs. So if you want to just run the state-of-the-art game out or deep-seek models,
that's fine. If you want to run something that's trained on a specific data set or doesn't come
out of big tech and Silicon Valley for some reason, then you can go and use the
sell-and-mental models from Barcelona University or the Luther AI stuff for whatever you want.
So we don't have a strong opinion on what the open weights model should look like and sort of just
use any model that's in this format or fine-tune your own thing if you want to. Let's get into
the code. We expose them very, very simple API and look sort of like this. I'll just go through
all of it. We first configure, like set the model, this is the file of GDUF, and you select
them from the last slide. There's a prompt, says you're an evil wizard, you always curse whoever,
then you call say, which is the user saying something to the character, and then it'll sort of
in that thread in the background generator response, and if you're familiar with GDUF idioms,
you'll know about signals, and which is sort of like a pub sub-tech thing you can
await response. You can also wait for the tokens as they come out when at a time, which makes
a much better experience. We'll see this in the next couple of demos. We also support embeddings
by the bar. I don't only have three minutes, so I'll talk too much about this. We support all
of the sample methods that allow us to be personalized, so you can do what you need to in terms
of controlling the model. If you ever want to penalize some tokens, compared to others, if you
want to greedy or a mere step-sign for them in P, whatever we can do all of this. This slide is too
early. Let's see some games. This game was made as a demo by a friend of mine. I like to think
of it. It's sort of like papers, please, in reverse. You're suspect of a crime. You're talking
to an interrogator who is sensing you with evidence, and you sort of have to provide convincing
explanations and elevations for each piece of evidence that they're presenting with. This one is
using two different model contexts, one that's sort of prompted to in a structured way using
JSON, assess the viability of your, of your, of your, of your, elevating your explanation. And then
there's another model context using the same model loaded into VRAM, which is doing the role
play of the interrogator. And you can see there's sort of a credibility meter down there. I think
that's really fun. Next one. This one is not a full game. It's a small demo I made to show that
you can have the element direct back to your game code. This is like a potion shopkeeper. I named
her a fubar. You can sort of ask her what potions tell for sale. What about that orange one? What
about the blue one? What does it do? I need a strength potion. What would you recommend? And then
you can also ask her like, okay, sure, let me get the strength potion. And it'll give you
like a pop-up. And this is sort of showing that you can use this to trigger your actual game code.
And then the strength potion disappears from the inventory. You can also do stuff like ask her like,
what do they taste like? Or what do you have for breakfast? And she'll sort of play along.
But this next one was something that somebody made for global game jam last week.
And it's another detective game. This one you play sort of as the detective, you arrive at a
space station that's binding helium 3. And there was an incident recently you have to figure out
what happened. And there's some undertones that like probably the corporate overloads for running the
station are trying to cover stuff up. And there's a bunch of different characters and they all
have different tones of voice and like they have secrets that you can sort of transcess out.
And that's kind of fun. And you can tell all of these demos by the way are running on a laptop,
right? So, and so it doesn't require like insane the gamer rigs or something. This is just a
framework 16. And the tokens come up reasonably fast. Who, one minute? It's good because I think
of one more demo. This one is sort of a dungeon crawler. I really like the, well I really like the
aesthetics of this game, but I really like the ambitions of this guy. Because there are some projects
that are like LLM power dungeon crawlers. But a lot of them work like collaborative storytelling
exercises. You can sort of go with them. Then I pull out my two double flame swords. And to
capitate tenogers in the game, we're just going to make sure you do another old debt. This one's
a bit more intelligent and works like an actual game. Like the power of your sword will assess the
probability if you actually feeling a certain number of damage. And you could still be creative,
like a pan in the, in the indecession and saying, okay, I use my shield to bash the barrel and make
it find the direction of the skeleton. And then it like SSO is absurd, false snow. This is actually
a barrel in the room. So it actually works like a real game, but you get to bring a lot of
your own creativity into it. That's it, I guess. Yes, you're out of time. Thank you, links.
Is Daniel around on next speaker?