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

[Flaab Mrlinux]

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

 

[David Vallner]

--------------enigD1391864393F89C8266C6645
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 ma= y
need updating.
=20

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 ;=
P

David Vallner


--------------enigD1391864393F89C8266C6645
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFeuGJy6MhrS8astoRArTMAJ0W2wYNWzZbvFjcyMmwvms7IWDWewCfUe+3
PBhjL1MKSs/Jkz3X8KO43gs=
=DAli
-----END PGP SIGNATURE-----

--------------enigD1391864393F89C8266C6645--

 

[M. Edward (Ed) Borasky]

Good afternoon everyone.
[snip]
Can this be done?

What's the business model?

 

[jungans]

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).

 

[David Vallner]

--------------enigBAFC392469BBD6FE0896597E
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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

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 Vallner


--------------enigBAFC392469BBD6FE0896597E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFfCQRy6MhrS8astoRAsuJAJ0WBmNk/wB71t1qzYspPyIbCb5g0ACeKbsX
6FQsnRCSCJIDgQPdZ2R4kBg=
=cVfA
-----END PGP SIGNATURE-----

--------------enigBAFC392469BBD6FE0896597E--

 

[Flaab Mrlinux]

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

 

[Giles Bowkett]

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.

 

[Giles Bowkett]

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.

 

[Alex Young]

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.

 

[Flaab Mrlinux]

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.

 

[khaines]

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 Haines