Monday, April 30, 2012

The case for RPG's in OpenSim

So now we're going to build on my previous posts about NPC's and take things a step further, making a case for RPG's in OpenSim.

Now that OpenSim also has an NPC module, and I've now spent time exploring the hypergrid and overviewed  the development possibilities with the new (to me) region modules, as well as the existing ossl functions, I've begun to see some enormous opportunity here. First, though, let's cover why not Second Life?

Why not Second Life?

With OpenSim NPC's, these could have been actual avatars..
moreover, attacking monsters became a painful issue, as
i relied on parsing text all the time. I had created custom list
"structures" so that attacks could have their own unique properties.
As Second Life has been making strides towards a more game oriented environment, becoming more and more public about it as we entered this year, I had been working on an RPG architecture in Second Life in LSL in the meantime. I came across some enormously frustrating roadblocks. I could go on and on about problems I had encountered, but let's just cover a small (-ish) laundry list:

  • Inability for scripts to structure data other than strided lists
    • You can wrangle strided lists to your heart's content, but the little syntactic sugar that other languages provide really make a difference visually. Moreover, since scripts do not have the ability to include function libraries, a good portion of your script header becomes wrought with data handling bandages, just so you can make your main code somewhat readable.
  • No way to create a global or static data structure, to keep track of overall game states and variables.
    • Sometimes there's a set of data that every script or object in the game needs to know about, and it's impractical to broadcast to each and include a parsing function for every single one, which brings me to the next point.
  • Even when data is passed between scripts of different objects, it has to be parsed as it's always sent as a string
    • AKA - No way to pass native data structures
    • Everything must be passed as a "say", EVERYTHING. And that gets annoying, because then every listening script needs to parse it, duplicating function headers over and over again. Which leads to my next annoyance.
    • Even in the case of integer bitmasking for link messages, that will only get you so far, and that's only between scripts in the same object.
  • No secure way to pass data between scripts in different objects. 
    • Even if you do decide you can live with passing data between objects, you still can't do it securely. Even if everything in an object is no copy/trans/mod, you can still rip the scripts out and place them into your own prims to examine.
    • Sure, you can use SHA1, but doing this for every single game message, including attacks, is an ugly hack, and that much string handling en masse can't be a good way to do things.
  • No decent way to represent NPC's. Prims do not cut it, it needs a skeleton. It needs to LOOK alive. See my previous post about NPC's.
    • Even when resorting to libomv to do NPC's, you must make an individual account for each, and then skirt the line on how many alt accounts you're allowed to have. Some people have 10 or 20 lying around, but even if LL gave an official thumbs up to this practice, you need either a personal server to run your bots, or run them from your computer, which means if your internet is glitchy, so is your game.
    • Pathfinding is fine and dandy, but many of the first RPG's got along just fine without it. I'm not saying it wont' eventually be crucial, but back in the NES and SNES days, it was more or less unheard of. Even so, I've already heard of some opensim experiments with it.
  • Data cannot be stored persistently
    • You could use an external server, but then you have two points of contact for breakage, and that means suddenly you're editing your files in several places across two locations in two languages (3 if you count MySQL)
    • We've seen using object description and other clever ways to carry persistent data in SL, but for one it's still not secure unless you use hashing, and two, it will barely hold enough data anyway if you have any decent amount of it.
      • At one point I even considered a suggestion of creating a humongous linkset, and using the description or other possible data fields of each "data prim". No- just.. no.
    • Scripts can hold a decent amount of data now, what with being 64kb (iirc) for mono scripts, but if the script somehow gets reset, well.. goodbye data.
  • Even if you manage to deal with ALL of these problems, you are still going to need land to run it on- and that will cost you no less than 125 to 300 USD / month.
    • You could run it on a smaller parcel, but then you lose a great deal of control over the immersion of your game. Having until recently (by the great generosity of two friends) run a hangout on parcels in SL, we've encountered some wacky next-door neighbors. I believe we so far encountered a sex-dungeon, a brothel, a texture-bloated mall, and some wacky giant purple box-shaped eyesore that we had famously dubbed the "purple people eater".
    • Even if that's not a big deal to you, consider that the texture, sculpt, and script usage of your neighbors can dramatically effect your game's performance and framerate.
    • One thing I feel was misportrayed about Linden Realms (whether LL meant it or not)  is that it didn't realistically portray gaming possibilities in SL at all due to the sheer amount of regions they used to run the game. 4 full regions alone would cost about 1200usd/mo.
Doing dialogue was a nightmare in only LSL, as
none of the NPC's were scripted to reduce sim load,
I did everything within the HUD itself, essentially creating
a pseudo-language for quests. Blarfgarbl, never again.

So, then why OpenSim?

