Monday, 19 March 2012

Opensim: Building Epic Role Play Environments

After reading Ener Hax's blog article, "building in OpenSim making a rough draft" and looking at one of the pictures I realized I use the same techniques for my own town and city building. Ener wrote, "I need a neighbourhood for Enclave Harbour so that we can talk about environmental science as it applies to homes." As I read on I started to think about my builds in SecondLife when I created several Moroccan style ports to represent the slave ports of the old North African Barbary coast. These were built on Homestead regions so prims were in short supply and I needed to cut corners without spoiling the view. What I did is very similar to what Ener has done in Enclave Harbour. Parts of the build were block houses with no internal structure and just the use of low rez textures which was pretty easy given the sandstone materials used in North Africa. Those buildings that did have internal structure where fairly colourful to reflect the Moroccan style.



Ener's rough street plan

Gaga's rough street plan
When I started building in Opensim primitives were no longer such an issue but what I had learnt in SL about prim would be still applied but it was so good to have more bricks, so to speak, where they were needed. Ener went on in her post, "i only need to worry about making one detailed house. the model home can be different looking and have taller camera-friendly ceilings too. since it’s supposed to feel like suburbia, why not make all the regular houses identical and just change the paint colour on a few? I borrowed Ener's picture which I am sure she wont mind to illustrate the rough plan. Below that is a recent layout of a build I am working on in OSgrid which represents a small part of the American port town of Boston around 1779.

What I am doing with Boston is not exactly to scale or totally authentic but I am building fairly accurate versions of important historical buildings such as the old state house where the Declaration of Independence was read out. Included too is a part of the waterfront seen from and old King street leading from the long wharf of Boston Tea Party fame right up to the old state house. Many of the buildings will be basically shells or even block houses and it is the exterior that is important here especially round the old state house which, in itself, is the most detailed and accurate building including the interior and the spiral staircase.
Seen here a view across the harbour at the rough building layout. The map used stands at the back with many old pictures dotted around for historical reference.

The build is essentially a role play environment meant to offer a base for Continental Revolutionaries from the period. The region, once completed, will be moved as an OAR file to a position in a 25 region mega sim for sailing ( I would love to be able to have done that in Second Life!). Boston will be in the North West and another build I haven't started yet will represent old Plymouth harbour for the British to go in the far North East region of the mega. The objective is to provide a vast seascape representing the North Atlantic where sea battles might take place between the British and Americans.
Still under construction the old state house takes shape and more buildings are starting to rise up around it.



Gaga poses with her handiwork inside the old state house. Here you see her working on the magnificent spiral staircase working from current photos. There remains lots of work on the rest of the Georgian interior too.





View in front of the old state house
about 1779 from which other
buildings can be recreated.



But more is planned since I have already set up one standalone mega on the hypergrid with walk through portals (blamgates) set up on moored ships at the major ports. So, you want to set sail for Gibraltar en route to the Barbary coast then just board a ship and arrive via hypergrid all conveniently arranged. You, in effect, teleport to another grid and can return the same way. This makes vast epic role play enactments possible and could easily be applied to a variety of themes including Sci-fi and fantasy worlds.







Here is the prim built version of the
Paul Revere medieval house typical
of many working class houses down
on the waterfront. Pictured below
you see the original house still standing
and preserved
Boston and Plymouth will remain as part of the Atlantic mega on OSgrid and include pirate islands in the south to represent the old Caribbean sea but, while it offers ample opportunities for role play in bygone times I want to include some fantasy elements in the form of Steampunk so Boston will have a steam pump house in Georgian style and a flying airship that doubles as a portal to yet another mega region representjng Mars in 1779. Yes, sounds strange, and Steampunk generally covers the Victorian period around 1889, but I figured steam and airships were already invented and the science of electricity was starting to be understood - I mean, Mary Shelley's Frankenstein monster (the novel) was not far off and electricity played a huge part in that so why not 

engage some alternative technology to enhance the role play? Besides, the Mars environment is completely separated on its own mega region so players can do both historical Georgian and Steampunk or simply stick with one or the other.

