How FANG works

From FANG

Below you'll find a summary of how the different mechanisms of the gaming package work together to make it fast, functional, and relatively simple. The API documentation and the source code for the gaming engine contain detailed descriptions of how it works, but reading the summary below can help you get the big picture of how the pieces fit together.

How the Gaming Engine Achieves Animation

The animation in the gaming package works by displaying approximately 25 frames per second. At each frame display, all the Sprites on the AnimationCanvas are drawn. If the Sprites do not move much between frames, then the rapid succession of still frames resembles movement in the same way that movies consist of many still frames pers second. The difference though is that in a movie all of the frames and movement are made ahead of time, while in a video game most if not all of them must be made shortly before they are displayed. Given a frame rate of 25 Hz, that leaves maximum 40 milliseconds to prepare each frame since 1/25 seconds/frame is equivalent to 40 milliseconds/frame. If the movement between frames is too fast, or the calculations between frames must be very accurate, it is often necessary to even calculate more frames than are displayed. This is the difference between the Model Frame Rate and the Display Frame Rate. Supposing that 10 intermediate frames are required per frame displayed, now there is only 4 milliseconds to calculate the frame (4 milliseconds = 1/250 second).

Because these frames must be computed so quickly to keep up the goal 25Hz Display Frame Rate, the advancing of frames must be efficient. A large part of this efficiency is to avoid making new objects on the advancing of frames. Java garbage collection can really slow down the game and even make it run out of memory, so only a minimal number of objects are created per frame. Because frames need to advance so quickly, your games should be careful not to create a large number of objects as well. Part of minimizing the objects created is also making sure the AnimationCanvas does not accumulate too many Sprites. As Sprites are no longer needed they should be removed from the canvas (via the kill method of Sprite or the removeSprite method of AnimationCanvas) and all references to them eliminated to make the Sprites eligible for garbage collection. If your game starts to run excessively slow, check the advanceFrame method of your class to make sure it follows these guidelines.

How Mouse and Keyboard Input are Handled

All games written using the gaming package are by design available to be run as multiplayer games. For this reason the games need to stay consistent across computers. This is achieved by making sure the games are a function of the mouse and keyboard input. All games, and even single player games, contain a single server and as many clients as there are players. The clients collect their own mouse and keyboard inputs locally then send them to the server. The server receives these keyboard and mouse inputs from all the players and distributes this information to all the clients. For a single player game this happens very quickly because no communications actaully have to travel across the network. For multiplayer games, this transfer of inputs may take a short amount of time and cause some delay from the time you press the keyboard of move the mouse until the time each computer receives the information. Clients have no access to the locally generated keyboard and mouse events because they would be receiving inputs before the other clients which would make the games inconsistent. Instead all mouse and keyboard input is taken directly from the server and placed into the Player object.

In earlier versions of the gaming package, local mouse and keyboard information was used in single player games to avoid the inherent delay in sending it to a server and getting it back again since consistency is not a concern for single player games. However, communications were optimized to make this every efficient and the difference in response time is not noticable. In addition, this single client/server model for all games makes the package simpler.

Another alternative to keeping games consistent is to transfer the game state from the server, not just the keyboard and mouse inputs. This approach was not taken because the size of the game state varies from game to game. Transfering a large amount of game state could slow down the Display Frame Rate to unacceptable levels. In addition, the keyboard and mouse information is very small and simple compared to all possible game states. How the Game Runs as both an Applet and Application The games you write can be run both as applets and applications. The Graphical User Interface (GUI) is designed to run in its own frame when run as an application and run in a browser when run as an applet. The GameWindow class takes care of making this distinction. By default, the GameWindow GUI does not have a frame. The method runAsApplication in GameWindow sets the GUI to use it's own frame rather than that of the browser and calls init. When run as an applet, init is called and the browser's frame is used instead of making a new one. All games are ready to go as an applet, and they can also be run as an application by calling the runAsApplication method. All you need to do in main is make an instance of the class that extends GameLoop and call runAsApplication on that instance. Now your game is an applet, an application, and even a networked game.

The Details Behind the Networked Games

The design of the networked part of the gaming package is a little more complex than the rest of the package. As discussed earlier in the Mouse and Keyboard Input section, the networking takes on a client/server model. The first question to be decided is how and where is the server to be run? Since every game requires a server, simply running the game starts up a server on the local computer. This server is designed to take up minimal processing time and memory. Even when games connect to a server other than their own, they still have a local server running just in case they'll need it later.

Initially the server accepts commands from clients to determine what games are running and to join games. This is so that it is possible to have a server running on a completely different computer which could be serving a large number of clients who may not even know about each other. The server supplies the games waiting for players and the clients can pick and choose the game they'd like to join. In practice, the server is not yet fully functional in letting the clients know which games are still accepting new players and which ones are currently in progress, so the networked games must be pre-arranged by the participants. The participants decide on who is going to run the server and where it will be. Then they select a name for their session and connect to the server to join the game.

Once all players have joined the game, the server sends out messages 25 times per second. These messages contain the current game time and the mouse and keyboard events (if any) which have occurred since the last transmission. The reception of keyboard and mouse inputs at the server and the transmission of these to the clients occurs asynchronously. That is the server transmits 25 times a second and sends its most recent information from the clients. It does not wait for input from the clients before sending. This design decision serves several purposes: first, if a player temporarily loses connectivity, only that player is affected (the game freezes and does not respond to input for a given time). The other players continue as normal. Secondly, there may be some lag in the input due to the round trip travel of the information, but the asynchronous communication allows clients to receive updates at regular intervals, making the game action smooth.

The players may also pause the game. If the server receives a pause from one of the players, it sends a final transmission to all the players indicating the game has been paused. As soon as the server receives the resume transmission from any player, it resumes sending at 25 Hz.