Serious Issue With Energy, probably Metal
Moderator: Moderators
Re: Serious Issue With Energy, probably Metal
This wouldn't quite solve the issue, because it still means construction could take all of the energy available before any units with fixed costs are even given a chance to subtract
Re: Serious Issue With Energy, probably Metal
In the system I've developed:
1. All fixed costs are removed from income every second, and totaled. So you're working from what's left, until the next second.
2. Units aren't polled wherever possible. Instead, events trigger spending, and new construction / destruction removes from a total that's maintained. IOW, if your Units costs 50 Power /sec. to run, that's what it costs, there's no need to ask it again every SlowUpdate.
The only part that must be polled is building, which unfortunately triggers per-frame costs.
I've been thinking that it'd be better to just remove that and stick them into to a table, and set their % built manually, to cut down on cyclic stuff.
That obviously won't be as pretty as polling them every frame, if I keep the OTA-style fade-in, so I might have to handle construction graphics a bit differently, or just go all the way and replace workertime with a substitute that could function in a different order- i.e., how much workertime was applied over this period, get what that should cost, determine real status of Unit being built.
But for now, it's a per-frame operation, it's compatible with the default drawing method.
1. All fixed costs are removed from income every second, and totaled. So you're working from what's left, until the next second.
2. Units aren't polled wherever possible. Instead, events trigger spending, and new construction / destruction removes from a total that's maintained. IOW, if your Units costs 50 Power /sec. to run, that's what it costs, there's no need to ask it again every SlowUpdate.
The only part that must be polled is building, which unfortunately triggers per-frame costs.
I've been thinking that it'd be better to just remove that and stick them into to a table, and set their % built manually, to cut down on cyclic stuff.
That obviously won't be as pretty as polling them every frame, if I keep the OTA-style fade-in, so I might have to handle construction graphics a bit differently, or just go all the way and replace workertime with a substitute that could function in a different order- i.e., how much workertime was applied over this period, get what that should cost, determine real status of Unit being built.
But for now, it's a per-frame operation, it's compatible with the default drawing method.