Sl Rpg

Is there a place for beta-project ideas? Here goes anyways.

I would like to create an optional RPG element to SL through scripts and attachments. I -deffinatly- need two things: to know if anyone else is interested, and some help if people are.

Here is my feature list, sure to be incomplete and at least partially impossible. And I'm thinking it up as I type.

- Control through scripted attachments and objects in world
- All objects would be "No Mod" and some verification/security measures would be in place. I have many ideas for this that I don't really wanna post. But the best solution is to wait until object to object IM is available. I would also like a method that returns the key of the creator of an object. For verification purposes.
- Registration with the game would be required.
- An "RPG Player" attachment, that acts as a control unit. All other attachments (weapons, armor etc) communicate necessary info to this item.
- A "Base Station" that the "RPG Player" would communicate with. For security info, stat reporting and more.
- Players would have stats, like str, int, cha etc. They would increase from actions taken by the player. Charisma could listen for things on channel 0 (you have been ranked ...) messages or something. And more.
- Death that is counted would be handled by scripts only. Meaning you have to be killed by an SL-RPG weapon for it to count against you, not just anybody with a max damage weapon. This allows for damage control.
- I'm thinking that some sort of shield needs to be built in, so that you can't be killed normally. But I dunno how to do that.
- A commmand to the "RPG Player" unit would send a stat report to your email. More specific commands could tell you specific stats.
- There would be objects placed in world like treasure chests that when touched by someone who is registered with the game would pay them money and then de-rez.
- I would like to have player made NPCs that react to registered RPG players. I would like both ones for fighting and ones for talking to.

There are other options too. I may charge a limited recurring fee in LD to be registered, so I could afford more prizes etc.

For security I would allow others to create items and scripts for the game, but I would have to be allowed to add an item to it and turn it no - mod and sell it back.

Anyways its a rambling idea. Please let me know what you think.

I'm very interested in this. This is the kind of user driven functionality that SL is great for. But we need to wait for a few things: Object<->Object IM, Object<->Object llGiveInventory, Object Damage, and Possibly, scripts that run on an actual AV.

Once we get some or all of these I will definitely start development, until the we can just discuss the functionality.

------------------------------------------------------------------

SL is not good for first-person action style games, because the lag prevents realistic movement & interaction. But it could be used as a framework for a more turn based RPG style game. I have no realy experience with RPGs. I played D&D for a little while, but I've never played any RPG computer game, so I don't really know how most of them work. But if somebody posts a well defined feature set, and explains how the gameplay is supposed to proceed, I'll put some more thought into it.

-Pat Murphy

That sounds like a fantastic idea. I'm willing to commit a significant amount of development time to this project.

Object <-> Object IM I think is a must to prevent eves dropping and security breaches. But I think development can be started without it.

Object damage can be handled via good scripts. Scripts that keep track of collisions in a smart way, decriment a health type variable, and take approprate action depending on that health. Either offering less defense or llDie() if it gets to 0.

Object<->Object llGiveInventory: While I admit this is a feature I want in SL, I am curious what you envision its need for is in SL-RPG. Loot from mobs?

As for scripts thta run on an AV ... that would be nice, but I think it could work also from scripts on an attachment.

Are you sure you need to prevent eavesdropping? Admittedly I haven't thought this through thoroughly, but it seems that only authentication is required. Obviously we don't want foreign objects ordering the RPG's objects to take damage, but that an object was damaged and by how much shouldn't, IMHO, be secret.

Usually in a RPG it's secret where mobs are located and where treasure is located, and so forth, but that is all handled by SL in this case.

As for making sure all objects can hear each other, the other reason IM might be convenient: It should be trivial to set up "repeaters" at appropriate distances to each other that rebroadcast messages as required.

I also think this is unnecessary. Loot from mobs would presumably be rez'd just before the mob dies. Any objects that the mob might need should be placed into its inventory from the get-go.

