You need to "notionally" do network access to get these data for images. But the images might come from the browser's cache if they're already available. You can encourage or enforce caching through a combination of web server headers and a cache-manifest file. Or you can just preload your images when your game starts so they're already available.
Once you have an Image object in memory, and you're holding a reference to it, it's not going to go away and you can use it without a problem. But when a player comes back to play the game again (in the same browser session or a different one), the assets need to come either from the server or the browser cache.
Image elements don't work on that level. You can't ask the Image object for its binary data. You can in principle extract the pixel data from an image, which might be an idea for loading maps or other assets.
If you want to do file IO for arbitrary (non-image) files, use XMLHttpRequest.
You need to think about macro rather than micro. Use the simplest scheme that you think might work.
The key is to avoid anything which is greater than O(N) on a regular basis (e.g. each frame). Even the N^2 "every object against every other object" is not really so bad provided the number of objects doesn't get too big.
It's really possible to iterate a lot of vectors - really, lots - each frame, without problems.
In the past I've used all these approaches. I'd recommend that you don't spend time building your own editor, if possible.
* Use a text-editor to edit a text-file, and have the game load it as a tilemap of some kind
* Use an existing tilemap editor (designed for games)
* Use a graphics bitmap editor (e.g. Gimp) and edit a bitmap; load it as a tilemap, background, collision map or something like that.
* Use an existing vector-editor (Inkscape, Flash) and convert or load the files in your game
In some cases it might be helpful to convert data into a different format for use at runtime.
Object placement and definition of logic e.g. "this button opens that door" can be tricky to do with standardised tools, you might need to knock up an object-placement editor, which could easily be inside the game itself (you run the game in a special mode, perhaps use a command-line option)
You have several typoes or spelling mistakes in code or comments, these are confusing or annoying to a maintainer but not really a problem (most notably SCREEN_WITDH)
There are a lot of global variables, some of which are not very descriptive or helpful, e.g. event / gameEvent. You might reduce the global variables by combining some of them into structs and/or putting them into arrays or some other container. It's also possible that some of them don't need to be global at all, and can be passed as parameters instead and/or held in a local somewhere.
Your variable and function names are not very descriptive and a maintenance programmer will need to refer to their declaration comments a lot. "state" might be better as "board_state", then we know what it's the state of. (conceptually, every variable is a state of something). Some function names don't start with a verb, for example "position" or "score".
"using namespace std" - I could possibly get into a Holy War over this, but I prefer not to use this nowadays.
Function position() ... this function needs the most work.
1. It is trying to do at least two things at once - determine the mouse click target and draw things on the screen. Logically, I'd try to separate these two operations
2. It does many rectangle-tests for the mouse-position, it looks like these could easily be refactored into an array or something else.
3. There is a great deal of repeated code
I suggest you might refactor position() into several stages, possibly different functions:
a. Determine whether the mouse-button has been clicked on a square, and which one
b. Check whether the square is a legal move (i.e. not already taken)
c. Draw the mark in the box
Obviously I can't see what's in your background image, but I suspect that the board has a regular grid, so you might be able to use a bit of arithmetic to work out the boxes' coordinates programmatically and not have to hard-code the locations of 9 squares.
However, if your tic-tac-toe grid is highly irregular, you could make an array of structs to store their coords thus:
The tinkerer problem cannot be solved technically, it's something which has to be done culturally within the team.
Not only is "tinkering" highly annoying for other developers who have to tolerate merge conflicts, it's actively a problem because tinkering creates bugs.
Only when you have a culture of "if it ain't broke, don't fix it", can the tinkering be prevented.
I prefer the matra "Even if it is broke, still don't fix it until we have a bug report which has been triaged and scheduled into the release you're actually working on". Occasionally people fix bugs by accident though
In general, some level of collaboration is necessary to avoid doing the same thing.
If several people are working on the same file, normally they'll be doing unrelated things.
Whoever commits first, "wins" and the other person has to do a merge. Doing the merge is not normally particuarly difficult, but it can easily go wrong.
One of the biggest problems is if you have another developer who is a "tinkerer" and randomly changes stuff (e.g: comments, whitespace, random refactoring) not related to his tasks. This creates unnecessary merge work and gives other developers pain.
If you have such a developer on your project, and you are unable to convince him so stop such behaviour, your project manager should be involved.
I think you are really trying to "put the cart before the horse". If you're *really* making a MMO, then the funding you have for content-creation should mean that you can afford to hire some experts for the network parts.
On the other hand, if you're making a smaller online multiplayer game (which is fine, too!) then you really don't need to worry about "the C10k problem". Pretty much any approach will definitely work.
Personally I can't really see a situation where any amateur-developed game is likely to hit the limitations of networking, unless you've made some incredibly bad decisions on the protocol design - which is something you should really think about early on.
There are a lot of hard things about network game programming, and the things you've mentioned are not part of them.
PySDL2 and Pyglet are good and gaining traction, but I would really recommend pygame if you are starting out.
None of those are game engines. That's not to say they're bad libraries though.
Personally I suspect that you don't really need a "game engine", especially for simple 2d games. If you find a suitable engine, great. If you don't, it's not a disaster either, your game might work just as well with a custom-written one especially if it's simple.
The way gravity normally works in game (and incidentally, real life), is that it is *always* pulling objects down.
If they happen to be on a solid platform, the platform is continuously pushing the object back up, so it can't fall.
Assuming you use Euler Integration (if you don't know, you probably are.), you're storing a velocity vector of the object, then if you get a collision with a solid thing like the ground, you'll want to modify the velocity to remove the component which is going into the ground (in practice, this is something like: if (velocity.y < 0) velocity.y = 0; )
Keep it simple, if the checks aren't too many for 100 objects, it's fine. Obviously this depends on hardware speed and the difficulty of the check.
Normally you don't actually want to test 100 objects against all others, some collisions are "deliberately ignored", for example, you might group them into "player objects", "enemy objects", "player missiles" and "enemy missiles". It's likely that only some combinations of these groups need to be tested, so you can dramatically cut down the checking by only checking "interesting" types against each other.
If most of the objects aren't doing anything interesting (e.g. they're outside the screen AND not moving) then you could also ignore them somehow.
There are a variety of optimisations which are not as "cool" as world-partitioning or something else clever (e.g. some kind of spatial index), which are much easier to implement and work nearly as well for relatively small numbers of objects. Keep it simple.