Development pointers

ID:265804
 
Dec 18 2007, 8:23 am
I really want to create a RPG, but I never made one before (I tried though), nor have I played many. Could anyone give me development pointers? Especially design and RPG-related programming tips.
Dec 18 2007, 9:39 am
If you're going to have a HUD, only create one reference. Then, instead of creating new ones for each user, simply add reference to the ones already existing. (Of course, there might be some things you may NEED to have for each user)

var/list/hudObjs = newlist(
    /obj/myHud1,
    /obj/myHud2,
    /obj/myHud3,
    /obj/myHud4
)


client.screen.Add(hudObjs)


You could help fight the creation of unnecessary objects this way!
Dec 18 2007, 9:55 am
In response to Cheetoz
Although that's an excellent trick, I was asking for RPG-specific coding. How would you handle MUD rooms? Combat? Magic?
Dec 18 2007, 9:56 am
I'm not sure if it'll be helpful, but here is what I have to say.

Firstly, RPGs are in general pretty simple games to make. They are probably the most common type of game on BYOND due to how easy they are to make. They don't require any complex or hard to make systems, nor do you need an excellent knowledge of BYOND to make one. About the most complex system a RPG would use I'd say is a battle system that is similar in nature to most JRPGs, but most online RPGs don't use turn based battle systems.
However, RPGs are very content heavy. Take a board game, Chess would be a good example. Chess is probably harder to code and more complex than the vast majority of RPGs, but once it has been coded you don't need to add new items, enemies, levels, skills, quests and whatever else to it. With a RPG first you make a system to handle things like equipment and equipping/unequipping them (which is pretty simple), then you add hundreds, maybe even thousands of pieces of equipment, you make a system to handle quests, then you actually add quests.
This is what takes most of the time spent making a RPG. Making all of the systems needed doesn't take too long to do, adding all of the content to the game takes a lot longer to do.
As for the process of making a RPG. What I tend to do is firstly make all the systems I will need or probably need. Then I will add content (though I find adding content REALLY boring and never get past this phase of development). That generally brings the entire game together.

Also, I know it is important for all types of games, but plan things out first. In a RPG there is usually a lot of content, and it is easy to get lost in it all and forget what parts of it do (or even that they exist!). So having a detailed plan of things can save yourself a lot of trouble.

