Mostly, this is a coding exercise for myself. I want to make each six letter word a unique, but consistent moniker. The jeremy on my computer will be the same as the jeremy on your computer. This is quite possible by "hashing" the words (basically encrypting them into numbers).
From my own experience in something like this, there are 95 printable characters in ASCII (far more if you support the potentially unlimited higher character sets). Though it looks like you're initially thinking of alphabetic characters only (maybe caseless, unless you want "shitty", "shiTty", "ShItTy", etc to all produce different patterns) so starting at at least 26^6 mappable word->stats combinations. Which is easily mappable to (I presume, from what I can see of your example-stats below the watermark) 20^4 unique stat-states.
In fact, by a factor of 1,930(-ish). So if it's just those four stats of 1..20 you're good with any decent hashing function, which should make "hitter", "hatter", "hutter", "hotter", etc, bounce around the phase-space of qualities (and, considering reversibility, finding the 'word' to get [20,20,20,20] will be a huge amount of trial and error. Yes, there may be ~2000 of them (like "usbiel", "hdappy", "mmmmmm", "random", "weakly", maybe), or perhaps none at all!
(Once you have come up with a basic function, you can quickly run through a wordlist of all 6-letter words (or all unique first 6-letters of all words >=6 letters) to register each of the 'landed on' stat-sets, count them up, ensure a good rough spread before you inadvertently release a game that it's virtually impossible to generate whole
territories of values for, due to some mathematical quirk.)
Anyway, you'll be going for more than 4x[1..20], by the sound of it. You'll be shaving off other values for other qualities not already calculated from the [speed,love,fight,sense] values. Sexual compatability, for one. Some value that can be compared for breeding test (I suggest, to allow for the
Ring Species phenomenon, a value (hidden? or perhaps handily tied to body colour for the player to have insight into it?) such as 0..255 with some quickly deteriorating breedability (two creatures within
n can always breed, within
2n have 50% chance,
3n have 25% chance, etc, but disregard any chance well before covering half the range).
Again, whatever you do, you'll be able to quickly run through your own code and auto-test inputs to map the distributions. At the very least do the basic maths (how many 6-character inputs there are, and how many visible+hidden independent stats there are) and make sure the dimensionality is enough to theoretically cover the latter with the former.
As to the function, I have had good results with a 'linear-feedback shift register' method. For you, maybe line up the binary of the 'seed' words (for extended-ASCII you could truncate each character to the 6 or 7 least-significant bits, to get good distribution without having to worry about multibyte characters as input). Add (XOR) a 'salt', and maybe even perform a shuffle of the bits[1]. Then run the LFSR of your choice across the bits at least once (I tend to favour as many iterations as there are bits, just to thoroughly mix up and recombine the original data, though that's overkill... ✓n iterations should be more than enough for an n-bit shifter in most well-chosen cases). Such operations should be highly efficient (and reliable), if done with bitwise operations, and knowing how to use bitwise operations is always a useful thing for a programmer.
Or just
hash it and then split the hash-value as needed, of course. But it's much less fun to just use someone else's work, even/especially if it's computationally proven to be sufficiently 'pseudorandom'.
[1] Might be overkill, but if your pre-testing of inputs comes out with too much 'value bunching/desert' in the output data then a simply altered salt or shuffle, at source, should shake things up enough to give a (probably) less problematic output distribution. You don't even need to understand how it works, just test until it does!