lee/hpr-knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: HPR Knowledge Base MCP Server

Browse Source 
- MCP server with stdio transport for local use
- Search episodes, transcripts, hosts, and series
- 4,511 episodes with metadata and transcripts
- Data loader with in-memory JSON storage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Lee Hanken
2025-10-26 10:54:13 +00:00
commit 7c8efd2228
4494 changed files with 1705541 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

310
hpr_transcripts/hpr2898.txt Normal file
View File

@@ -0,0 +1,310 @@
Episode: 2898
Title: HPR2898: Modeling people in space game
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2898/hpr2898.mp3
Transcribed: 2025-10-24 12:55:44
---
This is HPR Episode 2898 entitled, Modeling People in Space Game, and in part of the series,
Hackel, it is the 30th anniversary show of Tuku Toroto, and is about 22 minutes long,
and Karima Clean Flag.
The summer is, Tuku Toroto talks how they approach Modeling People in Space Game.
This episode of HPR is brought to you by archive.org.
Universal Access to All Knowledge by heading over to archive.org forward slash donate.
Hello, you are listening to the Hackel pop-up radio, and this is to tour the talking about
people, especially, specifically about how the people are modeled in the game I am writing.
This is a pretty long topic.
I will split this into multiple episodes and probably going to return to this again and again
as the game progresses.
This one will be mainly about how data is organized isn't that much of actual coding this episode.
So, there will be lots and lots and lots of people in the game, and some of those will be most
of them to be controlled by the computer and some of those will be controlled by the players.
And the ones that are controlled by the players are avatars.
So, every player always has a one character that they are playing as, and when that character dies,
then it's not the game over for the player, but the player will continue playing as the hero of that character
that they were just playing.
So, in a sense, they are playing as a single character, but as a dynasty, as a plotline that continues over the time.
So, if there's no air here, the player can choose any person to play.
I'm not going to kick them out of the game.
So, there's plenty of data about the people.
They are currently probably the most complicated complex convoluted part of the game.
Most of it is stored in the person table and the person data in the game.
So, there's a simple stuff like name, sex, gender, date of birth, some stats.
I'm probably starting directly from the Crusader Kings II.
There's a diplomat in Maasel, Stewarchs, in Greek, and learning at least currently.
I think this fits better describing a rule than, for example, the 20 stats of strength and wisdom and textarity.
But it might change in the future.
There's a primary title.
This is the, in case the character has domain over multiple places.
For example, if he's a ruler of three planets, then he has a bigger one of those as his primary place.
That place is where his court will be located.
And that also defines what his title will be, or at least his primary title.
So, if you are a ruler of a planet, for example, terra, then you are a traitor of terra.
And if you are a ruler of whole solar system, whether terra is located, then you are a procurator of soul.
And so on. I'm borrowing those from the Romans.
And names, names are actually funny.
And what's reading quite a bit about how people are.
People have been naming people over the course of history.
And there's lots and lots and lots of various ways.
I'm not going to implement all of them at this time.
Probably never going to implement all of them in any way.
But I choose three cases to spot it.
The simplest one is symbol name. That is just the first name.
And maybe a cognoment that's a name that describes the character.
That's sort of like an extra name.
Then you could be a massive fisherman.
Or you can beat a beat if you are not.
These are usually people of not that big importance.
Then there are regular names, which are first name and family name, and maybe cognoment.
And then you get to the level of the rulers, you get the regular names.
That's the first name family name, hecknall number and maybe cognoment.
And the hecknall number is one.
And that's the rule.
You get the regular names.
That's the first name family name, hecknall number and maybe cognoment.
And the diagonal number is what tells rulers that have been named in the same way from each other.
So you can have a number throwing up by a flank.
Elisabeth II, for example, there was a Elisabeth at some point and then there was a new queen called Elisabeth.
So that's Elisabeth II.
And also, I'm not here yet deciding how exactly the diagonal number will go.
It might actually differ from culture to culture.
Some cultures have the number to go in a way that everyone is every ruler who has a name is first.
And if there's the same one, then that's the second.
Some cultures too, that you are just a name.
And when somebody later on takes the same name, they are the second and you are the first from that point on.
So the number and scheme is different from the culture to culture.
And if you combine that with the title, you get things like Acrypina VII, the bold procurator of Sol.
This is a formal way of addressing them and so on the game.
I mentioned the Dynasties at some bit earlier, so they are the how the game progresses through the time.
The Dynasties group of people sharing the answers to more or less.
Of course, it's a bit more complicated than that because there are marriages involved.
And when somebody marries to different Dynasties, they don't in the game, they don't switch to that Dynasties.
But they have to choose who is the Dynasties.
The children of two Dynasties.
Two persons from different Dynasties marrying the children can be only either one of the Dynasties.
And because the inheritance goes through the Dynasties bloodline.
Then it's a pretty important decision.
And the higher up you go in the ranks, the more political the marriage is then to be.
And the marriages are actually stored in the separate table for this specific reason.
You have to have an information of who is married to who and who is done as the children will belong to.
I was talking about sex and gender.
So sex, that is the biological aspect.
In the game, I have just simple enumerous male and female intersex.
And gender is the social aspect that is enumerous of non-human or gender non-binary.
This is very coarse division, but it's sufficient for the purposes of the game for now.
I might fine-tune this a bit later on, but I just want to get some sort of framework into place where I can start experimenting with the data.
And see how this thing works.
I know that this will lead into the troubles, into later on.
It will be easy to just have a binary human and that's it.
But having a more complex system, I think it's more nuanced and offers more interesting choices later on.
For example, if we have an agnostic prognostic, meaning that the eldest children child will inherit and the preference is for the male,
but if there's no male here available, then the oldest female will inherit it.
But then in our system, we can easily have a transgender or intersex or non-binary character,
figuring out how inheritance laws work in these cases might be a bit tricky.
I have been giving it a little bit, doesn't seem to be too easy.
But I will tackle that when I get into the writing inheritance, how that they actually actually go.
Reading about different systems and different customs around the world.
I'm not currently not modeling sexuality at all.
I haven't yet figured out how to do that and how important it will be for the game.
But that's in the long list of things to figure out and start working at some point.
One of the important factor part of the characters is traits.
These are things that define, these are sort of defining features of the people.
They include things like brave, outward, ambitious, content honest, deceitful.
And these are binary, meaning that you need to have it or you don't have it.
You cannot be 55 person brave.
That's not possible in this system.
Either are brave or you are not brave or you are either covered or you are not covered or you are neither one.
So it's basically a three step setting in this topic market.
And these can change over time.
And they are stored in the separate table, again that links to the parent table.
And these can change.
Because these can change over time.
You have to keep track that you don't get into the situation where you are both brave and coward.
That doesn't make sense.
I have been thinking of writing it in a way that if some special event happens and you are as a result of that event,
you turn out to be brave.
Okay, fine, then you are brave.
But if later on happens another event where you act in a way that will be cowardly,
you don't turn into the coward immediately.
But you lose your brave status.
And if you do that simulating again, then you are coward.
Okay, relations between characters.
And this is, this is, this I found very, very interesting to write.
So stored in the person's relation table.
Basically, there are just two people.
The type of relation.
This is enumeration.
If it's a child or parent or spouse or friend or rival, for example.
And visibility.
Is it a public relation?
Is it a family relation?
Or is it part relation?
The public relations are known for everyone, basically.
Everybody knows of public relations.
Family relations are known for not necessarily for the family,
but for the smaller group of people.
And private relations are known only by the, by the persons involved.
So there's a three level setting on how secret relation is and how well known it is.
And this form interconnected web, like the same relation.
Every person in the game will have a bunch of relations.
And players will never ever have a whole information about this information,
of this web, web, web, to themself.
And they have to, they have to somehow try to uncover the information of the persons
that they are interested of knowing.
Or they might be the allies, they might be the enemies, they might be some powerful person
that is neither one and they are trying to figure out where they stand on a grand scale of the things.
And for this, figure out things that are in there.
And if you remember how I did that in the, with the planets in, in the planets,
they were a system that keeps collecting more and more information
and slowly builds up better picture for the player about certain planets.
First, first they only know maybe its location and its name.
And then as the information starts feeding in, they get the information
about the gravity and composition of the atmosphere
and what kind of buildings are located, if they are anything located,
who's the current ruler and how many people are living there.
I mean, information like this.
But I couldn't do it.
No, probably I could have done that with the people too,
but the amount of data would have been pretty big.
And it started feeling hard to keep track of things while coding.
So I opted for a slightly different system.
So there's a human interlinked change.
It's thought that they will name it in the same way.
That is basically just to store the information about the,
there's a link to the person.
There's the owner of the info and level of the info.
So this basically just tells that some person has,
some certain level of information about another person.
And they can, things like, on the level, they can,
they have spots or demesne, demesne, meaning,
area, they are controlling, fanny relations, secret relations,
opinions, trades, and so on.
So when I'm showing the data to them,
players on the UI, I have to, I'm not loading the,
I'm not showing them the information directly from the person
and relation, relation and so on tables,
but I'm filtering them based on the person intel
that they have about that specific, specific person.
So if they, for example, don't have a,
if they have stats intel about a person,
then they can, then they are shown the stats of the,
of the person.
If they don't have that information, then they are not shown,
shown of the, shown that information.
And the, and how this is done is, for example,
in the case of trades.
There's a person report that is the information
that is transferred between client and server,
showing, showing information of the person.
There's a field called person type of trades,
that is maybe trade report.
I'm sorry, maybe list trade report.
And this one tends possible list of trade reports,
hence it, maybe.
In the code, it's intended with the exclamation mark,
meaning that, that field is always evaluated
instead of tank being constructed.
Because Haskell Haskell works in a way that,
if you, if you create a total record,
and put, mark that some field is a result of some computation,
Haskell doesn't automatically perform that comp,
comp, computation, it creates something called tank
that is basically a place order,
that knows how to compute that information.
And only when that information is needed,
then the tank is forced, and you get the actual value.
Sometimes it really is, really nice you can,
you don't, well, big advantage is that you don't have to think about
in which order things have to happen.
Haskell will take care of that for you,
and it won't compute things that you don't actually end up using.
But the drawback is that if you have a big report
that has a lot of fields that you always end up using,
then this tank creation is wasted effort.
So, when preventing them with the exclamation mark,
you get the, you force the Haskell to compute the value
as soon as, as soon as you are creating the record.
So, yeah, so, so that percent report,
trades is maybe a list of trade reports.
And in the code we are creating this,
I'm just finding that percent report trades,
equals if trades element market intel,
meaning that if market intel value,
and that's a list holds a trade,
that's a very intel value,
then just dollar trade report,
dollar market trades, else and nothing.
Meaning that if we have the trade information about this person,
then we are going to call trade report function
to each and every of these trades of this person
to create a report otherwise we are returning nothing.
And the trade report is a function
that goes from person trade to the trade report
that includes name, description, trade pipe,
and information how long the trade is valid,
because some of them are very transient in nature.
So, this means that,
that if this information is the one that is sent to the client,
so on the server side,
they might be just a single value trade,
nothing else,
storing into the database for this person.
And when it's loaded and sent to the client,
then we are going to call the client side,
they are going to be a nice little record
that has name, description,
so, brave and string this person's particular brave.
Then there's the trade pipe,
that is the enumeration,
and information how long that is good.
So, that's basically all the code
I'm going to talk on this episode.
So, to recap, there's a person,
and from the person,
there's hanging from several other tables
that have information about the narratives and the relations
and intel that this person has about another person,
and this data is what represents a person in the game.
Next time, I'm going to look more closely into opinions.
This episode is starting long enough already as of yet.
So, I'm going to leave it to the next time,
but the opinions are going to be picked in the game
because this describes how, basically,
what somebody else has opinion about somebody.
So, it's as a rule,
you have to keep track,
what opinions you have about you,
and what opinions your allies have about you,
and have to manage them,
but I'm going to leave that for the next time.
That's about it for this time.
I'm going to stop now.
If you have any questions, comments or feedback,
they're always welcome.
Easy to get to me,
nowadays is the email or the first one,
where I'm too durable,
I'm master, and that's also,
other after.
You've been listening to HecopobliGradio
at HecopobliGradio.org.
We are a community podcast network
that releases shows every weekday, Monday through Friday.
Today's show, like all our shows,
was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast,
then click on our contributing
to find out how easy it really is.
HecopobliGradio was founded by the Digital Dove Pound
and the Infonomicon Computer Club,
and is part of the binary revolution at binrev.com.
If you have comments on today's show,
please email the host directly,
leave a comment on the website
or record a follow-up episode yourself.
Unless otherwise stated,
today's show is released on the
Creative Commons'
Attribution,
ShareLite,
3.0 license.