I will write more about this build and its environment as it progresses' and eventually I expect to open it all up to role players. It's a wonderful opportunity that would never have been possible in Second Life on cost alone but even on the technical level Opensim and hypergrid offer so much more to work with. I may even make some of the buildings available to schools that use Opensim for history projects.

I will join Kitely soon too now they have Twitter logins and it's probable I will bring some oars to that grid - Maybe even build Steampunk Venus or Mercury there once they have linked regions that handle border crossings well and/or mega regions at least. They need hypergrid too in order to seriously interest me of course. Anyway, stay tuned griders and travelers!
Here is a market screen - probably lower King Street - that fascinates me for its atmospheric bleakness.
An old commercial building long since gone but typical of buildings that existed around 1779. The traders usually lived above their premises in cramped conditions raising large families
This map which I used is the part of a British Survey map from 1775

24 comments:

  1. If you make a version for schools, announce it here and I will add it to bit.ly/edu_oars

    ReplyDelete
  2. Hi Gaga,

    We look forward to seeing you on Kitely soon :-)

    I estimate we'll begin working on bigger worlds sometime towards the end of April, hopefully it won't take us too long to roll them out after that.

    We're currently debating whether to use megaregions for bigger worlds or just use multiple regions on the same sim in the standard non-megaregion configuration. There are pros and cons to both options and I would love to hear your thoughts on the matter. Making it a user choice can create a lot of confusion for new users because no matter which option you chose as the default some people will expect the other one.

    ReplyDelete
    Replies
    1. Hi Ilan

      I am very interested to know your plans of course. I will work with what is available but some things are impossible. Using basic core Opensim if regions are not connected in a mega configuration then my ships will not cross the borders. At least, they wont using the current scripting which is based on physical wind sailing. Recently I learned that Avination has achieved stable border crossings and Melanie may yet share that code with Opensim core. At the same time InWorldz developer, Tranquility states the Phlox scripting engine enables stable border crossings for none-physical vehicles. And then there is Aurora sim which allows the area size of regions to be enlarged up to 256 standard regions and uses the resources for just one region. Aurora eliminates borders in effect.

      I am a huge supporter of hypergrid and a connected metaverse so for me to get interested in working with any particular grid then the owners must share a similar vision to me and do all they can and some to help build it. It all takes time of course but certain things must ultimately be put in place. Maria's survey showed that vehicle physics are top of the list but there is the mater of security too that some don't consider that important but others do. I think it is important if we are to get more quality content into the open metaverse but some scripting needs protection such as combat meters that might be hacked by cheats. Whitestar Magic's recent proposal for a 4th "Export" permission seems to me the way to go and it was tested on Aurora grid successfully in the recent past so it can be done. I am not sure mega regions are the best solution for dealing with border crossings anyway because mega's do have their own problems too but it is the best solution currently. Aurora var regions do work better in my experience if that code could be used in core. Aurora itself, though, has now moved too far away from Opensim, contrary to the dev team's original statement on remaining compatible. So, stable border crossings for vehicles is the heart of the issue when determining if mega regions should be implemented. If crossings could be improved substantially as they appear to have been done in Avination then mega regions really aren't so important although I still think var regions give huge areas for low processing cost.

      So, okay, the bottom line is that I currently have a 4X5 test mega region representing the North Atlantic and Caribbean sea along with some other single regions for building works in OSgrid. In addition I run a standalone mini grid mega of 3X3 regions representing Barbary coast which uses SoaS. Everything is hypergrid enabled. I am building for a future hypergrid of connected worlds regardless if I also build part of my network in another grid. Obviously, I am not interested in investing in walled gardens with no hg connection and eventually I will close the last two remaining sims I have in Second Life.

      I definitely am interested in Kitely because ultimately it may turn out the be a better platform model than core given it can be delivered quickly on demand from cloud servers and, cost wise and even asset/inventory scaling, this holds out the possibility of creating many more spaces for epic role play games such as I wish to build.

      Gaga

      Delete
    2. Thank you for your detailed response Gaga.

      We're currently working on enabling teleporting between different Kitely worlds, which is one of the prerequisite for enabling hypergrid support on Kitely. Initial support for this should be ready within a couple of weeks.

      Another prerequisite for hypergrid support on Kitely is content filtration that extends the permission system to work with the hypergrid as well. Adding a 4th "export" permission requires viewer support and we don't want to limit people's viewer choices. If this isn't addressed by someone else by the time we're ready to focus on enabling hypergrid, we'll probably implement a system similar to the one we created for OAR exports (which we later contributed to OpenSim core and is now part of OpenSim 0.7.3). This enhancement would prevent assets that the user doesn't have permission to copy and transfer on Kitely from being accessed outside the Kitely grid.

      Delete
    3. Hi Ilan

      Thank you for explaining but let me get this right. Hypergrid already has the Outward Bounds perm the blocks content from leaving a grid if it is set null but am I to understand that in stead of a blanket control like Outward Bounds perm you will implement a new method of blocking content that doesn't have full perms set?

      Is this effectively the same as the 4th "export" perm by another method?

      I am very interested to know and understand what you are aiming for.

      Gaga

      Delete
    4. Hi Gaga,

      Blocking all content from moving off the grid significantly reduces the value of hypergrid travel. We need to have a system that works with existing viewers and enables people to sell content to hypergrid visitors (if they want). Treating content permissions for hypergrid travelers and local grid users differently creates semi-closed gardens where people will need to keep track of what content they can and can't take with them when they travel and would force people to buy the same content multiple times in order to have access to it on multiple grids. When people sell a shirt in the real world they don't limit you to wearing it in the city where their shop is located - I don't think we should encourage virtual shops to act differently.

      Exporting an OAR file is similar to hypergrid travel in that it enables people to copy assets obtained in the grid. As we didn't want to block people from exporting OAR files but wanted to enable content creators to retain control of their creations we decided to use the standard permission system to determine what assets can be exported to OAR files:

      - If you can't copy an asset inside the grid then you shouldn't be able to create a copy by exporting that asset to an OAR file. Therefor assets for which you do not have copy permissions will be automatically filtered out from OAR files you export.

      - We used the same reasoning for automatically filtering out assets for which you don't have transfer permissions.

      We implemented this OAR improvement last August. For details see: http://blog.kitely.com/2011/08/28/copy-world-respects-permissions/

      We think the same type of change should be made to hypergrid content handling. That is, allow content to be accessed over hypergrid connections but only if you have both copy and transfer permissions for it. This ensures that the visited grid (even if it is running malicious code) can't copy/transfer assets which the user isn't allowed to copy/transfer.

      Delete
    5. Forgive me for finding fault here but I sense a conradiction in your reasoning Ilan. First you said, quote, "Treating content permissions for hypergrid travelers and local grid users differently creates semi-closed gardens where people will need to keep track of what content they can and can't take with them when they travel and would force people to buy the same content multiple times in order to have access to it on multiple grids." But further on you say, quote "allow content to be accessed over hypergrid connections but only if you have both copy and transfer permissions for it. This ensures that the visited grid (even if it is running malicious code) can't copy/transfer assets which the user isn't allowed to copy/transfer."

      Those quotes above struck me as contradicting each other in that you don't want to create semi-closed gardens due to asset permissions but, on the other hand, you want to allow assets to travel if copy/trans are permitted. Respecting no copy/trans perms' but allowing full perms to pass is as good as a semi-closed garden which ever way you look at it.

      Don't get me wrong though. I am almost in agreement that semi-closed gardens are perhaps the only way to handle asset permisions over the hypergrid but, as you say, it will probably need support from some/most of the viewer developers.

      As far as I understand hypergrid personal, or worn, assets travel as appearence anyway and the assets are called from the home grid so don't actually download to the visited grid but, of course, one would have to get those assets onto their home grid in the first place which your filtering of copy/trans would block for items obtained during hypergrid travels. Here again you said, quote "When people sell a shirt in the real world they don't limit you to wearing it in the city where their shop is located - I don't think we should encourage virtual shops to act differently." Well, actually, in the real world Customs might prevent you from exporting what you bought for one reason or another so the respect for copy/trans perms has a parallel. But, regardless, I do wonder if assets should be treated in the same way as Blackhole assets which Aurora sim uses. That is, if the asset exists on the grid travelled to then anyone owning the same asset should find it is available to them both as an appearnce item or even for use in the visited grid. The key here is does the asset you own exist on the visited grid? for if it dose then the creator must have put it there and probably distrubuted it to other trusted grids the visitor might travel to as well. This reminds me of Mesh Networking ( http://en.wikipedia.org/wiki/Mesh_networking ) which I wrote about in a previous article last year "Aurora Sim Security: a Mirror World" here http://metaverse-traveller.blogspot.co.uk/2011/07/aurora-sim-security-mirror-world.html

      I think you are on the right track Ilan and I also think it is brave of you to tackle asset permisions when the problems have been waiting for solutions for so long. In any event, the walled-garden commercial grids have been relying on their walls as the only feezable way to protect content (up to a point) thus far but the semi-closed method might actually be the best solution for the hypergrid short of something more radical like a form of Mesh Networking as mentioned above - content sellers would have to decide what grids they trust and place examples of the assets they are selling there.

      Delete
    6. Hi Gaga,

      "When inventory is accessed, the hypergrid wrapper checks if the user is foreign and, if she is, the wrapper simply brings the necessary assets from the user's asset server to the local asset cache and server; from then on, the wrapper passes the control to the existing inventory access functions." - see: http://opensimulator.org/wiki/Hypergrid

      This means that anything you access while Hypergrid traveling is also available to the grid that you are visiting. As a result, that grid can ignore all your asset permissions if it so chooses. Assuming an Export permission were to be created the visited grid could still ignore all the other permissions for exportable assets. So if you didn't allow Copy/Transfer but allowed Export then the visited grid could still copy and transfer your asset. This is obviously not the desired behavior therefore forcing knowledgeable content creators who don't wish to allow Copy/Transfer to also disallow Export. If Export is only allowed when Copy and Transfer are also allowed then, for the purpose of deciding whether an asset should be exported, there is no point in checking whether Export is allowed unless Copy and Transfer are allowed as well. The only reason left for adding an Export permission is if we would like to enable content providers to allow Copy/Transfer on a grid but prevent the content from leaving that grid.

      The solution we propose for filtering out assets that don't have both Copy and Transfer permissions has the following benefits:

      - It enables Hypergrid traveling while stopping content which shouldn't be copied/transferred from being copied/transferred.

      - It allows more content to be taken with you while hypergrid traveling than just your full perm assets (see details about why we don't think Modify permissions should be used for filtering below).

      - It works with existing viewers.

      The only downside of this solution is that it forces content providers to decide whether they allow Copy/Transfer in a universal rather than a grid specific manner (my comment about semi-closed gardens and first sale doctrine). That is, content creators can decide to prevent copying/transferring with the existing permissions but if they allow Copy and Transfer then they allow it everywhere and not just on the grid where they provided/sold that content.

      Grids may decide that they don't want to allow content to arrive from some/all other grids (your customs analogy) but people should be able to take the assets that content providers allow them to Copy and Transfer with them when they travel the Hypergrid (at least to grids that don't place content import restrictions).

      In case you were wondering why we aren't looking at the Modify permission: not having a Modify permission prevents the asset from being modified in the home grid. If the asset can't be copied and transferred then, using the system we propose, it can't reach a third-party grid via Hypergrid travel so it won't be subject to changes by a grid that may potentially ignore the Modify permissions.

      Delete
    7. Ilan --

      I'm confused by the all perms-vs-copy and transfer perms discussion, but I see in the code that you contributed for the OAR filtering that you leave it up to the grid owners. I assume you'll be doing the same for the hypergrid code? That grid owners can decide on what basis to filter assets before allowing them off the grid?

      The main thing, of course, is that the grid is up front about it, and makes the rules clear to content creators: objects which are Copy and Transfer can leave the grid -- turn at least one of those perms off to keep content on the grid.

      That puts a reasonable amount of control in the hands of content creators, in that they can easily allow content to travel, or to stay local.

      Meanwhile, on teh Megaregion vs. multi-region issue: I know it's confusing, but you need to give your users a choice.

      For example, you can say:

      * I want the regions combined into a single megaregion, with no border crossings, to make walking around easier, or to use vehicles.
      * I don't want my regions combined because I plan to save them as individual OAR files.

      Alternatively, you can figure out a way to export OAR files from megaregions. I asked Diva about this, and she said the main issue is when objects span multiple regions.

      She said: "Technically, the center of each of those prims is in only one of the regions. So only that region simulates the object's physics. As a consequence, the parts of those objects that overflow to the adjacent region aren't simulated. What this means in practice is that there is no collision detection for those parts. People would be falling through floors, not stopping at walls, etc."

      In practice, what people do in these situations is make two copies of the objects that spans the regions, and have one anchored in one region, and the other one anchored in the other, so that people can walk across.

      So maybe you could do something similar if someone wants to take individual OARs of a megaregion?

      Or save them based on where the center of the object is, and when they're loaded back up again, have the object coordinates recalculated so that they'd be back in the first region again...

      I think people who are trying to save OARs out of megaregions planning to use them as single regions will probably be aware that weird things will happen at the region borders if they're not careful....

      Or, maybe, when saving the OAR files of a megaregion, you could ask people if they prefer to have everything saved normally (piled into the first region) or distributed between all the regions, and warn people if they have objects that span more than one region, and ask them if they want to save the object based on where its center is, or if they want to make copies of the object in each region it touches.

      I think these details are important, since Kitely is such a great platform for building. For example, I recently had to redo my Hyperica terminals, and instead of futzing around with setting up OpenSim on my home computer (and figuring out how to turn off the megaregions in the New World Studio!) I just loaded it into Kitely, worked on it there, then saved it again.

      It would be nice to work with multi-region builds as well, like the Universal Campus.

      But then again, sometimes you might have a big megaregion, and you just want to save part of it to reuse somewhere else.

      Delete
    8. Hi Maria,

      Please remember that requiring more permissions for content to leave the grid reduces the amount of content that can be sold on the grid to hypergrid visitors. If only full perm assets can be sold to hypergrid visitors then the grid is forcing content providers that wish to sell on that grid to sell full perm items or forfeit the ability to sell to people who come from outside the grid. In addition, the more variance there is in how things work on different grids the more people need to know when traveling the hypergrid. Popular online services are rarely non-intuitive so having different grids configured differently will likely hurt the adoption of OpenSim-based services.

      The more complicated we make things the harder it will be for new users to understand how they work, which will result in less people using our service. As a general rule, unless we have good reason to believe that at least 80% of our users will use a particular feature we don't implement it.

      When most internet users think of virtual worlds they don't expect them to have artificial regions that prevent things from working in an intuitive way. They expect one big world to behave as one big world. The need to understand region boundaries and their effect on prims, sim crossing, physics, and other internal implementation-derived limitations is IMO one of the contributing factors to why OpenSim, in its current form, doesn't see mass market adoption. If we decide to implement bigger worlds as megaregions we will therefore likely update the OAR format to include all the data from a megaregion inside a single OAR file - we won't invest R&D resources to develop the capability to break a megaregion into separate regions.

      The fact that OpenSim still uses regions is an implementation detail that end users shouldn't need to care about. Extending this unnatural internal design to the user interface is detrimental to having an intuitive user interface people can understand at a glance. If we want people to be able to intuitively grasp how things work then we need to fix OpenSim so that it correctly handles everything that happens in a megaregion as if it were on the same big region. This doesn't have to force us to break viewer support. It just means that the server needs to translate communications to and from the viewer to the expected region's coordinate system and internal data structures. This way when non-SL-derived viewers are developed we won't be stuck with an interface and archive files that were designed to fit a region-based architecture. We might not do this immediately when we roll out support for bigger worlds but that is the way I think it should work given the region-based design of existing viewers.

      Delete
    9. WOW ... quite the road trip of ideas & arguments.

      Delete
  3. Replies
    1. Awwww thank you Mera

      Hey. I will catch you soon and tickle you into next year!

      *laughs*

      Delete
  4. hey Faneuil Hall! i only leave an hour north of there and so far your work looks great!

    if Ilan reads this, he should do regular regions - that the architecture taht bth SL and OpenSim are built upon. megaregions make more sense but there's so much legacy stuff out there

    ReplyDelete
    Replies
    1. Hey Ener!

      Faneuil Hall is within the map area I am working on so, yes, I do aim to build it too. I have engraved pictures of the hall when it was first built for Peter Faneuil by the artist John Smibert in 1740–1742 in the style of an English country market. It was later rebuilt and enlarged but I want to built the original.

      Gaga

      Delete
  5. Thank you for your recommendation Ener :-)

    ReplyDelete
  6. Hi Ilan

    I think I understand better what you are aiming for now. One point you raise I think highlights an issue that content sellers need to consider when building their businesses in Opensim grids if your methods are adopted. It's fine if they want to limit their sales to the residents of a particular grid such as InWorldz which protects content by simply preventing it leaving their world - a walled garden as we say. However, for content sellers wanting to tap into a broader market which the hypergrid offers then I think they will have to become more proactive in how they serve their customers.

    I totally agree that it should not be made hard for sellers or for buyers if it can be avoided but hypergrid functions on a different level to Second Life and walled gardens in general. It is not so limited for options but it dose require sellers to learn the way things work if not the customers so much. The sellers will have to be willing to offer what they have already sold someone visiting the same item for free or heavily discounted on other grids they trust.

    Sunny Whitfield of Total Avatar Shop (see my Vendors links above) has been willing to visit any grid to make deliveries and the bottom line here is that vendors like Sunny with a robust approach to selling should build a good reputation and do well out of the hypergrid in time.

    It is important to allow the free flow of full perm content as supplied by Linda Kellie who places no restrictions on the use of what she offers but there are many more content creators who would sell there goods on the hypergrid if they were sure it wont get pirated and re-sold back in Second Life. But, as I said above, I think developers can only do so much and there will need to be compromise where vendors explore the best way to serve what they sell in multiple worlds. They will have to do the extra work like Sunny dose, or at there needs to be vendor scripts that can check databases over http to check if someone already owns something sold on another grid so they can be served a free or discounted copy in the current grid they have arrived in. Vendors could open outlet stores on all the grids they trust and this way insure their interests are protected while making many happy customers who use hypergrid. I really believe an approach like this will pay off as the hypergrid market grows.

    Ideally, it would be great if it were possible to identify assets across grids so the perms set by the creator could be discovered then it would only be a matter of the creator placing a sample on each grid they decide to trust. However, in the absence of something far more radical like blackhole assets, it seems to me that your approach might work out but it needs cooperation from vendors in developing ways to run the market and work with it's limitations.

    Gaga

    ReplyDelete
    Replies
    1. Hi Gaga,

      Even the music industry eventually understood that the best way to increase digital sales and combat online piracy was by selling content that can be used everywhere. As sad as it may be, popular content that can't be conveniently obtained on a grid will eventually be illegally uploaded into it by some user who got it via illegal means.

      Content can be pirated in closed gardens such as inworldz and second life using copybots and that hasn't prevented sellers from selling their warez in those grids. The fact that many content sellers fear hypergrid-connected grids more than closed gardens is IMO due to them ignoring the sad reality of how prevalent pirating is in closed gardens. People who want to steal can do so anywhere. People who only sell inside closed gardens end up being forced to deal with copybotted copies of their warez appearing on hypergrid-connected grids anyway, just without getting any profit from selling to those grids' residents.

      There NEED to be MUCH better tools for detecting and removing stolen content from grids but making hypergrid asset transfers complicated won't achieve the goal of eliminating or even reducing the prevalence of stolen content being resold inside both hypergrid-connected grids and closed gardens; the pirates who wish to do so will simply use more advanced tools to copybot the content from inside grids where it is legally viewable.

      Anything that runs on an open-source based server can be reprogrammed to bypass content protection methods used by other servers, so vendor-side scripts can't rely on responses from other OpenSim servers to determine whether content can be legally hypergrided to/from there. Therefore the only way a grid can protect the content it hosts from being copied by people who don't use pirating tools is to filter it out when it is legally exported, via OAR files or the hypergrid, based on the permissions the content creator defined inside that same grid.

      DRM only works to protect content from being passed to people who are willing to refrain from using copybots and other forms of illegal software to pirate that content - and those are not the people content sellers need to fear selling to in the first place no matter what type of grid they are on.

      We could easily design a repository that uses cryptographic means to try to ensure content won't reach undesired grids but, as history has proven time and again, no such content protection DRM software has ever stood the test of time and people end up illegally copying the content from where they can legally view it using tools that don't respect the DRM system.

      Content providers such as Sunny Whitfield who have stopped trying to fight the windmills of people's morals when it comes to digital content copying are seeing a profit where more cautious content creators are just seeing loses. The solution is in making content available everywhere at an affordable cost, not by only selling it in closed gardens. Avoiding hypergrid-connected grids just creates an ironic situation where the closed gardens that are kept closed to protect valuable content from being copied quickly become the place where content pirates copy most of their illegally obtained content from.

      Delete
  7. Just wanted to say GaGa that this historically based RPG of yours looks wonderfully beautiful and fun, looking forward to visiting it. I like mixes of history and fantasy in an RPG. and you said "Maybe even build Steampunk Venus or Mercury" ..Neato! I want to see that one too ... Keep up the wonder. --Araxie

    ReplyDelete
  8. Hi Araxie

    Yes, I enjoy historical role play and I love alternative technology such as that you see in Steampunk. I am fascinated by space too so I though how I could expand the Age of Sail theme but introducing the mad professor who invents fantastic craft that can ride the ether waves of space & time. In Steampunk - Space 1889 http://mateengreenway.com/steampunk/Space1889USA.htm this bases the alternative technology on the current tech of the Victorian era and all very much Jules Verne of course. I want to stay rooted in 1779 for the sake of the current pirate theme but if we go by Jules Verne then we can stretch the imagination to consider a Flying Machine that not only covers the long voyages to the planets by dipping into the ether (or changing vibration) but could indeed travel in time too. Why not arrive in 1889 on Mars!

    Besides, I like Art Nouveau, cancan, Moulin Rouge and all that romantic stuff too so it just has to have time travel!

    Here's another shot I like...

    http://mateengreenway.com/steampunk/MarsSunrise2.jpg

    I really do fancy building a Ether Flyer *laughs*

    I am also fascinated by that fairy bot of yours and I can imagine lots of possibilities (hell, you could work with me on this!) I like to idea of solo quests when no one is around on the regions to role play with. Or even a bunch of players heading off on an adventure around the sims taking hg trips and all. What I want for that is NPC characters such as a bar maid, a soldier or just someone to give out clues and messages. NPC bots would be great for that.

    Anyway. I am often in my main region on OSgrid at Farworldz so look me up some time. I am sure we have a lot to chat about.

    Gaga

    ReplyDelete
  9. Oooh fun! These look wonderful GaGa. I love them!
    I am a huge romantic too.
    I would be glad to bring you or help ya make some NPCs goodies for your worlds, and work with ya on some stuff.
    I need to stop being such a hermit inworld.

    Some of our role-playing gang publishes Pangenre (pangenre.com) rpg system. Its all old school around the table (or in our case around the camp-fire) stuff. Hope to get to play some this weekend in it - great weekend for camping here in Georgia.

    My friend Fred ran an awesome historically based Pirates campaign. He did tons of research for it. Playing my French drunkard captain was so fun.

    I ran a campaign where the Steam-punks were the evil ones. It was called "kill the Steam-punks". The PCs played a slave race (the Morlocks-(tips hat to Jules Verne). The Steam-punks were highly specialised slave-masters and fashionista who lived on the service. Morlocks in the under-cities. It was all set on my very favourite moon (Triton) a moon of Neptune. The moon had methane powered in- station fusion satellites for Suns. It had two kinds of magic in it, lots of air ships, strange robots and fun stuff like that.

    I'd like to start bringing some of my old-school rpg ideas to the simulators. I may do a faerie thing. I have ages of content about Faeries, all kinds, not just the silly and cute ones (though they are a part of it too).
    Some of the not so cute ones can scare the pants off a Lovecraft monster.
    I may even think of ways to tie it to space adventure as well.

    ReplyDelete