Echolite - Update #6 - Resource Collecting, Saving/Loading

Echolite - Update #6 - Resource Collecting, Saving/Loading

Play this article

Table of contents

No heading

No headings in the article.

Collecting resources, and then saving those resources - it’s a perfect match! This update continues to add core functionality in the game with some early game mechanics. Let’s start with resource collecting because it’s visually more exciting!


Resource Collecting

With the inventory and crafting systems added in the last update, the foundation is there for using resources. The only issue though, is that the player has no way of getting items! A certain surprise (read till the end!) will fill that role for most of the game, but in that initial stage there needs to be a way to gather materials manually. It should drag a bit so that players are motivated to explore better alternatives, but still function reliably.

To keep the design simple, I opted for a basic keyboard press to pick up resources. Godot offers a super flexible keymapping interface to set up keyboard actions, in which I tagged “C” as “collect_action.” Using this triggers a function that checks what tile type the player is currently standing on. It’s similar to the scanning code that the echolocation dashboard uses, but even easier as only one tile is being checked.

image.png

From here, we have a few design options for the kinds of resources that the player can collect. If we recall the planned tile types, there will be 3 resource tiles per “ring,” so at a minimum we will have 3 total resources in the first ring. This seems a bit limiting, so we could have multiple resources at each tile. While this is on the right track, having too many resources could overwhelm the player and make it difficult to “plan” runs into the darkness.

This leaves us with a neat solution! We have a few “starting” resources that can be generated per resource tile (1-3), and then those can be combined into newer, better resources. It gives more value to collected resources while still keeping the initial experience fairly stable. In this example, the geode item drops from the ore resource tile, and will eventually split out into this item tree:

image.png

Why does this solution work so well? Essentially, it has tons of synergy within multiple subsystems in the game:

  • Crafting isn’t exclusive to placeable items with larger recipes - it more quickly rewards you for using the resources you collected.
  • It requires being on a resource tile, supporting the use of the echolocation dashboard to maximize the exploration experience.
  • Longer collection times create tension against the energy levels going down as the player stays in the darkness for longer periods of time.
  • That “certain teased feature at the end” can leverage the mixed resources so that players are challenged to control and maximize what resources they collect through automated means.

This is the kind of design I strive for and hopefully it inspires you as well! More often than not, simply adding a feature won’t make a game better. It’s the smooth integration of a new feature into multiple subsystems that adds the most value. This doesn’t necessarily mean adding complexity to the game, but supporting the depth of choice and freedom within the gameplay.

image.png

With the main mechanic of item spawning in place, we can add some more “juice” into the collecting action. First, we add a new animation for the character that allows them to dig up items. The general approach is to have the character bend down, swing their arms, then lift back up. I’m quite proud of how this turned out since all of the art here is fully custom, just like the above resources. My pixel art skills are certainly still rough, but I am reaching a point where I enjoy experimenting with designs and going through numerous revisions. Let’s take a look at the animation strip!

image.png

Next up are some particles! Nothing too elaborate here - essentially picked the darkest color used in the basic tiles and had it explode out in all directions. The trickiest part here is timing the particles and allowing them to only run when needed. Right now, the particles are hidden until revealed, but at the cost of performance. In the future, I may opt for instancing in a saved particle sequence when needed so that it is not constantly in the node tree when not needed.

image.png

Finally, we add a GUI popup to designate how long it takes the player to dig up an item. These values are saved on the player so that future items or objects can influence how fast the player can dig. The GUI is fairly small and custom-made as well! To keep it consistent with other GUI elements, I did adapt the same palette as usual, found here.

The GUI popup in game is animated to grow from a certain point and then shrink once completed. With how small the GUI gets however, the tween function to shrink the element does a tiny flip and doesn’t cleanly exit the scene. I showed off this feature last week on my Reddit account - this is the point where I shamelessly plug it to be showered with love :)

Reddit: https://www.reddit.com/r/godot/comments/tfykaa/echolite_week_11_update_really_digging_this/

I received some wonderful feedback on this post examining the feature, and users felt the same way about the shrinking portion of the animation. With reflection, I decided to have it fade until reaching a zero alpha value, then having the node hidden as before. Here is the final product with the new GUI popup, particles, and character animation (excuse the ongoing particles - it's been added to the endless bug list/abyss):

via GIPHY

Comparing this to the Reddit post, that small improvement made a huge difference!


Saving/Loading

The game runs great, and it only runs once! I would imagine this makes the game less than ideal for players, in which some basic saving and loading functionality is needed. File saves will come at a later point, but for now some basic items can be saved in a specific Godot file format, aptly labeled “.save”

I'll admit, this portion of the week isn’t very flashy as saving and loading is more of a background process. The one interesting decision that I did have to weigh though is what level of saving should occur. I figured either:

  • Have automatic saving/loading
  • Require the player to save all the time
  • Partial saving (automatic but manual, somehow)

This decision I made fairly quickly - automatic saving/loading is my preferred choice. Having to remember to save a game and fearing that it doesn’t correctly save is something I always dread when playing other games. Knowing everything will save in advance takes away that concern so that the player can dedicate their attention towards having fun.


What’s Next?

The next 2 devlogs will be entirely dedicated to a huge new element of gameplay - machinery! As much fun as digging up items can be, it will likely get repetitive after a while. The next devlog will specifically look at preparing the artwork and setting up object placement. Essentially, just picture Factorio, but more “Echolite-ified” (totally a real word). From there, time will tell how spicy these machines become!

Thank you as always for the amazing support! <3