Addition of Object Pooling System in the GUI Mechanism

Description

Currently, the addition of an object pooling system to the game's GUI mechanism is necessary. This request aims to enhance efficiency in resource usage, especially concerning memory consumption during the initialization of graphical interfaces.

Justification

The object pooling system involves storing instances for subsequent reuse, avoiding excessive instantiation during the game's initialization. The current situation leads to a significant increase in RAM consumption, as each instantiated GUI in the project creates all necessary objects during the initialization process.

For example, the "HUD" GUI currently instantiates 30 objects just for the element selection header, consuming approximately 6 to 7 MB of RAM. If the system remains unchanged, building dozens of interfaces could result in more than 5000 instantiated objects, consuming a concerning 126 MB of RAM.

Implementation

The implementation of the Object Pool system can be done through collections of objects that store and provide instances when needed. New objects can be instantiated only if all current instances are in use.

After implementation, it is advisable to update how GUIs and their elements are initialized. The suggestion is to add events such as "OnLoad" and "OnUnload," which construct GUIs by loading and unloading elements in the object pool, reusing specific instances for each context when necessary.

Potential Impact

The introduction of this system will have a highly positive impact on the memory consumption of GUIs, especially considering the number of objects present in a single menu. Additionally, there is the possibility of improving performance through intelligent caching strategies, information storage, and even multithreading implementation.

The only potential negative impact could be a delay in the loading and unloading of GUIs due to the necessary reconstruction. However, this aspect can be mitigated with the use of smart caching and storage strategies, providing a significant performance boost.

Additional Context

It is crucial to conduct a thorough study to determine the feasibility and effectiveness of this implementation in relation to the overall game performance. If proven viable, this addition could represent a significant advancement in the operational logic of GUIs in the project.

Parallax Background Implementation

Introduction

The incorporation of parallax effect backgrounds is a technique that involves the movement of distinct layers at varied speeds, providing an additional sense of depth to the game's environments.

Description

The parallax effect is achieved through the composition of different layers, each containing sprites that move at various speed rates in response to camera movements on the X and Y axes. To intensify this effect, the same background image is rendered three times consecutively and readjusted as the camera reaches certain limits. This creates the illusion of an infinite scenery without significantly overloading the performance of the system in which the game is being executed.

Implementation

The implementation of parallax backgrounds can be carried out following these steps:

1. Parallax Layers: Define different layers with sprites that will have parallax movements. Each layer should have a unique movement speed.

2. Repeated Rendering: Render the same background image three times consecutively, aligning them side by side. This forms the basis for the parallax effect.

3. Dynamic Repositioning: When moving the camera, dynamically adjust the position of the layers according to the defined speeds. This creates the illusion of depth and differentiated movement between the layers.

4. Boundary Management: Implement logic to reposition the layers when the camera reaches predefined limits, maintaining the continuity of the parallax effect.

Player HUD Implementation

Introduction

The Heads-Up Display (HUD) in games plays a crucial role in creating an engaging experience for players. It serves as the central control panel, providing essential information and contributing to immersion in the game environment.

Description

In the context of the Pixel Dust game, the HUD goes beyond simply displaying general data. It is the central point for the player to interact with the virtual world. In addition to being aesthetically pleasing, the HUD should be organized, intuitive, and offer utilities that enhance the gaming experience.

Roadmap

The development of the game's HUD interface is currently focused on the following aspects:

• Element Selector Panel
  • Recent Elements
  • Element Explorer
• Global Utilities Panel
  • Climate Configuration
    • Set Time of Day
    • Set Weather Event
    • Set Temperature
  • Brush Configuration
    • Set Brush
      • Square
      • Circular
      • Triangular
    • Set Brush Type
      • Point
      • Line
      • Fill
      • Replace
      • Picker
    • Set Size
      • Size Options (Very Small to Very Large)
  • Zoom Configuration
    • Zoom Level
  • Screenshots
    • Include GUIs
    • Include Cursor
    • Set Image Scale
    • Save Buttons
      • Save to Clipboard
      • Save to Device
  • General Settings
    • Set World Size
• Game Utilities Panel
  • More Options
  • Tools
    • Save/Load
    • Erase
    • Undo
    • Redo
    • Restart
    • Reset

Implementation

The implementation of these elements will be done using the GUI system, an essential tool for building interfaces in the project. It will be ensured that the HUD not only meets functional requirements but also follows best practices in user interface design.

Screenshots or Concepts

Purely conceptual image.

Optimize the blob rendering system of elements

Introduction

For better system efficiency, it is necessary to pay attention to valuable aspects that can optimize and raise the level of rendering.

