My design philosophy was to make a game that works with very few ajax requests. I'm not spamming the server, the game is designed in a way that walking around requires just one request every few seconds. The movement is actually pretty simple, you click where you want to move, path-finding algorithm on the client side will find the closes path to that point (if there is one), another click will confirm that and send the path to the server to execute the move (and check if the game client is not cheating, never trust the client!), and then the character warps to that point. Now, to make the distance between point A and B actually meaningful, there is a cooldown during which you can't move again, and the length of that cooldown depends on the amount of squares you moved.

So, while this is not really an action game or anything, the game world does what it's supposed to do:

- allows exploration
- makes distance important
- lets you actually see other people and interact with them

I'll obviously eventually launch the game on a dedicated server, I'm looking up for ability to use RAM-drive to store session files which I'm using to cache SQL data in, but for closed and even open beta an ordinary virtual hosting should be enough,  as I've worked hard to make sure it's not a server killer . Basically anything that can handle phpBB forums or such with many users, should be able to handle Vanthia.

Why not just make dedicated app that functions as an http server,then when specific pages are requested just disregard everything except posted json data? It'd be so much faster and really not that difficult to make.

Qard wrote:

Why not just make dedicated app that functions as an http server,then when specific pages are requested just disregard everything except posted json data? It'd be so much faster and really not that difficult to make.

I'm doing this in my case with a custom built Rack app.

Use lots of AJAX for functions and most importantly, have the server verify EVERYTHING.

The whole code encryption thing... yeh that's what sucks about javascript, but since it's a client side language it is how it is.

Learn Java

fiote wrote:

Hm? wanna put a simple image from your website in it? YEAH come on 2dgraphics url.toimage new image draw all over again HEEEEELP.

ROFL

Anyway regarding your JavaScript problem, search for an obfuscator. This is a tool that scrambles your code as much as possible - generally starting with renaming your variables to a,b,c... and functions to similarly unhelpful names. Also often uses tricks such as a string lookup table to make things even more confusing, and so on.

Any program can be disassembled (or in Java's case, decompiled). JavaScript is just a scripting language, so it's extra easy.

You can also send JavaScript through AJAX calls... I mean, depending on how much work you want to do (apparently not much from your quote), you could make it like a puzzle where some of the pieces are on the server and some are on the client, and load and assemble it at runtime, or even just as-needed as the game plays.

And yes, server verification is a no-brainer. Client side can never be trusted.

PiNK UNiCORN wrote:

How about the back-end? What tools have you used?

Can you explain yourself a bit clearer? What kind of "tools" do you mean, for what?

Its python (not from scratch, but using CherryPy) and MySQL serverside.

You always need a serverside language. To give clients full access to the database in a multiplayer game would be terribly stupid.

Of course, if it were a single-player game, the opposite is true: it would be best to keep the whole database client-side and not have any server side interaction as it would be unnecessary.

nea wrote:

PiNK UNiCORN wrote:

I would love to see how would plain javascript with couchDB work without any serverside language..

Cheating could be a problem..

You know you can use javascript on the server side?

Isn't that called php?

Nea, sure you can use is, there is plenty of frameworks, Floppy mentioned one of the most popular, node.js.

my point was made as lightweight solution as it can be, all processing on client side(I know it is a bad idea) and only server storage, hmh, data exchange between clients would be also somewhat problematic, because it should also go via database, not nice. Thou it could use some memorydb so no i/o for harddrives. Or some partition of couchdb tables could be only in memory.
well this is just a speculation
In real life you should have some serverside validation used.