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.

I keep on thinking it's important to have a CORE running and 
event-oriented design would not work, cause users produces events indeed 
but they don't have to became processes inmediatly; they might have to 
wait a lot. I've a lot to learn if somebody thinks otherwise i'll be 
pleased to be tought.

Concurrency problems have indeed to be taken care of, two databases it's 
a good idea like i've been told here.

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.

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?

PD: I'm from Spain sorry for my lame english xD



-- 
Posted via http://www.ruby-forum.com/.