Prev: 3D with Ruby (Ogre ?)
Next: Gem build issues Ubuntu 9.10 64 bit
From: Aldric Giacomoni on 14 Jan 2010 12:16
Zach Bartels wrote:
>
> Also I admit I have 0 knowledge of unit testing, version control,
> etc. So I probably do need some education in those areas.
>
It's like everything else - once you get past the learning curve, you'll
be fine. Prepare to stumble though. Several times. :)

> I so appreciate the links to those MUD projects, as I didn't know we
> had that many in the community. Although I am loathe to "steal" as it
> were, from other projects I definitely will want to look at them for
> ideas on how I want to approach the same obstacles.
>
It's not stealing if it's open source ;-) Just credit them!

>
> So I am definitely going to have to learn event management.
> I totally understand the mountain I have just made for myself but I
> feel pretty committed to it and I know it will take me a LONG time to
> do this. So I'm ready for the challenge. (I hope)
>
> -Zach

Sounds like a lot of fun. Let me know if you want help on any of this, I
could probably learn a lot from this too (and maybe teach you some
stuff). I can be reached there: aldric at trevoke dot net
Or if googlewave is your thing, trevoke at googlewave dot com :-)
I have found that googlewave is actually pretty nice for lengthy
discussions and planning.
--
Posted via http://www.ruby-forum.com/.

From: Phillip Gawlowski on 14 Jan 2010 12:45
On 14.01.2010 17:35, Zach Bartels wrote:

> So I am definitely going to have to learn event management.
> I totally understand the mountain I have just made for myself but I
> feel pretty committed to it and I know it will take me a LONG time to
> do this. So I'm ready for the challenge. (I hope)

The trick is to take a large, unsolvable problem, and break it down into
tiny, solvable problems.

That it is where, I think, TDD shines: It allows a lone developer to
break down a big problem into a smaller problem in the form of assertions.

Good luck with your MUD. :)

--
Phillip Gawlowski


From: Marnen Laibow-Koser on 14 Jan 2010 20:55
Zach Bartels wrote:
> Thanks for those replies all, I definitely got back more input than I
> expected. So let me just quell a few concerns. I'm afraid this is
> going to be another long post (sorry, lol)
>
> Yes, I am aware of the scope of this project. However I'll reiterrate
> that at this time, my goal is not to produce any kind of functional
> multiplayer environment.

Er...OK. Then why did you say you were building a MUD if you're leaving
off the MU part? :)

> So regarding DB issues with concurrency I
> think SQLite will fit the bill nicely.

On what basis do you think this? Have you got a reason to think this,
or is it just handwaving?

> Any attempt at a multiplayer
> game / MUD server would almost assuredly mean a rewrite / new project
> built using any knowledge I gain from building the single player
> environment - and as far as modifying it for multiplayer if I wanted
> to, I mean something small like allowing a couple friends to join in
> (ala early examples of small MP environment from the pioneering FPS /
> RTS games).

Once you have 2 users -- or 1 user doing multiple simultaneous things --
you have potential concurrency issues. SQLite is not a suitable
database in that case. Fortunately, there are enough decent database
abstraction layers for Ruby (ActiveRecord, Sequel, DataMapper...) that
if you use one (and you probably should), switching DBs later on will
not be a huge problem. Just be aware that you're likely to hit a wall
with SQLite fairly soon.

>
> Sorry if I confused anyone on that point. I simply wished to express
> my desire that the game complexity be comparable to a MUD environment
> with regards to the complexity of the world mechanics, and
> interactivity with objects / npcs in the environment itself. As
> opposed to those really early text games which while nice, still
> couldn't compare to a MUD with a good parser.

Actually, the early text games (particularly the Infocom ones) often
have better parsers than most MUDs I've played.

>
> So its safe to say while not a "throwaway" project, I intend to take
> it quite seriously and probably put it out there for fun at some
> point.

Good. Then don't hamstring yourself by refusing to consider anything
but SQLite.

