Tokyo (Giappone) – Sony Online Entertainment apre le porte al mercato parallelo di personaggi ed oggetti virtuali. La software house fa crollare i divieti che finora punivano tutti gli utenti dediti allo scambio di merci digitali. L’esplosione di un fiorente mercato illegittimo basato sull’universo di Everquest ha vieppiù aperto nuove prospettive di guadagno.
Al riparo da truffatori e raggiri, il servizio verrà attivato entro la fine di giugno e si chiamerà Station Exchange . Tramite uno speciale sito web i giocatori avranno la possibilità di acquistare denaro virtuale da utilizzare all’interno di Everquest. Gli utenti gioiscono, mentre gli amministratori di Sony si strofinano le mani.
“Il mercato parallelo attorno ai giochi online è in crescita e molti nostri utenti ne fanno già parte”, ha dichiarato John Smedley, presidente di Sony Online. “E’ nostra intenzione creare un nuovo standard per la vendita di oggetti virtuali”. Infatti su Station Exchange gli utenti pagheranno una somma nominale per ogni annuncio che pubblicheranno. C’è da ricordare che i giocatori non eserciteranno diritto di proprietà su quanto acquistato: godranno semplicemente di una licenza d’uso limitata.
Il mercato dei giochi multiplayer è sempre più esteso. Secondo gli autori di Playstation, la compravendita di oggetti virtuali potrebbe generare annualmente oltre ottocento milioni di dollari . Everquest avrebbe in pugno il 20% del mercato globale del divertimento online. Tra i concorrenti che dispongono di un proprio sistema economico è da ricordare Project Entropia e Gunbound .
Tommaso Lombardi
-
Peccato che...
...così come è scritto l'articolo sembri chissà cosa.In realtà la specifica è praticamente inutile in tutti i contesti in cui i servizi utilizzano protocolli di trasposto sopra TCP (ossia il 99,9% dei casi) che già svolge questa funzione.Solo una semplice estensione per portare web service affidabili nell'altro 0,1% delle soluzioni.bye brainRe: Peccato che...
- Scritto da: Anonimo> In realtà la specifica è praticamente inutile in> tutti i contesti in cui i servizi utilizzano> protocolli di trasposto sopra TCP (ossia il 99,9%> dei casi) che già svolge questa funzione.> TCP fornisce soltanto un servizio con connessione punto-punto. Le tecnologie basate su Web-Services riguardano l'interoperabilità tra partner differenti (in termini di piattaforme hardware/software) e quindi devono fornire "qualcosa in più" del semplice TCP. La famiglia di protocolli della serie WS-* fornisce un numero elevato di funzionalità che discuterne qui sarebbe troppo oneroso e riguardano: la politica dei trasferimenti, la sicurezza, le transazioni atomiche, l'indirizzamento, il trasferimento affidabile... questi protocolli possono essere combinati tra loro (come dei mattoni) per fornire funzionalità inimmaginabili negli strati inferiori della pila protocollare. Inoltre i messaggi che vengono scambiati tra WS non sono vincolati ad uno specifico protocollo di trasporto. Molto utilizzato è http (che funziona su tcp), ma un generico messaggio può attraversare anche tratti su protocolli differenti. Si capisce come sia fondamentale un protocollo affidabile che lavori al di sopra (ad es.) di http e che riesca a gestire in maniera ESPLICITA i messaggi SOAP (ricordiamo che tcp riguarda i segmenti e non ha alcuna conoscenza del tipo di messaggi che vi viaggiano sopra).Re: Peccato che...
bla bla!venendo all'osso! ma insomma dove e come usi i web services senza tcp?Casi di uso prego non chiacchere!Altrimenti siamo alle solite (complicazione del semplice attraverso l'inutile!)Byeuna volta?
E' impossibile essere sicuri che un messaggio sia stato consegnato una e una sola volta, qualunque sia il protocollo utilizzato.E' un problema classico.Re: una volta?
- Scritto da: Anonimo> E' impossibile essere sicuri che un messaggio sia> stato consegnato una e una sola volta, qualunque> sia il protocollo utilizzato.> > E' un problema classico.Non è impossibile in senso teorico. Noi siamo abituati a ragionare in termini di TCP/IP che rappresenta una pila di protocolli molto semplici, che devolvono gran parte del lavoro ai terminali in gioco, ragion per cui tutta una serie di problemi relativi ad es. al trasferimento affidabile devono essere risolti su pile protocollari costruite SOPRA TCP/IP. I Web Services riguardano proprio questo.Re: una volta?
- Scritto da: Anonimo> E' impossibile essere sicuri che un messaggio sia> stato consegnato una e una sola volta, qualunque> sia il protocollo utilizzato.> > E' un problema classico.E' impossibile senza la collaborazione di tutti e due, questo dice la teoria. Ossia chi spedisce non può garantire "once & only once" se il ricevente non collabora.In realtà è abbastanza banale implementarlo, basta che per il time to live del messaggio il ricevente mantenga un identificativo dei msg ricevuti e scarti i duplicati ricevuti (sliding window)Qualsiasi middleware di messaggistica lo fa out-of-the-box e anche TCP lo fa (a dun livello molto più basso)Ora si parla di estendere la cosa ai web-services (è da un po' che si parla di ReliableMessaging)Re: una volta?
- Scritto da: Anonimo> (è da un po' che si parla di ReliableMessaging)Oh penso che si possa scrivere staccato (se non addirittura in Italiano ;) )Re: una volta?
Il protocollo credo si chiami WS-ReliableMessage e sia una proposta congiunta IBM-Microsoft-BEA per la standardizzazione.Re: una volta?
- Scritto da: Anonimo> - Scritto da: Anonimo> > (è da un po' che si parla di ReliableMessaging)> > Oh penso che si possa scrivere staccato (se non> addirittura in Italiano ;) )ReliableMessaging è il nome della specificaMicrosoft Indigo lo usa?
Indigo lo userà? Sarebbe molto comodo, anche se nella beta che ho io ancora non ce ne sono tracce.Re: Microsoft Indigo lo usa?
- Scritto da: Anonimo> > Indigo lo userà? Sarebbe molto comodo, anche> se nella beta che ho io ancora non ce ne sono> tracce.http://www.c-sharpcorner.com/Code/2004/May/ReliableWebServices.aspGrazie, il tuo commento è in fase di approvazioneGrazie, il tuo commento è stato pubblicatoCommento non inviatoLeggi gli altri commenti21 04 2005
Link copiato negli appuntiTi potrebbe interessare
21 04 2005Link copiato negli appunti
