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.
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.
On 12/9/06, Flaab Mrlinux <flaab_mrlinux@hotmail.com> wrote:
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.
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
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.
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).
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.
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.
···
On 12/9/06, Flaab Mrlinux <flaab_mrlinux@hotmail.com> wrote:
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.
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.
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?
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.
···
On 12/11/06, Giles Bowkett <gilesb@gmail.com> wrote:
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.
On 12/9/06, Flaab Mrlinux <flaab_mrlinux@hotmail.com> wrote:
> 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
>
> --
> Posted via http://www.ruby-forum.com/\.
>
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.
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
···
On 12/11/06, Giles Bowkett <gilesb@gmail.com> wrote:
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.
On 12/11/06, Giles Bowkett <gilesb@gmail.com> wrote:
> 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.
>
> On 12/9/06, Flaab Mrlinux <flaab_mrlinux@hotmail.com> wrote:
> > 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
> >
> > --
> > Posted via http://www.ruby-forum.com/\.
> >
>
> --
> Giles Bowkett
> http://www.gilesgoatboy.org
> http://gilesbowkett.blogspot.com
> http://gilesgoatboy.blogspot.com
>
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?
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.
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.
On 12/12/06, Flaab Mrlinux <flaab_mrlinux@hotmail.com> wrote:
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.
