[ONLINE GAME] Ruby Core + Php FrontEnd (open)

Good afternoon everyone.

I’ve been thinking around this for a long time. I want to program a
Online Estrategy Game (sort of Ogame style) and I just had technical
problems. But since i learned ruby I think i might just have found the
solution and i would like to check out your opinions.

My main problem was…Fine, players will have their empire and can do
certaing things (attacking, organizing their army, creating new fuel
sources, etc) and those actions change/create lines in the game
database. That’s cool by now and had no problem with it, Php would do
the trick. But the problem is that the GAME core has to be running and
executing actions when neccesary. For example; an attack takes some
hours to arrive the attacked city, and depends of distance, speed of the
army, etc. Fuel sources creates fuel and arms but also takes some time.
This is why i need a CORE to be working all the time (or almost).

So this is what i’ve thought; I’m gonna have a Web Based Php Front-end
for the players to comunicate with the game. And a Ruby Core program
sinchronized with Cron to be launched every 3 minutes for example. That
Core will do all these things i can’t do from Php, catching MySql files
that tells it what to do, do it, and update those MySql fields which may
need updating.

Can this be done?

Thx

Why oh why are you even mentioning PHP? Do you not know of Rails? It
will
make your life a ton simpler, trust me.

As for the design question, you can check out the BackgrounDrb plugin
for
Rails; I can’t remember if it does cron-like jobs, but I think it does.
Otherwise, a system cron would work ok as long as the only method of
communication between the front-end and back-end is the database,
otherwise
it starts getting very hairy if you’re passing data around through files
or
pipes at different times.

BackgrounDrb: http://backgroundrb.rubyforge.org/

Jason

Flaab M. wrote:

So this is what i’ve thought; I’m gonna have a Web Based Php Front-end
for the players to comunicate with the game. And a Ruby Core program
sinchronized with Cron to be launched every 3 minutes for example. That
Core will do all these things i can’t do from Php, catching MySql files
that tells it what to do, do it, and update those MySql fields which may
need updating.

Concurrency errors beware. Whatever the frontend, how do you plan to
communicate with the backend? Since this is write-mostly database work,
what architecture do you plan to use?

You might want to consider two database layers, one to store things that
happen between these three-minute cycles (to provide immediate feedback
to players), some action log (message queue) you’d sort through
depending on what the evaluation cycle is (think M:tG turn phases), and
then a second DB layer with the long-term state of the game.

Hrm, did I get taken away on an ill-informed architecture rant? Ah well
:stuck_out_tongue_winking_eye:

David V.

Flaab M. wrote:

Good afternoon everyone.

[snip]

Can this be done?

What’s the business model? :slight_smile:


M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC§
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

So this is what i’ve thought; I’m gonna have a Web Based Php Front-end
for the players to comunicate with the game. And a Ruby Core program
sinchronized with Cron to be launched every 3 minutes for example. That
Core will do all these things i can’t do from Php, catching MySql files
that tells it what to do, do it, and update those MySql fields which may
need updating.

Why not just use PHP for the cron job? It doesn’t seem like a good
decision to write the app in two different languages (harder to
develop, harder to maintain, etc).
Also, concurrency is not an issue as long as you use transactions to
enforce integrity at the application level (i.e.: if an attack is about
to occur, damages on both sides (attacker and victim) have to be
updated inside a single transactional block).

Flaab M. wrote:

/ …

So this is what i’ve thought; I’m gonna have a Web Based Php Front-end
for the players to comunicate with the game. And a Ruby Core program
sinchronized with Cron to be launched every 3 minutes for example. That
Core will do all these things i can’t do from Php, catching MySql files
that tells it what to do, do it, and update those MySql fields which may
need updating.

Can this be done?

The question is not whether it can be done, the question is why would
one
want to do it this way. In modern times a program like this is
event-driven, not clock-driven, for excellent reasons.

Paul L. wrote:

The question is not whether it can be done, the question is why would one
want to do it this way. In modern times a program like this is
event-driven, not clock-driven, for excellent reasons.

If it’s a turn-based game, why not? Besides, the architecture would be
similar anyway, you’d just evaluate the player actions in discrete
ticks, not immediately.

