Im fairly proficient in php and am also 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
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.