On Tue, Jun 8, 2010 at 1:00 PM, uaca man <uacaman@gmail.com> wrote:
> This would work except for one thing, the building may affect another
> buildings, Consider this:
>
> the user starts one construction that will finish in 10 minutes and the
> building will give a bonus of +5 gold each seconds for the user. This has to
> be available in the seconds that the build is done and not one hour late
> because the user will lose the bonus for one hour.
>
Sounds like you need to take a big step back and figure out what
overall systems architecture makes sense for a real time gaming
platform.... Couple of suggestions:
1) If you need real time events you do them where you need them: on
the front end, where the user interaction is happening. Do not
attempt to code gaming rules and logic into database triggers and back
end relationships (though you might store gaming rules etc. in a
table).
2) Think of the front end as changing states as the user interacts
with it, then figure out what queries need to be made to correspond to
the changes in state. For example, it is unlikely the user needs the
amount of "gold" updated every 5 seconds. Rather, they need to know
how much they have on hand when they go to use it. At that point, you
query for the old balance, find the last updated time, how many
buildings have been completed since then and for how long and figure
out what the new gold balance is. Update the new balance at that
point (with a timestamp), and the front end goes on it's merry way...
--
Peter Hunsberger