Posts filed under "Business"
April 13, 2022
Game Governance Domains: a NFT Support Nightmare
A Game’s Governance Domain
There have always been key governance requirements for object trading economies in online games, even before user-generated-content enters the picture. I call this the game’s object governance domain.
Typically, an online game object governance domain has the following features (amongst others omitted for brevity):
- There is usually at least one fungible token currency
- There is often a mechanism for player-to-player direct exchange
- There is often one or more automattic markets to exchange between tokens and objects
- May be player to player transactions
- May be operator to player transactions (aka vending and recycling machinery)
- Managed by the game operator
- There is a mechanism for reporting problems/disputes
- There is a mechanism for adjudicating conflicts
- There are mechanisms for resolving a disputes, including:
- Reversing transactions
- Destroying objects
- Minting and distributing objects
- Minting and distributing tokens
- Account, Character, and Legal sanctions
- Rarely: Changes to TOS and Community Guidelines
In short, the economy is entirely in the ultimate control of the game operator. In effect, anything can be “undone” and injured parties can be “made whole” through an entire range of solutions.
Scary Future: Crypto? Where’s Undo?
Introducing blockchain tokens (BTC, for example) means that certain transactions become “irreversible”, since all transactions on the chain are 1) Atomic and 2) Expensive. In contrast, many thousands of credit-card transactions are reversed every minute of every day (accidental double charges, stolen cards, etc.) Having a market to sell an in-game object for BTC will require extending the governance domain to cover very specific rules about what happens when the purchaser has a conflict with a transaction. Are you really going to tell customers “All BTC transactions are final. No refunds. Even if your kid spent the money without permission. Even if someone stole your wallet”?
Nightmare Future: Game UGC & NFTs? Ack!
At least with your own game governance domain, you had complete control over IP presented in your game and some control, or at least influence, over the games economy. But it gets pretty intense to think about objects/resources created by non-employees being purchased/traded on markets outside of your game governance domain.
When your game allows content that was not created within that game’s governance domain, all bets are off when it comes to trying to service customer support calls. And there will be several orders of magnitude more complaints. Look at Twitter, Facebook, and Youtube and all of the mechanisms they need to support IP-related complaints, abuse complaints, and robot-spam content. Huge teams of folks spending millions of dollars in support of Machine Learning are not able to stem the tide. Those companies’ revenue depends primarily on UGC, so that’s what they have to deal with.
NFTs are no help. They don’t come with any governance support whatsoever. They are an unreliable resource pointer. There is no way to make any testable claims about any single attribute of the resource. When they point to media resources (video, jpg, etc.) there is no way to verify that the resource reference is valid or legal in any governance domain. Might as well be whatever someone randomly uploaded to a photo service – oh wait, it is.
NFTs have been stolen, confused, hijacked, phished, rug-pulled, wash-traded, etc. NFT Images (like all internet images) have been copied, flipped, stolen, misappropriated, and explicitly transformed. There is no undo, and there is no governance domain. OpenSea, because they run a market, gets constant complaints when there is a problem, but they can’t reverse anything. So they madly try to “prevent bad listings” and “punish bad accounts” – all closing the barn door after the horse has left. Oh, and now they are blocking IDs/IPs from sanctioned countries.
So, even if a game tries to accept NFT resources into their game – they end up in the same situation as OpenSea – inheriting all the problems of irreversibility, IP abuse, plus new kinds of harassment with no real way to resolve complaints.
Until blockchain tokens have RL-bank-style undo, and decentralized trading systems provide mechanisms for a reasonable standard of governance, online games should probably just stick with what they know: “If we made it, we’ll deal with any governance problems ourselves.”
February 7, 2017
Open Source Lucasfilm’s Habitat Restoration Underway
It’s all open source!
Yes – if you haven’t heard, we’ve got the core of the first graphical MMO/VW up and running and the project needs help with code, tools, doc, and world restoration.
I’m leading the effort, with Chip leading the underlying modern server: the Elko project – the Nth generation gaming server, still implementing the basic object model from the original game.
http://neohabitat.org is the root of it all.
http://slack.neohabitat.org to join the project team Slack.
http://github.com/frandallfarmer/neohabitat to fork the repo.
To contribute, you should be capable to use a shell, fork a repo, build it, and run it. Current developers use: shell, Eclipse, Vagrant, or Docker.
To get access to the demo server (not at all bullet proofed) join the project.
We’ve had people from around the world in there already! (See the photos)
http://neohabitat.org #opensource #c64 #themade
March 5, 2014
Two Recipes for Stone Soup [A Fable of Pre-Funding Startups]
There once was a young Zen master, who had earned a decent name for himself throughout the land. He was not famous, but many of his peers knew of his reputation for being wise and fair. During his career, he was renowned for his loyalty to whatever dojo he was attached to, usually for many years at a time. One year his patronage decided to merge with another, larger dojo, and the young master found himself unexpectedly looking for a new livelihood. But he was not desperate, as he’d heeded the words of his mentor and had kept close contact with many other Zen masters over the years and considered many options.
As word spread about the young master’s availability, he began to receive more interest than he could possibly ever fulfill. It took all of his Zen training and long nights just to keep up with the correspondence and meetings. He was getting queries from well-established cooperatives, various governments, charitable groups, many recently formed houses, and even more people who had a grand idea around which to form a whole-new kind of dojo. This latter category was intriguing, but the most fraught with peril. There were too many people with too many ideas for the young master to sort between. So he decided to consult with his mentor. At least one more time, he would be the apprentice and ventured forth to the dojo of his youth, a half-day’s journey away.
“Master, the road ahead is filled with many choices, some are well traveled roads and others are merely slight indentations in the grass that may some day become paths. How can I choose?” asked the apprentice.
The mentor replied, “Have you considered the wide roads and the state-maintained roads?”
“Yes, I know them well and have many reasons to continue on one of them, but these untrodden paths still call to me. It is as if there is a man with his hands at his mouth standing at each one shouting to follow his new path to riches and glory. How do I sort out the truth of their words?” The young master was genuinely perplexed.
“You are wise, my son, to seek council on this matter — as sweet smelling words are enticing indeed and could lead you down a path of ruin or great fortune. Recount to me now two of the recruiting stories that you have heard and I will advise you.” The mentor’s face relaxed and his eyes closed as he dropped into thought, which was exactly what the young master needed to calm himself sufficiently to relate the stories.
After the mentor had heard the stories, he continued meditating for several minutes before speaking again: “Former apprentice, do you recall the story and lesson of Stone Soup?”
“Yes, master. We learned it as young adepts. It is the story of a man who pretended that he had a magic stone for making the world’s best soup, which he then used to convince others to contribute ingredients to the broth until a delicious brew was made. This story was about how leadership and an idea can ease people into cooperating to create great things for the good of them all.” recounted the student. “I can see the similarity between the callers standing on the new paths and the man with the magic stone. Also it is clear that that the ingredients are symbolic of the skills of the potential recruits. But, I don’t see how that helps me.” The apprentice had many years of experience with the mentor, and knew that this challenge would get the answer he was looking for.
“The stories you told me are two different recipes for Stone Soup,” the master started.
“The first caller was a man with a certain and impressive voice that said to you ‘You should join my dojo! It is like none other and it is a good and easy path that will lead to great riches. Many people that you know, such as Haruko and Jin, have tested this path and others who have great reputations including Master Po and Teacher Win are going to walk upon it as well. Your reputation would be invaluable to our venture. Join us now!'”
“The second caller was a humble and uncertain man who spoke softly as he said ‘You should join my dojo. It is like none other and the path, though potentially fraught with peril, could lead to riches if the right combination of people were to take to it. Your reputation is well known, and if you were to join the party, the chance of success would increase greatly. Would you consider meeting here in two days time to talk to others to discuss our goals and to see if a suitable party could be formed? Even if you don’t join us, any advice you have would be invaluable.” The mentor paused to see if his former student understood.
The young master said “I don’t see much difference, other than the second man seems the weaker.”
The mentor suppressed a sigh. Clearly this visit would not have been necessary if the young master were able to see this himself. Besides, it was good to see his student again and to be discussing such a wealth of opportunities.
He resumed, “Remember the parable of Stone Soup. The first man did not. He recited many names as if those names carried the weight of the reputations of their owners. He has forgotten the objective of the parable: The Soup. It is not the names or reputations of the people who placed the ingredients into the soup that mattered. It was that the soup needed the ingredients and the people added them anonymously, in exchange for a bowl of the broth. The first man merely suggested that important people were committed to the journey. I am quite certain that, were you to ask Haruko and Jin what names they have heard as being associated with the proposed dojo, you would find that your name was provided as a reference without your knowledge or consent.”
The student clearly became agitated as the truth of his mentor’s words sunk in. There was work to do before the day was done in order to repair any damage to his reputation that speaking with the first man may have caused.
The mentor continued, “The first recipe for Stone Soup is The Braggarts Brew. It tastes just like hot water because when everyone finds out that the founder is a liar, they all recover whatever ingredients they can to take them home and try to dry them out.”
The mentor took a quick drink, but gave a quelling glance that told the apprentice to remain silent until the lesson was over.
“You called the second man weaker, but his weakness is like that of the man with the Stone from the parable. He keeps his eyes on the goal — creating the Soup or staffing his dojo. Without excellent ingredients, there will be no success; and the best way to get them is to appeal to the better nature of those who possess them. He, by listening to them, transforms the dojo into a community project — which many contribute to, even if only a little bit.”
“Your skills, young master, are impressive on their own. You need not compare yourself with others, nor should you be impressed with one who would so trivially invoke the reputation of others, as if they were magic words in some charm.”
“The second recipe for Stone Soup is Humble Chowder, seasoned with a healthy dash of realism. This is the tempting broth.” And the mentor was finished.
The apprentice jumped up — “Master! I am so thankful! I knew that coming to you would help me see the truth. And now, I see a greater truth — you are also the man with a Stone. Please tell me what I can contribute to your Soup.”
“Choose your next course wisely, and return to me with the story so that I may share it with the next class of students.”
“I will!”
And with that, the young master ran as quickly as he could to catch up with the group meeting about the second man’s dojo. He wasn’t certain if he’d join them, but the honor of being able to contribute to its foundation would enough payment for now. When he approached the seated group, he was delighted to see several people whose reputation he respected around the fire, discussing amazing possibilities. One of them was Jin, who was shocked to learn that the first man had given his name to the young master…
[This is a long-lost post, originally posted on our old site six years go. Once again, the internet archive to the rescue!]
August 26, 2013
Randy’s Got a Podcast: Social Media Clarity
I’ve teamed up with Bryce Glass and Marc Smith to create a podcast – here’s the link and the blurb:
Social Media Clarity – 15 minutes of concentrated analysis and advice about social media in platform and product design.
First episode contents:
News: Rumor – Facebook is about to limit 3rd party app access to user data!
Topic: What is a social network, why should a product designer care, and where do you get one?
Tip: NodeXL – Instant Social Network Analysis
August 23, 2013
Patents and Software and Trials, Oh My! An Inventor’s View
What does almost 20 years of software patents yield? You’d be surprised!
I gave an Ignite talk (5 minutes: 20 slides advancing every 15 seconds) entitled
“Patents and Software and Trials, Oh My! An Inventor’s View”
Here’s some improved links…
-
I’ve created ip-reform.org to support the “I Won’t Sign Bogus Patents” pledge.
-
Encourage your company to adopt Twitter’s Inventor’s Patent Agreement
-
Support the The EFF on Patent Reform – DefendInnovation.org has a proposal
-
Sequestration has delayed a bay area PTO office, support this bill
I gave the talk twice, and the second version is also available (shows me giving the talk and static versions of my slides…) – watch that here:
April 14, 2011
We’re at it again and we’re hiring…
Chip has created the Nth generation of his massive-scale real-time server architecture (the spiritual descendent of Habitat) and we think the time is right for mobile/social games to go multiplayer! So we’ve gotten the band back together, and you can join us!
FUDCorp Job Openings
Real-Time Game Server Programmer, SF Bay Area
About us: a still-stealth start-up with a groundbreaking mobile/gaming platform that will reshape social games/apps. Get in on the ground floor with world-class founders and established technology. If you know us, you what we’ve built since the earliest days of online play.
Your role:
- Writing server-side Java code for an original massively multiplayer mobile online game
- Writing/maintaining testing frameworks (mostly in JavaScript for Node.js) for rapid development and massive scale performance evaluation
- This is a contract position, with potential to join our full-time team
Job Requirements:
- Immediate Availability. Our recent successes (partners and funding) means we need more help immediately!
- San Francisco Bay Area. With live meetings at least weekly, increasing over time.
- Minimum 3 years as a professional Java programmer working on client-server applications in a small, decentralized team.
- Strong Linux/Unix skills: shell scripting, command line tools, server administration, etc.
- Big plus: server-side JavaScript/ECMAScript skills, especially with Node.js
- Big plus: experience with Amazon EC2, and optimizing server features for automatic deployment
- Big plus: previous work with implementing social games, such as taxonomies, economies, abuse mitigation, and social issues
- Big plus: experience with iPhone or Android app development
Please send resume and contact info to jobs@fudcorp.com.
January 15, 2011
Requiem for Blue Mars
Another virtual world startup (Blue Mars) is dying. At The Andromeda Media Group Blog Will Burns [Aeonix Aeon] writes:
Looking Back at the Future
The really interesting part about all of this is that in order to see the future of Avatar Reality, and subsequently Blue Mars (or any virtual environment today), we need not look into the future but instead look to the past…
[many interesting insights about 1990s era worlds]
In 1990, the solution was given by two people to all of this madness. Chip Morningstar and F. Randall Farmer, authors of Lessons Learned From Lucasfilm’s Habitat. Strangely enough I had asked Mr Farmer about Linden Lab and he informed me that he was actually called in as a consultant in the early days, and not surprisingly, ignored.
That’s a bit of a harsh summary, but more than five years ago I did write The Business of Social Avatar Virtual Worlds: Or, why I really like Second Life, even if their business is most likely doomed. Clearly I wasn’t 100% right about them – they found a business model that at least got them to cover their run-rate. But many of the things in there may to apply to Blue Mars…
November 16, 2010
Quora:What lessons of Social Web do you wish had been better integrated into Yahoo?
On Quora, an anonymous user asked me the following question:
In hindsight, what lessons have you learned from the Social Web that you wish you had been more successful at integrating into Yahoo before you were let go?
I considered this question at length when composing this reply – this is probably the most thought-provoking question I’ve been asked to publicly address in months.
If you read any of my blog posts (or my recent book), you already know that I’ve got a lot of opinions about how the Social Web works: I rant often about identity, reputation, karma, community management, social application design, and business models.
I did these same things during my time for and at Yahoo!
We invented/improved user-status sharing (what later became known as Facebook Newsfeeds) when we created Yahoo! 360° [Despite Facebook’s recently granted patent, we have prior art in the form of an earlier patent application and the evidence of an earlier public implementation.]
But 360 was prematurely abandoned in favor of a doomed-from-the-start experiment called Yahoo!Mash. It failed out of the gate because the idea was driven not by research, but personality. But we had hope in the form of the Yahoo! Open Strategy, which promised a new profile full of social media features, deeply integrated with other social sites from the very beginning. After a year of development – Surprise! – Yahoo! flubbed that implementation as well. In four attempts (Profiles, 360, Mash, YOS) they’d only had one marginal success (360), which they sabotaged several times by telling users over and over that the service was being shut down and replaced with inferior functionality. Game over for profiles.
We created a reputation platform and deployed successful reputation models in various places on Yahoo! to decrease operational costs and to identify the best content for search results and to be featured on property home pages [See: The Building Web Reputation Systems Wiki and search for Yahoo to read more.]
The process of integrating with the reputation platform required product management support, but almost immediately after my departure the platform was shipped off to Bangalore to be sunsetted. Ironically, since then the folks at Yahoo! are thinking about building a new reputation platform – since reputation is obviously important, and everyone from the original team has either left, been laid off, or moved on to other teams. Again, this will be the fourth implementation of a reputation platform…
Are you sensing a pattern yet?
Then there’s identity. The tripartite identity model I’ve blogged about was developed while at Yahoo an attempt to explain why it is brain-dead to ask users to reveal their IM name, their email address, and half their login credentials to spammers in order to leave a review of a hotel.
Again we built a massively scalable identity service platform to allow users to be seen as their nickname, age, and location instead of their YID. And again, Yahoo! failed to deploy properly. Despite a cross-company VP-level mandate, each individual business unit silo dragged their heels in doing the (non-trivial, but important and relatively easy) work of integrating the platform. Those BUs knew the truth of Yahoo! – if you delay long enough, any platform change will lose its support when the driving folks leave or are reassigned. So – most properties on Yahoo! are still displaying YIDs and getting up to 90% fewer user contributions as a result.
That’s what I learned: Yahoo! can’t innovate in Social Media. It has a long history in this, from Yahoo! Groups, which during my tenure had three separate web 2.0 re-designs, with each tossed on the floor in favor of cheap and easy (and useless) integrations (like with Yahoo! Answers) to Flickr, Upcoming, and Delicious. I’m sad to say, Yahoo! seems incapable of reprogramming its DNA, despite regular infusions of new blood. Each attempt ends in either an immune-response (Flickr has its own offices, and a fairly well known disdain for Sunnyvale) or assimilation and decreasing relevance (HotJobs, Personals, Groups, etc.).
So, in the end, I find I can’t answer the question. I was one of many people who tried to drive home the lessons of the social web for the entire time I was there. YOS (of which I helped spec in fall 2007) was the last attempt to reshape the company to be social through and through. But, it was a lost cause – the very structure of the environment is personality driven. When those personalities leave, their projects immediately get transferred to Bangalore for end-of-life support, just as much of YOS has been…
I don’t know what Yahoo! is anymore, but I know it isn’t inventing the future of social anything.
[As I sat through this years F8 developers conference, and listen to Mark Z describe 95% of the YOS design, almost 3 years later, I knew I’d have to write this missive one day. So thanks for the prodding , Anonymous @ Quora]
Randy Farmer
Social Media Consultant, MSB Associates
Former Community Strategy Analyst for Yahoo!
[Please direct comments to Quora]
October 12, 2010
First! Randy to be the kickoff guest for new Community Chat podcast series.
Bill Johnston and Thomas Knolls are launching a new live podcast series: Community Chat on talkshoe.
I am so honored to be the lead-off guest on their inagural episode (Wednesday 10-13-10):
|
I’ll be talking with them about online community issues developers and operators all share in common – well, as much as I can in 10 minutes. :-) Click on the widget above to go there – it will be recorded for those who missed it live…
February 24, 2010
Grizzled Advice from Business & Legal Primer for Game Development
[Two years ago, I wrote up a few lessons for inclusion in Business & Legal Primer for Game Development. I’d always meant to cross-post it here and was surprised to see I hadn’t already when I went looking for it to share with the folks over at PlayNoEvil in reply to a recent post. – Randy]
Here are three top-line lessons for those considering designing their own MMORG or latest Facebook game for that matter…
1. Design Hubris Wastes Millions
Read all the papers/books/blogs written by your predecessors that you can – multi-user game designers are pretty chatty about their successes and failures. Pay close attention to their failures – try not to duplicate those. Believe it or not, several documented failures have been repeated over and over in multiple games, despite these freely available resources.
If you are going to ignore one of the lessons of those who went before, presumably because you think you know a better way, do it with your eyes wide open and be ready to change to plan B if your innovation doesn’t work out the way you expected. If you want to hash your idea out before committing it to code, consider consulting with the more experienced designers – they post on Terra Nova (http://blogs.terranova.com/) and talk to budding designers on the Mud-Dev (http://www.kanga.nu/) mailing list, amongst other places. Many of them respond pretty positively to direct contact via email – just be polite and ask your question clearly – after all, they are busy building their own worlds.
2. Beta Testers != Paying Customers
One recurring error in multi-user game testing is the problem of assuming that Beta users of a product will behave like real customers would. They don’t, for several reasons:
A. Beta testing is a status symbol amongst their peers
“I’m in the ZYXWorld Limited Beta!” is a bragging right. Since it has street-cred value, this leads the user to be on their best behavior. They will grief much less. They will share EULA breaking hacks with each other much less. They will harass much less. They won’t report duping bugs. The eBay aftermarket for goods won’t exist. In short, anything that would get them kicked out of the beta won’t happen anywhere near as often as when the product is released.
B. Beta testers aren’t paying.
Paying changes everything. During the Beta, the users work for you. When you release the game, you are working for them. Now some users will expect to be allowed to do all sorts of nasty things that they would never had done during the Beta. Those who were Beta users (and behaved then) will start to exploit bugs they found during the test period, but never reported. Bad beta users save up bugs, so they could use them after your product’s release to gain an edge over the new users, to dupe gold, or to just crash your server to show off to a friend.
So, you’re probably wondering; How do I get my Beta testers to show me what life on my service will really be like and to help me find the important bugs/exploits/crashes before I ship? Here are some strategies that worked for projects I worked on:
Crash Our World: Own up to the fact that Beta testers work for you and they do it for the status – incentivize the finding of crash/dup/exploit bugs that you want them to find. Give them a t-shirt for finding one. Put their portrait on the Beta Hall Of Fame page. Give them a rare in-world item that they can carry on into general release. Drop a monument in the world, listing the names of the testers that submitted the most heinous bugs. Turn it into a contest. Make it more valuable to report a bug than to keep it secret.
Pay-ta: Run a Paid Beta phase (after Crash Our World) to find out how users will interact with each other socially (or using your in-game social/communications features.) During this phase of testing you will get better results about which social features to prioritize/fix for release. Encourage and/or track the creation of fan communities, content databases, and add-ons – it will help you understand what to prepare for, as well as build word-of-mouth marketing. But, keep in mind that there is one thing you can never really test in advance: How your user community will socially scale. As the number of users grows, the type of user will diversify. For most games, the hard-core gamers come first and the casual players come later. Be sure to have a community manager whose job it is to track customer sentiment and understand the main player groups. How your community scales will challenge your development priorities and the choices you make will have you trading off new-customer acquisition vs. veteran player retention.
3. There Are No Game Secrets, Period
Thanks to the internet – in-game puzzles are solved for everyone at the speed of the fastest solver. Read about “The D’nalsi Island” adventure in Lucasfilm’s Habitat where the players consumed hundreds of development hours in only tens of minutes.
The Lesson? Don’t count on secrets to hold up for long. Instead, treat game walk-thru websites as a feature to be embraced instead of the bane of your existence. “But,” you’ll say, “I could create a version of my puzzle that is customized (randomized) for every user! That will slow them down!” Don’t bother; it will only upset your users.
The Tragedy of the Tapers
Consider the example of the per-player customized spell system in the original Asheron’s Call (by Turbine, Inc.): Each magic spell was designed to consume various types of several resources: scarabs, herbs, powders, potions, and colored tapers. The designers thought it would be great to have the users actually learn the spells by having to discover them through experimentation. The formula was different for every spell and the tapers were different for every user.
One can just hear the designer saying “That’ll fix those Internet spoilers! With this system, they each have to learn their own spells!” But, instead of feeling enjoyment, the players became frustrated with what seemed to be nothing other than a waste of their time and resources burning spell components as they were compelled to try the complete set of exponential combinations of tapers for no good reason.
What was interesting is that the users got frustrated enough to actually figure out the exact method of generating the random seed to determine the tapers for each user as follows:
Second Taper = (SEED * [ Talisman + (Herb + 3) + ((Powder + Potion) * 2) + (Scarab – 2) ] ) mod 12
[Modified from Jon Krueger’s web page on the subject.]
The players put this all into a client plug-in to remove the calculation overhead, and were now able to correctly formulate the spells the very first time they tried. Unfortunately, this meant that new users (who didn’t know about the plug-in) were likely to have a significantly poorer experience than veterans.
To Turbine’s credit, they revised the game in its second year to remove the need for most of the spell components and created rainbow tapers, which worked for all users in all spells, completely canceling the original per-player design.
Hundreds of thousands of dollars went into that spell system. The users made a large chunk of that effort obsolete very quickly, and Turbine then had to pay for more development and testing to undo their design.
Learn from Turbine’s mistake; Focus on making your game fun even if the player can look up all the answers in a database or a plug-in.
Don’t start a secrecy arms-war with your user. You’ll lose. Remember: There are more of them than you and collectively they have more time to work on your product than you do.