Hello all for my first post after a long time lurking,
I am currently writing up a small game “engine”, as a hobby really.
Nothing that will make me rich or anything. Consider it a way to mix
personal passion with a positive impact on my professional life.
Personal research :D
So this “engine” is being written for browser-based gaming:
have probably guessed).
* server-side: stackless python, the stackless implementation of
sockets, and a bit of memcache(d). The engine is action-driven, i.e.,
actions between entities define the way the game can behave. I’ve tried
to make the thing flexible and easy to update/change by having those
dynamically loaded upon server startup.
Client and server are talking over websockets, using an obfuscated
protocol. The defined language is still very .. err … primitive right
now, but grammar is being worked on.
What I am looking for is ideas, suggestions on how to implement the
* server-side only protocol: given the nature of stackless python,
ingame “objects” talk to each other by sending stuff over channels. This
happens “in-process” only.
* client-server protocol: this is what gets sent over the wire.
Now, I _would like_ the two protocols to be similar in nature, i.e.,
to share the same syntax/grammar. For ease of maintenance, enhancements,
and the overall maintainability and beauty of the whole.
Would that be a good idea? Efficient or horribly not so? For which
Many thanks for your input!
Please log in or register to post a reply.
This is a huge and domain specific problem. I can’t give you any direct
solutions, but I can recommend you look-up using JSON as a potential
data transmission format and avoid deliberately “obfuscating” your
protocol. Throughout development, use a readable protocol to make
tracing and debug issues easier. You can write code or tools to optimize
and minimize transmission data for your release builds.
What are you doing to secure the client, and communications between the
client and server?
And, as for TheNut’s suggestion, JSON is still verbose, but less so than
the atrocious idea of XML. Also, one thing people don’t see at first is
the tree-based structure of JSON and XML. This can be a problem at times
if your data is highly inter-related. The good thing is the wealth of
tools and libraries for it. I’d consider YAML
along with JSON.
Or, look at something more efficient, like
Hello and thanks for your answers.
To secure the client:
. php login, nothing fancy, with PDOs and sanitization.
. php writes to memcache, that info has a temporary lifetime there.
. now the issue was to bridge the PHP world with the python world. So
upon Websocket fire-up, the client sends information, whose validity is
checked by the python server, via accessing the stuff in memcache. If
ok, allow client to request for more things (world loading, engine init,
etc.) over that websocket.
Dunno if it’s perfect. It’s not my speciality. Then again if it was, I
wouldn’t be around here asking advice/ideas. :)
About the protocol: it is fully hexadecimal (+ascii control characters).
I’m using this as it lends itself nicely to:
. One-time passwords
. XORing, on a client basis, anything that gets sent on the wire. That
_may_ also have a lifetime shorter than socket life (a few client-sent
commands, maybe). But then is raised the option of history logging
server-side versus freshness of the client elements that it uses to
“asks” things from the server (hope that makes sense).
I _believe_ (or would like to believe, heh :)) that this wil make the
protocol reasonably secure.
I wanted to do something else than:
. XML: heavy, verbose. Big no-no since the very start indeed.
. JSON: more light-weight, faster to parse via .parse() - but I’ve seen
too much of it after 11+ years of working in the web industry. :)
If the hex seems like a good direction, I will actually revert to a
“clear” protocol, one that will indeed be easier to read (and debug ;)
). And then go back the hex way to makes things lighter.
The one thing I like a lot about hex is its weight. 60-80 bytes for a
full message sounds very nice to me.