Chapter 6. Going Cross Platform

So, we are at the sixth chapter of the book, and you may be wondering why everything was so simple. You may be wondering where the really complicated parts are hiding out. I will be talking about all the complicated aspects of the flag defense game in this chapter. The source code for the completed web game can be found in the FlagDefenseComplete folder and the source code for the completed cross-platform game (Android and iOS) can be found in the FlagDefenseDevice folder.

In this chapter, we will cover the following topics:

  • Complete details on the implementation of the web version
  • In-depth analysis of the AI decision-making
  • Supporting multiple screen sizes
  • Tricks used by the game for supporting multiple devices
  • Creating dynamic texture atlases
  • iOS and Android specifics
  • Local leaderboards
  • Integrating ANE for AdMob
  • Publishing to the Google Play Store and the Apple App Store

The finished game

If you have not yet played the game, please go ahead, compile the FlagDefenseComplete project, and give it a go. The code base has the usual single player game as well as a same device multiplayer game, where you can play against a friend by sharing the mouse on the same PC. It is not possible to explain the whole code in this chapter; I am focusing on explaining the complicated aspects only.

Let me briefly explain the organization of the code base. We have a few dependencies such as the Starling framework, the Starling Particles extension, AS3 signals, TweenLite, Flox, and sounds.swc, which resides in the assets folder and contains all the sounds used in the game. The default application is Web_Preloader.as, which shows the loading progress and eventually loads our main entry class. This compiler argument sets up the StartupFrame FlagDefenseComplete frame.

The libs package has the Pathfinder class and com.csharks has all the game-specific classes. The ResourceManager class handles playing sounds, accessing support files for particle effects, and populating the AssetManager instance with all the textures. We are using a single 1024 x 768-based texture atlas embedded in the EmbeddedAssets class. The GameStates class has two new states to facilitate the automatic movement of bombs per turn that are mentioned as follows:

  • BLUE_BOMBS_MOVE: This moves blue bombs automatically
  • GREEN_BOMBS_MOVE: This moves green bombs automatically

The com.csharks.flagdefense.entities package has the Bomb class and the Explosion class, which were introduced earlier. The com.csharks.flagdefense.helpers package contains the following classes:

  • The AiManager class: The core decision-making is done by this class assisted by other helper classes
  • The LeveUtils class: This stores the level data and creates the collision array
  • The SceneManager class: This is the starting Starling class, which swaps out the different game scenes

The com.csharks.flagdefense.scenes package has the MainLevel class and the MultiSamePC class, which respectively handle the single player and multiplayer modes of gameplay. Additional classes, AiStates and AiDecisions, help AiManager to go through the process of AI decision-making.

Tip

It is interesting to note that the MultiSamePC class actually extends the MainLevel class and overrides some key functions, which easily transforms the game from the single player mode to multiplayer mode; of course, with no small help from the AiManager class.

The MainLevel game loop

Now that you have gone through the code base, I am sure that you can easily understand the logic flow and realize how the game works. Let me reconfirm what you have already found out. The MainLevel class is the starting point, which initializes an instance of the WorldLayer class, spawns one soldier each for each side, sets the initial game state, sets up the UI, adds the game loop listener, adds the game UI listener, and a touch listener. The following list explains what the game loop does:

  • Updates the changes in the game world, runs the AI process, and renders the scene
  • Checks if all the blue soldiers have completed moving and then changes the state
  • Checks if all the green soldiers have completed moving and then changes the state
  • Checks if all the blue bombs have completed moving and then changes the state
  • Checks if all the green bombs have completed moving and then changes the state
  • Checks if any side has won

The touch listener handles the following logic:

  • If a touch is started, it checks if it was on a soldier and starts path drawing
  • If a touch has moved, it checks if it has a valid neighbor, and appends it to the path
  • Ends the path drawing when the value is used up or placed at the wrong position
  • Toggles the bottom game UI

The touch listener is overridden by MultiSamePC to make it work for both sides.

The most important part among all this is the following line of code in the game loop, which actually advances the game logic:

worldLayer.render(e.passedTime,groundImage);
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.135.247.181