Starting game development in javascript. Where to draw the line between JS and Server Language

Im fairly proficient in php and am al开发者_运维知识库so learning python. I have been wanting to create a basic game for some time now and would like to create it in python. But in order to have a fancy smooth interface I need to use javascript (i dont much care for the flash/silverlight route). So I decided to start looking up game development in JavaScript. And in doing so most of the examples I have seen are games nearly completely done in javascript. And many of these games are quite nice.

But what im wondering, is if i combine python and javascript together for creating games; should I rely more heavily on javascript and let python do some of the background stuff? Or should I only use javascript for the basic UI elements, animation, flashy stuff and whatnot and keep the core game engine in python. Or some kind of mix between the two.

For php/python im mostly used to MVC style frameworks. So if i used JS only for the visuals would I just make heavy use of the in the view files as I would with a normal application? I know I can make a game in either language completely, but to use the best of both worlds im not quite sure where I should draw the line on letting python do work and letting JS do the work.

Also as a reference I would like to use some advanced features like canvas/svg and so on. Not really so much WebGL. And the game I have in mind to practice on is an isometric style RTS. The game will mostly be for learning. Im not really planning on releasing it.

Any input is appreciated.

Clarification: the game will be web based. My web server is nginx. The games i would like to to would be multiplayer games where multiple people are playing online at the same time. Think world of warcraft. each server could hold up to N players that play against eachother. When that one is say 80% full a new one is spun up. Or something along those lines. I would like for the players to actually be able to interact with eachother live. Which is why in same ways i was also kind of looking into node.js but dont know as much about it yet. but seemed like it could fit.

-- Update: Im also planning on using mongodb as the database, if that matters to anyones answer.

to a certain extent, the problem can be considered in terms of economic forces, where you maximize your own utility and minimize costs. In the case of a game with a client/server aspect, The actual forces acting on you are

• consuming server resources costs you actual money, but consuming client resources doesn't
• clients could try to cheat, so you have to validate some of the data coming from a client
• if you consume too much client resources, clients won't want to play, since their utility is outweighed by their costs.

Each of these points can be subtle enough to merit some additional discussion.

The actual cost of getting your game to clients comes in two parts, the cost of the physical hardware necessary to run the game, and the cost of the network bandwidth to distribute it to clients. Often you might have to trade one for the other; optimizing network usage means you have to be better at anticipating what clients will need or do, increasing processing demands, but offloading more of processing the work to the client means sending more data to the client.

There's only so much work the client can do, though. For instance You can't always trust the client to tell you where they aught to be, because that might mean that they are flying around in the air, or teleporting from place to place; You have to actually make sure that clients actually can do the things that they say they're doing. The particular nature of the game can determine how far you have to go, though. In man MMO games, extreme measures are often taken to limit the activity of bot players, but that often has a negative affect on real players. Strictly cooperative games often suffer less even when abusers are at work.

Not all potential users of your game have the best available hardware, or are willing to upgrade to the latest, fastest browser, So to make a successful game often means toning down the graphics enough so that a majority of users can play it.

Surprisingly, it's often the case that an either client or server approach doesn't actually produce the ideal results. Instead you have to implement key game logic in both places, On the client so that the game feels responsive to the user, but also on the server to mitigate abuse and decide player to player interactions fairly.

python would probably run on the server powering your web server.

If you want to write multiplayer client-server games then a lot of server code/logic would be in python.

If you want to write simpler singleplayer games then all your code is in the client (browser) and would be javascript. Python would just be there for serving your web game.

If you want to write desktop games you can do that in python using the pygame library.

So depends on what you want.

• Multiplayer web game : client in JS, server in pythong
• Singleplayer web game : client in JS, server only for serving web files
• Desktop game : client in python.