Description

Exhaustive repetition of the process every frame on all elements

Even though the calculations are simple and are based on constant numbers pre-defined in the system, they are all repeated tirelessly in each frame of the game, causing a gradual overload in the process as the number of rendered elements increases, constantly causing lag and problems. that could get worse.

It would be interesting to add a cache system that can save and compare the states of the elements, checking if it really needs to be updated or if its current sprite already matches the last update. All of this will improve rendering performance and improve overall project speed.

Rendering elements that are outside the camera

Something that has a negative influence is the constant rendering of objects that are outside the limits of the camera. As they are not seen by the player, there is no apparent reason to render them, avoiding unnecessary extra load that in the end is barely used. To do this, simply use methods present in the camera to check whether a target position is or is not within the camera, thus performing the check and storing the elements that really need to appear on the screen.

GUI System Creation

Introduction

GUI (Graphical User Interface) is a system based on the design of a graphical interface through which the user can interact with a program. It is marked by interactive components such as buttons, text fields, labels, and others. In essence, GUIs feature various interactive components that can be controlled using devices like a mouse, keyboard, gamepad, etc.

Description

The GUI will be built entirely from scratch using logical layouts and control of elements for the construction and display of graphical content on the screen that can receive direct interaction from the user in a simple and user-friendly flow of events involving controllers (mouse, keyboard, joysticks, etc.).

It should be based on an object hierarchy system (parents and children), along with other auxiliary implementations such as positioning anchoring and similar features. Objects can also have properties inspired by CSS, such as margin and custom positioning. An important note is that the parent-child system is a very good design decision as it helps in relative positioning to the parent element and also defines the rendering order of elements in the game. Starting from the first element and gradually going through its children.

It is interesting to implement a manager that contains a collection of all GUI instances existing in the project. These GUIs would be abstract classes: specialized containers that would build and contain all the necessary elements for the composition of an interface in the scene, utilizing MonoGame for rendering and updating all components and elements.

The manager would be responsible for registering all GUIs present in the game and initializing them with general information such as reference definitions, among others. After that, there should be methods that allow searching for them, providing more dynamism and possibilities in the project.

Addition of Blob Rendering System to Elements

Introduction

The blob rendering system, often referred to as "Blob Tileset," is a versatile technique for creating varied patterns in games using only 47 sprites. While known as "Rule Tiles" in the Unity Engine and as "TileA2 ground autotile" in the RPG Maker VX community, we'll adopt the term "Blob Tileset" in this project.

The goal is to dynamically incorporate this system during the rendering process, where elements merge based on context. The main sprite consists of four sub-parts that are queried to define a suitable sprite, providing visual cohesion to the game.

Description

The system is an adaptation of the "Blob Tileset" concept, utilizing 47 sprites to form various connections between elements arranged on a map. This adaptation allows covering all possible edges of a solid element with other elements of the same type or different ones.

Based on this, we adjust the system so that, from a basic set of 5 groupings of 4 parts arranged in a sprite, they are dynamically defined for the construction of the final element sprite, taking into account its nearby neighbors.

Implementation

Set

Each element has a basic set of slices:

• Full;
• Corners;
• Horizontal Borders;
• Vertical Borders;
• Gaps.

Division

This set is dynamically used to assemble a complete element sprite in a 3x3 area, based on nearby neighbors.

An element is divided into four sub-elements located at each end, identified by cardinal positions.

Each sub-element checks the nearby neighbors of the element in the surroundings. The position of the sub-element determines which neighbors will be considered.

After checking the neighbors, each sub-element performs a weighted sum of the values corresponding to the cardinal directions, obtaining a unique identifier to determine the suitable sprite.

Each sub-element has 6 possible cases to determine its sprites, depending on the obtained values.

Northwest Sub-element

Northeast Sub-element

Southwest Sub-element

Southeast Sub-element

Rendering

This process is performed individually on each element during the game's rendering, dynamically connecting the elements and providing a natural visual experience.

Benefits

The system adds complexity to how elements integrate into a map, visually smoothing connections and removing abrupt grid lines, providing a more natural experience to the player.

Screenshots

Before implementing the algorithm

After implementing the algorithm

Sources

• Tileset Roundup by Boris.
• Wang ‘Blob’ Tileset by Guy.
• Original idea website, currently unavailable: http://www.cr31.co.uk/stagecast/wang/blob.html.

Additional Article

An article on blob tilesets highlights their utility in creating random designs, such as mazes, in platformer, side-scrolling, or top-down games. Some examples of blob tilesets are listed for reference.