hpr-knowledge-base/hpr_transcripts/hpr2858.txt

Episode: 2858
Title: HPR2858: Vehicle designer for a space game
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2858/hpr2858.mp3
Transcribed: 2025-10-24 12:17:59

---

This is HPR Episode 2858 entitled, Vehicle Designer for a Space Game, and in part on the
series, Hakell.
It is hosted by Tuku Toroto, and in about 23 minutes long, and Karima Clean Flag.
The summary is Tuku Toroto talks about modeling vehicle designer for Space Game.
This episode of HPR is brought to you by archive.org.
Arch-Universal Access to All Knowledge by heading over to archive.org forward-slash-donate.
Hello, you are listening to Hack-Up-Apple-Playbio, and this is Tuturpa.
This episode will be about designing a vehicle or vehicles in my space game that I am
riding in Hakell.
So, every space game needs tons of vehicles, and I have been working on a designer for designing
them.
And this is just a tool where you can design a whole bunch of vehicles.
I have been thinking if I need a crew of other ships and submarines, and I have been thinking
if I need a crew of other ships and submarines, but haven't designed those yet, and they
can be added later if needed.
And this ties into the episode 2818, where I talked about the research in the game.
So, first you need to research some technologies, and that technology unlocks things that you
use for designing the six vehicles, rather, and what you gain from research is different
types of chassis and different types of components, and those are the pieces that you use
for designing the vehicles, so you take the chassis and then you add the components,
and the result is a blueprint that you can then use for building them.
This episode will be more about how I modeled the data, and maybe I do another episode
later, where I talk about how to use the data, and I try to read as little code as possible
because that's a bit hard to follow on a podcast.
So, there's a major part, I think the basic piece is the component, so vehicles are designed
using components, this can be like star sails, astro-8 navigator, long range sensors,
and so on.
And each component in a blueprint is designed by two values, component IT and component
levels.
If you know these two values, you will know the rest of the values.
So, the component idea is just a innovation stating these kind of components they are,
it could be a cyclone-range sensor or shift-bridge or vehicle, vehicle-wheeled
motor system or vehicle-mover motor system if you are building a spacecraft.
And the component level is the, it tells the quality of the component.
So, when you first research something, you get a prototype components.
And when you first research it, you get more improved components.
And I haven't written that part yet, but I have been sketching the idea that if you design
a, let's say, a car using a prototype components and produce it, then that,
then that produced car will have some faults like it could run slower than you
anticipated, it will run and use more gas and heat up more and things like this.
And if it has a, if it has a communication system, that the communication system would be
quite, it would have static in the sound and things like that.
And when you continue researching the components further and you build the same car,
then you get a much more refined, refined, it's the same blueprint.
But now you know how those, now you have more improved components.
So now you, now it runs faster and it uses less gas and things like that.
Like you have figured out how to use the technology.
And the component itself has a bunch of, bunch of values.
These are all these in the show notes.
It's easy to follow, follow there.
But basically test the component ID, that's the identifier for the component,
test the component level, telling the level of it, then test the name and description.
These are just, just stating what it is and short description, what it is useful for weight.
Obviously how much it weights, each chassis has a limited amount of weight it can carry.
A slot, component slot, these states where the weight of component can be installed.
Some vehicles have more space inside than others.
Some has, some vehicles as to slip those off for armed forces have more slots for weapons,
than civilian vehicles and so on.
So this, this states in what slot this component can be installed into.
There's a list of component powers.
These are just the sort of description of what the component actually does.
Like it states, states if it's a star sale or if it's a supply component producing a supply,
or carrying supplies for you, or if it's a sensor component.
And again, the level of the power.
So if you have some really sophisticated component, it could perform multiple functions.
It could be stated here.
And then the cost, as a raw resources and then the chassis type that tells on which kind of chassis this can be installed to.
You cannot install components meant for the big space in your small car like vehicle and you cannot use a components that are meant for the.
Your towers are more in your Icarus suit.
Okay, so those, those things define the components and here I have been trying a new thing.
I have been trying to have types for everything like.
For example, component, component name is normally I mean previously I would have choose text.
So any text can go here, but I here I defined a new type called component name that is essentially text, but it has a different bite.
So now when I'm handling component name and component description, both are essentially text, but they're different parts.
I will not mix them up accidentally. The compiler will give me an error, but you mix these two things up. You need to fix that.
And let's see.
And then there's one important function related to the components called component requirements.
This takes a one parameter component ID and has a value of maybe technology and this tells you what technology is required to unlock this component.
It's essentially just a case. I think the case collection of cases like I have a couple of lines component requirements.
Cplonger and sensors equals just high sensitivity sensors. And then the next line component requirements, ship bridge equals nothing.
So I have I have to handle each and every component ID in the component requirements function and produce for each and every one of those maybe technology.
So in the example ship bridge doesn't need any technologies. They are unlocked when you when you when the game starts, but long range sensors need high sensitivity sensors.
Research and this is what you perform in the perform in the research section of the game.
So I think that's enough for the components. Then the chassis. One one one thing I probably should clarify the all components are hard coded.
They exist solely on the code. There's no way of adding new components without modifying the source code.
But then next to the chassis, these are starting the database. It's a little bit more complicated than our coding, but it's a part of it more flexible.
Again, the show notes have a detailed definition of the of the both database table and the actual data.
But the basic idea is that there's a name. Then there's the weight of the conversation stating how much weight it can carry.
There's the chassis type. This tells you if it's a land vehicle or spaceship technology.
We required to unlock this one if there's one and then there's a bunch of slots as a slot.
There's a almost slot in a slot out the slot sensor slot weapon slot engine slots motive slots and sales slots.
This tells you how many of the given type these slots are available in this chassis.
And the inner slots are for the components that are inside of the hull, out of ones are for the components that are outside of the hull.
Inside would be things like preach and quarters and such outside would be a sensor for example.
Then there's an armor slot obviously if you need to need to if you need to install armor on your ship a vehicle. This is where it goes.
In the sensor slots, no actually I have a sensor slots separate from the other slots.
The other sensor slots is for the sensors and other slots for things that are outside of the hull.
Maybe if you have some sort of crane that you can lift used to lift things or load things that could go outside slot.
There's one slots for various kinds of weapons engine slots.
If you have an engine on your vehicle this is where it goes motive slots.
These are more abstract like if you if you are if you have a land vehicle you can you can have wheeled motive system or you can have a tracked motive system or you can have a whole motive system.
Maybe I'll come up with more and this tell how the vehicle moves.
Does it have wheels or does it have tracks?
And sales clutch is for the star sales mainly mainly only for the starships and some not all chassis have all of these available.
Some have like star those sales are only for the starships for example.
Then there are chassis might have had some requirements.
For example the way poorly that starship is perfectly happy with just a single star sale but fly boat is another star ship is decent to be fast and always has to have tools.
Two star sales on it.
So when you're building you have to full when you're designing you have to fulfill these requirements otherwise the design isn't valid.
And these requirements further characterise the different kinds of chassis.
Like if you have a science ship as a chassis you can have a it might be that it has a requirement that it has to have at least five slots of sensors in use because it's a science and it might have to requirement that it has to have a space for a laboratory.
Okay.
Actually designing the vehicles.
I think I almost skipped one.
Then there's these requirements they are stored in the record component.
They are the best table and they are represented as a record component data inside of the program.
I can't even show notes but it will have a because it's a database table table.
There's a chassis ID linking the requirement into the specific chassis.
There's a component type and component level and component amount.
These three values state which component what level and how many are needed to fulfill this fulfill this requirement.
For example a bit some small ship it might be enough that there's a level one bridge.
It's enough that there's some sort of bridge and that fulfill the requirement.
But when you have a peak peak peak cruise liner that sells around the far system serving passengers.
Then you have to have a level two bridge for example.
You need more sophisticated bridge to handle such a big ship.
And again all these values should actually.
All these values should have their own types.
So the level is an insert of intake.
It's part of that component level.
So I don't accidentally mix them up.
Actually designing of the vehicle.
So based on the complete research you get a list of chassis available.
And from that list of chassis you pick one.
And that defines what kind of vehicle you will be designing.
Is it a land vehicle? Is it a space ship?
And what kind of space it will be?
Is it a small space ship or is it a huge space ship?
Is it a fast or slow?
Is it meant for the civilian use or is it meant for the military use?
Is it a research ship or is it a is it a is for trading?
And based on that selected chassis and complete the research you get a list of components that are available.
And then you select what components to install.
And you have to keep track of the maximum damage of the chassis that you don't exceed it.
And that there's enough slots.
And so that you don't, if your ship has a space for three inner slots you don't install for inner slots.
And then you have to keep track of the requirements.
If the ship requires two star cells you have to have two star cells.
And then you also need the name for your design and save that to the database.
And that's your, that's your brand new design.
Starship, whatever.
Designs.
They are saved in the database.
There's two tables.
There's the actual design table that has a name, owner and chassis.
So name is the name of the design, for example, SS enterprise.
There's only owner, that's a fraction ID that links the design to a specific fraction.
You cannot, you cannot use designs of a different fraction.
You can only use the designs of your own fraction.
You can maybe try to gain access to another fractions designs.
For example, by trading or by espionage or something.
Finding, finding a derelict ship in a space, holding it back and reversing, engineering it.
And then there's the chassis ID that defines which chassis this design uses.
And this is a link to the chassis table.
The components that are designed for the design are in a plant component table.
Again, there's a design ID linking to that specialty design, component ID, stating each component, component level, stating what level of component has been planned for this.
I'm not quite sure about this, actually.
If I should have, if I should store the component level at all, because this allows you to build ship using a prototype components,
even if you have a higher level of components available.
I don't see why would anyone want to do that.
Unless it is that the prototype components are cheap, then most produced ones.
And I don't think that's a case.
But that's something I'll be thinking about.
Figuring out what it is exactly that I want to do with this stuff.
And then there's an amount stored as a component amount, telling how many components of this one are planned.
Because when you're designing a, when you're building a design, you're handling components as well.
They are pretty abstract. Well, abstract may be not the correct word, but they're not in the individual components are not involved.
You can have, for example, then, then, ah, okay, then it's a bit much.
You could, you could have three set of, set of three sensors of set of trees, like three sensors.
And you can, you just clamp them together and treat them as a group of three sensors.
But when you have a actual ship that is sailing around, then you have to deal treat those sensors individually,
because one of them might get damaged and start malfunctioning, while two others are working fine.
So here you can group them, group them together.
But when we are later on building our real, actual vehicles, there we have to treat components.
It has the individuals.
And, ah, here I, again, have defined amounts, a component amount, level as a component level, like this.
There's a, even in the database level, I'm trying to use pipes that have been defined, some, some, different to have a specific meaning.
Previously, I would have used amount as an index, but now I'm trying to use the component amount.
But, ah, I will, ah, probably in the next episode, I will explain a little bit more about how, how I did this and why I did this,
and couple things that need to be done to enable this.
Okay, ah, but that pretty much wraps up this episode.
So, there's a, you do research, you can access to the components and chassis, then you use those chassis and components to design your vehicles,
and later on you can use those designs to build, build them.
Ah, if you have any questions or comments, the best way to reach me is either email or, from your active status,
where I'm to talk about mustard on the dot social.
And, even better is, if you are, I'll record your own episode and participate in the hack-up-up radio.
Okay, that's about it. Thanks for listening. Ad Astra.
You've been listening to hack-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-up-
The public radio was founded by the Digital Dog Pound and the Infonomicon Computer Club and is part of the binary revolution at binwreff.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 create of comments, attribution, share a light, free.or license