[...]
>
> I can honestly say I feel SQlite is up to the particular task I have
> in mind at this stage though.

What you feel is irrelevant. What SQLite can actually do is what
matters.

> I have done a lot of thinking about
> tables, rows, and specifric column fields I will need / want and if I
> have to add an extra column or two in the future I don't think I will
> be too concerned.

Right.

> Most of the data stored in the DB is going to be
> pre-made content, such as room descriptions and stuff like that. I
> do plan on keeping a lot of run-time generated content in memory and
> then saving out what is needed when appropriate (a new item is created
> on the fly, and then it gets saved to the DB).
>
> I think my particular approach to building my individual systems and
> testing them, one at a time, before working on integrating them, will
> leave me a lot of flexibility in needed changes to design and how
> difficult it will be to change said design.

No. It will just put you in integration hell later. Follow the agile
approach of integrating constantly or nearly so.

> It leaves me a lot of
> time to flesh out ideas in my head, while I'm dealing with other
> problems, and then write them down and whatnot. Perhaps this is not
> the most efficient way to do it, but so far its worked well for what I
> perceive to be a relatively small project.

This won't be a small project, from what you've described.

>
> I have no intention of using rails at this point, as I don't really
> see a need for it for this particular case. But I will admit I know
> very little about it, and it seems like just another "web platform" to
> me so maybe I am making wrong assumptions.


>
> Also I admit I have 0 knowledge of unit testing, version control,
> etc. So I probably do need some education in those areas.

Then don't start this project until you've gained at least a little
knowledge of each. In 2010, there is no excuse for developing without
both of these in place. None.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen(a)marnen.org
--
Posted via http://www.ruby-forum.com/.

From: Phillip Gawlowski on 14 Jan 2010 21:07
On 15.01.2010 02:55, Marnen Laibow-Koser wrote:
> Zach Bartels wrote:

>> So regarding DB issues with concurrency I
>> think SQLite will fit the bill nicely.
>
> On what basis do you think this? Have you got a reason to think this,
> or is it just handwaving?

"SQLite usually will work great as the database engine for low to medium
traffic websites (which is to say, 99.9% of all websites). The amount of
web traffic that SQLite can handle depends, of course, on how heavily
the website uses its database. Generally speaking, any site that gets
fewer than 100K hits/day should work fine with SQLite. The 100K hits/day
figure is a conservative estimate, not a hard upper bound. SQLite has
been demonstrated to work with 10 times that amount of traffic."
<http://www.sqlite.org/whentouse.html>

So, yeah, obviously SQLite is not able to handle multiple connections.

> Once you have 2 users -- or 1 user doing multiple simultaneous things --
> you have potential concurrency issues. SQLite is not a suitable
> database in that case. Fortunately, there are enough decent database
> abstraction layers for Ruby (ActiveRecord, Sequel, DataMapper...) that
> if you use one (and you probably should), switching DBs later on will
> not be a huge problem. Just be aware that you're likely to hit a wall
> with SQLite fairly soon.

http://www.sqlite.org/lang.html

BEGIN TRANSACTION, END TRANSACTION, and COMMIT TRANSACTION are SQL
features that SQLite supports. ACIDity is pretty much guaranteed when
transactions are used.

--
Phillip Gawlowski

From: Seebs on 14 Jan 2010 22:18
On 2010-01-15, Marnen Laibow-Koser <marnen(a)marnen.org> wrote:
> Actually, the early text games (particularly the Infocom ones) often
> have better parsers than most MUDs I've played.

Which leads me to an observation which may not be popular around here:

If you want to write text adventures, do it in Inform6. It's a purpose-built
language which generates games that can be played on widespread standard
interpreters (available for basically every PDA I know of, for instance),
complete with a well-considered standard library of laws-of-physics suitable
for making games like this.

If you want to learn Ruby, sure, go ahead and do it in Ruby. But if your
goal is to write text adventures, Inform6 is an extremely good language for
the task.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: 3D with Ruby (Ogre ?)
Next: Gem build issues Ubuntu 9.10 64 bit