hplus0603

The packets are already received by the computer and buffered in the kernel. All that your "receive" function does is copy the received data out of the kernel to your application. If you write the code correctly, you should be able to receive hundreds of thousands of packets a second from a single thread (be it main thread or other thread.)

In my simplified layer both A & B start their sequence at 0.

By doing that, you run a greater risk that replays may confuse the protocol state, and the risk that an attacker may be able to inject his/her own packets because the state is "known." That may or may not actually matter for your case, but it did matter for the TCP designers back in a day where packets would be duplicated and a copy delivered 10 seconds late.

Yes, queuing is the right solution for de-jittering.

Another problem you may end up seeing is that the player sends "position X, direction Y" at time T, and then turns around at time T+1, and the packet that sends the next direction won't go out until time T+3, meaning there will be a "snap" on the receiving end if it does forward extrapolation.

The smoothest option is to wait until you have data for all your time before you display the entity. I e, if you send data for times (T-2, T-1, T) at time T, and it's received on the other end at time T+2, then the other end would display the location at time T-2 at time T+3, aiming to display the location at time T a timt T+5, so the next packet arrives in time to display T+1 at T+6.

If you don't want to always display "known" data (which introduces this latency) then you have to extrapolate, and you will get jitter. The Entity Position Interpolation Code (EPIC) library is one way of smoothing out the extrapolation, but it will never be perfect, because you are, at the core, guessing, and you will guess wrong at times.

I think your friend is slightly off the mark. Flash is here, and works, right now. It's not going away anytime soon.
Once it goes away, it will probably be subsumed by HTML5/JavaScript/Canvas/WebGL/Video-tag/SVG, rather than Unity.
Unity is a fine game making editor/environment, although it is much more aimed at 3D than 2D. It also doesn't have good integration with remote web services (the WebClient implementation isn't very good) like you would want for a turn-based game like a CCG.

So, my recommendation would be:
- If possible, write your game in HTML5 and JavaScript! This will make it run on all web browsers (including Apple phones and tablets)
- Else, keep going with Flash. It's a fine platform for 2D games right now.

There's the whole back-end part. You need to figure out both a language, and a server environment, that lets you serve the game, enforce rules, and keep track of player state; ideally without letting the client be open to cheating. If you already know JavaScript, Node.js might be a good choice (assuming you can host it somewhere.) If you want to use low-cost shared web hosting, PHP is the best supported environment for that, and would also work.

The reason you're asking this in context of "MMO" is that player characters are generally customizable, and there might be many of them on the screen?

