Android game using the LibGDX engine.
Introduction • Components • File extensions • Media • Links
As of 2016, i began working on an Android game called "The Fish Game", the idea was to have flappy bird's mechanics, friendly graphics and an eye catching environement, but somewhere into the development process of the game, i realised that i lacked the necessary knowledge/resources to make beautiful graphics assets, so i quickly shifted the game into a simpler, less textured and more shape oriented graphics.
As of September 2017, the game was officially released on Google's Play Store under the developer's name "OrMisicL Apps", and amassed more than 2000 downloads worldwide, but ended up getting taken down along with my suspended developer's account sometime in March 2018.
So here is it, fully open source for anyone to re-release it, improve it or simply learn from it.
Generator • Encoder • Android • Core
This will convert any LibGDX's physics body editor tool JSON file into a ready-to-use OBM file, simply pick a directory containing all of your JSON files and hit the "Generate" button, the output files will be generated under "(Your picked directory)/Generated", refer to the assets folder for a better example.
This will encode configuration files using Base64, and will generate an OAC file, simply pick a valid XML file and hit the "Encode" button, the output file will be generated under your picked directory, refer to the assets folder for a better example.
Contains a full implementation of Appodeal's LibGDX Library (banner, interstitial and rewarded video), as well as a full implementation of Google Play Games Service (BaseGameUtils).
This project should not be edited and could be directly imported and used for future implementations of this sort.
The game's core implements both generic and specific systems, where everything starts from the Core and reports back to it, the Core then delegates tasks to generic managers which handle other specific components of the game.
Responsible of handling game's resources, immediate loading, disposing and queued loading, textures quality are also handled internally as well as loading configuration files.
NOTE: This cannot be directly exported and used somewhere else as it relies heavily on the game's Core and some of its components, unless you remove this dependency (which shouldn't be hard), but you'll give away texture's quality handling and configuration's loading.
Responsible of handling models loading (configuration, body, movement), and will internally store all loaded models along with their movements and shapes.
NOTE: This only depends on the File Manager and can be probably used anywhere else.
Responsible of handling game's files, from XML parsing to decoding file extensions, this is basically the lowest layer that the game refers to for handling all of its resources.
NOTE: This only depends on LibGDX's library, so it can be exported and used anywhere outside of this project.
Will handle and process every game screen and transition between them, will also handle the UI windows and delegating input between the main UI components and windows.
Is the one responsible for what appears on the screen, will handle rendering cycles (begin, render and finish) and some rendering effects like flashing and fading. This is the lowest layer of rendering, meaning anything appearing on the screen has to be passed to this manager and it will be handled accordingly.
This is pretty much straight forward, it will load levels from their configuration files and store them internally.
The core's components are well organized and well commented that it makes them easy to understand and re-use, i made sure to write a clean, reusable and well documented code while keeping close to the game's needs, if you have any more questions about the game's core, please contact me by email or leave an issue on this repository and i'll be happy to help.
The game would mostly load its own file extensions and formats, these files serve as a dynamic configuration tools to modifying the game without changing the code (Example).
Most of these files are Base64 encrypted, this would offer an extra layer of security for the final product and could potentially lower the risks of undesired modifications, other extensions are simply a collection of vertices and points and are constructed in order to minimalize the stored data size and optimize the loading time.
This file is generated using the Generator tool, and it holds data about the object body's vertices and collision, please refer to the Entity body part node for more insights.
This file is generated using the Encoder tool, and it holds data about the object's configuration, please note that this extension doesn't follow any general guidance as every configuration file follows its own set of rules.
- Model configuration example
- Movement configuration example
- Model settings configuration
- PreSet combinations configuration
This file is generated using the LibGDX's Particle Editor tool, and it holds data about particles, please note that this file is a simple extension rename and does not modify the final output of the particle editor.
NOTE: It was originally going to be an encrypted effects file but the idea was dropped as it would be just a waste of resources.
This file is used to save the user's data, it's a Base64 encypted XML based file with basic security machanics, please refer to How To Use Persistence section for more information.
Gameplay Video
First Level Video
- LibGDX as game engine
- Box2D as physics engine
- Appodeal as ad mediation platform
- BaseGameUtils as Google Play games implementation