So I was in the middle of building a text based browser strategy game but fear that there is no one interested in those anymore...So I am looking into making something like game of war without pay to win ideally but I am at a loss how the building timer works.

Basically I need a timer that runs even when you are offline and notifies the client when its done if they're online and shows it ticking down on the client. I assume I need to save it to a database at some point the completed building as well. I feel like I am missing something simple because frankly I couldn't find any questions regarding this topic.

Also do I need an instance of unity running on the server for this? I am not super new to programming but I am new to online multiplayer unfortunately.

Can someone enligthen me please? Thanks in advance.

Also are these type of games easy to make?

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!

I wouldn't necessarily do a _timer_ at all.

A timer implies some kind of eventual state change. It implies an eventual computation and an eventual event. If you start building, you must send an event to all players, and then upon completion, send a second. And know when the completion happens, efficiently. That's a lot of stuff.

Instead, just store the building as state with its initial build time and its expected completion time. Send both to the clients in a single event. Now all clients know when the building will be completed and can update themselves accordingly with no further involvement from the server.

For big Web-scale MMO things, you want to avoid every possible computation you can. Work in the minimal state changes possible. Create the building with all state it needs to know its current and eventual building state. If something changes the expected state (additional resources put into construction, for example) then update the state and expected completion and send that event to all clients (they'll need an event anyway to make the proper UI changes and the like).

Minimal effort/data/events.

Thanks for the replies. Ok let me get this straight, so when a user orders a building, I insert into the database the userid, building, the time on the server and how long it will take. The server then spits back to me the difference between the two and the client is left to calculate from its end only. I can just leave the "complete" state marking as a comparison in the database if server time > timestamp + construction time for whoever needs to know instead of the client sending a "im done" message... correct?

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

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?

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

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

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?

Since you mentioned it as alternative solution, I thought I'd mention a possible security problem with this approach :)

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.

Well my original plan as was mentioned before was just a text based browser strategy game - I was only planning to use mysql php html css and javascript. I didn't actually give much thought on what else I should use should I go with the game of war like route yet I am still looking into it if I can pull it off or not. Unity was the first of the list because yes I have used it before though not much online multiplayer stuff. I figure it would get me finished the fastest regardless of what new things I need to learn for it. But I am pretty open to other things - gotta learn something somewhere no matter what anyway. Thanks for letting me know of these~

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?