The triangle count is ALMOST not important anymore. The number of materials (draw batches) is much more important -- make it a low number (1 material would be ideal; with heavy customization, getting to that point might require some fancy on-the-fly texture coordinate re-mapping and texture atlasing etc. You do want LODs, for characters in the distance, and also so you can "scale down" for Intel integrated graphics users by drawing everything at the coarser LOD.

Number of bones is also important -- you don't want your character to have so many bones that calculating the animation pose takes too much CPU, nor too many bones to fit in a single shader pass. Depending on how your shader works, this may limit the number of bones to 27, or up to 120 or so. If you target only higher-end cards, you may get away with render-to-vertexbuffer methods that remove those limitations.

Amount of texture space used is actually more of a problem for most games. As is the ability to draw objects in level-of-detail. If I were designing this, I'd probably give instructions something like:

- The entire character, with weapons, armor, hair, accountrements, etc, should render using a single 2048x2048 DXT5 texture. Weapons, armor, upper body, lower body, hair, etc, should all map to specific well-defined areas of that texture, that can be swapped out by the CPU at character-load-time.
- There should be two LODs; one at no more than 12,000 triangles for a full set of weapon/armor/character, and one at no more than 2,000 triangles. The more detailed LOD should use no more than 60 bones; the less detailed LOD should use no more than 25 LODs.
- Define skeletons: will you re-use animations by re-targeting, or will there be a matrix of separate animations for attack-with-spear-as-ogre; attack-with-sword-as-ogre; attack-with-spear-as-elf; ...

If you want to feature character customization, and have not yet implemented how that will work technically, you are not yet ready to outsource any art. You have to work with a technical artist to define the art path for this, first, because it's a highly complex and resource-intensive part of an MMO (that, and building the large world, are the two biggest challenges!)

Finally, I'm moving this to the Graphics forum -- it really doesn't have much to do with Networking & Multiplayer.

"Tell me about automated data capture and review tools you've used." (Note: if whatever you're using is less capable than open source like https://github.com/imvu-open/istatd then you're not doing enough!)

"You need to run this piece of software on 300 Windows machines. It requires a redist upgrade for a package that requires a user to accept an EULA when installing. What do you do?"

"We put covers on our TPS reports now. Did you get a copy of the memo?"

you can't have a game with money involved be hosted by one of the players

In fact, you can't even host it yourself. Many jurisdictions require that, if you do "gambling" for real money, you host your computers in dedicated data centers that regulators have access to.
I heard second-hand that those data centers are not always up to best practices in neither things like infrastructure nor access control (!) so you may have to compromise your technical requirements to fit in there.

In general, the wisdom is that if you go into the "real money" sector, there are significant regulatory hurdles, and significant costs, like a third-party company auditing all of your gambling related code. Neither the regulators nor the auditing companies have any understanding of your own particular schedule. If you think Apple App Store approval takes a long time, waiting four months for a review of a code change is taking it to a whole new level...

most MMOs are written in C++

I would agree that many are. However, it's not a rule that you have to. Eve Online was well known for its use of Python, for example, and it did OK. You might as well say that "most AAA games are written in C++" and then not count Minecraft or Naughty Dog Lisp or UnrealScript or whatever.

Quoting the linked-at MMO skepticism article:

Graphics are one of the largest things to note about an MMO.

Tell that to the creators of Realm of the Mad God! (Or, for that matter, Maple Story.)

The truth is that if you are *truly* unique, and your idea holds water when all you do is double down on the one thing you do uniquely, and everything else is scaled down to a level you can actually manage, then you have a shot. Most newbies actually fail in the estimation of what they can reasonably manage, rather than in any particular technical area.

And if you do this on server will be unfair for the slow connections.

If you have a game where the differences in connection speeds matter, then you basically have a car race situation. In a car race, the combination of the best driver and the fastest car will win. Someone with more money will inherently have a better chance to have a faster car and thus have a chance to compensate for any small imperfections in driving skill (not to mention break down less often.)
That's the way of the world.

The FAQ does mention this.

In general, for full-on action games, you need to rent a whole computer (or multiple computers) to provide low-latency simulation. You either rent "self-managed" hardware that someone else puts together, or you rent space and power in a co-location facility and put in your own machine and network connectivity.

For slightly less twitch-intensive games (like RPGs or whatever) you can usually get away with renting virtual computers from places like Amazon EC2 or Linode or Rackspace or whatever.

The web-style services (PHP, Rails, whatever) typically only work for very slow turn-based games, like fantasy sports or crime syndicate simulations or whatever.

If the server is publicly available, then any client that can send UDP packets out, will receive them back in, barring outright bugs in their network. If this wasn't true, then the DNS service wouldn't work.
The reason this works is that router/firewall/gateways implement NAT, where, once a packet goes out, a response to that packet will be routed back in. All the server has to do is to respond to the incoming packet using sendto() to the address that the packet had when you called recvfrom().

If you have fill rate concerns, beware that Retina units count as "newer" but actually have less effective fill rate because of the higher resolution.
One solution for that might be to render to a render target at a smaller resolution, and stretch-blit to the screen for present.

The first is it will require a faster network than 3G.

3G does several megabit of download speed. This is the same kind of speed as a lot of users have on wired connections with DSL or even lower-end cable modems in some areas. Also, many users pay for data on their 4G connection, so a game that uses more than a megabit a second to play would be pretty harsh on the wallet. WiFi doesn't have that problem, but then has to share the connection with everything else in the household (Netflix, bittorrent, zombie trojans, WoW patching, etc.)

Are you talking tablets, or phones?
The original Amazon Kindle Fire is an Android device that's pretty run-of-the-mill by now.
For phones, it seems like 400-800 MHz and 256 MB RAM running 2.3 in 480x640 resolution is the lower end -- and, thus, the bigger market. If you're targeting iPad v1, then it seems you want a wide market, so you should consider that. Also: there are still androids out there in 320x480 resolution.

A good ball park number for maximum payload size is 1300 bytes. This works well with the vast majority of networks out there, and is big enough that the per-packet overhead won't be more than a few percent.

If the problem is that Enet limits the number of packets per second (with a small send window, say) then you should cram as much as you can into each packet. Let's say Enet allows up to 1300 bytes per packet, then you should cram as many entity updates as you can into that one packet. 39 packets later, you will have sent everything.<br />

If you do not understand that description, then you need to first do step 0: Learn to effectively develop software. This includes being good at at least two different programming languages, and being able to read and understand the manual pages and documentation of the system libraries.
If you do not yet have those skills, you cannot develop a robust game server. Right now, you're trying to learn calculus, from a textbook written in Latin, without knowing any Latin. You need to learn the Latin before you can learn the calculus.

If you want one-on-one help, there are many contractors and consultants that will spend their time helping you out. That will cost money, though.