This is an open letter to the Decentraland community, which I wanted to share my experiences as a developer and artist with the Decentraland project and why currently my decision is to buy no MANA and purchase no LAND in that project.
This article is being submitted as an "Idea" through the Utopian IO community as a way to see what additional community reactions there are to this current state of the Decentraland projet, and foster additional conversations about these ideas. And since the Decentraland team has been actively sharing their design ideas and discussions with the community with a chance to shape them (notably Christopher Chapman as "Experience Architect" at Decentraland sharing his daily musings), I wanted to add my voice into that mix.
Repository
https://github.com/decentraland
Decentraland is a virtual space for users to traverse through and interact with other users. Ownership of regions of this virtual landscape is backed by tokens on the Ethereum blockchain ("LAND" tokens) with each LAND token being 10 meters square.
Components
Client UI and user interaction within the digital Decentraland landscape.
Proposal Description
I have been a user of one other virtual 3D world, Second Life, and indeed the Decentraland team and community have compared that world to Decentraland as well. Comparing my experiences there with the plans for the Decentraland virtual space, along with my background knowledge as a developer and 3D artist, I have a few suggestions:
Grounding yourself
One structural element that Second Life incorporates as a baseline in their world is a ground plane. Every parcel of land is forced to be connected to the ones surrounding it by and unbroken ground texture. This seems to be done with the intent that it would always be possible for an avatar to physically walk between parcels. However, in practice, land owners are given terraforming tools to be able to raise/lower the ground terrain, and can raise their land up much higher than their neighbors, creating a sharp "cliff" between the two that is too sharp to walk up as an avatar.
(Customized island in Second Life, showing dramatic elevation changes from water to island, and island to mountains/plateaus)
And as a virtual space where users can fly and teleport, how important is it really to maintain walk-ability between parcels? Having a ground plane also lops off the possibility of any sort of underground exhibit/experience being created. If you want to create recreations of Hobbit holes, subway stations, mines, or any other subterranean experience within Second Life, you have to create an artificial terrain layer (usually pretty obviously not the "natural" ground) for yourself, with a hole cut into it to allow a door to exist to the "underground".
Hence, I'd suggest the Decentraland virtual space have no ground terrain created at all. Now, you might think "But then what will avatars stand on when they first arrive in the space? How will a new LAND-owner create their structure?" Those would be problems experienced in Second Life if the ground plane were removed, as in Second Life, building is done by the avatars in the world itself (Minecraft as a virtual world also has this rubric; building is done by the character altering the world in the near vicinity of their avatar). Decentraland has already set the direction for their SDK to have the major structures of a LAND-owner's parcel be generated by code (written outside the VR experience entirely), so it's not critical to have a place for avatars to stand when doing their building.
Additionally, Decentraland has laid out the concept of roads. Second Life only has the concept of "land" and "water" as the base definition of the world, but Decentraland has dedicated some parcels as being roads, and wound their way through the other parcels. I think having those roads in there from the beginning, as a base feature of the world itself is a great idea. But in terms of how the roads appear in the game, I'd suggest to the Decentraland team that rather than envisioning this virtual land as the surface of a planet (with "real" terrain elements) instead it represent a "cloud city" in concept (floating in space). With that vision in mind, then the "roads" become walkways winding like ribbons through the space. Like a bridge with no upright supports (or like the "Rainbow Road" in MarioKart!), the roadways could have texture and some thickness, and possibly railings or curbs at the edges, and still fulfil the purposes for including them in the virtual world (default landing spaces for avatars, social spaces, transportation means, etc.).
(A road with thickness, winding through space, with room to build off the sides of it)
With those elements in place, then parcel owners then have the flexibility to build both up and down from "road-level", and using that as connotation with the experiences they create.
Sky's the limit
With the Second Life world, land owners purchase a footprint of land, and the height they have to work with is nearly limitless (objects can be placed up to 4,096 meters up). This leads to some parcel owners leasing out residential spots way high up in their space ("skyboxes"), as for most parcel owners, the structures they build at ground level would never reach nearly that high, so they lease it out as an additional money-maker.
Decentraland LAND parcels are even smaller than the smallest chunk of Second Life land (a 1/128 region parcel in Second Life is 16x32 meters, while a LAND parcel in Decentraland is 10x10 meters), and the height of the parcels are currently dependent on the number of parcels a given scene/entity occupies. A basic one-parcel scene is then capped at 20 meters. This is dramatically more restrictive, and also then makes the "ceiling" of the constructed items much more varied (if an avatar wants to fly above the city, they may have to adjust height several times as most things will be rather short, but will have occasional tall structures at random spots; it will be hard to tell how high you'd have to be to be above everything).
Having the heights be varied like that limits the usefulness of being "above" the city; there's very limited possibility for a consistent "skyport" level where avatars could congregate above "road level".
So, I propose having a consistent construction height limit for parcels, but allowing avatars to move freely above that height. Combining this idea with the "no ground terrain" idea, you get a visualization of a cloud city with several distinct "levels": "road-height" at the middle of the vertical range, and "top" and "bottom" of the vertical range, where land owners could build "spaceports" or "landing pads" for avatars to serve as a launching point into the unmanaged space above/below.
This concept of "moving beyond the boundaries" not only gives some value to parcel owners who aren't adjacent to a road (they at least have a "top" and a "bottom" area that cannot be blocked by neighbors), but it can also add value to those on the extreme outsides of the map. If avatars are also allowed to move laterally beyond the edges of the mapped parcels, the parcels on the edge can be similar to road-edged parcels in that neighbors cannot block them on that edge, and could structure themselves as a "spaceport" or "airship-port" for avatars to fly into (since there will be no road there to assist). A lack of easy navigation through unowned space in Second Life makes it much harder to traverse the land through any sort of vehicle, since land owners can ban others from entering their specific parcel, so a fast-moving vehicle may be stopped short at any time by a single banned parcel.
Having a consistent, large height limit (Second Life's 4,096 meters or something similar) will be way more height than most parcel owners would use (assuming that most structures that will mirror spaces a human avatar would walk through to experience would only be a couple dozen meters high in most cases), and so giving LAND-owners a built-in ability to sub-lease a chunk of their parcel (a certain vertical offset range) would be a useful feature to make sharing space consistent and trustworthy. It would give owners the ability to use regions of their parcel that they otherwise wouldn't be using to generate income for themselves, and it provides a basis for people to band together and buy a LAND parcel together. With the cheapest LAND tokens on the marketplace going for around 6,000 MANA, and MANA at around $0.075 USD, that puts the minimum entry point at around $450 USD. That's way to high for a casual user to buy into as a entry-level experience. Aftermarket rentals may pop up naturally, but having a built-in way to segregate a plot would make a group buy-in more appealing and less dependent on trust, and having all parcels be a consistent height would put all LAND-owners on equal footing for the possibility of getting sub-renters (like creating subdomains on a registered ENS name). I'm much more likely to purchase a parcel for $500 if I know there's a way for me as a casual owner to make some sort of recurring revenue off of it. Keeping the existing height limit increasing with contiguous parcel ownership would do more centralizing of power with those with the finances to own multiple parcels. This is a key reason I haven't bought into the project yet; with the minimum entry to "own" anything at more than $400, with no guarantee of recouping any of that cost, LAND ownership to me I'd classify as a luxury/trophy (the main purpose of it would be bragging rights; come look at this shiny thing I have), rather than something I'd use on its own.
Or, alternatively, having differently-shaped parcels be available for purchase. For me as an artist envisioning the experiences I could design in a virtual space, most are either tall and skinny or wide and flat. Very few are both extremely wide and extremely tall. Changing the footprint of the Genesis City parcels is probably not feasible at this point, so assuming they are set as 10x10x5000 meters, and a new city created with some parcels that were 50x50x200 and some that were 100x100x50 meters, those parcel dimensions are all the same amount of volume (500,000 cubic meters), and so are fair in the sense of area they occupy, but having different arrangements allows buyers to pick parcel types that match the intended use. The creation of things like full-sized sports fields could be created within a single parcel of the last type, and could lead to regions/districts where most of the experiences are racetracks, sports fields, and other, wide-open (but not very tall) spaces. And in another area tall and skinny experiences like climbing/diving would naturally assemble. Knowing that there's a build height for those types of parcels, Decentraland could stack regions on top of each other (one floating city above another) if they wanted, as well. If I wanted to build a sports-stadium-sized scene (approximately 200x100x70 meters) with the current parcel setup, I would need a 20x10 parcel grid, so would be 200 parcels, which would give me a build height of 150 meters, which is not too excessive for that sort of build. The only restriction would then be how expensive it would be to purchase a 200-parcel area; where one other owner snatching a parcel (and then either jacking up the price massively or the user going dark and not ever returning to the Decentraland project) in the middle would throw off my plans. Having a single land-owner messing up plans for a development project is something that happens in the real world, though I don't know if we want to bring that conflict into the virtual world as well, especially with the possibility of an owner losing their private keys and a LAND parcel getting permanently locked.
Bring in the web
The way the Decentraland SDK is shaping up, it calls for the structure of the world to be defined as code submitted by the creator of the parcel. But there's also talk of having various "things" (ERC721 tokens, mostly) have a physical representation in the space. I think this is a great idea to pursue; having the option to have carry-able or other 'detached' items move through the space that aren't just the creation of the LAND-owner. Second Life has the concept of "attachments" which allows users to customize their avatar by adding 3D models to body parts (allowing elaborate costumes) as well as having free-moving "physical" objects that can be ridden/driven through the space (vehicles, which then collide with other objects so as to not drive through walls) or move on their own (scripted "pets"). Having these things greatly enhances the experience, and I'm glad to see focus being given here.
One of the additional aspects of VR that applications like Bigscreen on Steam bring is the social act of enjoying computing together. People gather in a "Bigscreen" room to watch video streams together, or to show what's going on on their computer. That second aspect is mimicing the real-world interact that happens at a LAN party: people can stand over the shoulder of other users, watching them play the game, while at the same time glancing at other players screens to see the other perspectives too. That's the benefit of being in the same physical space for a LAN party. Having the ability to screen-share within Decentraland would bring that social atmosphere into that virtual space. Currently, watching an eSports game is either done on your own computer watching a live stream in your own home (solo experience), or done in a stadium type setting (social experience). Watching an eSports game in a stadium means the real players need to travel to the stadium, and they play on hardware there at the stadium. Attendees can see the players physically there, but also the game images on the stadium screens. If streaming video could be rendered onto geometry in a Decentraland parcel, then an eSports stadium could be constructed and competitors play with the same amount of social interaction as competing in a stadium, but without the need to physically go anywhere.
GitHub Account
My GitHub account: https://github.com/midnightlightning/
Hi @midnight426, thank you for your contribution.
You made a great post although I found it a little bit difficult to follow, maybe because I am not familiar with Decentraland.
It is seems that your post is more a discussion of why the developers should change their direction (regarding the restrictions/structure into the 3D world) instead of suggesting new features. Unfortunately Utopian doesn't reward this kind of posts (yet), but it will be useful for the developers to know your opinion, for sure.
However, I encourage you to keep contributing on Utopian. I recommend you to read this guide
Your contribution has been evaluated according to Utopian policies and guidelines.
Need help? Write a ticket on https://support.utopian.io/.
Chat with us on Discord.
[utopian-moderator]
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Okay, thank you for your feedback. As feedback for Utopian, I would suggest consider either re-wording or re-labeling the "Ideas" category, as after reading that guide and your comment that my post is not "suggesting new features" it seems that there's a heavy bias toward "ideas of things to add to the project" (features), rather than "ideas for future changes to the project" (an idea in a broader term).
Having the "Ideas" category focus on "suggesting new features" seem to me to limits the possibility of contributing to a project like Decentraland where it's in a formative state, and limits the possibility of a contribution proposing the removal of some aspect of the project (is that still a "feature" if it's not "adding something new"?), that would benefit the project in the long run.
If I were to rephrase my comments more like "change the appearance of the road structures from a realistic road on a hillside to a floating road with nothing suspending it", would that be a "feature", then? I couched my suggestions more like "when you do create the appearance of the road structures, consider making them look like a floating road with nothing supporting it", because the application is still in development and there's no code specifically for that component yet, but the point is the same, right? I would think "Idea" contributions to projects that are in the early stages like this would be beneficial in giving suggestions/direction so that the code gets written the most beneficial way the first time, rather than having to wait until they have some code output and then suggest re-working it?
If the focus Utopian wants to have is really on feature suggestions, my suggestion would be to rename "Ideas" to "Feature Ideas", to make it clear that it's a more focused, narrow type of idea, and more closely related to the "Development" contribution (a "Feature ideas" post could lead directly to a "Development" post where a developer then implements the described idea).
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Thank you for your feedback, I really appreciate it. We will try to re-word the name of the category to make it more clear.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Hi, I couldn't find the correct repository for the sections that you are talking about, it's seems that part of Decentraland are not Open Source or maybe I'm missing something.
Could you provide me the correct repository instead of the GitHub account?
Thank you.
[utopian-moderator]
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Sure thing! Decentraland as a project has parts of it that are complete and operational (like the MANA tokens operating on the Ethereum blockchain (source code for those contracts over here), and the Marketplace (source code over here).
However, other parts are still in development, and my comments/ideas are about the next phase of the project, which is creating a browser/viewer for multi-user interaction. Developers wanting to create content currently can follow Decentraland's SDK Documentation, which uses their CLI tool to create and build a local representation of the 3D world.
My comments are mainly in response to the Documentation/SDK directly, which shows the Decentraland team's current direction for putting restrictions/structure into the 3D world the CLI tool creates. For the sections I talk about:
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Thank you for your review, @favcau!
So far this week you've reviewed 1 contributions. Keep up the good work!
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Congratulations @midnight426! You have completed the following achievement on the Steem blockchain and have been rewarded with new badge(s) :
Award for the total payout received
Click on the badge to view your Board of Honor.
If you no longer want to receive notifications, reply to this comment with the word
STOP
Do not miss the last post from @steemitboard:
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit