Learning Godot: My Journey to Creating a Turn-Based Strategy Game

Summary:

The terrain is starting to look more coherent and visually appealing, thanks to the new shader and various fixes/changes to the way the terrain is being generated..

What's New:

• Unwrapping and Texturing: I've implemented a custom shader to unwrap and apply textures onto a procedurally generated mesh. The shader considers the Y-coordinate of each vertex to decide which texture to apply. The result can be seen in the image below:
  
• Triangle Direction: Fixed some issues I was facing with the direction in which the triangles were being generated at the corners.
• Height Artifacts: Managed to sort out some visual artifacts where the height was incorrect, particularly where water is supposed to be.

Challenges and Solutions:

• Color Interpolation on Vertices: When I initially applied color to vertices it was producing bad results:
  
  The issue stems from the inherent behavior of vertex color interpolation in shaders. This feature works optimally for smooth, flat surfaces, but when applied to a mesh with varying heights and shared vertices, it doesn't behave as expected. Specifically, the colors gradually transition from one vertex to its neighboring vertex without considering any changes in height. This results in an unintended gradient effect where a more distinct color boundary was intended.
  
  To solve this issue, I created a custom shader that considers the height of each vertex before applying the color. This approach allowed for uniform coloring based on the Y-level of each vertex.
  

• Texture Unwrapping: Switching from a color display to a texture display introduced the challenge of unwrapping all of my squares. I accomplished this by using a tilemap format and applied the texture using a ShaderMaterial.
  Voila! We've successfully integrated all squares into a single mesh that utilizes just one material. The image below showcases the custom shader that made this possible:
  

• Triangle Direction: I encountered issues with the direction of the triangles, which created problems when vertex heights differed.
  
  To address this, I altered the triangle generation direction for specific cases, flipping the indices to generate triangles in a different order. Below image shows a more detailed explanation of the solution to the problem:
  
  This resolved the issue, as shown below.
  This solved a part of the problem but if you notice the last image another one appearead. Artifacts are left behind. This makes the terrain look weird in specific cases. To fix this we go to next challenge.

• Height Artifacts: Some vertices were placed at incorrect Y-levels, leading to unwanted artifacts.
  
  To combat this, I implemented a check for each vertex against its adjacent vertices. If the heights did not match, the current vertex's height would be adjusted to align with its neighbors.
  

Up Next: Crafting Data Structures for Game Squares

The focus now shifts to architecting data structures for each of the squares. Specifically, I'll be:

• Assigning various attributes to these squares, such as their type, available resources, and whether or not they're occupied.
• Integrating this data structure to make these squares fully functional within the game environment.

Your insights or tips for effective data structure design in Godot are more than welcome! This should add a layer of complexity as we continue this learning journey!

Summary:

Implemented a Cell Manager for data storage of grid squares and introduced a custom raycasting system to detect cell selection via mouse clicks.

What's New:

• Bitwise Data Packing and Unpacking - Breaking away from the traditional route of storing structs or classes in an array, I took the more challenging path of bitwise packing into a byte array. Though this adds an extra layer of intricacy to the system, it significantly optimizes data storage.
• Custom Raycasting System - Bypassing the usual static mesh rigid bodies and mesh colliders, I opted for a custom raycasting mechanism. The system evaluates the position of the ray at each step to determine whether it intersects with the grid. Additionally, it consults the heightmap to accurately identify terrain types based on different Y-axis levels, such as hills and water.
  

Challenges and Solutions:

• Cell Manager: I ventured into the realm of bitwise operations to achieve a level of data optimization that might make developers cry, but would certainly make computers happy. The Cell Manager has two primary responsibilities: packing and unpacking cell data into a byte array.
  
  • Packing Data - Let's explain the first responsibility. Suppose a cell has the following attributes: "Terrain Type: WATER," "Resource Type: FISH," and "Occupied: True." The process is as follows:
    • The terrain type "Water" (binary representation: 000) is shifted 5 bits to the left, resulting in "00000000."
    • The resource type "Fish" (binary: 0010) is shifted 1 bit to the left, giving us "00000100."
    • The "Occupied" status (binary: 1) remains as "00000001."
    • Finally, these are combined using the bitwise OR operation, resulting in a packed value of "00000101."
      
  • Data Unpacking: The second responsibility involves the reverse process, which involves interpreting the packed data back into its original, readable form. For example, if we need to access cell data at row "3" and column "3," the unpacking process is as follows:
    • Shift the packed data "00000101" 5 bits to the right, yielding "00000000." Then use an AND operation with 0x7 (00000111) to get "0," representing the "WATER" terrain type.
    • Shift the packed data "00000101" 1 bit to the right, giving "00000010." Using an AND operation with 0xF (00001111), we get "2," signifying the "FISH" resource type.
    • Use an AND operation on the packed data "00000101" with 0x1 (00000001) to get "1," which corresponds to "True" for the "Occupied" status.
      
      This approach allows for efficient data storage and quick data retrieval, although it does introduce a level of complexity in the codebase. Now, who cried while reading this?
• Custom Raycaster: I've opted for a unique approach, forgoing the typical use of static rigidbodies with trimesh collision for each triangle. Instead, I've implemented my own raycaster. This custom system launches a ray in the normalized direction from the camera towards the mouse position.
  
  This methodology offers a fine-tuned approach to grid interaction, eliminating the need for additional collision geometry. To make this more concrete, let's explore the code involved:
  
  Here's a breakdown of the procedure:
  • Step 1: Calculate the directional vector pointing towards the mouse position.
  • Step 2: Scale this direction by multiplying it with a step value, effectively determining the length of each ray step.
  • Step 3: Compute a new ray position by summing the camera position with the scaled directional vector.
  • Step 4: Derive the row and column indices by dividing the ray position by the cell size.
  • Step 5: Validate if both row and column values are above 0 and if the ray's Y position is less than a single step.
  • Step 6: We loop through Steps 2-5 until one of two conditions is met: either we acquire valid cell row and column, or we end up with null values.

Up Next: Data Import via Google Sheets

My next endeavor steers us towards data importation via Google Sheets. The focus here is to fetch data, such as building, unit or card
data, and store them as game "Resources".

• Find a way to import Google Sheet data into the engine.
• Create/Update/Delete custom "Resource" classes to hold the data for different game elements like buildings, units, and cards.

Wondering how I will create custom edtior button to pull the data. Is there an easy way to do this?

Summary:
Made some good progress this time around. Alongside the Google Sheets integration, I also started laying the groundwork for the UI. It's a work in progress, but it's getting there.

What's New:

This update features two key implementations, one of which is complete and the other is still under development. For more details, read on:

• Google Sheet Integration: A significant milestone. It streamlines the process of managing game data like Units, Buildings, Events, Upgrades, and Territory Settings. The integration allows for real-time online updates which can then be pulled into the game's central Database with a single click. For those interested in a deep dive into the implementation details, you can check out the dedicated thread:
  Google Sheet Integration
• Buildings and Building UI: This part of the project is engaging and demands a good deal of work before it reaches completion. Below is a snapshot of the current state of this feature:
  
  The design is modular, allowing for the seamless addition, removal, or modification of buildings. Even entire categories of buildings, such as "Resource," can be removed without disrupting the overall system. New types can be introduced just as effortlessly. More details on the challenges and functionalities of this feature will follow.

Challenges and Solutions:

• Item Database: Developing a centralized Data System presented its own set of challenges, but the approach I've taken has streamlined many aspects of the game's data management. The database accepts an item ID, which allows for straightforward retrieval of various kinds of data, each based on a universal "Item" type. This negates the need for multiple arrays or other more complicated structures.
  Moreover, structuring the database as a type of Resource permits the storage of items externally, which not only facilitates easier management but also acts as a safeguard against potential future bugs. Here's a glimpse of what the database looks like:
  
  One essential feature is that items are read-only within the game, ensuring that any modification can only occur within the editor, thereby maintaining the integrity of the data.
• Buildings: This is another key component of our data management strategy. Buildings are classified as a type of Resource, and they extend the base "Item" data type. This forms a crucial data block that is universally accessible across all game systems. Whenever a system needs information related to any building, it simply queries the Item Database using the building's ID.
  Currently, the structure holds a range of data values, with plans for more to be added in the future.
  
  Importantly, all data values are marked as "ReadOnly" (a custom attribute). This setup restricts any in-engine adjustments, thereby eliminating the potential for discrepancies between the online data set and what's downloaded into the game.
• Building UI: This is still a work-in-progress but is coming together steadily. The system currently operates in two primary modes:
  • Acquiring All Building Item Types: The first step involves fetching all types of Building items from the Item Database. Upon doing so, it instantiates these items on the screen. Initially, these items are hidden. However, when a player clicks on a specific tab (defined as 'TabType' in the Google Sheets), only the buildings corresponding to that tab type are displayed.
    
  • Create Building UI:: During the creation of each UI item, it automatically assigns an Icon and an ID. When the corresponding button is clicked, this ID is returned, and new information is displayed to the player. These UI elements are then neatly arranged in a horizontal box for straightforward display.
• Building Placement: The system here is also quite straightforward. Upon selecting a desired building and clicking on an available slot on the screen, the building is constructed. If the slot is already occupied or is a resource that doesn't match the building type (e.g., trying to build a harbor on a forest), the game prevents the construction. Once a building is placed, the cell's 'isOccupied' attribute is set to true to prevent additional buildings from being placed there. Here's an example where a 'Harbor' is successfully placed on a 'Fish Resource':
  
  This approach ensures that the placement rules are respected, avoiding duplicate constructions and helping maintain gameplay integrity.

Up Next: A Step Back

By adding so many things I neglected one of the more important systems: FSM. It is really a big requirement of the turn-based strategy games.

• FSM (Finite State Machine): Implementing an FSM is a crucial step forward, as it will act as the centralized control hub or "Brain" of the game. For games with discrete states like turn-based strategy games, an FSM is often more suitable than a Behavior Tree. With an FSM, transitions between various game states such as "Unit Movement," "Building," and "Turns" can be clearly defined and managed. This will improve the gameplay flow and make it easier to debug and extend the game in the future.
• Code decoupling: The current parallel systems for building selection, placement, and raycasting have led to bugs. Implementing an FSM will centralize these processes, resolving existing issues and preventing future bugs.

Up next, the focus will be on integrating the FSM and breaking down the code into more manageable components to fix current issues and set a solid foundation for future work.

Update [0.230923]

Summary:
A lot of effort went into cleaning up and reorganizing the code. Several new features, such as an Observer System and State Controller, are now in place. Let's dive in.

What's New:

Here's a rundown of the main updates:

• Code Cleanup: The game reached a point where better organization was essential. So, various pieces of code were either moved, deleted, or updated to make everything more cohesive.
• Observer System: This feature keeps tabs on specific values and notifies other parts of the code when changes occur. It was challenging to implement, but it's doing its job well.
• State Controller: This acts as the game's "brain," governing changes in the game state. Everything else in the game reacts to this centralized system
• UI: The UI used to be tightly bound to game controllers. Now, thanks to the Observer System and State Controller, the game can run without being tied to the UI. This means that removing any UI element won't crash the game.
• Scene Cleanup: Every UI element has been converted into "Packed Scenes" and organized under a main UI component. This not only tidies things up but also allows each component to focus on its own specific function. Overall, it's a big step toward making the project more manageable.

Challenges and Solutions:

Skipping the Code Cleanup, as it's too much to unpack here. However, the Observer System does warrant a detailed look:

• Observer System: This system is vital for cleanly separating various game logic pieces. It's a bit intricate but pays off in spades for extensibility and maintenance. Here's what it entails:
  • ObservableProperty: Just as the name suggests, it's a property that triggers an action when its value changes. Setting up a new observable property is fairly straightforward, and you can bind other properties to it just as easily. Whenever a property changes, an event is fired, alerting all the listening objects.
    So, anytime the value of any of the properties changes it fires an even to the listening objects.
  • ObservableAction: Similar in concept, this is essentially a wrapper around existing actions, making them generic. Creating and binding new actions is simple. The generic nature of these actions greatly simplifies a lot of issues, making it easier to keep the code clean and manageable.
    
• State Controller: This is essentially the game's command center, coordinating all observable properties based on mouse inputs. By doing this, it enables the game to run using just a SINGLE PROCESS METHOD. What happens is the State Controller listens to mouse events, and then toggles the state of the game accordingly. This, in turn, triggers the appropriate observable properties, and thus the necessary game components, to update.
  
  Here's a quick illustration: when you press the left mouse button, the property "IsMouseLeftDown" is set to true. This change then fires off an event to any other component that's listening for changes to this observable value.
• Scene Cleanup: The UI has undergone a significant overhaul, moving from a somewhat disorganized structure to a cleaner, more modular setup. All UI components have been encapsulated into their own "PackedScenes." This approach not only tidies up the main UI scene but also localizes the functionality of each UI element.
  
• Building System: Hey, let's talk about the fun stuff—buildings! I managed to clean up the game behavior, which is already helping me sidestep potential bugs. Here are some of the improvements:
  • Show/Hide Buildings: You know that building tab that's always on your screen? Now you can easily toggle it on and off just by tapping the same tab again. Keeps the screen cleaner and lets you focus on your game.
    
  • Display Info: Got a small but neat update here. Now, building info will only pop up when you hover over the button, and it'll go away the moment you move the cursor out of the button's area. A small change, but makes the experience feel a lot smoother.
    
  • Building Placement: So, now when you're dragging a building around the map, you'll actually see it where it could go. If the spot's good, the building stays visible; if not, it disappears. It's still a work-in-progress, but I'm liking where it's headed!
    

Up Next: Displaying Resources and Selecting Buildings

Alright, the housekeeping is done, the stage is set, and now the real fun begins! Here's what I'm diving into next:

• Displaying Resource: Let's make resources visible on the map, shall we? This way, you won't have to hover over every grid cell to find out what's there.
• Building Selection: Placing buildings is good and all, but how about clicking on them to see what they're up to? Time to add some interactivity to these static structures.

I'm pumped! Finally, I can focus on enriching the gameplay experience without the fear of breaking everything I've built so far. Let's get to it!

Update [0.031023]

Summary
Hi all, I've been spending some time on UI work, logic adjustments, and a bit of modeling lately. While there's still much to learn and refine, the project is coming along. The codebase is getting quite extensive, making it a bit more difficult to keep track of everything. I'm considering adding more comments for clarity, although I usually rely on well-named methods, variables, and classes to keep things understandable.

What's New:

• Building Hotkeys: Simplifying player interactions, you can now use hotkeys for selecting and building structures, eliminating the need for repeated button clicks.

• New Building - Barracks: A humble addition to the game. The Barracks model follows a similar aesthetic to the Archery Range. It's designed to be efficient with a minimal vertex count and shares the same color palette texture as previous models.
  

• Revamped Building Selection UI: The previous UI had sections for "Battle," "Resource," and "Economy," which felt cumbersome to navigate. The new UI layout places all these elements under one umbrella but categorizes them for easier navigation. Added a bit of smoothness to the transitions as well, thanks to Godot's Tweening capabilities.
  

• Drag-and-Move Building:: A small but handy change—while dragging the map to explore, any "ghost" buildings you're holding won't be canceled. The building will only be placed once you stop moving the map.
  

• Building Canceling: Added the ability to cancel "ghost" buildings using the "Escape" key, right-click, or "B" key to select a new building. A tiny feature that makes a big difference in gameplay fluidity.
  

• Civilization Colors: All civilizations now share the same building models, but the building colors change depending on the chosen civilization. In the future, players will have the option to customize these colors. This change required a slight alteration in rendering, requiring two draw calls instead of one.
  

• OtherChanges:

  • Instant Placement: Now, buildings appear immediately on the selected tile.
  • Build Rule: You must deselect a selected building to build another.
  • File Format: Switched from .GLB to .OBJ for models.
  • Resource Icon Positions: Slight improvements to resource icon placements on the screen.
  • UI Hotkeys: Building hotkeys are now displayed in the UI.