Folien von meinem Vortag "Echtzeit Browsergames" von der PYCON DE 2012 in Leipzig.
https://2012.de.pycon.org/programm/schedule/sessions/19/
Mit gevent und browserseitigem JavaScript können Mehrspieler Browsergames entwickelt werden, die Spielerinteraktionen in Echtzeit zulassen. Dieser Vortrag versucht Lust auf das Echtzeit Web zu machen und zeigt anhand eines konkreten Spieles (KODEX, http://kodexgame.com/) Lösungen für Entwicklung, Hosting und Vertrieb auf.
Der Vortrag beleuchtet neben den Implikationen des Realtime Web wie Caching, Scaling, Same-Origin-Policy und Cross-Origin-Resource-Sharing auch Strategien zur horizontalen Skalierbarkeit, oder: Wie löst man das C10K Problem?
Während NodeJS oft als die Lösung für Echtzeitanwendungen angepriesen wird, kommt hier auf der Serverseite gezielt Python mit gevent zum Einsatz.
1. Echtzeit Browsergames
Michael P. Jung <me@bikeshedder.com>
Thursday, 1. November 2012 [W]
2. Kapitel 0 – Michael P. Jung
whoami
Thursday, 1. November 2012 [W]
3. Michael P. Jung
Software Engineer und Designer
Softwareentwickler
C, C++, Python, Java (uvm.) me@bikeshedder.com
Linux Benutzer
seit 1994
Python Entwickler
seit Python 2.3, ~2003
Django Entwickler
seit magic-removal branch, ~2006
Brettspielefan
Thursday, 1. November 2012 [W]
4. http://terreon.de/
Software und Design
Gegründet: 2000
Echtzeit Client-Server-Anwendungen
E-Commerce
App-Developers (HTML5)
Game Developers
Thursday, 1. November 2012 [W]
5. http://pyrox.eu/
Hosting Experts
@pyrox_eu
Gegründet: 2008
Python Shared Hosting
Individuelle Hostinglösungen
“The next big thing” (ETA 2013)
Thursday, 1. November 2012 [W]
6. Kapitel 1 – Konzept
Von der Idee zum Spiel
Thursday, 1. November 2012 [W]
19. Kapitel 2 – Technik
von async bis zmq
Thursday, 1. November 2012 [W]
20. Anatomie
Was gehört zu einem Browsergame?
Thursday, 1. November 2012 [W]
21. Client Spielinhalte
Browser Waffen
JavaScript Applikation Gegner
Missionen
Server
Achievements
Game server Hub Server
Grafiken GFX
MoM
Datenbank Message oriented
Middleware Musik Sounds
Thursday, 1. November 2012 [W]
25. Opoge Pusher
Nette Idee, aber leider etwas umständlich...
Thursday, 1. November 2012 [W]
26. Opoge Pusher
Publish-Subscribe Dienst
Keine Permissions
Senden von Nachrichten und Steuern der Subscribe
ausschließlich über Kontrollkanal
https://bitbucket.org/bikeshedder/opoge-pusher/
Thursday, 1. November 2012 [W]
27. Deployment
Browser
Web Applikation Opoge Pusher
Thursday, 1. November 2012 [W]
28. Ablauf
Browser WebApp Pusher
Login session.create
Pusher Session
Login
session.push
Data
Thursday, 1. November 2012 [W]
29. Pro und Contra
Einfach zu verwenden
Kompatibel mit beliebigen Programmiersprachen
Sessions müssen doppelt verwaltet werden
Session-Pinning notwendig
Thursday, 1. November 2012 [W]
30. Mushroom
Realtime web messaging
Thursday, 1. November 2012 [W]
31. Designziele
Kein vollwertiger Dienst
sondern ein Framework
Eingebautes RPC
Unterstützung von
Message Queues
Thursday, 1. November 2012 [W]
32. Architektur
Server
Call Long polling WebSocket SSE*
Client
*Server-sent events
Thursday, 1. November 2012 [W]
33. Mushroom Server (1/2)
class GameServer(object):
def __init__(self, listener):
self.server = mushroom.Server(listener,
mushroom.MethodDispatcher(self, ‘rpc_’))
self.mom = mushroom.messaging.Client(
settings.BROKER_URL,
exchange, queue,
mushroom.MethodDispatcher(self, ‘mom_’))
Thursday, 1. November 2012 [W]
34. Mushroom Server (2/2)
class ChatServer(object):
(...)
def mom_message(self, request):
self.server.sessions.notify(‘message’, request.data)
def rpc_message(self, request):
self.mom.notify(‘message’, request.data)
Thursday, 1. November 2012 [W]
35. Mushroom Client
var client = new mushroom.Client({
url: SERVER_URL
});
client.method.method(function(request) {
console.log(request.data);
});
function sendMessage(text) {
client.notify(‘message’, { text: text })
}
Thursday, 1. November 2012 [W]
36. Download
https://bitbucket.org/terreon/mushroom/
Thursday, 1. November 2012 [W]
37. Sync-Models
Synchronisierte Objektgraphen
Thursday, 1. November 2012 [W]
38. Grundidee Server
Objektgraphen synchronisieren
Änderungen vom von Server zum
Client pushen (z.B. via Mushroom) Push!!!11one
Jedes Objekt erhält eine
eindeutige Objekt ID
Sobald ein Objekt Teil des Graphs
wird werden Änderungen
automatisch übertragen. Client
Thursday, 1. November 2012 [W]
39. Zutaten
Django (optional)
“Simple JavaScript Inheritance” by John Resig
KnockoutJS
Thursday, 1. November 2012 [W]
40. Beispiel Graph
Server Client
Root Root
[0] [0]
Thursday, 1. November 2012 [W]
41. Beispiel Graph
Server Client
Root Root
[0] [0]
X
Thursday, 1. November 2012 [W]
42. Beispiel Graph
Server Client
Root Root
[0] [0]
X
[1]
Thursday, 1. November 2012 [W]
43. Beispiel Graph
Server Client
Root Root
[0] [0]
X push X
[1] [1]
Thursday, 1. November 2012 [W]
44. Server
from kodex.sync import models
class BulletinBoard(models.RootModel):
messages = models.ReferenceListField()
class Message(models.Model):
user = models.ReferenceField()
text = models.StringField()
Thursday, 1. November 2012 [W]
45. Server
from kodex.sync import server
class Server(server.SyncServer):
def __init__(self):
self.root = BulletinBoard()
def post(message):
self.root.messages.append(message)
Thursday, 1. November 2012 [W]
46. Client
bb.Client = kodex.sync.Client.extend({
post: function(text) {
this.request(‘post’, { text: text })
}
})
var client = new bb.Client();
$(‘#bb’).koApplyBindings(client);
Thursday, 1. November 2012 [W]
51. Kapitel 3 – Hosting
Wie hoste ich ein System dieser Art?
Thursday, 1. November 2012 [W]
52. Google Appengine
Asynchrone Kommunikation mit dem Client nur über
die Channel API möglich.
Stateful Services umständlich
Verhältnismäßig teuer
Wartungsfrei
Lokale Entwicklung eingeschränkt
Thursday, 1. November 2012 [W]
53. Heroku
Beliebt unter Entwicklern
Serverstandort nur in USA
Push-Dienst muss zusätzlich gebucht werden (z.B.
Pusher oder PubNub)
Lokale Entwicklung eingeschränkt
Thursday, 1. November 2012 [W]
54. Eigene Server
virtuell oder physikalisch
Server müssen gewartet werden
Maximale Flexibilität
Software läuft sowohl lokal als auch remote
Kein Vendor Lock-in
Thursday, 1. November 2012 [W]
55. Kapitel 4 – Marketing
Publisher, Social Marketing, P2P Propaganda
Thursday, 1. November 2012 [W]
56. Publisher
}
7 Games
BigPoint
Gameforge Keine Resonanz
Frogster
...
Thursday, 1. November 2012 [W]
58. P2P Propaganda
Registrierung für Closed-Beta
http://kodexgame.com/beta/
Thursday, 1. November 2012 [W]
59. Kapitel 5 – Geld verdienen
Bezahlmodelle und -systeme
Thursday, 1. November 2012 [W]
60. Zahlungsmodelle
Abo, Free to play, Premium Items,...
Thursday, 1. November 2012 [W]
61. Abo (Subscription)
World of Warcraft hatte zeitweise bis zu 12 Millionen
Abonnenten.
Neue “Stammspiele” lassen sich schwer etablieren.
Für kleinere Indie- oder Casualgames kein brauchbares
Zahlungsmodell.
Thursday, 1. November 2012 [W]
62. Free to play
Große Teile des Spiels sind spielbar aber bestimmte
Inhalte und/oder die Spielzeit sind eingeschränkt.
Premium Items können gegen Geld gekauft werden.
Die Anzahl der Spielzüge ist begrenzt und kann durch
Einsatz von Geld wieder aufgefüllt werden.
Thursday, 1. November 2012 [W]
63. Pay what you want
Spieler bestimmen selbst was Sie für das Spiel
bezahlen wollen.
Thursday, 1. November 2012 [W]
64. Werbefinanziert
Kann große Teile der Spielatmosphäre zerstören
Spieler können gegen ein Entgelt die Werbung
entfernen lassen.
Thursday, 1. November 2012 [W]
65. Sponsored
... schön wär’s.
Thursday, 1. November 2012 [W]
66. Zahlungsmodell – Fazit
Free to play ist Pflicht.
Spielbalance sollte nicht darunter leiden.
Unkritisch:
Spielzeit einschränken
Spielinhalte verkaufen
optische Individualisierung
Thursday, 1. November 2012 [W]
67. Bezahlsysteme
PayPal, Amazon FPS, Google Checkout,
Paymill, VirtualPiggy, Premium SMS,...
Thursday, 1. November 2012 [W]
70. Bezahlsysteme (3/4)
VirtualPiggy
Payment Lösung für Kinder und Jugendliche
http://virtualpiggy.com/
Pay by Call
T-Pay wurde 2010 eingestellt
DaoPay: Gebühren nicht öffentlich
paysafecard: 15% - 17%
Thursday, 1. November 2012 [W]
76. Jugendschutz
Nur Spiele, die auf einem Speichermedium vertrieben
werden müssen von der USK geprüft werden.
Browsergames können optional geprüft werden.
Einmalige Prüfung: 300 EUR
Jahresmitgliedschaft: 3.000 EUR + Prüfgremium + X
Jugendschutzlabel empfehlenswert:
/age-de.xml im Root-Verzeichnis der Domain ablegen
Thursday, 1. November 2012 [W]
77. Lektion 3: Kein IE
Internet Explorer? Nein Danke!
Thursday, 1. November 2012 [W]
78. Kein Internet Explorer
Verwendung von Chrome Frames:
https://developers.google.com/chrome/chrome-frame/
Akzeptanz für Spiele mit Browser-Plugins ist merklich
gestiegen. Chrome Frame ist in wenigen Minuten
installiert und sofort einsatzbereit.
Anwender mit Internet Explorer und ohne Chrome
Frame werden ignoriert.
Thursday, 1. November 2012 [W]
79. Lektion 4: NIH
Not invented here
Thursday, 1. November 2012 [W]
80. Not invented here
Opoge Pusher
Dependency Injection
JavaScript Bundler
...
Thursday, 1. November 2012 [W]
81. Kapitel 7 – KODEX
Join the intergalactic scavenger hunt.
Thursday, 1. November 2012 [W]