Jan 8, 2020, 7:26 PM
What's the best approach to learn Ruby for Ares, preferably while actively constructing the game itself?
Learning Ruby for Ares
-
What's the best approach to learn Ruby for Ares, preferably while actively constructing the game itself?
-
It largely comes down to preferences and learning style.
Some folks prefer to just take a basic intro like Try Ruby and then learn the rest by tinkering. The Ares coding tutorials are a good starting point once you have the basics of the language down.
Others would rather take a more in-depth Ruby course, like the ones at Udemy, Pluralsight, CodeAcademy, or many others. I don't have any specific recommendations on that front.
It's worth noting that if you also want to make web portal modifications, you'll eventually need to learn Ember Javascript in addition to Ruby. But it's suggested that you get familiar with the MU-client side of things first before diving in to the web side.
I'm not sure what you mean by "while actively constructing the game". Unlike other MUSHes, Ares comes with much of the code you'll need out of the box. So you can still play, chat, etc. while you're off crafting whatever skill/magic/etc. systems you want custom for your game in a separate test/development instance. Typically you'd make sure the code was solid and well-tested before 'promoting' it from the test instance to the real game. So you can definitely do that in parallel with setting up the wiki, building, configuring the plugins, etc.
-
I found deciding on something to achieve and then just working to achieve that thing. Like I wanted to be able to have 9 stats and be able to view and set those stats. So that's what I worked on first.
In addition to Ruby tutorials I would highly recommend digging into some existing plugins to see how an established coder does things. I learned a lot by deconstructing the Cortex and FFG plugins when working on my own.
-
@faraday 's intro to coding on Ares is def. a good place to dive in.
-
@ZombieGenesis Yeah, having a specific project in mind helps a great deal.
It's good to start with a modest project, as you described.
Diving in with "I know no Ruby at all so my first project shall be a full-fledged Shadowrun chargen" is probably not going to have a happy ending.
-
So, I've been learning Ares, and looking at a couple of things:
Where you start really depends on how much prior knowledge you have.
If you have a good working knowledge of python, for instance, y ou can probably just pick up a ruby syntax guide and go from there.
If you've got a decent grasp of at least programming logic, you could start with something a bit more fast-paced. The Well-Grounded Rubyist I've found offers a decent speed and doesn't hand-hold you through every little thing about programming ever, presuming that you already know how most of this works and they just need to teach you how ruby applies to that basic framework.
-
I started with an inventory system, which I promptly scrapped because it was a bad idea to mess with stuff in aresmush/engine/aresmush/models. I've since re-implemented it as a standalone plugin. After that I did a space system for a Firefly game that I am still working on and off. Next was a domain system for a L&L style game which I am also still actively working on.
I had no experience with Ruby before this but I've been working with Evennia for close to 2.5 years now and that experience made it super easy to pick up Ruby.
-
These are all very helpful things! So I have a good start.
That Udemy course looks pretty good and is on sale. I might poke at that.
-
Some public libraries offer free access to tech training sites like Lynda.com, which has several Ruby courses available.
-
@Snackness Since Udemy is having like a 95% off sale I got the Udemy course for $10 lol.
But I'll keep that in mind about Lynda, very useful!
-
Is your inventory system on Github? Would you be willing to share it? I've been thinking of starting one for my own game next, trying to tackle the ins and outs of design, and I'd love to see what you've done with yours.
-
@HelloProject This is deliciously fun
-
@Tyche said in Learning Ruby for Ares:
@HelloProject This is deliciously fun
The guys I game with (who are developers) are loving this.
Well, one spoke up and went 'Oh hey! It's the book I learned Ruby from.'
Saying the quiet parts out loud since 1996.
-
Install Ares. Break everything. Reinstall Ares. Break everything again. Ask @faraday for help. Fix everything. Go do her tutorials. <.<
-
@Derp said in Learning Ruby for Ares:
Is your inventory system on Github? Would you be willing to share it? I've been thinking of starting one for my own game next, trying to tackle the ins and outs of design, and I'd love to see what you've done with yours.
Not yet. It's still missing some things (like commands for give, drop, get, etc) which I haven't needed since it's just me working on the game by myself. That, and I let myself get sidetracked by the space system (which, admittedly, is much more fun to work on).
Updated to add:
Honestly, now that I've done it, I'm thinking about not using it since objects are really little more than just "desc" holders and there are other ways to do that without needing real objects for it. -
@Auspice said in Learning Ruby for Ares:
Well, one spoke up and went 'Oh hey! It's the book I learned Ruby from.'
Yeah it's great, but I think it works best for someone who already is familiar with another programming language. My impression was that it wasn't well-suited to somebody learning from scratch. YMMV.
-
I tinkered a bit with it. It looks a bit familiar, kind of like the C++ and other such formats friends have taught via Twitch streams. It all goes over my head, but maybe someday I'll learn how to mu* code using this.
-
@Darren said in Learning Ruby for Ares:
Honestly, now that I've done it, I'm thinking about not using it since objects are really little more than just "desc" holders and there are other ways to do that without needing real objects for it.
That's why Ares doesn't come with an inventory system built in (or "thing objects" for that matter). Everything they're traditionally used for can be done in different ways. There's a discussion about this in the chopping block article.
An inventory system could still be useful in conjunction with other systems though. FS3 for instance relies on storytellers to adjudicate sensible weaponry. The system will let you equip a rocket launcher, but that doesn't mean you have a rocket launcher.
If you wanted to eliminate the human factor there and track someone's gear, you'd need an inventory system. Most likely the basis of it would just be a simple list of gear items, which is simple enough. But then you'd also need to figure out how people get gear, what gear is available, what the gear does, how it relates to other systems (like combat) ... all of which is highly game-specific. It can be done, but I'm doubtful that it can be done generically.
-
I'm leaning toward a more traditional inventory system based on objects for a couple of reasons, really:
First -- while what I want to do could probably be done with a database, I'm not sure how to do it in a database, and it might be more complicated.
Second -- because the objects in some games provide a pretty complicated system of stat bonuses that I can at least get a grasp on with object parameters, and it lets me link it to a player-managed inventory system in a more direct way.
DnD, for example, has objects that provide stat bonuses, but only certain types of objects stack, and only one 'type' of object can be worn per object slot. I know that if I create an object, I can just give it specific parameters for those things:
name = "Circlet of Wizardly Mojo"
slot = head
bonus_type = "enhancement"
bonus = skill.raise(Spellcraft,2)
current_container = "Bag of Holding"
equipped? = falseOr whatever.
When another object is equipped, it'd be pretty straightforward to just code a method that wipes the existing bonus types and recalculates. I don't necessarily have to worry about stacking bonuses if I just have it run through a list and say 'if the bonus on this object is less than the current bonus, don't set it, otherwise set it'.
I wouldn't know how to begin doing that in a pure database system, and i"m not sure that it'd be as clean.
That said, I'm always open to being told I'm a big dummy and that there is a better way.
Racism isn't Tinkerbell. It doesn't need you to believe in it for it to exist.
-
@Derp said in Learning Ruby for Ares:
I'm leaning toward a more traditional inventory system based on objects for a couple of reasons, really...First -- while what I want to do could probably be done with a database, I'm not sure how to do it in a database, and it might be more complicated.
Well... if you want to store something in Ares dynamically, you're gonna store it in the database. There's just no other way to do it. (By dynamic I'm excluding static configuration settings, like 'a broadsword always does d6 damage'. Those you can chuck into config files, like FS3's weapons config.)
The difference between Ares and other MU code systems is that most traditional MU code systems have four classes of objects - Characters, Rooms, Exits, Things. Things being the "yeah anything that isn't one of the above gets shoved in here, and you can kinda use parentage to classify them". They also then have a separate storage system for mail and channels (typically).
Ares doesn't really work that way. It has the big three types of objects (which we call database models in AresLand) - Characters, Rooms, Exits. But then it also has a zillion more. Scene. MailMessage. ForumPost. Pose. Damage. PageMessage. Channel. WikiPage. etc. etc. etc.
So there's nothing wrong with creating an inventory system based on objects (database models). What I was saying is that whatever system you came up with, the db models are going to be specific to your inventory system, and not some generic "Thing" object that could be repurposed easily in some other system and/or game.