Haha, everybody is going to have their opinion on this. Heck, I read through the comments and I didn’t see this answer but probably in the time it takes to type

Haha, everybody is going to have their opinion on this. Heck, I read through the comments and I didn’t see this answer but probably in the time it takes to type it up, someone else will post it. So Adam Savage had a video[1] a few months back on weathering prop money to look like a properly “gangsta” stack of bills rather than a set of nice printed paper. And when it was broadcast it was live and he took questions from the audience while some espresso was drying on the bills in his oven, and one of those questions was about someone needing a prop that looked properly covered in dirt and blood, and what is the best way to do that? He said that the dirt part was easy (I assume he meant, just bury the stuff for a day or two and come back and it will be covered in dirt) but the blood part was harder because blood doesn't stay red for very long. But at the end he had some really great commentary, looking back at the question he said > So, your question though, “what is the best way”... The answer is, there is no, there is no best way! There is the way you figure out how to do it. Yeah! That’s really the thing. It may be that you’ve gotta, like, take a brush and kinda work at a whole bunch of different bills, and then take the stack and then effect the stack, right?, I think that’s like a multi-stage process, and then you should do some tests with different paints and see, like, under the lighting conditions these will be seen—I don’t know if it’s for a theater or a film—does it communicate? Does it tell you that it’s bloody, dirty money? That’s the question to be asking, you gotta hold it up, look at it, [mimes looking at it and pausing and thinking] “does that sell to me?”—and ask other people, “does this sell?”... and like most of the time they’re gonna go, “no,” and you’re gonna keep on going. But it’s trial and error. I present this advice to you in part as a way of combating decision fatigue. It’s gonna be trial and error, there’s not gonna be a ‘best way,’ so spending too much time up-front trying to figure out what is that best way* is gonna be a waste of your precious limited resources of attention and drive. Because the actual definition of “best” is coming from these extrinsic factors. Sure you don’t have lighting. But maybe you have a constraint that you would like to build a JavaScript game around the same rules engine as you’re using to analyze the game and figure out cheap play and winning/losing, and it would be really tremendously inconvenient if you discovered that the two rules engines are subtly different and your analysis misses a loophole that breaks your JavaScript game. So you write the analysis engine in Node.js or so, so that you can reuse identical code in both places—or maybe JS is an inconvenient language because it does not have a great library that some other language does, like maybe you need to do a Fast Fourier Transform as part of this game so now you have to switch to a client-server model with the server having access to your FFT library. I don’t know. But the decision is made not by which technology is intrinsically better, just like the decision of which red goes into your blood paint is not about which paint is intrinsically better. Two minor tips, (1) I commented recently in another post that you should not concern yourself at all about scaling problems. I want to repeat that here. On initial selection of technology, do not worry about whether it scales. On initial selection of algorithms, it is even acceptable to brute force through some n! number of ways of permuting some elements until you find some better heuristic. Always start with doing it whatever is the easiest way for you personally, because you do not know until you see it in its eventual lighting what parts will and won’t work. It may be that this n! is indeed too long, mostly n is small but every once in a while it goes to 12, 13, 14, or even 15. But it may also turn out that the final decision can be effortlessly cached and then it becomes O(1) after that, so it is a one-time cost that doesn’t need to be recalculated. Or maybe it does. Spend all of your time optimizing that, and you may find out that n is never more than 8 in practice and the thing completes in some fraction of a second. You don’t know how to choose tech or algorithms to scale until you know what your scaling problems are, and when you know that you’ll be able to measure them. Never start with Kubernetes, never start with anything intricate, just do the easiest thing which might work and then see why it doesn’t. And this solves a lot of decision fatigue. (2) In addition to ease, you might consider joy. Start writing the thing in Haskell, if that will bring you joy. You may find that with a Data.Map.Strict and a System.Random.StdGen that you can very easily load a dictionary of names and frequencies into Haskell and then randomly generate a name according to that frequency table, and maybe that is fun to you, that this fits in just a couple lines of code. If you are playing then you aren’t nearly as subject to decision fatigue. Nobody sits there with a box of lego trying to make a castle going “but is the 2x4x3 brick a better material to build this castle rather than say the thinner, longer walls of a 1x6x3 brick? What about a 2x4x1 brick, a larger number of thinner layers in case I need curvy designs built into the walls?” Like those decisions do have to be made but you kind of just make them and if it’s wrong you unmake them later, and you don’t care because you’re playing around and so it doesn’t feel like a big decision to you. Those are my three pieces of advice. There is no best way there is just the way that you figure out which does the thing; do whatever comes easiest to you and worry about making it better later; and feel free to play around with other things you’re curious about. 1: https://www.youtube.com/watch?v=igEqC3snaYY https://www.youtube.com/watch?v=igEqC3snaYY