FlyingDutchman

There's much much more wrong in that piece of code than just a plain pointer issue.

 

Besides the allocations you do every frame, there are also a lot more copy-constructor calls than you might expect.

Get rid of that; it may be just a Vec2 class but clean code doesnt hurt anyone.  use const references, or just pass the position as 2 parameters.

 

Next point is ... why do you want to use a pointer anyway? Sprite classes usually store their position for collision detection or rendering or whatever.

And you do realize that pointers take up memory as well, right?  Depending on the OS, the size is different. On Windows it's 4 byte if i remember correctly.

So basically you win nothing using your method.

 

best regards

 

true. And talking about efficiency. Malloc/new are quite expensive in terms of computation cost (if you compare it to just decreasing the stack pointer) and also lead to heap fragmentation. 

I co-sign nearly everything Xaan said. Even tho i'd go for Ruby with EventMachine instead of Node. But thats just personal taste. Both scale well and are easy to learn/use.

just use a sha512 with salt and push your regular stream through it. the results you write on disk. the salt should be hardcoded somewhere.

when somehow then wants to "crack" your program, he would need to get the salt out of the binary.

On UNIX, you can use fork() to spin off a "fixed" copy of whatever is in memory right now.

However, it sounds like you don't have the right data structures. The "modifiable" state of a world is unlikely to be 160 MB. Most games define "world data" as immutable state that doesn't need to get saved, plus mutable state for what the players can change. In addition, most MMO games will save all mutable state by each player, rather than in the world, which is why players can't affect the world like dig tunnels or cut trees etc. For games that allow the world to be mutated (Eve Online?) those games will still keep the amount of modifiable world state small, and sliced into sections (by system, by zone, etc.)

With this approach, the amount of data you need to save at any one time should be small, and can be done by collecting what you need into a memory buffer and doing an asynchronous write on that memory.

The main danger when saving players is one of item duplication and similar race conditions. For example, let's say my character is saved, then I trade a Flaming Sword of Fire to you, and then you are saved, and then the server crashes before it can save me again -- now there's an item duplication. Thus, things that matter for the economy (like trades) are typically implemented on a transaction-based database.

Thats what Ultima Online actually day. Once an hour nobody could cross server boundaries, they forked all servers, wrote the whole RAM on disk and releases the boundaries. I had to laugh when i read it because i remember too good the in game messages but didnt know back then what they were actually doing. :-)

IMO, you're going to cause more pain than needed for using multiple threads for each client's connection, and for little (if any) benefit.

You could create 1 thread to handle all client connections, and just check all the clients sockets with select, or, you could treat the client connections portion as you would any other part of a typical game loop update:

  int clientsReady = select([b]NumClients[/b], &ClientFDs, NULL, NULL, &timeout);
  if (clientsReady > 0) {
	// process the clients
  }
  else if (clientsRead == -1) {
	// handle error
  }

numClients is a bit wrong here. The first argument shall not be the number of fds in your fdset but the number of the highest fd to check + 1.

http://linux.die.net/man/2/select
nfds is the highest-numbered file descriptor in any of the three sets, plus 1.

Its also worth mentioning that ClientFDs and timeout should be reinitialized after select.

To answer the question:

Go for async IO and use select/kqueue/poll or whatever else you like. select is pretty easy to use , even tho a bit confusing at first. especially if you want to to asyncronous write operations as well or add fds from files to your select queue to do asynchronous file access to the OS. But i know from back in the days that UOX2 (a very famous Ultima Online freeshard) was coded with select and ran great. Later one they added threads etc to leverage level loading and other stuff but in the beginning everything was one thread and async IO. I think thats anyway the way to go for online rpgs. You should just take care not to do put too much stuff in each cycle of the main loop. But thats where sharding comes into the picture. For example, Ultima Online (the real one), had multiple servers per world.