Wednesday, December 17, 2014

Introduction


Real time game. Three words that summarize the mission that we want to achieve. Even Better: High Frequency Real Time Game.

Create a multiplayer game in real time. This will be our mission throughout this blog. Even Better: we want to  create a multiplayer game in real time in which movements will often succeed at milliseconds rate.

A major challenge we will face in the next chapters.

What applications will benefit from the engine that will build? Certainly a variety of areas, but we have to focus on a specific use to show how to achieve this goal.

Looking back, we will take as a reference of a classic game Snake. If you put an eye on it, you will realize that green large animal moves pretty fast. We will implement a version of Internet snake through the determination of the game is perceived in the same way to the standalone version. Like when a child is and there are no limits, we have added the following to the wish list:
  •     We don’t want to limit the number of players.

  •     The game has to be fast. Maybe no as fast as the original but quite fast.

  •      We want to play with my smartphone, performing a first implementation in Android.

  •     We want to play through mobile networks. We don’t want to be forced to  use wifi if we want to play in a fast way.

  •    We do not want to see us affected when people leave the game.

It’s not an easy list to achieve. Specially the points related to the agility and mobile networks. Anyway, we were young and we still have no limits, so we are going to make it.

Where do we start?
In relation to architecture, which approach we will take?. Client to Client approach or a client-server architecture?. Well, let’s think about it. We do want to play several players at the same time. It seems clear that someone has to be the referee. Someone has to guarantee the real state of the game since remote players can have networks issues or, directly, leave the game. This referee can’t be one of the remote players ( as we have just said he can leave the game ). It has to be someone else. Who? The game server.

We also should think in which language we are going to use for implementing the game. At client side we will have to use Java or Objective-C (later) if we plant to be at Android /iOs Markets. At server side, for sure, C is the fast way we can do it… but, why not Java?. Yes, its more slower than C but this won’t be our bottleneck: it will be the net. Besides that, we are not planning to draw 3d pictures (at least, at the beginning). Java inheritance and polimorphism are such powerful tools that we want to be on our side. So, Java is our language. Besides, Android is Java based so at Android version  we would have client and server layers using the same language.

In the following entries we will go deep inside this approach detailing some specifics that will make us win the battle.

No comments:

Post a Comment