PYCON DE 2012 - Echtzeit browsergames

Echtzeit BrowsergamesMichael P. Jung <[email protected]>

Thursday, 1. November 2012 [W]

Kapitel 0 – Michael P. Jungwhoami


Michael P. JungSoftware Engineer und Designer

SoftwareentwicklerC, C++, Python, Java (uvm.)

Linux Benutzerseit 1994

Python Entwicklerseit Python 2.3, ~2003

Django Entwicklerseit magic-removal branch, ~2006

Brettspielefan

[email protected]


file://localhost/Users/mp/Downloads/terreon-logo.svg























































































































































































































































































Gegründet: 2000

Echtzeit Client-Server-Anwendungen

E-Commerce

App-Developers (HTML5)

Game Developers

http://terreon.de/Software und Design


http://pyrox.eu

http://pyrox.eu

Gegründet: 2008

Python Shared Hosting

Individuelle Hostinglösungen

“The next big thing” (ETA 2013)

http://pyrox.eu/@pyrox_euHosting Experts


http://pyrox.eu

http://pyrox.eu

Kapitel 1 – KonzeptVon der Idee zum Spiel


Foto von doom.wikia.comFotograf: Janzidreg


Kapitel 2 – Technikvon async bis zmq


AnatomieWas gehört zu einem Browsergame?


Datenbank

Browser

SoundsMusik

GFXGrafikenGame server Hub Server

MoMMessage oriented

Middleware

Missionen

SpielinhalteClient

Server

JavaScript Applikation Gegner

Waffen

Achievements


Technologie Stack (Server)

Python 2.7http://python.org/

Djangohttp://www.djangoproject.com/

Django Socialauthhttps://github.com/omab/django-social-auth

geventhttp://gevent.org/

PostgreSQLhttp://www.postgresql.org/

RabbitMQhttp://www.rabbitmq.com/

Mushroomhttps://bitbucket.org/terreon/mushroom

Sync Modelshttps://bitbucket.org/terreon/sync-models (noch nicht released)


Technologie Stack (Client)

JQueryhttp://jquery.com/

Knockouthttp://knockoutjs.com/

Sugarhttp://sugarjs.com/

Mushroomhttps://bitbucket.org/terreon/mushroom

Sync Modelshttps://bitbucket.org/terreon/sync-models (noch nicht released)

Compasshttp://compass-style.org/


Architektur

Browser

static.kodexgame.com

kodexgame.com

hub.kodexgame.com

gNNN.kodexgame.com

Database

MoM


Opoge PusherNette Idee, aber leider etwas umständlich...


Opoge Pusher

Publish-Subscribe Dienst

Keine Permissions

Senden von Nachrichten und Steuern der Subscribe ausschließlich über Kontrollkanal

https://bitbucket.org/bikeshedder/opoge-pusher/


Deployment

Web Applikation

Browser

Opoge Pusher


Ablauf

Browser WebApp Pusher

Login

Pusher Session

Login

Data

session.create

session.push


Pro und Contra

Einfach zu verwenden

Kompatibel mit beliebigen Programmiersprachen

Sessions müssen doppelt verwaltet werden

Session-Pinning notwendig


MushroomRealtime web messaging


Designziele

Kein vollwertiger Dienst sondern ein Framework

Eingebautes RPC

Unterstützung von Message Queues


Architektur

Server

Client

Long pollingCall WebSocket SSE*

*Server-sent eventsThursday, 1. November 2012 [W]

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_’))


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)


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 })}


Download

https://bitbucket.org/terreon/mushroom/


Sync-ModelsSynchronisierte Objektgraphen


Grundidee

Objektgraphen synchronisieren

Änderungen vom von Server zum Client pushen (z.B. via Mushroom)

Jedes Objekt erhält eine eindeutige Objekt ID

Sobald ein Objekt Teil des Graphs wird werden Änderungen automatisch übertragen.

Server

Client

Push!!!11one


Zutaten

Django (optional)

“Simple JavaScript Inheritance” by John Resig

KnockoutJS


Beispiel Graph

Root [0]

Root [0]

Server Client


Beispiel Graph

Root [0]

Root [0]

Server Client

X


Beispiel Graph

Root [0]

Root [0]

Server Client

X[1]


Beispiel Graph

Root [0]

Root [0]

Server Client

X[1]

X[1]

push


Server

from kodex.sync import models

