Kog2 Mobile Edition - Code Documentation. ------------------------------------------------- -------------------------------------------------- The code hangs together in the following manner. MainActivity is called first and handles the single activity that the game runs in on Android. Program is called within a handler loop to initially load resources and check the config file. The config file handles all the relevant game settings and parameter such as frame rate and screen resolution and so on. The loading of resources is done in the Resources.java file. All resources are read in from a text file first to find out where to seek for the file, and also any extraneous information such as cell widths and heights of animation frames and such. After resources are loaded the game sits in a loop called in Program - game(). Two main methods are called which are update and render. Rendering is done in the RenderList module. All drawing commands are sent here to be processed in the render() method. In update all the various game features are handled here such as updating the gui, drawing the gui, updating the game units and effects in battle, as well as drawing them All the features that have an update and render method or draw method separate our their logic into those two areas. So in update, movement and interaction with the user takes place, while in render or draw all the draw commands are performed. All major game elements are placed within an array. Some arrays are resized at runtime, though they usually reach a maximum size and then are left at that size for the duration of the game. NetworkUDP handles the multiplayer component. It uses a simple process of sending and receiving Datagrams in two distinct threads, a listening and a sending thread. Information received from the listening thread is placed in a queue of instructions which are then read from. While reading from the queue the system does not wait for messages. And while listening for messages the system does not process the queue. They are kept separate so that the threads do not mix up what they are doing. Images are loaded except where the flag NOLOAD is set on an image in its text file script. Before a battle on mobile the armies unload from memory and recycle their bimaps, before loading those that are needed immediately prior to battle. This prevents out of memory errors that can happen if the user has far too many units in the game at once loaded. Some classes are not used, such as Tech and Translation. Other classes are hangovers from earlier coding and are almost redundant such as the My..... java functions. They were written 5-6 years ago when I was learning Android. The Music service is quite simple and probably should be updated. LocalStorage writes and reads from the Shared Preferences feature of Android. This code is based on the C# SDL game engine I wrote for the PC versions of Knights of Grumthorr. The main changes between the C# SDL game engine and the Java Android game engine are as follows: Simple Syntax changes - .Length instead of .length for array lengths for example. Android uses the Canvas feature. The only real changes needed to port from C# SDL to Android Java was to modify the RenderList.render() method and the Resources.LoadAnimImage and Resources.LoadImage methods. Android uses a different audio system, called a Sound Pool. The relevant Audios methods were also changed. For the most part the two engines are very similar. Due to memory issues the large pathfinding arrays were not included in the Android version, instead pathfinding is performed in real time rather than precalculated. Triggers are much the same with a difference that the *ANY, *FRIEND, *ENEMY values have had the * dropped from their names. The Blood, Bullet and Gibbet effects are not processed on Android for performance reasons. Screen resolution handling is a little different on Android. There are only two Android UI elements in the game. One is a frame layout with surface view, the other an edit text. The Edit Text UI component is to handle the multiplayer mode of the game. To allow the user to specify an IP address. I tried all sorts of malarky to get the system to self identify the IP address without the user entering it and in the end just went for a simple 'user enters the IP' system. Since it is only a two player game that should be fine. KRect is a helper class for the Android Rect class just because I didn't want to rewrite the RenderList too much. In it I use x,y,width and height rather then top, left, bottom, right. Config has a lot of fields that are irrelevant to Android since they carry over from the Windows version. Unit.java has a lot of fields and features, as does Gui.java that are relevant to my other java Android games and are also irrelevant to this game. ArrayResize.java was taken from a user's explanation of how to resize an array of arbirary objects that uses Reflection. I would not have had a clue how to do this myself and would have instead have had to write a messy system of simply recreating each array element and building the array up again piece by piece. Images and Fonts have very little in the way of methods, and Fonts on the surface looks like it doesn't do anything at all. Functions.java carries a lot of functions that also exist in java natively. These carry over from my Javascript days when I was writing games for the browser. They are still very useful however.