Timers are trivial, you compute and store the end-time, and upon retrieval from the DB, you compare that time with the current time.

The big nightmare with timers in network play is keeping time in sync between different computers. Time on your server runs at the different speed than time on every client, there is also an offset between them (if we could compare local time on our computers, you could have several minutes difference), and there is network lag. Last but not least, there is non-zero query time. When a client asks for a result, the server needs time to get it from the DB, and/or compute it. A simple request is thus 2x network delay + 1x query delay of unknown quantities.

When a timer runs out, the client and the server should agree on when that happens. I play a commercial game where they make a mess of it, timers of 24 hours shift 10-15 seconds a day, even though I restart the timer within a second.

I don't know unity, but in theory, there is no need to run the same program at the server. You talk between client and server using a network that only transfers messages (as in, sequences of bytes), and nothing else. As long as the server runs a program that understands those messages, and returns useful answering messages, all should be fine. You can write such a program in pretty much anything.

Obviously, without unity, you won't get its functionality, so you have to implement that in another way. Not sure how much that is, for a network server.

Given the kind of questions you ask, I think you'll have a hard time grasping how to do these things. Network code is quite non-trivial, and distributed computing is complicated as well.

On the other hand, nothing works better in learning than trying it, and see what happens!

The server then spits back to me the difference between the two and the client is left to calculate from its end only.

instead of the client sending a "im done" message...

That assumes the time to send the command "build" from client to server, server checking if allowed etc, server inserting entry in db, server sending client return message, and client computing end-time is all timeless? What if server needs 5 seconds to do its work (DB very busy, for example), or network is slow?

Well I guess I can have the server send back with the elapsed time as part of the formula, a few seconds isnt a deal breaker though...As long as the DB has the correct state and the client is close enough. Unless maybe the client finishes early in which case users will be wondering why something isnt working if it relies on said building. I guess I can also send a "r u done" check after the client is done so they can agree on it. Either way if the client finishes early, the user is left with a "uh whats happening" scenario :(

I'd like this, I hack the client or the network connection, and send "done" as soon as server responds.

thats why I said instead of...no? or did I misunderstand your point?

Thanks for your patience with me :D

Also I just reread your post I just realized I don\t really need the start time, just the end time.

thats why I said instead of...no? or did I misunderstand your point?

Apparently, you know already, but I wasn't sure that was the case.

I read your post last night. Not sure if I can be of any help, but I'm making a game that requires a lot of the same functionality you need. I'm using Javascript though. Are you pretty comfortable with Unity which is why you're wanting to use it?

Anyways, if you're interested look up what THREE.js can do along with node.js and redis. I'm currently using all three for a browser game I'm working on, great thing is I only need to use Javascript for all of it.

Hey guys, I just realized a solution to a game design issue that made me drop this project but found a solution that might make me pick it up again but I realized the timer solution doesn't work in my head.

I mean yes I can save the due time of things and check by query if something is done but I realized I needed to check for it?

The issue : Not exactly a building timer at the moment but theoretically the same. So there a game called Utopia that I am loosely basing the genre from and it has armies go on attack then have a "due back" time. This is how I had it planned out, I have a database table of cities, and a table of "out armies" which has the army, time due, and city owner.

Now the issue I have is not letting every client know the army is back so much as letting the server know its back when its due.

The way I see it I have 2 options,

1. run a script every min to check for every out army - sounds computation heavy and inefficient

OR

2. Query the "out" armies every time someone checks the "at home" armies or similar action - which sounds a weird solution to me. Basically the army doesn't "officially get home" until someone checks for it from a client. Not to mention I have to repeatedly query the "out" armies. Although i think this is a better solution than 1.

But then what if I want the attack part to happen on a timer instead of instant? By that I mean theres a march time towards the actual attack then a march to come back. Then I don't even know what will trigger the attack part.

Hope I made sense ... T.T

TLDR

How does the database/server update itself without the client's cue it its time to do so?