That is what I think and what I have confronted over the years, so other people might disagree (and if they do I will SMASH their skulls in >:[). But yeah, I really don't think making a RPG is a hard or complex process compared to other genres of video games, it is just longer (and more boring).
Also, I am only talking about things in reference to BYOND, which provides a lot of basic things for people and cuts out the need to make some of the more complex RPG systems (more specifically, an inventory system).
Dec 18 2007, 10:32 am
In response to DivineO'peanut
Well, a MUD is a very specific kind of text based RPG game. There are several MUD projects to be found, specifically those by Alathon (http://developer.byond.com/hub/Alathon/BMUD and http://developer.byond.com/hub/Alathon/Intermundia) and Dan's MUD stuff (http://developer.byond.com/hub/Dan/mud). You might also want to look into some of the parsers out there by Abyssdragon or Ebonshadow.

The mud projects deal with room handling, but not really combat, magic, etc. (As an aside, DM has built in support for "rooms"- they are areas without map location.) Part of the reason is that such systems should be tailored to your game vision. For example, combat can be a hit roll/AC/HP system ala D&D. Or it can include a complex wound location tracking system. Or maybe it is based on move combinations typed by the user ala KAVIR's Gladiator Pits. Or perhaps it is a swashbuckling theme where taunts and maneuvers drive combat. Or even a social conflict system where players select responses to each other's statements.

For my mud project, I use a fairly complex system for combat and injury. Combatants compare skill in a variety of areas and have the opportunity to evade, block, or even reverse and riposte on melee attacks in an automated system. Wounds are tracked by location and may limit actions and generally lower abilities from pain. Blood loss has not been implemented yet, nor has limiting of fatal injury to body and head wounds (except from blood loss). Wounds heal over time, faster is kept clean and properly treated, possibly growing worse with poor/no treatment. I intend to add a scarification system at some point so that major injuries will leave a mark. Permanent disability is still in the air, but I am inclined to not include it as I believe it would hamper fun.

Magic is another area that should take some thought and design. My current approach is to divide magic into skill sets by type (animism, necromancy, pyromancy, etc.). "Spells" can be cast from written instructions and rituals such as scrolls or pages, which can be compiled into books ( often called grimoires). Certain talismans, fetishes, etc. can increase the potency or ease of incantations. However, magic is risky, and is likely to be fatiguing at the least. Channeling greater power can invite disaster resulting in injury, death, or far worse.... Additionally, even successful wizards are likely to be influenced by the magic they wield over time. So a necromancer might grow increasing skeletal and gaunt or kill foliage by his touch, while a fire magus may acquire glowing eyes, golden skin, or the scent of brimstone. Such is the price for trafficking in such arcane power.
Dec 18 2007, 9:00 pm
0x30567895
0x3F56b9a2
0x2C82402D
0x1E50390A

More seriously, associative lists are perfect for equipment. Have a 'equipment' list for a character that's just a list of text strings - each string is a location. For example:

list("left hand", "right hand", "torso", "head", "neck", "pants")


And then give items a procedure that returns a constant list - the places they can be equipped in:

list("neck") //Can only be equipped on the neck

list(list("torso", "pants", "head")) //Simultaeneously takes up the torso, pants, and head slots.

list("left hand", "right hand") //May be equipped in left or right hand slots.

list(list("head", "torso"), "pants") //May be equpped in "pants", or in "head" and "torso"


When items are equipped, store a reference to the equipped item as the association for all the slots it is equipped in.

Works really well. Remember to be environmentally friendly, though - if a mob has nothing equipped, null out its "slots" list. It doesn't need it. You can instantiate a null slots list if you want to use it for something.
Dec 19 2007, 2:10 am (Edited on Dec 19 2007, 6:31 am)
In response to The Magic Man
The Magic Man wrote:
I'm not sure if it'll be helpful, but here is what I have to say.

Very helpful! Thank you (though I disagree RPGs are easier to program than chess ;-).

Also, I know it is important for all types of games, but plan things out first. In a RPG there is usually a lot of content, and it is easy to get lost in it all and forget what parts of it do (or even that they exist!). So having a detailed plan of things can save yourself a lot of trouble.

My problem with RPGs is that they are very content-dependant. I barely come back to RPGs I finished, and I fear other people don't do that too. It just doesn't have that 'I want a rematch!' feeling like board games or fighting games have.
Dec 19 2007, 2:17 am
In response to Jmurph
Magic is another area that should take some thought and design. My current approach is to divide magic into skill sets by type (animism, necromancy, pyromancy, etc.). "Spells" can be cast from written instructions and rituals such as scrolls or pages, which can be compiled into books ( often called grimoires). Certain talismans, fetishes, etc. can increase the potency or ease of incantations. However, magic is risky, and is likely to be fatiguing at the least. Channeling greater power can invite disaster resulting in injury, death, or far worse.... Additionally, even successful wizards are likely to be influenced by the magic they wield over time. So a necromancer might grow increasing skeletal and gaunt or kill foliage by his touch, while a fire magus may acquire glowing eyes, golden skin, or the scent of brimstone. Such is the price for trafficking in such arcane power.

Personally, I don't like the modern approach to magic. The concept of 'magic' is generally something that can't be explained; a god-like power of some sort, and yet RPGs such as DnD treat it like it's some obvious-by-itself thing. I do feel that magic is one of the signatures of RPGs, but I also object that it should be implemented in this manner.
Dec 19 2007, 2:42 am
In response to Jp
Yeah, thats a good approach, though you don't have to use an associative list for it, also saving strings in the process, you can just use index numbers. 
mob/var/list/equipment = new

#define LEFT_HAND 1
#define RIGHT_HAND 2
#define TORSO 3
#define PANTS 4

//producing basically the exact same effect in usage:
M.equipment[LEFT_HAND] == x
Dec 19 2007, 3:57 am
In response to DivineO'peanut
Yeah, I agree that magic is more of a literary device than anything and quantifying it destroys some of the mystery and ... well... magic. This is especially true when magic is seen as little more than the equivalent of military tech. IE magic missile spells, enchanted items are primarily enhanced arms and armor or combat related, etc.

OTOH, mythic and fantasy literature is largely defined by a supernatural element. Without it, it's historical fiction. And players often want to play the role of someone with access to such strange powers. The key, I think, is to carefully plan the scale and scope of player magic. My approach is to limit player information somewhat and avoid obsessive number reliance and related contrivances such as "magic points/MP". While such may be fine for a combat "RPG", I am aiming for more of an interactive fiction approach. Player magic is more akin to hedge wizardry and doesn't generally approach the power levels of demi-gods, dragons, etc. Players can tap into more than they can control (you can summon that demon, but you better have some way to persuade it when it gets here...), so I think it makes for an interesting dynamic.

Again, I think it all goes back to illustrate the need for careful design and a coherent vision of the game.
Dec 19 2007, 3:32 pm
In response to Jmurph
Attempting to balance a game through the control of information is a very, very bad idea. A player WILL, eventually, figure everything out, then proceed to post it on a webstie, at which point every player knows about it. Not to mention it's just plain obnoxious.
Dec 19 2007, 8:32 pm
In response to Kaioken
I'm pretty sure you need to start specifying sizes for lists, then. My approach also means that you can have monsters with different slots without creating a wealth of constants.

But yes, they're basically equivalent.
Dec 20 2007, 5:12 am
In response to Garthor
It depends on the approach.

Sometimes it is better to limit a bit to increase immersion. Sure, you could say "You hit for 240 damage in the lower leg." Or "Your riposte connects slashes deep into the guard's calf, spraying deep crimson blood!". Both tell the player the information, but one limits it to the context of the game. Likewise, telling a player that they can't quite make out the runes inscribed on the parchment is a bit more satisfying than ,"You fail your Arcane Lore check by 10."

It's not used to "balance" but to set theme. The game uses a zero sum approach for balance. Not hoping players won't figure out effective combinations. So, players will likely discover that leather armor isn't great against most attacks, but is light and quiet and that plate and chain is a solid armor, but heavy and noisy. It is unlikely that they will figure out the exact numbers, but it isn't necessary either. The game does not rely on optimizing every point of adds.

And just because a player *does* figure out something doesn't mean they even know it. That is one of the fun parts of information control. So long as it isn't confusing or frustrating, players will determine roughly how it works and guess at the rest. The behaviors that develop from this are often quite entertaining and can add alot of depth and personality to a game. I am reminded of some MUDs where the basics were clear enough, but there was a lot of speculation and contradicting ideas on the specifics. So some players thought certain charms and talismans did one thing, others thought differently. So it made for neat schools of thought and variety.

In short, some mystery in a game can be good- it keeps it novel. Pointless obfuscation, however, is definitely frustrating.
Dec 20 2007, 5:17 am
In response to Jp
First of all, a neat idea.

How well does this work with the internal list limit? It seems like you will be assigning at least one list per mob instance and likely several for each obj. Couldn't you avoid this by simply defining constants for the wear locations and then allow or reject in a mob proc (IE check_can_equip(slot))?
Dec 20 2007, 6:53 pm
In response to Jmurph
If you're careful about it, you won't run into list problems.

You only need the list for mobs that have items equipped, for starters, which cuts out a lot of it. And because the list for items will never change (At least, isn' likely to), you can be a bit sneaky and use a procedure that generates the equip list:

obj/equipment
    proc/GetEquipLocs()
        return list()


Then it's only temporary.

Basically, you store only a single list per mob with equipment equipped, which seems reasonable to me.

You could probably even cheat a bit and use the vars list:

mob
    var
        slot_head
        slot_torso
        slot_rhand //etc.

    proc
        getEquip(slot) //Returns the item equipped in the given slot, or null if there's nothing there
            return vars[slot]


The biggest issue I can see with doing it that way is that every mob then needs to have a set of slot variables - and depending on how you do things, that might be a lot of variables. I just prefer using a list because it feels cleaner to me, but it's probably just a stylistic issue.
Dec 20 2007, 8:50 pm
In response to Jp
You could store everything in one list. Store a mob/equipment followed by its slots/locs. To retrieve the slots/locs, find the mob/equipment and then continue until either another mob/equipment is found or you reach the end of the list. (That's how I store turfs and movables in my BigBump library.)

The catch is that, if you do use text, you risk hitting the text limit. However, many of the slots will probably be common enough that you can reuse the same text tokens.

On the bright side, it's dynamic.
Dec 31 2007, 2:16 am
Something that might be helpfull just came to mind.

It's not a shared opinion but you might find this way of thinking a good way to go.
Don't punish people in the game, make sure that when they gain something they can't lose it, and make them gain things often.

This will give the people a sense of wining all the time which will make them stay.

Example, let them fight eachother, and gain points. Give the winner loads of points, but never take away point from the loser, just give him a bit less.
Don't take away items from someone when they die, just spawn them at a safe spot, no debufs. Walking back is already enough of a penalty.
Don't lock out things so that some people can get something and others cant, make sure people are equal.

This also brings the aspect of balancing into account, making sure decisions only effect playstyle and not strenght. Meening that 2 lvl 10 people should be equally as strong, even if 1 put all his stats into AGI and 1 all his stats into STR. The stats chooice in this case will meen that 1 person will rarely get hit and the other hits hard when he does.

I think a RP is only enjoyable to play when things go well, they need to bring you into a world were you can relax, not worry about doing things wrong, explore the world and make up your character and interact with people.

Ofcource not all people will agree with this opinion, nor do I want to say this is how all RP's should be, but if you can find yourself in this way of thinking it might help you.

- Fint