A lot more information than how much damage should be done will be transmitted. Including reports back to the central unit for how much damage was taken by another attachment, reports back to the "Central" unit about statistics, etc. And yes they do need to be private. Not because I care about someone know how much damage is being done, but because I don't want other objects to be able to interface. If unapproved objects are able to talk to approved ones, because they know the auth codes etc., then someone will just make an instant kill weapon. And I don't want that.

For this to really work, only approved, verified objects can talk to each other. And steps need to be taken to ensure that no one is able to duplicate an authentic message.

Also OtO-IM allows for communication to the central box from anywhere in the world. This makes authentication much much easier, as well as tracking etc.

If objects could send private messages to each other, then certainly communications would be easier to secure. On the other hand, just because an object IM'd another object doesn't mean the object was authorized to give whatever data it just gave: there still needs to be some sort of authentication. That's generally a hard problem, whether messages are exchanged privately or publically.

Some serious math capabilities in LSL would make this easier and more secure. Imagine authentication of messages by RSA signature, for example. Shared secret security is really, really difficult to do correctly, and even harder to maintain. (What if the shared secret becomes not so secret for whatever reason? You'd have to pull out every script in every object and modify them all.)

Yup, you'l get no argumet from me that objects IMing each other would not be useful. I think, though, that we can proceed without this functionality, at least for now.

Way too much CPU power required. I don't trust people to use it correctly (to just pass the password for a less cpu intensive security system) and not totally kill sims with it.

Really though if OtO IM is there everything can talk to an authorized node to verify that the players are registered and that the equipment is registered. That would have to be handled very smartly to minimize delays and cpu requirements. And one reason I would like to be able to have a llGetCreator() message is it would be easier to check that the creator is an approved creator (much shorter list) at the time of incident, and only check the actual object ID at convenience.

Hm I think we also need a llGetSim() that returns the sim the object is currently on. With such a method we could have one central node, and some on several sims. The central node would pass off work to the node closest to the person.



And I said earlier:



So yeah, I agree.


I have many, many ideas about this project. Many of them are for future advanced incarnations. And many are about the security system, which I would rather not post on a public forum like this.

I'm not quite sure what the objection is here, or indeed how many objections were raised by this statement. I see that one objection is the computational load of verifying digital signatures. Well, alright, I acknowledge that there is a non-trivial load caused by such a system. What's better, though? Unless you are seriously prepared to edit every script in the entire system every time a shared secret needs to be changed, or ...

... you feel that this is a good idea, to keep and maintain a list of all approved objects and approved object creators. Well, I guess that's one way to do it, but it doesn't strike me as a particularly clever or robust one. For one thing, with LSL lacking a means to interact with permanent storage, every time you change something in the registry's scripts you'd have to re-register all the valid objects and creators.

(Oh, a random point I'd like to throw out: I think, from an infrastructure point of view, that it's very important to keep the number of trusted components down. The more that can be done with untrusted components, the easier it will be to maintain the system. In a client-server model, for example, it's easy to see that the server should be trusted but the client should not be trusted. The client should in fact be treated as actively hostile. In this case, a very strong line should be drawn between The System, which consists of everything that maintains the state of the RPG, and Everything Else, which is, well, everything else. (What components go where is certainly a matter for later discussion.) Things from the Everything Else group should be permitted to interact with The System, but only in ways that The System defines and allows. You mentioned this point or something similar when discussing foreign weapons, but I think some interaction with Everything Else should be permitted.)

It's often debated whether systems are more secure when they are kept secret or shared with the public. I stand firm in my belief that security cannot be reached through obscurity. None of us are independently capable of warding off all manners of attacks on a security system. Any flaws in a secret system will be found eventually, and in the short term, so it is my belief that it is more beneficial to air out a system to the public and examine potential weak points critically from many points of view. Still, I acknowledge that the debate on full disclosure and related topics will probably never be resolved, so I won't even be disappointed to see you disagree.

Well, in any case, this is going to go nowhere until something actually gets done. Can you suggest a reasonable sub-project that I might hack up in a day or so, to act as a starting point?

About security through obscurity I actually usually agree with you. Just not this time, because of the way I am thinking of doing it. Data on a private IM channel can't be overheard (I hope) so there will be no eves dropping. Which means that to 'hack' the system you have to essentially guess what is being sent where. I would rather not discuss what is being sent, what type of information, because that could drastically reduce the ammount of info required to compromise the system.

And I see your point about interaction with foreign objects, and I concure. I think we are going to have to create a series of API calls (handled through chat channels for now, IMs later) that any object can call on another object. It will be these methods/commands/whatever you want to call them that will be the limiting factor to prevent abuse.

I do want to limit interaction between players to those registered. With the multi node system I mentioned earlier this is possible. If done smartly all nodes are possible super nodes, and supernode can pass off the job to another node along with it's data if it needs to be serviced, and other nodes can pass off their data if they need service. Anyways its all a bit much for right now eh?

============
Sub projects:
============
Modeling
- Armor pieces
- Weapons models
- Treasure chests
- Simple Mobs (I'm really thinking less than 5 primitives)
- The base tower/something.

Scripting
- Something that detects and blocks incomming bullets. (if possible)

- Stats maintainer
- - Int, Cha, Str, Dex 'base stats'
- - HP, AC as derived stats
- - Listens for commands of the structure <cmd=value>

- Armor script that detects collisions and decriments an internal value and/or passes a number/command on to the stats mainainer.

- Some limited hostile AI.
- - Moves the model along a route (could be straight line)
- - Detects a player nearby and grabs their ID.
- - In the future it will send this ID to a base station to get confirmation. Doesn't need to do that now, but keep it in mind.
- - Fire at target (in the future only if the target is approved).

- Some limited friendly AI.
- - Listens on 0 for chat. In the future it will check with a base station.
- - Keeps a list of key words it listens for, and responces to those.
- - (Dunno if this is possible) but accepts inventory drops, people putting things on it, and has specified actions for it. It should delete the given item and rez another item. Potential for requiring multiple items would be nice.


And of course anything else you can think of.

One of the reasons I only want approved armor is I don't want armor that accepts a collision and does nothing with that info, thus making the player invulnerable.

I'm in for what I can do. Or maybe when I can do. Talk to Jax Slate too.

BBC

I'd still like to better understand the "big picture." Could you describe the gameplay in detail? Nothing about how it should work under the hood, just how it will be played.

-Pat Murphy

Well, now we have private communication between objects in the form of email. Is there any interest in reviving this idea?

I'd love to see something like this in place. My interest is less in the technical, but more in the "fuzzy" details.

If I may offer my opinion as a veteran roleplayer (including the uber-nerdy Live-Action RP, which is extremely comparable to SL) it's to offer a way of masking one's identity at least from a visual standpoint. Otherwise all your characters are going to have the same name as your SL name, which is cumbersome and inflexible. Since SL doesn't currently seem to support NPCs, you could get a group of SL players to play those roles (this is how it works in live-action RP). Swapping costumes and identities in this case would be very important.

Ideally you'd include some kind of "identity kit" in an outfit folder, which you'd drag onto your avatar. This would not only give the visual identity of the character you wanted to play, but might also either mask or change your displayed name.

Turning off the mini-map is probably best as well. Fantasy-genre scenarios don't normally have radar in them

My last suggestion at this time is to try to incorporate an existing open-source or free-license game system rather than develop one on your own. There are many good systems out there, and you could save a lot of work by going with something that's already been in use for several years or more.

I notice this was originally an old old thread. Is this project related to DarkLife in any way?

No. I was part of the Darklife team in the beginning and I had never heard of this thread. I think Pirate Cotton just pulled an idea out of his hat one day and talked to me, I said I would help him code it, but alas my computer died and Mark Busch took my place. Since he was all secretive with his silly little code, I wasn't able to help much when I returned and so after making a few objects for them I decided to leave the team.
There's been a bunch of "game" attempts but no one has ever succeeded at creating anything I would want to play for any length of time.
Here's a hint: an RPG is a ROLE PLAYING GAME. Not a leveling fest. It has to have a PLOT, and the plot has to be good and immersive.
Before you start getting all hot and bothered about creating a rule system and coding it, make sure you have an actual GAME to go with your rules.
Once you have that, its trivial to come up with a basic DnD implementation, and you would be wise to stick to the DnD standard instead of coming up with something that is likely to be much worse.
Downloading the SMAUG codebase would be a good start. LSL is much like C so I'm betting that you could rip a lot of code from it.

Thanks for the history lesson, Eggy.
Hear hear. And let me add, if you bring level grinding to SL I will come to your house and make you eat your computer. And then I'll drive to the houses of people who think SL would benefit from The Sims-style "needs" and give them a snack too. If I want to play games that require me to use a toilet I'll move to Japan.

Maybe this should go in the rants forum.

I am still interested, but I have even less time than when I first respondend.

bbc

I quit everquest to play DarkLife.......Is it ever comming back? I miss it alot! I've seen some other projects like it, but none done. I need an RPG game in SL....

Well... I have a couple of projects pretty similar to this.

- The prototype from 2002ish is here: mmogtoolkit.sourceforge.net
- The current version has migrated to the name ManagedDreams and has moved on a lot but is frozen at this time.

It turned out I was devoting *significant* time (at least 50%) to counter-exploitation code, which is a lot, so it's sortof on the backburner for now pending SL updates that will allow you to lock down your land.

For persistent gaming to work easily, without major amounts of counter-exploitation code, ideally we'd be able to sign scripts and objects (or tag them in some way), and only allow nominated signed scripts and objects on our land.

In the absence of this, you're by-and-large restricted to using non-physical objects (physical can be moved, deflected, stolen...) which seems a shame.

Azelda

Well, i'll still be draped in my old DL backpack with my sword and shield hardly tarnished by the mind flayers, my speed bracelet dangling from my hands and helm and chest piece and helm broken in twane from the last battle....waiting by the front of the castle for the bugs to come back, waiting for the new updated items to come to the store...... U'll probably see me roaming the area at night as a ghost or vampire roleplaying in the night at the new village <least new seeing to me>

After I finish my house I will get back to STing and will start Wraith. However my system is a little less complex than yours Ama. I like to call it "a note card". Oh, how I wish I could script!

You don't totally need to. Certain scripts/items can be used becasue there free or can just pik at a little. I'll try to make some items for powers and stuff, but i'll have to ask the makers for their consent

Sign me up, Ama. Been a while since I worked on an RPG system (used to code on muds all the time, even had one running for a while on a mudlib I wrote from basically scratch), but I used to dig it quite a bit.

One of the first steps, IMHO (or not so) is to come up with the game system and then develop from there. You know, how combat will work, how skills/levels operate, experience, magic, etc.

Anyways, I am willing (as time permits) to contribute idea/concepts and lend my hand to do some of the coding.

All right, Bob. I think if an RPG is made you get to be the necromancer for bringing back WAY old threads to life. I will paraphrase a conversation I just had with alondria:

Alondria: Hey get me in on that RPG action!
Ama: RPG! Woot!
Alondria: Have you thought about rules and stuff yet?
Ama: Um... WTF are we talking about?
Alondria: You know, game mechanics
Ama: Yeah I know that, what RPG are we talking about??

Suffice it to say this thread got pushed to a forum I never read. I am extremely limited on time, and I was finding that a lot of my time was also spent on anti-exploitation code. Although a significant part of that is done and burried in my inventory.

Anyone who wants to run with this is free to.