Flaab Mrlinux wrote:
> Jonas Pfenniger wrote:
> 
>> If you take the example of Ogame. Imagine you send an attack to planet 
>> XY.
>> You don't need to know the result until user A or user B access their
>> profile and see that user A has destroyer all user B's sattelites.
> 
> I Jonas. This is not actually true: I'll explain myself. Supposse the 
> following:
> 
> 1) User A sends an attack to user B, supossed to arrive within 5 hours.
> 2) Then none of A or B users connect again due to whatever.
> 3) Just after those 5 hours passed, an user C sends an attack to user B, 
> but user B has already received an attack that hasn't been proccessed 
> cause neither the atacker or himself connected again and the user B 
> defense forces info is deprecated.
Event-driven would still work here, you'd just need to have a global 
event queue rather than a user-specific one.  For example, User A sends 
an attack to arrive 5 hours hence.  This puts an event into the queue. 
Then, whenever *anyone* checks their profile (which I assume will be a 
regular event), *all* messages left on the queue with an effect time in 
the past are processed.  This means that, in your example above, User C 
logging on to make the attack causes A's attack to be processed and B's 
forces to be suitably depleted.

> I was thinking about doing it with Php cause it's my "mother languaje" 
> for dynamic web programming, I knew about ruby on rails but i thought it 
> was more like a "PhpNuke" or "Mambo" CMS programmed in ruby, or close to 
> it.
It's a lower layer than that - more like CakePHP or CodeIgniter (if 
you've come across them).  You could write a "RailsNuke" or a "Rambo" 
with it if you wanted.

> I've read that Rails is much more fast to program dinamic web sites 
> but...as far as I know, Php is pretty effective and Rails was something 
> fast to do standard web applications but i didn't thought it could do 
> the trick for a complicated game web-based interface. Can it really be 
> usefull to do this?
Yes.

-- 
Alex