class BulletinBoard(models.RootModel): messages = models.ReferenceListField()

class Message(models.Model): user = models.ReferenceField() text = models.StringField()


Server

from kodex.sync import server

class Server(server.SyncServer):

def __init__(self): self.root = BulletinBoard()

def post(message): self.root.messages.append(message)


Client

bb.Client = kodex.sync.Client.extend({ post: function(text) { this.request(‘post’, { text: text }) }})

var client = new bb.Client();$(‘#bb’).koApplyBindings(client);


Client<div id=”bb”> <ul class=”messages” data-bind=” foreach: root().messages”> <li> <span class=”user” data-bind=” text: user”></span>: <span class=”text” data-bind=” text: user”></span> </li> </ul></div>


Protokoll(Snapshot)

{ “0”: { “class”: “bb.BulletinBoard”, “messages*”: [1] }, “1”: { “class”: “bb.Message”, “user*”: 2, “text”: “Was rockt?” }, “2”: { “class”: “auth.User”, “username”: “bikeshedder” }}


Protokoll(Update)

{ “0”: { “messages*”: [2, 4] }, “4”: { “class”: “bb.Message”, “user*”: 5, “text”: “PYCON DE 2012” }, “5”: { “class”: “auth.User”, “username”: “solid” }}


Protokoll(Delete)

{ “0”: { “messages*”: [4] }, “1”: null, “2”: null}


Kapitel 3 – HostingWie hoste ich ein System dieser Art?


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


Heroku

Beliebt unter Entwicklern

Serverstandort nur in USA

Push-Dienst muss zusätzlich gebucht werden (z.B. Pusher oder PubNub)

Lokale Entwicklung eingeschränkt


Eigene Servervirtuell oder physikalisch

Server müssen gewartet werden

Maximale Flexibilität

Software läuft sowohl lokal als auch remote

Kein Vendor Lock-in


Kapitel 4 – MarketingPublisher, Social Marketing, P2P Propaganda


Publisher

7 Games

BigPoint

Gameforge

Frogster

...

Keine Resonanz}Thursday, 1. November 2012 [W]

Social-Networks

Facebookhttp://kodexgame.com/facebook/

Google+http://kodexgame.com/google+/

Twitterhttp://kodexgame.com/twitter/


P2P Propaganda

Registrierung für Closed-Betahttp://kodexgame.com/beta/


Kapitel 5 – Geld verdienenBezahlmodelle und -systeme


ZahlungsmodelleAbo, Free to play, Premium Items,...


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.


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.


Pay what you want

Spieler bestimmen selbst was Sie für das Spiel bezahlen wollen.


Werbefinanziert

Kann große Teile der Spielatmosphäre zerstören

Spieler können gegen ein Entgelt die Werbung entfernen lassen.


PYCON DE 2012 - Echtzeit browsergames

Technology

Transcript of PYCON DE 2012 - Echtzeit browsergames

Pycon APAC 2016 후기

Echtzeit Pressemitteilung · Echtzeit Pressemitteilung Echtzeit Verlag , — 18. September 2015 Violino di capra, Schabziger und Pan jauer: «Das kulinarische Erbe der Schweiz»,

Echtzeit und Nicht-Echtzeit Integration von MATLAB … · Echtzeit und Nicht-Echtzeit Integration von MATLAB und Simulink in das neue Robotik Software Framework aRDx des DLR ... C/C++

Echtzeit-Risikomanagement - SAS · EchtzEit-RisikomanagEmEnt Entscheidungen in Echtzeit statt Batch-Verarbeitung über Nacht: wie High-Performance-Technologien das Risikomanagement

Ashutosh pycon

Pycon Brasil

PyCon 2012 紀行

PyCon JP 2015 keynote

Introducción a PyQt - PyCon

PyCon Korea 2015

PyCon Slovakia 2016

Marketing Innovation Day – Markenerlebnisse in Echtzeit · 54 Marketing Verband 6 2016 DMV Szene Marketing Innovation Day – Markenerlebnisse in Echtzeit „Marketing in Echtzeit

LFS PyCon DE 2011

Mod Wsgi Pycon Sydney 2010

PyCon JP 2012 Sprints

PyCon JP 2012 Closing

한국 PyCon 2014 - 개회사

Echtzeit Klub

2015 PyCon - 프로그래머가 이사하는 법

PyCon KR 2017 orientation