This planning session will be particularly complex, and might end up being more of a 'pre-planning' than anything else. Daily Action Points and Time Required for Action are both huge gameplay mechanics, that affect basically the entire system of the game. There's no way this stuff isn't going to change, and there's also no way that I can even start coding without this concept being fleshed out in some way.
Daily Action Points basically represent the 'energy' of the Player Character. All actions, including moving between sections, take away from DAP. DAP is a variable, that either resets, or increases, upon resting in a bed.
Resetting DAP upon resting is somewhat easier to do, codewise, than just a straight increase, because an increase creates the possibility of going over the DAP limit. This could be controlled, though, with a check upon rest, where the DAP gets checked, and if it's over a certain amount, it doesn't add any more benefits. This would allow the player to kill time, while keeping them from building up unrealistic levels of DAP. When DAP runs out, I guess I'll transport the player character to the nearest bed, but I'm thinking that if the PC's DAP is at a certain low point, I just won't let them travel anywhere.
Balancing the actions and their DAP values is going to be a real challenge, but it's the only way that I can make the time system work, and actually have a real game. I'm thinking that just straight up talking to someone won't really take too much DAP, but if you start a political debate, or invite them over, or whatever, that could end up being a lot of DAP cost, overall.
The amount of DAP required for travel, as well, would vary depending on the method of travel. Driving takes more DAP, but less time, while taking the bus is the opposite. Less DAP, but more time, and you have to pay a bus fare. Of course, with the car, you have to pay for gas. I'm going to make the gas payments a deduction with each trip, for the sake of my own sanity.
So we've introduced DAP as a concept. But what about time? Time is, really, what makes this game. Every action that you take has a time value. This is related to the DAP value, but independent of it. For example, washing clothes by hand, takes a lot of time, but not a lot of DAP. Having sex with a boy takes not much time, but quite a bit of DAP.
Each day will be split up into 4 sections. 0000 to 0600 will be night, 0600 to 1200 will be morning, 1200 to 1800 will be afternoon, and 1800 to 2400 will be evening. Now, it would be convenient if we could use those numbers, but we can't. There are not 2400 minutes in a day, and there is no 0680 hours.
The exact time will be tracked in minutes, but that doesn't really mean that things will change from minute to minute. In fact, I probably won't even bother to have 2 maps, but I'll probably have multiple event tabs for each person, depending on where they're supposed to be at what time. I don't want to get too complex with this, though. Basically, the people in the trailer park are either going to be mulling around the trailer park, or at home, or in the Temple. Maybe a few of them will have jobs. I really don't want to get too overly complex here. Maybe having 4 maps would be the correct solution to this problem. I'm not totally sure. It's something that I'll have to think about more later.
For now, let's just work out how the time system is going to work. Basically, time will be governed by a global variable, that gets updated every time the character does something. When that global variable hits a number divisible by 360, the time period changes. When it hits 1440, the date, another global variable, changes. It's easiest to have the date simply be a counter, with each 1440 resetting the clock, and adding one day to the counter. When the day hits a number divisible by 7, a weekly roll is triggered. When the day hits a number divisible by 30, a monthly roll is triggered. I'm thinking that at a certain number of days, the player will get a non standard game over. Luckily, I can have an almost unlimited number of global variables, so I don't have to fight with the engine too much, here.
Well, it's late, and I'm intellectually drained. This is essentially a starting point for these concepts, and both of them will have to be expanded, greatly, later. There's a lot to think about here, and a lot to plan, as well. These two ideas are very much the cornerstone of the game, and I'm glad that I've at least given them some thought.