Fighting Eleven #14: The Model
I've been hoping for weeks that analyzing a recruiting database of the last ten years of recruits would enable me to formulize the process.Nope.
All recruiting, as has been said about politics, is local. What is the quality of your program? How many recruits do you have in your state, and how many in adjoining states?
So, after research that was extremely interesting, but not fruitful in regards to my original intentions, I realized I was just going to have to use brute force.
In the recruiting model, there are three "rings": in-state, adjoining states, and outside. To decide where a recruit comes from, here is the procedure:
1. Load current rank of the recruiting program.
2. Determine whether recruit is 5,4,3, or 2 stars, based on program rank (dice roll heavily influenced by program rank).
3. Load home state of the recruiting program.
4. Determine whether recruit is from program home state, adjoining state, or outside (dice roll based on actual school recruiting history for that recruit star rank for last five years).
5. State determination:
--home state
--for adjoining state, identify adjoining states, then determine state (dice roll based on actual school recruiting history for last five years for that recruit star rank).
--for outside, based on total pool of available recruits for that star level outside home/adjoining states of program (dice roll not influenced by school recruiting history).
6. After recruit home state is identified, load available locations in that state for recruits based on recruit star level (all locations from recruits in the last five years).
7. Determine home city for recruit (dice roll based on available locations).
All the user is going to see is a city and a state on the recruit card.
It seems so simple, but doing it right (for me, anyway) requires thousands of lines of codes and a huge Excel spreadsheet with all the recruiting data to set all kinds of things like adjoining state percentages.
My primary concern at this point is now how many lines of code it takes (an embarrassing amount), but that I write the code in such a way that it's easy to debug. As long as code is easy to debug, I don't care how long it is, but I don't want code that I can't troubleshoot easily.
Fredrik doesn't even know this yet, but when I get all this working, I think I'm going to ask him to do most of the art for this module, instead of waiting until all modules are finished. That way, when I ask people to help me test this portion, they're going to be seeing art that's well along in the process. Testing code with placeholder graphics is just not as much fun, and I want people to have fun. So each module is going to be fairly well-polished as the code is completed.
<< Home