I worked with Ruby on Rails professionally for a little under a year,
but then got a new job and have been a flash developer for the last 2.5
years.
So I'm extremely rusty with Rails.
[b]What I'm doing:[/b] I want to make a small browser text based RPG
with the option to use flash. (So people can play at work).
[b]The Focus:[/b] Ideally I'd like people to be able to control their
actions in the fight instead of just reading through the log of their
auto attacks after.
I'm thinking you can have 8 slots to remember spells/abilities to be
able to use while in combat. Kind of like old school EverQuest.
[b]The Problem:[/b] I want to include PVP as an option. So if you're in
a zone and you see in your /who list another player from the opposed
faction, you can choose to attack them. But how do I implement this so
they can join in turn based combat? I was looking at Smartfox Server
lite, but this is just a project for friends and friends of friends. I'm
with HostGator and I really don't think I can install something like
Smartfox on the shared hosting server.
Also for Chat, I was thinking of just having a database that stored the
last 30 or so entries and updated them on refresh. Is there a better way
to implement that on a shared hosting server?
Any ideas or theories would be really appreciated. If I can't find a
solution I may have to change up how combat works so that you just
manage the AI of your character and when to use their spells. Something
like in Dragon Age.
I think at the very least, you'll need to use a Xen-based VPS where
you get root access, such as a Rackspace Cloud server.
I'd look at messaging/queuing options, such as Jabber/XMPP or AMQP
implementations. That'd work for both managing a turn-based combat as
well as chat. You'd write it like the old MUDs. If you're willing to
sacrifice HTML4 support, you can try the Websocket stuff in HTML5 and
require all players to install browsers that support it (such as
Chrome and Safari).
I wouldn't try using a browser-refresh scheme written using Rails; a
background process at the very least or a separate server using
, or even using Node.js for the server-side. The Rails side would work
well if you take advantage of REST to describe resources (such as,
descriptions of game objects and user avatars), but not specifically
to manage the combat (ephemeral, state-ful, evented system vs. the
shared-nothing, stateless system that Rails and the Web is based on).
So I think Redis works better than a SQL db for handling the combat
states itself.
The downside is that this starts getting pretty intricate. The beauty
of the auto-combat system in current web-browser games is that they
give the *llusion* of control, which is enough for most players (see
Creating the illusion of accomplishment - Wolfire Games Blog).
If you implement AIs as part of the gameplay, I suggest looking at
making its perceived user control of the new system match the
perceived user control of the old system.
A lot of that was far over my head. But the mention of HTML5 Web sockets
was something I was unaware. I could easily force my userbase to use
HTML5 as it's just going to be friends. There won't be any profiting in
this project at all. Just something fun for maybe 10-20 people to do.
and it has the advantage of letting you put together an app for the
iPhone/iPad while bypassing Apple's requirements for AppStore.
When Chrome beta first came out and I heard it had the ability to
create app shortcuts on the desktop, I realized you could package a
web game in what appears to be a desktop app. The installer would just
check if Chrome is available and if not, it'd download it for you.
Chrome comes with Google Gears, so you can use a local SQL store,
though I'm not sure how well that'd work with your game. Maybe as a
cache.
I'd like to talk to you more about the game off this list/forum. Using
Rails to write a web-based turn-based game has been something I've
been messing with in my head for a while.
