Echolite - Update #16 - Usable Tools, Revamped Placement

Echolite - Update #16 - Usable Tools, Revamped Placement

Table of contents

No heading

No headings in the article.

Welcome back fellow Sparks! We have a neat little devlog this week that both brings in the new and revamps the old!

The core gameplay loop is mostly complete at this point, in which development of the game can finally enter an exciting phase. New features and subsystems will be added in to provide gameplay depth, in addition to revamping existing systems and jamming in tons of content! As prep work for entering this new phase, this devlog is focusing on building out usable items from the hotbar and redoing how placement is handled.


Usable Tools

This isn’t limited to just tools either, but we need some way of using items in the world that go beyond placement. Currently, objects are queried when highlighted in the hotbar to see if they have a placeable scene counterpart that can be instanced.

via GIPHY

For tools however, we are not placing an actual object (and thus no placeable scene exists). This naturally led me to rewriting the hotbar to query the ItemData.json file I have in place to look up an item’s category. It is the same key/value that the crafting system uses so luckily this did not require any changes to the core data beyond giving each tool its own entry.

Now, when an item is highlighted in the hotbar (either by selecting numbers 1-9 or through mouse scrolling), an item category is queried first and then searches for a function based on what is parsed. From here, custom functions are added to default nodes and instanced as needed. The only difference is that they are not placed visually - just added to the hierarchy for as long as needed to perform the tool’s function.

The only work left is creating a new selection sprite for using tools. With object placement, red corners are used to denote invalid spots, and inversely green signifies valid tile placement. With tools however, I wanted to have a middle level to visually demonstrate that object placement is different from using items. To achieve this, I went with a recolored selector as yellow and added a moving arrow icon to better denote which tile is being targeted by the tool.

image.png

As a tease for one tool made during testing, here is a neat drill (name pending). Animations will come at a later point, but at least the functionality is there! This tool is meant to mine a special resource from those rock formations throughout the world. I wanted to give these cool world generation features a purpose beyond acting as collision points while trying to navigate. Right now the plan is to make this resource a more exclusive one since it can’t be automatically gathered by machinery, perhaps as a base resource for a group of items like all furniture.

via GIPHY

Similar to the drill, more particles and visual changes are needed to make this mechanic pop, but I am quite proud of how this turned out!


Revamped Placement

For context, the placement system came at a point in the game where it needed to be built in order to introduce other features. Some of my favorite devlogs to write are showcasing new objects like machinery because they give so much life to the world. While the system was not rushed when initially developed, I certainly knew that it would need to be extended. Finally, today is that day!

There are numerous tasks I want to address with the placement system, but to stay motivated I will tackle one larger item. If you recall the current machinery options in game - the ore machine and hatch drill - one consistent feature is that they are both one tile in size. This became apparent when adding interiors to the tents in the base camp during the previous devlog. If I want to allow the player to place their own tents that aren’t pre-placed by the game, the current placement system would not cleanly allow that action. While it would place the item, it would only be assigned to one tile and mix up collisions.

image.png

To address this, I had to tackle two major changes. First, objects need a new JSON file that details placement and setting options outside of the main ItemData.json file. Second, placement needs to correctly scale from these set parameters and take all tiles into account for validity checks.

Addressing the first change, here is how I formatted the new JSON file:

image.png

You can see from this image that length and width are defined by integers, essentially just measured in tiles. Additionally, the valid tiles are defined for each object that help indicate where an object can be safely placed. Godot currently handles tilemaps with ID’s among other values, such as the first tile of “ore deposit” within my resource Tilemap has an ID of 0. This is why the JSON entries use numbers next to each defined tilemap. For cases where any tile type within a tilemap is allowed, I simply put “All.”

Next up is the second major change, starting with splitting up the selector sprite as previously referenced in the tools section. Each corner marker is now a separate sprite and cleverly uses the same length and width values with a multiple applied to auto-scale around any sized object.

image.png

Finally comes the magical coding logic which parses the new JSON file, scans the selected tiles, and places the object as before. Using the same length and width values, the top left-most tile is queried as the previous implementation did, but now repeats it for each tile. This builds an array of boolean values that highlight which tiles are valid or invalid. Assuming this entire array is valid (and no other objects exist on that tile), the object is placed as expected. The nice aspect of making objects separate saved scenes is that all of their individual logic for operating is handled separately. As long as consistently named functions are available on each object, this new placement system does not require any other rewrites. Here is an example of placing a larger table:

via GIPHY


What’s Next?

By far, the highest viewed devlogs involve machines being introduced to the game (and for good reason). With these new changes, some new machines can finally be revealed that are larger and better than ever! I think this next devlog might just blow your mind!

Thank you again for all of the support! It helps keep me motivated and excited, and I can’t wait for the day when this game releases. Pending a Steam page being set up, the best way to support this work right now is simply sharing it around! The more eyes on this project, the better it will turn out!