You don't need a math PhD to play Dwarf Fortress, just to code it(the-stack-overflow-podcast.simplecast.com)
the-stack-overflow-podcast.simplecast.com
You don't need a math PhD to play Dwarf Fortress, just to code it
https://the-stack-overflow-podcast.simplecast.com/episodes/you-dont-need-a-math-phd-to-play-dwarf-fortress-just-to-code-it/transcript
87 comments
Ha I was going to quote this exact passage. The "and miss a little bit. It's fine to miss" was oddly satisfying to read.
> because I'm not in like n dimensional non Euclidean space
huh. I was sure that DF used taxicab distances
huh. I was sure that DF used taxicab distances
Taxicab distances are perfectly fine in Euclidean spaces
Many things go by the name of “Euclidean space” (basically the “flat” case of every kind of space, linear=vector, affine, topological, uniform, metric, topological manifold, algebraic variety, differential manifold, Riemannian, topological linear=vector, Banach manifold, countless others).
I (and probably the GP) think of “R^n with taxicab distance” as a metric space, which is indeed non-isometric to the “Euclidean metric space” as in “R^n with Euclidean distance”, thus can meaningfully be called non-Euclidean in this context.
You seem to be thinking of whether taxicab distance agrees with some preexisting, weaker structure on this structure’s notion of “Euclidean space”, like how the taxicab metric topology agrees with the topology of the “Euclidean topological space”, that is, “R^n with standard topology”, or how taxicab distance is translation-invariant thus an admissible norm on the “Euclidean vector space”, that is, “R^n with standard R-vector space structure”. In those senses taxicab distances are in fact fine in Euclidean spaces. (Note that this ceases to work as soon as you go into infinite dimensions, probably in any of the many, many ways to do so.)
I (and probably the GP) think of “R^n with taxicab distance” as a metric space, which is indeed non-isometric to the “Euclidean metric space” as in “R^n with Euclidean distance”, thus can meaningfully be called non-Euclidean in this context.
You seem to be thinking of whether taxicab distance agrees with some preexisting, weaker structure on this structure’s notion of “Euclidean space”, like how the taxicab metric topology agrees with the topology of the “Euclidean topological space”, that is, “R^n with standard topology”, or how taxicab distance is translation-invariant thus an admissible norm on the “Euclidean vector space”, that is, “R^n with standard R-vector space structure”. In those senses taxicab distances are in fact fine in Euclidean spaces. (Note that this ceases to work as soon as you go into infinite dimensions, probably in any of the many, many ways to do so.)
I think we're just working with slightly different definitions of "works fine". Isometry is a pretty strong definition of "works fine", but R^n with 1-norm is isomorphic and quasi-isometric to R^n with 2-norm which is still fairly strong.
didn't need language classes either is it? Not that my commenting is free of errors anyway
This is an imperfect transcript of (casual) conversation.
It's a transcript; you don't type like you talk either. I know I uh and ahh a lot more, awkward pauses, etc.
But you do need a math PhD to code it, because if you were coding it, you'd be Tarn Adams, who has a math PhD. There is no state in which one can be "coding Dwarf Fortress" and "not have a math PhD".
The most reasonable gloss on "You need a math PHD to code Dwarf Fortress" is "Necessarily, if someone codes Dwarf Fortress, they have a math PhD." The modality "necessarily" is widely understood to refer to possible alternative states of affairs, not merely those states of affairs which are actual. In other words, if an alternative state of affairs is possible, in which someone (whether Tarn Adams or someone else) codes Dwarf Fortress without a math PhD, then it is not true that it is necessary to have a math PhD to code Dwarf Fortress.
Most people in this thread believe that since a math PhD did not play a crucial role in Adams's ability to develop Dwarf Fortress, then it is true that such an alternative state of affairs is possible. (The language of "alternative universes" - usually called possible worlds in the literature - is one way of getting at this.)
Most people in this thread believe that since a math PhD did not play a crucial role in Adams's ability to develop Dwarf Fortress, then it is true that such an alternative state of affairs is possible. (The language of "alternative universes" - usually called possible worlds in the literature - is one way of getting at this.)
I'd posit that there could exist an alternate universe where someone without a math PhD made exactly Dwarf Fortress
I would make an even stronger assertion that this is almost certainly the case. ;-)
Classic theoretical mathematician answer, but games are applied mathematics :P
Well if such a universe exists, there is probably one where it turns out exactly the same w/o math PhD, and another where its a very different game. In any case, we're not privy to those universe's goings on :/
To that I'd say if you had a jazillion monkeys with a jazillion typewriters, the monkey that types Dwarf Fortress has at most at 50% chance of having a PhD
That universe exists and the game is called Rimworld!
[deleted]
[deleted]
You don't need a math phd to code it either, you just need skill and motivation.
That might be correlated with having a phd, but it isn't mandatory.
EDIT: I physically cannot comprehend how what I have said is somehow worthy of a negative reaction.
That might be correlated with having a phd, but it isn't mandatory.
EDIT: I physically cannot comprehend how what I have said is somehow worthy of a negative reaction.
I think it's arguable if you even need skill - I believe Toady One has mostly taught himself good project design through having to deal with Toady One's code from three years prior. Changing a fixed 2D legacy game to 3D and completely rewriting fluid dynamics in a shipped title will do that to you.
I agree entirely about motivation though - he's stuck with that project for an immense amount of time. Urist Borushdumat[1] and Boatmurdered[2] are both from 2007 - George W Bush was president then and The Colbert Report had barely gotten started - your nephew in high school was still in diapers. However - over the full run of nineteen years dwarf fortress has been in development[3] he has received pretty tremendous community support - well probably since 2005 or so - I don't know if anyone knew it existed in 2002.
1. http://www.bay12forums.com/smf/index.php?topic=15572.0
2. https://lparchive.org/Dwarf-Fortress-Boatmurdered/Introducti...
3. Wait - wtf - it's older than Firefly! (that's the show that made Nathan Fillion famous before Castle or Dr. Horrible's Sing-a-long-blog FYI) I can now use the line "I'm getting too old for this sh*"
I agree entirely about motivation though - he's stuck with that project for an immense amount of time. Urist Borushdumat[1] and Boatmurdered[2] are both from 2007 - George W Bush was president then and The Colbert Report had barely gotten started - your nephew in high school was still in diapers. However - over the full run of nineteen years dwarf fortress has been in development[3] he has received pretty tremendous community support - well probably since 2005 or so - I don't know if anyone knew it existed in 2002.
1. http://www.bay12forums.com/smf/index.php?topic=15572.0
2. https://lparchive.org/Dwarf-Fortress-Boatmurdered/Introducti...
3. Wait - wtf - it's older than Firefly! (that's the show that made Nathan Fillion famous before Castle or Dr. Horrible's Sing-a-long-blog FYI) I can now use the line "I'm getting too old for this sh*"
And the number of times save compatibility has been broken is surprisingly small for a long-lived one-man project.
I think that’s just more a result of the game style/architecture. I don’t think there’s much hidden state that’s not encoded into the map/entities, and even things like AI is I think ultimately preserved as a simple stack of pending tasks.
So being a proper simulation, and combined with the lack of replay, you can almost entirely discard the past events. The game is largely modeled as f(world-state, sim-rules) -> world-state, and so you simply take the old save and continue running it under the new simulation rules, and no one has to really care how many rule sets the world has seen. It only matters that they produced a valid world-state, every time.
So being a proper simulation, and combined with the lack of replay, you can almost entirely discard the past events. The game is largely modeled as f(world-state, sim-rules) -> world-state, and so you simply take the old save and continue running it under the new simulation rules, and no one has to really care how many rule sets the world has seen. It only matters that they produced a valid world-state, every time.
The issue with saves and compatibility is that the saved world state needs to remain a valid world state in a new version. This can be as simple as initialising missing data to sensible defaults or a lot more complex if simulation changes have caused the world state to change significantly. Then to avoid breaking things you need to somehow migrate the old data to the new data. And you may need to do that several times if someone loads a save from eight versions ago.
To code something like Dwarf Fortress takes an uncommon level of dedication. The project has been going for a decade and a half!
It's only recently that the project has been paying off via community funding/patronage. A great deal of those early years must have been very difficult for them.
It's only recently that the project has been paying off via community funding/patronage. A great deal of those early years must have been very difficult for them.
I know it’s silly but for me the most impressive part of the whole project is that he doesn’t use version control. I can’t even comprehend how that’s possible.
> It's only recently that the project has been paying off via community funding/patronage.
Another way it is like a PhD - a ton of up-front work for an uncertain payoff, largely dependent on the whim of others.
Another way it is like a PhD - a ton of up-front work for an uncertain payoff, largely dependent on the whim of others.
[deleted]
mostly my professional life too. Lesson learned : a ton of up front work doesn't lead to success. Replace "work" by "delegate, socialize, have lots of luck" and you'll go much further :-)
Also work. Don’t do a PhD if the work is a problem. Do a PhD only if the work is in your bones. And also socialize, and do other luck-maximizing activities. But work is indicated.
A PhD spot is an opportunity, not a gravy train.
Regarding your edit, I do not disagree. DF does not require a PhD. It would help, but it is not necessary and the people downvoting you, in my opinion, are misusing the privilege.
That said, talking about downvotes on HN is pretty boring, so I won't be replying to responses to this comment.
That said, talking about downvotes on HN is pretty boring, so I won't be replying to responses to this comment.
Certainly one of the most important shared attributes between getting a math PhD and working on the same game for 15 years is the stick-to-it-ness required.
One attribute that people don't often ascribe is luck. This was a labor of love and luck.
We hear about projects all the time that have been developed for longer (Linux, Star Citizen, Temple OS, et al) and those are the successes and failures that people have actually heard about. Lots of other people fail along the way (or succeed in not achieving much) with decades of development. I think DF's development need not be elevated to a quasi-religious tale because someone got good enough life RNG, anymore than being born with the money to brute force it is laudable.
We hear about projects all the time that have been developed for longer (Linux, Star Citizen, Temple OS, et al) and those are the successes and failures that people have actually heard about. Lots of other people fail along the way (or succeed in not achieving much) with decades of development. I think DF's development need not be elevated to a quasi-religious tale because someone got good enough life RNG, anymore than being born with the money to brute force it is laudable.
[deleted]
I'd recommend thinking a little about the algorithms involved in efficiently assigning a nearby task to each dwarf and then planning a path for each dwarf to its destination.
It gets interesting pretty fast and a PhD would not hurt. :)
e.g. https://arxiv.org/abs/1906.08291
Would you maintain a roadmap telling you how to get from place to place, or just constantly replan? What happens when you change the available paths by building a wall or locking a door?
It gets interesting pretty fast and a PhD would not hurt. :)
e.g. https://arxiv.org/abs/1906.08291
Would you maintain a roadmap telling you how to get from place to place, or just constantly replan? What happens when you change the available paths by building a wall or locking a door?
Pathfinding is largely not that bad — hierarchal A* for long distance pathing, flow field for dense agent areas (eg your fort). With sufficient density, it’s worth recalculating the field repeatedly. Partitions can also be used for resource-lookup, threat caching, etc. Brogue’s djikstra maps[0], and Dave Mark’s modular influence maps[1] are very interesting possibilities as well..
Your paper is dealing with a completely different problem — collision avoidance is hard, and you really shouldn’t care about it in a game like DF anyways. Simply treat existing dwarves as a wall, or allow multiple dwarves to be on the same tile momentarily (with a very strong preference to stand on their own tile).
Task assignment is DF/rimworld/etc is also pretty dumb — they’re fairly obviously simple greedy algorithms. you don’t need to be anything close to optimal to be effective. There exists a list of open tasks (place building, move x59 stone, fight baddie. User actions generally corresponds to multiple tasks). When a dwarf is idle, he takes the task-list, merges it with his needs (food, water, self-preservation, etc). Filter this list by permitted activities for the dwarf, prioritize the list (needs first, then by user-defined job priority, then by random roll). Lock any relevant object (eg x59 rocks in a move task) and execute.
As far as I know, there’s no attempt at global coordination in DF beyond simple locks — which I’m not sure are actually that strict. In DF I’m pretty sure two dwarves can go for the same pile of x50 rocks, and it’s simply first one wins. In rimworld it’s quite clear only one entity can hold a claim. DF in that case is much simpler and error-free (don’t need to care about dwarves dying while holding a lock) but rimworld’s would be more consistent and make better progress over time (eg a far away entity doesn’t keep getting screwed trying to grab resources from the base).
Pathfinding is largely a solved problem. Resource allocation doesn’t need to be smart.
I’m fairly positive DF’s biggest hurdles are largely in finding game-sufficient and efficient estimate models for complex processes: planet, fluid, wind (a kind of fluid), plant growth, etc. These models are all fairly well defined (to our gaming needs) by their respective communities, but they’re also far more involved than what we need — we just need to be roughly correct, and ideally have a self-stabilizing sim.
The difficulty of gamedev generally is simplifying the problem to find only what actually matters.
[0] http://www.roguebasin.com/index.php/The_Incredible_Power_of_...
[1] http://www.gameaipro.com/GameAIPro2/GameAIPro2_Chapter30_Mod...
Your paper is dealing with a completely different problem — collision avoidance is hard, and you really shouldn’t care about it in a game like DF anyways. Simply treat existing dwarves as a wall, or allow multiple dwarves to be on the same tile momentarily (with a very strong preference to stand on their own tile).
Task assignment is DF/rimworld/etc is also pretty dumb — they’re fairly obviously simple greedy algorithms. you don’t need to be anything close to optimal to be effective. There exists a list of open tasks (place building, move x59 stone, fight baddie. User actions generally corresponds to multiple tasks). When a dwarf is idle, he takes the task-list, merges it with his needs (food, water, self-preservation, etc). Filter this list by permitted activities for the dwarf, prioritize the list (needs first, then by user-defined job priority, then by random roll). Lock any relevant object (eg x59 rocks in a move task) and execute.
As far as I know, there’s no attempt at global coordination in DF beyond simple locks — which I’m not sure are actually that strict. In DF I’m pretty sure two dwarves can go for the same pile of x50 rocks, and it’s simply first one wins. In rimworld it’s quite clear only one entity can hold a claim. DF in that case is much simpler and error-free (don’t need to care about dwarves dying while holding a lock) but rimworld’s would be more consistent and make better progress over time (eg a far away entity doesn’t keep getting screwed trying to grab resources from the base).
Pathfinding is largely a solved problem. Resource allocation doesn’t need to be smart.
I’m fairly positive DF’s biggest hurdles are largely in finding game-sufficient and efficient estimate models for complex processes: planet, fluid, wind (a kind of fluid), plant growth, etc. These models are all fairly well defined (to our gaming needs) by their respective communities, but they’re also far more involved than what we need — we just need to be roughly correct, and ideally have a self-stabilizing sim.
The difficulty of gamedev generally is simplifying the problem to find only what actually matters.
[0] http://www.roguebasin.com/index.php/The_Incredible_Power_of_...
[1] http://www.gameaipro.com/GameAIPro2/GameAIPro2_Chapter30_Mod...
Headlines often aren't meant to be read literally.
It's just a teaser to read the article.
It's just a teaser to read the article.
But why is it bad to react to a headline? It offered something interesting to consider.
Because the creator himself specifically addressed the headline in the article. So either you think you know better than the creator, or just saw the headline and knee-jerk wrote a comment without reading the article contents.
Saying "You don't need a PhD you just need to believe in yourself", or whatever, is fine - but it's not related to the article, so gets down votes.
Saying "You don't need a PhD you just need to believe in yourself", or whatever, is fine - but it's not related to the article, so gets down votes.
The headline is part of the article. You could say “so you think you know better than the author” by quoting the body or “so you think you know better than the subject” by quoting the headline. Both are quoting the article to react to other parts of the article. The fact that the single most salient and most read part of the article sucks is plenty worthy of criticism.
When did I ever say any of these things?
I specifically said that it is possible for someone to create a game like Dwarf Fortress without being the recepient of a PhD in Math.
I never said that I knew better than the author, or that you needed to believe in yourself, or anything like that.
I believe you are assuming that I'm reacting to something, but all I am saying is that you do not need a PhD to do what has been done.
I specifically said that it is possible for someone to create a game like Dwarf Fortress without being the recepient of a PhD in Math.
I never said that I knew better than the author, or that you needed to believe in yourself, or anything like that.
I believe you are assuming that I'm reacting to something, but all I am saying is that you do not need a PhD to do what has been done.
> Headlines often aren't meant to be read literally.
Why is this normalized?
Why is this normalized?
Because most humans are functional enough to understand the concepts of metaphor and allusion.
No rational person would read this headline and assume that some cosmic force prevents you from coding Dwarf Fortress unless you have a math PhD. Therefore the most reasonable conclusion is that the creator of Dwarf Fortress does have a math PhD, and that it provided significant transferrable skills. That this is not what the headline says on a literal reading does not prevent a reader even with zero familiarity on the topic from correctly understanding it.
No rational person would read this headline and assume that some cosmic force prevents you from coding Dwarf Fortress unless you have a math PhD. Therefore the most reasonable conclusion is that the creator of Dwarf Fortress does have a math PhD, and that it provided significant transferrable skills. That this is not what the headline says on a literal reading does not prevent a reader even with zero familiarity on the topic from correctly understanding it.
more clickbait -> more views -> more ad impressions -> more money -> more marketing -> more market share -> more clickbait
it's a competitive advantage.
it's a competitive advantage.
[deleted]
“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?”
— Brian Kernighan, The Elements of Programming Style
(fortunately the interview itself is not so trite as the headline)
— Brian Kernighan, The Elements of Programming Style
(fortunately the interview itself is not so trite as the headline)
> “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?”
By becoming more clever! That's the very principle of learning: to become more clever.
The act of debugging your own code to become more clever is a well-known learning technique called "Kernighan's ladder", precisely due to this inspiring quote.
By becoming more clever! That's the very principle of learning: to become more clever.
The act of debugging your own code to become more clever is a well-known learning technique called "Kernighan's ladder", precisely due to this inspiring quote.
>The act of debugging your own code to become more clever is a well-known learning technique called "Kernighan's ladder", precisely due to this inspiring quote.
According to Google, you seem to be the first person to use that phrase.
According to Google, you seem to be the first person to use that phrase.
Sorry, I meant "kernighan's lever" :
https://www.linusakesson.net/programming/kernighans-lever/
https://www.linusakesson.net/programming/kernighans-lever/
Ah, thank you.
Think it's called Kernighan's lever.
I am not an English native speaker, but I think when you learn you become wiser, not "more clever*.
There are things that can increase your "cleverness" like deliberate practice (of mental calculations, of memorization), meditation or deleting social media to increase your attention, or using drugs. I would not call that "learning".
Learning is similar to "installing new software on existing hardware". Becoming more clever is similar to "installing new hardware".
There are things that can increase your "cleverness" like deliberate practice (of mental calculations, of memorization), meditation or deleting social media to increase your attention, or using drugs. I would not call that "learning".
Learning is similar to "installing new software on existing hardware". Becoming more clever is similar to "installing new hardware".
I guess you have a point, but, you don't only code for yourself; the quote applies to others as well, and in practice, few people code in a vacuum.
Don't write clever code; the problem you're solving with code is difficult enough already.
Don't write clever code; the problem you're solving with code is difficult enough already.
> Don't write clever code; the problem you're solving with code is difficult enough already.
No, it isn't. 90% of times it's just tons of dumb boilerplate. The sheer amount of that code creates its own accidental complexity, so if a bit of clever code can cut it down by an order of magnitude, by all means go for it. Other people may need to spend a bit of learning up front, but they'll come out better at the other end, and they won't have to pay the ongoing price of wading through vast amounts of code noise.
No, it isn't. 90% of times it's just tons of dumb boilerplate. The sheer amount of that code creates its own accidental complexity, so if a bit of clever code can cut it down by an order of magnitude, by all means go for it. Other people may need to spend a bit of learning up front, but they'll come out better at the other end, and they won't have to pay the ongoing price of wading through vast amounts of code noise.
I guess I misunderstood it and falsely applied it to make my code clearer and more effective. I failed to become "more clever" in the process and now I'm doomed to write unclever code other people understand better.
Nobody said that you should never write unclever code. Unclever code is alright, but it does not help you to improve. When you want to have a "cleverness boost", you can try to write and debug some clever code thus applying Kernighans's lever. You are not doomed, you can start doing that at any time. I'm sure that the unclever code that you get to write most of the time will even improve after that process.
That's fun.
I remember writing a little bit of clever (at the time) code for simplicity and speed. Ended up doing debugging and sanity checks via napkin math to confer with my partner because it was easier than reading through the function.
I remember writing a little bit of clever (at the time) code for simplicity and speed. Ended up doing debugging and sanity checks via napkin math to confer with my partner because it was easier than reading through the function.
Exactly. I've never interpreted that quote other than encouragement to continue writing "clever" code in order to get better at coding, despite the fact it's typically used to suggest the opposite.
As the party guilty of trotting that quote forth, I have to say I couldn't agree more.
Nevertheless, the time lag to improving enough to debug your own very clever code may for some be recalled as a period of floundering dismay, self-doubt, and potentially crippling imposter syndrome.
At these times it is important to be willing to ask for help.
Corollary: at any given time, write code that is only slightly beyond your ability to debug, so that the competence delta is small.
Nevertheless, the time lag to improving enough to debug your own very clever code may for some be recalled as a period of floundering dismay, self-doubt, and potentially crippling imposter syndrome.
At these times it is important to be willing to ask for help.
Corollary: at any given time, write code that is only slightly beyond your ability to debug, so that the competence delta is small.
Here's an example: I was writing some code that needed predicates and assertions and at first I did the functional thing and mapped the list of preds into a list of assertions. It worked and was short and DRY, but it had lots of downside, not the least of which is that it ruined stack traces (this was in JS). It turned out to be better to just do the simple thing and statically define a list of assertions that mirrored the preds. It was far longer and more repetitive, but much easier to read and understand.
It’s a real shame languages have such shitty stack traces for functional style code. It’s nothing fundamental about the style, so I’m hoping the situation improves over time.
> It’s a real shame languages have such shitty stack traces for functional style code. It’s nothing fundamental about the style
It is, though. Stack traces are fundamentally high-impedance for anything other than structured imperative code.
It is, though. Stack traces are fundamentally high-impedance for anything other than structured imperative code.
Could you elaborate?
I'm obviously not the person you responded to, but one thing to note is that the stack is going to be a more useful source of debugging information if the function call stack is encoding the logic of the program, which I would assert is more often the case in imperative style programming.
Imagine for example a state machine implemented two ways. In an imperative style where you have a big if STATE_IS_X /then function_x() /else if STATE_IS_Y ... tree calling a function for each state. Secondly in a functional style where you have a pattern match on a list of tuples of (state, function). In the first case the stack tells you exactly which state you were in and which function got called. In the second case the call stack will look the same in each case because you just match on the first part, unpack the second part into a variable and call the function in the variable.
Imagine for example a state machine implemented two ways. In an imperative style where you have a big if STATE_IS_X /then function_x() /else if STATE_IS_Y ... tree calling a function for each state. Secondly in a functional style where you have a pattern match on a list of tuples of (state, function). In the first case the stack tells you exactly which state you were in and which function got called. In the second case the call stack will look the same in each case because you just match on the first part, unpack the second part into a variable and call the function in the variable.
I guess I see what you're saying, but shouldn't it be evident which function got called based on the next stack frame up? When I look at stack traces I guess I'm usually just trying to figure out the sequence of calls so that I can know where to look for a bug, but if I needed to inspect state I would probably be doing it in a debugger.
This sounds like one of the many cases that is just begging for good codegen frameworks.
When will DF be playable on Steam?
Confirmed source from Valve said 'soon'
Also, every time someone asks, it gets postponed by a year. Good job on the parent commenter for pushing it out again...
You need a PhD to run it on a Mac.
It does not take a PhD to download the Lazy Mac Pack. http://www.bay12forums.com/smf/index.php?topic=158322.0
You can even get it as a Brew cask.
You can even get it as a Brew cask.
I did this months ago, it crashes if I generate too large a world. Even if I generate a small world, it crashes a few minutes into gameplay anyway. :(
(brew install dwarf-fortress-lmp)
Is it already time to gush about Dwarf Fortress again? Wow, time sure flies!
(I wonder if anyone will have a good story where something ~zany~ happened in their game... Fingers crossed!!)
(I wonder if anyone will have a good story where something ~zany~ happened in their game... Fingers crossed!!)
These days, my dwarf fortress entertainment comes from the great Kruggsmash on YouTube! He makes very nice artwork to go along with all of the happenings of the play throughs. His presentation is great.
> TA I think I think the math PhD itself didn't because I'm not in like n dimensional non Euclidean space. It's tricky. But But I think having practiced a lot of math and just solved a lot of problems. And generally being good at math. Like I've taught linear algebra. So that part of games is not hard for me, right? It's like and same thing like I'm calculus comes up sometimes. I've used a partial differential equation once it was for like windspeed firing arrows. I don't remember what it was. It was something like that. But it didn't I didn't really end up needing it. I mean, I used it to inform what I was doing but in the end faster just to use discrete simulation and miss a little bit. It's fine to miss. [Tarn laughs]