David V.

David V. wrote:

Paul L. wrote:

The question is not whether it can be done, the question is why would one
want to do it this way. In modern times a program like this is
event-driven, not clock-driven, for excellent reasons.

If it’s a turn-based game, why not?

Responsivity? The fact that the processor would not bother with the
process
unless there was a need, and the more need, the more attention. The
usual
reasons for event-driven design.

Besides, the architecture would be
similar anyway, you’d just evaluate the player actions in discrete
ticks, not immediately.

Yep, true. I’ve always though event-driven made more sense in a case
where
there might not be any processing required at a particular time, or
conversely, when there were a lot of players and a lot of attention
needed.

In detail, when there are no players, the timer gets the processor’s
attention for no reason, but when there are a lot of players, the timer
cycles might begin to overlap, a contingency that must be handled in the
game routine.

Neither of these issues comes up with an event-driven design.

Hi Flaab,

I don’t think that mixing two programming languages like that is a
really
good idea. What I would do in your case is use a producer / consumer
pattern.

Who cares that the fight didn’t occur exactly at the time you say it
will ?
What’s important is that when the user consults their data, that they
are up
to date.

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.

And since the data only concern user A and B, you only have to caluclate
those results on user A or user B’s page access.

Now that I’m thinking of it, this may be why Ogame only calulates the
user’s
score on a daily basis, since it requires to calculate all expired
actions.

Jonas P. 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

You know, I just read my own post and it seems kind of mean, but
honestly, I’m looking out for you. Avoid this method. It is a bad
idea.

Rethink your design. The proposed architecture is a recipe for failure
at best and a recipe for insanity at worst.

To answer your question, can it be done, God, I don’t know and I don’t
want to find out. Probably not without significant brain damage.

Flaab,

If you want a PHP comparison to Rails, look at Cake (which is, of
course,
made in the likeness of Rails). Rails is simply a framework to make
developing data-driven websites easy. People have written CMSs and
whatnot
in Rails, but they are not Rails.

The gist of what you want to do has been done before, check out
TribalWars (
www.tribalwars.net). This game does everything time-based, though there
is
no access to the code so I don’t know how it goes about it exactly.

I will reiterate what has been said here: mixing languages and
technologies
and trying to get them all to agree on what’s going on is something you
just
don’t do.

Seriously, check out Rails (www.rubyonrails.org) and the BackgrounDrb
plugin
(http://backgroundrb.rubyforge.org/). I’m sure something can help you
there.
Otherwise, if you want to stay with PHP, do it all in PHP.

But yeah, good luck on the project!

Jason

I’ve read carefully your posts =)

So u encourage me to program the game using Ruby(Ruby + Rails) entirely
design right?

What the heck let’s have a try to rails. Can u recommend me a good rails
tutorial?

About using a event-driven design and no-need-no-stinky-core…i’ll
think about it but using a process queue that might became really big
sounds a not-useful.

Thanks a lot.

Flaab M. wrote:

  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.

Rails tutorials:

http://rails.homelinux.org/

Book: Agile Development with Rails

Docs: api.rubyonrails.com

Jason

On Tue, 12 Dec 2006, Jason R. wrote:

If you want a PHP comparison to Rails, look at Cake (which is, of course,
made in the likeness of Rails). Rails is simply a framework to make
developing data-driven websites easy. People have written CMSs and whatnot
in Rails, but they are not Rails.

CakePHP is SLOOOW, though. Rails is slow, yeah, but Cake is SLOW. For
a
game with a lot of simultaneous users, Cake will exact a hardware
penalty
for using it, for sure.

I will reiterate what has been said here: mixing languages and technologies
and trying to get them all to agree on what’s going on is something you just
don’t do.

Why? People use more than one language on a project all the time. It’s
not a bad thing to do. Interfacing between discrete pieces of a project
written in different languages is little different from interfacing
between discrete pieces written in the same language, unless one is
using
some language specific feature (like Marshal) in the interface.

What he wants to do, writing the user interface in something he is very
familiar with – PHP – and the backend in something more suited to that
role – Ruby – is perfectly practical.

Kirk H.