Learning Ruby for Ares
-
Basically she means that Ares doesn't have anything like MUSH attributes which allow you to store random data on any object. Persistent data needs to be stored in a database model and the model will have to be designed specifically to hold the data that you want to store. Fortunately models are fairly easy to work with!
Here's an example of a model that I am working on now for my Space system, just to give you an idea:
module AresMUSH module Space class Console < Ohm::Model include ObjectModel include FindByName attribute :name attribute :name_upcase attribute :desc index :name_upcase reference :location, "AresMUSH::Room" reference :player, "AresMUSH::Character" reference :ship, "AresMUSH::Space::Ship" before_save :save_upcase # ----------------------------------- # CLASS METHODS # ----------------------------------- def self.dbref_prefix "C" end # ----------------------------------- # INSTANCE METHODS # ----------------------------------- def save_upcase self.name_upcase = self.name ? self.name.upcase : nil end end end -
@Darren said in Learning Ruby for Ares:
Persistent data needs to be stored in a database model and the model will have to be designed specifically to hold the data that you want to store.
Ruby also allows you to extend existing classes. You have to judge whether the data you want to store can fit onto an existing model or warrants its own.
If all you want to add is a
goalsfield, you can easily do that by just adding a new attribute to the character model. Something more complicated - like a spaceship - you'd want to define a new model for that. -
Yep very handy indeed, and something I only picked up on after reading some Ruby tutorials.
-
@faraday said in Learning Ruby for Ares:
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.
Spirit Lake has an inventory system for magical items and potions (that folks are welcome to look at if interested), but it definitely gets messy real fast if you want the inventory to limit what people can DO with things (ie, in combat). Ours do, but only via a lot of extra code.
Our code could probably be adapted fairly easily for generic items if you literally want to store lists and descs, but that's about it.
Or, @Derp , if you're wanting to build something out more fully, I can show you how I did it and it might offer some inspiration (caveat: there are often better ways to do things than the way I do things, but it does at least work).
-
My intro to Ares was mostly just tinkering with the existing game, to change a few things I wanted different, or do some early bug fixes. Really, though, Faraday has a tutorial on how to build a plugin from ground up. A simple plugin, but still one that would be very useful in-game (which I did use!). Definitely suggest that, if you're wanting to learn Ares, and by proxy, Ruby.
If you're the Thenomain type and cannot stand the "do this now, understand it later" approach to learning, then you probably want some of the classes that Faraday's suggested before moving into the "How to Ares".
-
@Darren said in Learning Ruby for Ares:
Basically she means that Ares doesn't have anything like MUSH attributes which allow you to store random data on any object. Persistent data needs to be stored in a database model and the model will have to be designed specifically to hold the data that you want to store.
In case anyone's curious... here's a couple quick examples of how this works.
Say you want to just add a simple field to all characters for their favorite color.
Penn/Tiny Version:
&favcolor *Bob=Blue # Sets Bob's favorite color get(*Bob,favcolor) # Returns "Blue"Ares Version:
class Character attribute :favcolor end Character.named("Bob").update(favcolor: "Blue") # sets Bob's favorite color Character.named("Bob").favcolor # returns 'Blue'The main difference is that we need to define the attribute ahead of time via code before we can use it. As Darren said, we can't just wing it and and set any random attribute from within the client.
ETA: Oh, and the other big difference being that Ares code is generally edited server-side and not typed raw into the client.
Now let's say you wanted to have weapon objects so Bob can have a gun:
Penn/Tiny Version:
@create Weapon Parent (some other code on the weapon parent to control what the weapon does) @create Bob's Gun @parent Bob's Gun=Weapon Parent &ammo Bob's Gun=10 &type Bob's Gun=Blaster give Bob's Gun=*BobAres Version:
class Weapon attribute :name attribute :type attribute :ammo reference :character, "AresMUSH::Character" (some other code on the weapon parent to control what the weapon does) end gun = Weapon.new( name: "Bob's Gun", type: "Blaster", ammo: 10, character: Character.named("Bob"))The main difference here is that in Ares the 'shoot' command would live in a separate command class. It would utilize properties of the weapon class; the commands are just not tied to individual database objects.
The syntax is different obviously, but the core ideas are still the same.
-
The real beauty of it is, once you figure out how models work, you can apply that knowledge to Evennia, too since they're quite similar.
from django.db import models from evennia import ObjectDB class Weapon(models.Model): name = models.CharField(max_length=256, null=False, blank=False) type = models.CharField(max_length=256, null=False, blank=True, default="Blaster") ammo = models.IntegerField(default=6) character = models.ForeignKey("objects.ObjectDB", null=True, on_delete=models.SET_NULL) > py from guns.models import Weapon; gun = Weapon(name="Pistol Mk II", character=me, ammo=10, type="Pistol") -
@Darren said in Learning Ruby for Ares:
The real beauty of it is, once you figure out how models work, you can apply that knowledge to Evennia, too since they're quite similar.
Indeed. The concept of database models is pretty universal in any kind of modern application using a database. Pretty much across the board, the programming skills and tools you learn doing Ares or Evennia will translate well to other non-MU programming.
-
I was reminded that I did a blog post awhile back on the Ares dev blog awhile back about learning Ares code by starting small and reinventing a few wheels before working up to tackle a major project. Might be of interest to some.
-
@faraday said in Learning Ruby for Ares:
I was reminded that I did a blog post awhile back on the Ares dev blog awhile back about learning Ares code by starting small and reinventing a few wheels before working up to tackle a major project. Might be of interest to some.
While I did indeed jump straight into the big projects, the coding tutorials were actually a huge help! I had tried getting into Ares several times before and each time I was quickly overwhelmed by the complexity (and I have 20 years of experience with MOO, MUSH, MUCK, LPMUD, etc so it wasn't like I was coming in completely "cold". It was still overwhelming).
This last time, I worked my way through the basic coding tutorials and they really helped me learn the system. Ruby was a different story. I was able to figure out the basics just by looking at the code, but ultimately I did have to invest in a Ruby book to learn some of the not-so-obvious things such as code blocks, modules, and how only nil and false are considered False (which actually caused me no small amount of frustration because I use short-circuit evaluation in my code quite a bit).
I highly recommend that anyone interested in learning to code for Ares, start with those tutorials. They'll definitely help ease you into what is a fairly complex game engine.