All these issues mentioned above can be resolved with a custom region module, or are already supported in OpenSim (e.g. persistant structured storage in the form of JSON, server side NPC's, and C# scripting capability). As for cost- you can run it at home (not advised usually) or find a ridiculously cheap hosting solution in comparison. Cyberwrld grid offers regions in the range of 5 to 30usd/month. These prices are becoming more and more common in the open grid.

Anything that can't be done via scripting alone can be done as a region module, and in particular, a special advantage to this is to create custom scripting functions.

What this means is an entire simplified RPG api could be developed as a region module, and accessed by LSL functions. This means complex data handling, attacks, interaction, so on and so forth, can be reduced to simple logic-only scripting, and the scripts themselves could be beautifully compact, easy to read, and not full of hacks.

But why is it important to have a clean script like that? What's the difference if you're a good enough code slinger to handle all those complexities and 1,000+-line RPG code?

Nevermind the fact that no matter how seasoned you are, hundreds to thousands of lines of code is more annoying to look at than less than a hundred- and when most of that code is designed to work around shortcomings in the language, and only a small portion of code may actually be doing anything directly related to your game's own logic- coming back to a slough of alphabet soup becomes a nightmare.

Most importantly though, with a dedicated api that effectively reduces code down to the essential logic, you enable a majority of would-be storytellers and hobbyist game makers to get down to the business of creating assets and writing stories, and that's something I think the hypergrid could REALLY use right now.

Some hangups in both scenarios

The inventory transaction system was likewise a headache, and
likewise was frustrating that I couldn't implement visual inventory
management without resorting to some crazy LSL on one end, or
dealing with MOAP shortcomings on the other.
The one thing I've had major trouble with, and was perhaps the main demise of my RPG endeavor (in SL at least), was the lack of any proper HUD capability. I needed a scrollable inventory, with drag and drop icons, and for one, I just wasn't up to the task of writing the kind of elaborate HUD I needed in only prims and lsl, it's just not my strength. I did look at other options:

 If you've seen Nexii's NexUI2, which has an impressive widget set, and manages to work via SL prims only, you can see just how far you can push the envelope, but I needed a little bit more, and wasn't willing to put the time in to get familiar with the code to tweak it.

The easier (and more importantly non-LSL) solution, and one I did attempt for a short while, was using MOAP as an HUD. Except yet again, 2 gigantic roadblocks: 

  • Prim_Media_First_Click_Interact is broken, and has been broken for OVER 2 YEARS.
    • Without this, you would have to click once to focus, then click on whatever it was you were trying to click on in the first place. Frustrating? Oh yes. My suspicion along with a few other people's, is that this worked somewhere along the line, and got broken in a merge to viewer trunk. Really though, 2 years?
  • Long-polling is the only way to do a server push on MOAP data between javascript and LSL
    • This one isn't actually so bad, but there's other technology out there to push data to the client now. Important for all kinds of things like updating the HUD's hit points and stats.
    • At one point I did consider just rewriting the entire game in a jquery HUD MOAP with minimal LSL.

Why not Unity3D? Or some other, better suited game package?

I had to think about this one for a while- so if you had to jump through all these insane hoops to run even a mediocre RPG system, on a platform that couldn't handle an MMO-sized player spread to begin with (though the OpenSim DSG branch may be changing all that), using a viewer that on average eats up half a gig of memory-- why not just use Unity, or some other game engine?

I really was stuck on this one for a while, then I realized, as I was hypergridding, that it was all in the environment. Being able to script, chat, walk around, and level design, all from one seamless interface is what made this so addicting to be a part of. You're in the game while you're playing the game and designing the game, that gives you time to sit there and play around and change and tweak things while they're happening, while you're there- no shift over to the edit-compile cycle, no walling yourself off from people while you're developing, and then pushing a binary to them every hour or so, it's all real time and in your face. It may have its encumbrances, and may not reach a big commercial potential for quite a while, but it's still a very very immersive and real medium. An art medium if you will- and there's something to be said about that, especially in terms of the hypergrid.

Having spent a good amount of the last week exploring hypergrid, and I found it a joy to explore new regions- oftentimes I would find not just one region, but 4 to 9 all gridded together, as one coherent build, and not chalk full of stores with insane texture bloat simply to keep up with region costs. There were certainly regions that had their share of chaos and emptiness, but it was quite often that I'd come across a real gem that exemplified the owner or their group's love for simply building worlds.

A store, but not a store :)
- and to a point I think that's what this whole culture comes down to. Our love for assembling our dreams into a form others can experience. It's a pure endeavor, and you can see by the gems spread across the hypergrid, how the virtual world thing has become so intensely a part of people's lives that they will take on these large projects for the sheer love of it. Someday, I hope in the future, this does become a supporting endeavor for people, but for now, I present this case RPG's on OpenSim as another way to extend the the world-builder's toolkit from being scenery and chat, to story and interaction.


Backdrops in collaboration with JubataJuno Noyes, who took my skeleton layout and turned it into this gorgeous backdrop for our would-be game, hopefully someday.. Also thanks to the sim owners for giving us the space in SL that we otherwise would never have been able to fund.


1 comment:

  1. A lot of SL problems for those that really want to use it as a platform for game development could be solved by resurrecting C# project. It was such a shame that it got cancelled when it was so near completion.