With these larger hurdles already tackled, it’s an exciting time to finally introduce two new resource-harvesting machines! Given the extra time, I was able to put more effort into their animations, which was a challenging yet rewarding experience for my non-artistic self.

Let’s check them out!

Suction Pump

I always wanted to have some kind of “pump” machine in the game, as I really felt the motion could bring some life to the environment. My approach to the design was quite different from other machines though, as I started with the animation first.

As shown above, I messed around with making a wireframe of the pump sequence. I envisioned a bellow-esque “squash,” kind of like an accordion. This would allow me to use identical plate sprites on top of one another for easier shaping later on.

The biggest challenge was making the actual squash. My initial version simply had horizontal lines moving up and down, one after another. While this collapsed and expanded appropriately, it didn’t really give a feeling of pressure by the time it was fully collapsed.

My solution was to move the corner sprites up a pixel initially, and then transition to a straight line a frame later. This provided a nice curve as seen in the wireframe.

To shape and color the final machine, I had to consider what resource tile this would match up with. The Suction Pump best suited this acid/sap tile in the second ring, so I opted for a more green/blue color palette.

This did spawn an interesting design option - as the machine is dealing with a liquid-esque tile, why couldn’t it also work on larger bodies such as the water pools and tar lakes?

I took out the legs in the original design and made it more rounded so it appears to float on the tile. This officially makes the Suction Pump the first machine to operate on multiple resource tiles, which allows it to feel more valuable to the player. Here is the final design as it appears in-game:

Robust Scraper

Sticking to the second ring, the other resource tile needing a machine is this interesting “dusty streaks” tile (unofficial name):

This required some extended thinking, as the tile has a similar premise to the debris/coarse tile in the first tile. For that tile, we developed a hatch drill which was breaking up the sediments. My first thought was to have a “smashing” machine that would pound the tile. This could still work for a future machine, but when trying it out in this tile, it didn’t feel very satisfying. I still have an initial draft of that idea as shown below, which would have been a multi-tiled sized machine:

I decided to change the central mechanism so that it still smashed down, but had teeth that would churn up the tile. It almost feels like a progression of the hatch drill while also feeling unique.

The animation is where it really shined however! The basic idea was to move down, rotate, and back up. This is still present in the final design as seen here:

Notice the beginning pause? Yeah, that was a mistake with the ordering and duplication of frames. I must admit it’s the best mistake I’ve ever made! As it turns out, I accidentally leaned into a common animation principle - I think it’s anticipation? As I’ve said, I’m not a professional artist, but that’s what makes this process even more exciting!

What’s Next?

New machines, wooooo! One thing that may have been on your mind though, is that we’ve seen resource gathering machines before. They are certainly a joy to create, but I’d like to push forward with machinery beyond collecting resources!

How do we push forward? With the help of conveyor belts AND mine carts! It might just be the next best thing after sliced bread (or fairly close at least).

Thank you as always for the support my fellow Sparks!

Let’s discuss!

Pro #1

Tutorials provide a visual component to learning game development that documentation and other written tutorials can not always capture. Seeing how another developer navigates the space of a game engine and explaining how tools can be leveraged can be incredibly useful at an early stage.

This will certainly show up on every other point too, but this pro can largely depend on the tutorial. Finding videos where code, assets, etc… are fully explained while being implemented are extremely beneficial. If you find yourself walking through a tutorial where the developer simply asks “to paste in this simple code,” consider typing it yourself and breaking down each line.

Seeing how each bit of code is structured or how assets are imported and tweaked will help build those habits. This makes it easier to move beyond tutorials at a later point because you have done more of the work on your end.

Pro #2

Tutorials provide a workable project that you can easily experiment with. This is super valuable because you can edit values or code directly and see how that changes across the game. You tend to learn more from this as you learn how each piece of the engine interconnects.

For those that are just beginning, I would highly suggest sticking with the tutorial and not copying the full project up front. After each video, take some time to experiment with the newly added features before moving on to the next lesson. As you add more features the complexity easily becomes overwhelming, so going more slowly between steps is easier to manage. It creates a nice moment of reflection to ensure you understand all of the newly working pieces of the game.

Pro #3

One issue I often see within game dev communities (and the technology field as a whole), is the struggle to ask the right questions. I see a lot of new developers who innocently ask for help with their project “not working” with no other details given. While many people are willing to help, asking vague questions about a project only seen by one person is not exactly easy to solve.

With tutorials, even though this trap is still possible to fall into, I have found that the comments tend to ask more direct questions. This is because the individuals following along are able to provide line numbers, exact errors, etc… that they know other users have already seen. When they receive detailed responses, it helps reinforce the idea that asking direct questions with detailed steps already taken and info provided yields better support.

Essentially, using tutorials can help shape the way you ask for assistance within the game dev community, making troubleshooting a less painful process.

Con #1

It is quite easy to fall into the “tutorial pit” - a place where developers spend more time searching for the perfect tutorial for their game instead of just working on it. Tutorials can provide an excellent launching point for learning game development, but the truth is that there is no tutorial out there that will create your game. If that were the case, it would already be made!

If you find yourself spending too much time searching for a tutorial, consider moving away from that for a bit of time. This is where you get to apply your new skills! Break down the feature or system you want to create into different steps and then search for guidance on the steps that are still confusing.

My best personal example of this was when I made conveyor belts for my game Echolite. There are some scattered videos about making conveyor belts in Godot, but they are not top-down, do not process items the same way, and are difficult to expand upon. At this point, I knew I had to build everything from scratch. I found that looking for smaller tutorials along the way, such as scene instancing, tweens, etc… both saved time and was more rewarding.

Con #2

Tutorials provide a working solution, but it may not be the best solution. This point comes down to time as smaller games do not need to be as optimized or compartmentalized. For medium to large scaled games however, tutorials are not equipped with setting up projects that can easily be managed long-term.

One way of navigating this issue is to spend time after completing a tutorial trying to change the approach while still getting the same result. There are so many ways to achieve the same goals with the numerous tools provided through game engines, so finding alternative solutions can help you grow accustomed to tackling complex problems differently.

This helps a ton when expanding your game as you have a more in-depth understanding of the inputs and outputs for each subsystem. The more comments you can add into your project as well, the better!

Con #3

Tutorials can set an unrealistic expectation for approaching game development. When you work through a tutorial, you aren’t seeing the many hours of planning, testing, etc… that went into it. This can create the illusion that developers simply open their engine, drop some pre-made assets, copy over some pre-existing code, and they are done. Maybe a developer out there can do this, and uh…the rest of us are jealous!

Part of the tutorial process should be considering how you would approach the system before you see how others do it. For instance, when attempting to build an inventory system, try writing out how you would approach it and then compare the differences. The tutorial may be a cleaner, more obvious solution, but it at least gives you a realistic idea of how game developers should approach problems before solutions.

TL;DR

Tutorials work best when you work alongside them. Rather than copying every single step, try attempting the problem beforehand. Then, as you learn more, continue to experiment and reflect so that the information you learn is critically consumed rather than blindly followed. Even though tutorials won’t build your entire game, they can serve as a strong launching point for becoming a smarter game developer.

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.

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.

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.

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.

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:

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.

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:

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!

Breaking this down though, we can quickly see how complex this can get. Let’s focus on just art for example (and this is coming from a relatively non-artistic dev).

• Physical
  • Choose the right materials
  • Have a solid understanding of durability, texture, color, etc…
  • Print, mold, etc… in a physical capacity
• Digital
  • Texturing/UV wrapping
  • Color palettes
  • Understanding different art styles
  • 2D, 2.5D, 3D
  • Modeling
  • Rendering
  • Animations/Rigging
  • Shaders
  • Asset pipelines
  • Forms of UI
• Other
  • Sketch/capture ideas
  • Prototyping/boxing
  • Concept work
  • Marketing materials
  • Adjusting shared assets based on use case

Already we have an extensive list, and there are so many topics I likely left out just because I haven’t encountered them yet. Then going beyond art, there are the many facets of design, programming, sound (ambience, music, sound effects), organization, marketing, effective debugging, documentation, designing custom tools, game packaging/deployment, and so much more!

The point is that in order to be a successful game developer, which is seen as a single job, you are effectively managing the talents of (dare I say) hundreds of jobs. It can be extremely overwhelming, especially when that perfect idea for a game requires nearly all of this knowledge.

This is where I want to offer some advice. Game development should not be a daunting task meant to scare people from creating their dream games. It should be a rewarding journey of learning and adapting your strengths to form games that are unique and special to you!

With this in mind, let’s look at some interesting mindsets you can adopt.

Embrace The Outfit Change

Wearing the same hat is usually the go-to move, but you do tend to appreciate it more when you wear other hats and then go back to your favorite one. Plus, it’s easier to not become tired of your outfits when you choose to mix it up each day.

Forgoing this extended analogy for a bit, game development can fall into a similar vein where continuing to focus on the same skills can easily lead to burnout. Personally, art takes longer to do because many of the techniques are unfamiliar, whereas programming is easier for me to approach. It’s still a challenge in both cases as all parts of game development can be a lengthy process, but motivation does tend to be tied to what skills you are most comfortable with.

This is why I suggest “embracing” the other hats of game development. Even though art is challenging for me, sometimes I find that taking a break from a complex coding scenario and just placing some pixels around in Aseprite helps refresh my mind. This is certainly a hidden luxury with game development that seems backwards at a first glance. We are able to set our own schedules, so use this to your advantage by rotating between the different demands of game development. You’ll likely find that you are able to focus better over extended periods of time and remain consistent with making updates to your game.

Know Your Favorite Hat

As much as it is important to mix up development, it’s certainly okay to lean more into your strengths! There are lots of games where the gameplay isn’t super streamlined, but it gets a lot of attention based on the visuals. Similarly, games may have “weaker” visuals, but the core gameplay loop is extremely engaging. Even though it’s good to build up the skills you are less comfortable with, part of the charm for your game can come from the strengths you have.

Essentially, it’s important to recognize that not every part of your game will be perfect. Of course, you want your game to be a smooth experience and extremely enjoyable, but the first goal is simply to release it! So when it comes down to time and there’s too many areas to address, consider falling back on your strengths to get the most out of your development cycle.

I strongly address sharing your games while in development for this point alone. As an indie game developer, it can be difficult to know which aspects of development are your strengths or weaknesses. Showing your progress to various people and allowing them to give feedback can help you recognize what you are naturally capable of.

Try On Other Hats

As a way of overcoming the many hats needed for game development, I suggest experimenting a bit with the areas you are unfamiliar with before implementing them into your game. One way I recommend doing this is by creating side projects within your preferred engine and messing around with what you are trying to learn. This allows you to avoid the complexities of your actual game and have a safer environment to practice in.

The neat part of this approach is that you can have a bunch of isolated example projects that you can reference at a later point when those skills are needed. This is partly why I recommend the Godot Engine because the node/scene system naturally creates modular components that you can easily adapt between projects. Most engines use this concept though, so you can’t go wrong with any of them!

A good place to start is searching up tutorials. The sad reality is that there aren’t exact tutorials for the game you are looking to build (otherwise, it would already be made). However, finding tutorials that focus more broadly on specific topics can help learn more efficiently. There’s no perfect route when it comes to tutorials, so you may as well just pick the first one that looks intriguing and then adjust from there. For instance, you may find a tutorial such as “Making Good Pixel Art” - it’s vague but it should help point you in the right direction. As you watch this video, terms such as shading, dithering, color palettes, etc… will come up that are completely foreign. This is where you can branch out into other tutorials that focus on those specific categories.

The central point here is that experimentation is a good approach to game development. I would argue that effective learning within this space is a separate skill on its own, but mastering it can greatly help you adjust to the many hats of game development.

TL;DR

Game development involves many skills that can quickly become overwhelming. Use this to your advantage by assessing your “game dev mood” for the day to determine what you should focus on. This helps give variety so that you become less bored with your projects (avoid burnout), and keeps the creative juices flowing. Don’t be afraid to experiment with new areas of game development and maintain a solid understanding of your strengths and weaknesses as you continue to learn!

Crafting Improvements

The existing crafting system has worked well so far, so in this case I do not see an immediate need for a “revamp.” However, there are some nice quality-of-life items I want to implement based on recent testing. With more items being created over time, the catalog of craftable items has exponentially grown. Even though the GUI is currently able to handle tons of items, the act of scrolling through an extended list of recipes really breaks immersion.

This has encouraged me to divide objects into various categories, such as machinery, advanced resources, furniture, etc… As with most devlogs, we start with the assets which I am quite proud of how they turned out! Here is the mockup of the updated interface:

In terms of the item data, this requires an easy JSON edit. Going through each item in the ItemData.json file, a new category attribute is added and populated. Finally, the magical code is added in to handle the switches between crafting tabs and refreshing the recipe section accordingly. Everything else still functions as expected. One interesting choice I made in the design was wrapping the crafting tabs in a visibility function that other items can call in the world. This means that a basic crafting bench could purposely only display the crafting GUI with the machinery section available. Here is just one example of the advanced reagents

So in planning out future content, we can now choose different crafting stations that either choose a specific crafting category to target or any mix of them as the player progresses. It’s a neat example of clever game development where I was able to work backwards by taking an arguably “overpowered” all-purpose crafting menu, and spreading out that power to better fit progression. This also gives another aim for players who may want a late game crafting station that can handle all types of items.

Beyond tabs, I also wanted to mess around with basic cursor text displays, most notably with the recipe requirements section while crafting. All of the resources are scaled down to fit the GUI, but this also makes it difficult to see exactly what items are needed. To help players out, I added a new text field that floats above the cursor. Any part of the game can call on a special cursor function to display or hide text. In this case, when the player hovers over a resource in the recipe requirements section, it will now show the name of the item! This will certainly be leveraged more with other subsystems, so I’m glad that it’s being added in now for easier development!

New Tent Interiors

Quality of life is great and all, but what about the world? The people? The things that make Echolite more immersive?

I have you covered! This week, the tents that have been sitting in the base camp during most of development finally receive some functionality! Adding interior to tents was a multi-step process, in which I’d like to highlight some of the notable achievements.

First, tent interiors require proper player “teleportation” to reach outside of the established world map. Only the first tent was being leveraged with the first NPC and crafting table for building those features, in which movement was hard-coded. To make this more dynamic, I added logic to the tents to locate which “interior” to connect with, alongside querying that space for the desired start point (i.e. the tent opening/entrance).

This naturally goes into the next bit of work, which is establishing how interiors are mapped out. Similar to the liquid pools (water, tar, magma, etc…) that are generated in the world, I decided to use a similar auto-tiling approach with tent flooring. To keep it extra open-ended, I made basic colored tiles and hand-crafted some layouts. The outer rings represent the boundaries, while the other tiles define the shape of the interior and the location of the entrance. Here is an example layout:

Going back to player movement then, when the player (out in the world) enters the front portion of a tent, it searches the specific layout mapped to that tent to find the entrance tile. This is turned into a vector point and set as the player’s new position. In advance as well, a flooring tilemap is used and auto-tiled to form the remainder of the tent. Here is that result:

These spaces are fairly empty though, leading to many hours of piecing together artwork for starter furniture. I may allow the player to craft these same items in the future, but for now they are solely decorative to fill each interior. Finally, the NPC’s are added into their respective spaces, such as the Librarian, Syvil!

What’s Next?

It’s only natural for a game like Echolite to include useable tools! Being in an underground environment with an open-world aesthetic, it simply makes sense. Additionally, we revisit how world generation loads, more specifically the waiting period beforehand and how a loading bar can spice up that experience!

Thank you again everyone for the amazing support!

“Why do none of my game dev posts go viral?”

My hope is that everyone can become more confident in the way they share their awesome indie game dev creations with the world!

The more I continue to post content about my own game, the more I’ve noticed the variety in likes, upvotes, etc… between posts. I would imagine that this is a common struggle for all kinds of indie game developers.

As a starting dev who’s pouring all their passion into their projects, seeing that fluctuation can certainly be disheartening. I think we tend to look at the data incorrectly though, or at least fail to see the bigger picture. We need to learn what our metrics actually represent and continue to show our creative visions to the world in confidence!

With this, let’s explore the following items:

1. Viral Is Just That, Viral
2. Visibility Is Key
3. Use Data As Feedback
4. Leverage Community Culture
5. Respect The Grind

Viral Is Just That, Viral

When starting out, we tend to set these grand expectations for how our game will appeal to the masses. It’s also easy to compare ourselves to other indie game developers who constantly trend with each post they make. What we fail to see here however, is how much time and energy they took just to reach a “baseline” of views.

Let’s say you have a YouTube channel, and you are getting one single view for a video while having 100 subscribers. For another channel, they may get 1000 views and be sitting at 100,000 subscribers! When you compare your single view to 1000 views, of course it’s going to be overwhelming. Overall though (assuming my math skills don’t fail me!), you’re still hitting the same ratio as that bigger channel. With consistency, you can just as easily hit the same amount of subs and views over an extended period of time.

In terms of going viral then, that same channel may have a viral video, but I doubt every single one of their videos is just as successful (unless they’re super good). You have the same chance of getting a viral video - the only factor is the number of attempts they’ve made. The more content you put out, the more likely it is that one of them will catch on with the masses.

Keep in mind that this does not mean quantity > quality. Instead, simply recognize that continuing to share your work will be rewarded over time. It’s just hard to see that in the beginning when those expectations are not instantly met.

Visibility Is Key

A lot of so-called “influencers” continue to flock to Tik Tok as the platform grows, and for good reason! The all-mighty “algorithm” tends to push content to more people initially. You could have a post with zero likes and still have 200+ views just from that initial push. If your post catches on and gathers additional views, then good job! If not, that’s totally okay too because that minimum number of views is still insanely good!

As a personal example, I have observed this behavior on the Echolite devlog posts I make on the Godot subreddit. Even though they only receive 1-20 upvotes, the number of people viewing each post is usually around 3,000! For reference, whenever I first post a devlog on this blog for Echolite, it will only get 1-10 views. After linking it as a side comment inside those Reddit posts to cross-promote, the blog posts suddenly skyrocket to 100-150 views.

The lesson here is to focus less on how many “clicks” your posts get, and instead focus on the visibility data. More people are likely seeing and interacting with your content than you likely realize!

Use Data As Feedback

When sharing your game dev journey, it’s important to use the performance data of each post you make in order to better inform future posts. For instance, one of my most commented posts on Reddit for Echolite involved a question. This kind of post naturally led people to share their own thoughts because it made them feel valued. In comparing this to my other posts which simply show off a feature, this kind of feedback should push me to use more question-sided narratives with my posts to boost engagement.

Even looking at what communities you post in and the frequency can help show which items resonate the most with your target audience. Consider this - why continue to do the same format for all of your posts if they continue to yield the same limited results? Perhaps the best way to break out of this zone is to mix up the usual formula you use! As long as you approach it in good faith, experimenting with how you share your journey will be positively received.

Leverage Community Culture

Every platform you engage with is completely different from one another. They all have their own established rules and cultures that users automatically expect from one another. Part of the reason why game dev posts can fail in these spaces is because they fail to match that culture. It’s worth taking the time to look at other game dev posts on your desired platform to see what performs best. Similarly, looking at the community guidelines for a site and looking at the language being used can help narrow down what content is preferred.

Through this review process, you can tailor your content to specific platforms. I can understand where this can be difficult on a creative front, as basing your marketing from the successful angles of others may not feel “unique.” The trick here is to not copy what others do - instead, be inspired by the posts that do go viral and add your own unique twists that still feel authentic to your own game.

Respect The Grind

One of the most common replies I have continued to receive across various platforms has been along the lines of, “Wow it’s week 28 and you are still going strong, nice!” Essentially, users will notice over time the frequency and quality of your game dev posts, which show how dedicated you are to your craft. Of course, make sure to take breaks as needed and understand your limits so you can avoid burnout. I do like this idea of “respecting the grind” though, as being consistent alone can already be rewarding in the long run. People may not engage strongly with your first post, but as they continue to see more they begin to connect with your journey more. It’s both a way of building credibility and allowing people to see how far your projects have come along so they feel like they are also a part of the creative process.

TL;DR

If your game dev posts on different platforms are not being engaged with as much as you expected, do not worry! Sharing your creative journey is always a slow process when starting out, but it does pick up the more you stick with it. Even if the likes/shares are not quite there, the views may tell a different story in the number of people you actually reach.

When it comes to strategies for boosting engagement - being consistent, mixing up your format, and matching community cultures can help improve your interactions with others. Don’t give up as we all have amazing, creative works that deserve to be seen!

Game Customization

What better way to build a game than to have players do it themselves? Everyone plays games differently, and while I would like to have an “intended” experience, there's going to be more engagement and replayability with multiple game options.

So, what are some of the basic options to include when creating new file saves? I got you!

• Character selector
• World generation seed
• Game difficulty

Using a simple background panel like other GUI elements, we can have a new page to hold these options like so:

In terms of the character selector, I only have the two original designs for now. While I did consider a character creator where you swap individual parts and colors, I still wanted to keep it a bit restricted. With a game that relies heavily on lighting, having too much character customization could jeopardize the experience. In future devlogs you’ll get to see more new character looks :)

In regard to the world seed, this goes back to the procedural generation we did several devlogs back. For testing purposes, a default string was used, but now the player will be able to enter their own! To make it easier as well, I added in a randomize button in case the player wants to jump into the game more quickly. My hope with this seed field is that players will be able to share cool world layouts they discover with one another.

The game difficulty is stored as a selected value, but as with most development items, this will come more into play with future gameplay elements. It does influence gameplay a little though already, mainly in how frequently resources generate in the world and how quickly the player’s energy bar drains.

While this work seems pretty straight-forward, it did require a bit more time than anticipated. Essentially, the saved values of a world are located in a filesave, but until it’s created, where do those initial customization values go? This prompted a rework of loading and saving in the game. Now, a “Save Connector” script is used as a manager of sorts. Values outside of gameplay like the game difficulty configure the correct pathing in the Save Connector, which is then referenced once the actual save is run. It’s a bit confusing because it crosses so many different parts of the game, but it’s certainly a lot cleaner now!

Splash Screen

This feature is something that is likely only exciting to me, but of course I still love sharing all the steps of development with all of you! Sparkful Studios as a concept has been floating around in my head for awhile, but after lots of planning and prep work, you finally got to see actual content at the beginning of this year (2022 for future readers). Now that half of the year has already passed (and super quickly at that!), it seems fitting to add in a splash screen as a way to reflect on the game's progress thus far.

Using one of my favorite nodes in Godot - the magical tween - I opted for some “snapping” and "fade" animations on both the logo and lettering. A splash screen wouldn’t be complete without a jingle though! The jingle itself is just a small amount of notes, but I think it nails the right tone. This sound did get cut out of the gif, but trust me, it's amazing! Here’s the final look:

What’s Next?

First, a good ‘ole thank you to everyone who has continued to follow Echolite’s development! I always love showing flashy content, so showing off a bit of the “boring” work can be difficult. It’s certainly necessary work though, plus it means that the game is nearing a playable state!

With that said, we are now stepping away from the main menu and diving into more of the actual gameplay! Crafting has become a major part of the game, and with so many new items coming up in future devlogs, some better management is needed for organizing recipes. Additionally, we will be going all the way back to one of the earliest developed pieces of the game - the tents! They look great on the outside, but what exactly could the insides hold?

The question then becomes - “is this new feature worth including in my game?”

In general, a feature will either:

1. Improve your game
2. Expand your game
3. Ruin your game

Let’s dive deeper!

Improve Your Game

A new feature will improve your game when it fills a gap in engagement that was previously present. One solid example is the game “Raft” by __. In this game, you need to hook in items floating in the ocean and build your raft to survive the harsh environment. It’s a simple concept, and many of the core mechanics are just that - core ones. When developing, they likely faced the question “is the ability to hook in items worth including in the game?”

Indeed, the player could simply pick up items directly, so a basic tool seems like an unnecessary inclusion. In a game where the player has a shark constantly circling their small raft though, the player is not afforded the luxury of picking up items further out. The hook item suddenly becomes a key feature to aid (and reward) the player for wanting to gather as many items as possible.

Expand Your Game

Continuing the examination of Raft, the idea of expanding your game is to provide depth, such as narrative or technical options. Many players desire a fishing mechanic in their game, and for a game where you are stranded at sea, fishing is a no-brainer. The catch here (pun intended) is that fishing does not introduce any subsystems that drastically change gameplay. When you fish, you collect new fish items that can be cooked for survival. It provides another option for gathering food and another way to relax within the game at the later stages.

Even with the rare treasures you can collect, they are mostly decorative and entertaining. This idea of expanding the game through fishing though is just as important as features that improve the game. It diversifies gameplay and enables players to make additional decisions on how they navigate the game. Whereas improving the game involves new systems to change the dynamics of the game, expanding the game seeks to stretch out the game in ways that better engage the player.

Essentially - to improve your game, you add new layers. To expand your game, you stretch those layers.

Ruin Your Game

Ruin is perhaps a strong word, but certain features do have the power to turn players away. I struggle to think of a good example through Raft, so I’ll turn to a different game - Minecraft.

A few updates back when the world generation was completely overhauled in a massive update, a new ore was added into the game…copper. For the record, I absolutely love Minecraft and when it comes to copper, I am super glad they added it for the decorative features it provides. When it comes to gameplay though, this ore is one of the most frequent ores that players will first encounter. The ore is used for decorative blocks, lightning rods, and a spyglass. I’m sure there are other uses I am forgetting in this instance as Mojang usually reuses items in future updates to extend gameplay.

However, in its current state, this early game material hardly “progresses” the game. It expands your color palette, protects you from lightning that could damage the house you are…only starting to build, and offers visibility that is…already possible through settings…

I’m skipping some of the finer details here, but I think the main point is clear. For a new player, this early-game resource doesn’t provide a step forward in gameplay. Not every item needs to do so, but to have it apply here is a bit conflicting.

The risk is that players may feel that their time was wasted on gathering copper since they expected it to extend gameplay beyond aesthetics or nifty little features. Copper absolutely needs to be in the game, but I would argue that its placement within the supposed progression path is not ideal.

When faced with a feature such as this example, I think there’s two options that come up. First, you can scrap the feature entirely. Second, you can change or move the feature in a way that better fits the natural tendencies of the player in approaching the game.

TL;DR

It’s worth saying that I don’t think there’s ever a “bad” idea in game development. Every idea has the potential to be good, given the time to either correctly implement it or change directions with it. With a positive mindset, you will confidently be able to determine the viability of every feature you dream up!

We don’t quite do the impossible work this time - instead, we do the necessary work. It’s the kind of work that isn’t as flashy or exciting, but for the sake of design transparency it’s worth showing. We need a way to launch this game, which means adding in a main menu!

Main Menu

When it comes to the main menu, one important item to include is the game’s title. Just in case the player forgets what game they have just launched or something…Truthfully though, making a logo for the game is an amazing milestone as a developer. If a game is considered a gift, then the logo is simply the bow on top - it represents all of the energy and passion that has gone into development!

So, how did I come up with an amazing logo? By working smarter, not harder! Given the player is a robot and machinery has a central focus, fitting in an industrial/steampunk look made the most sense. I took the time to search through dozens of fonts until I narrowed it down to one. Here is a link for those curious:

https://www.fontspace.com/geosteam-font-f24054

This is how the font appears initially as an example (default text, not the game's title):

I downloaded this font, scaled it up massively in a text editor and then typed out “Echolite.” From there, an image was exported and uploaded into my favorite pixel editor - Aseprite! Next was scaling down the image and reformatting lines to make the lettering more consistent. Then, basic coloring (using the GUI palette for additional consistency) was used to fill in each letter. Finally, some extra shading and detailing (such as pipes, screws, etc…) were layered on top to give it additional depth. Here is the final result!

Those small differences really transformed this logo into something special that matches the overall aesthetic of the game. In the future, I would love to animate some of the gears, screws, wheels, etc... to give it even more character.

Moving to the editor, we are focusing on basic functionality. I opted for a “warm black” styled canvas as the background for all of the GUI elements. The logo is placed along the top (centered) and given a very straightforward animation. The AnimationPlayer node was used to move the logo up and down (very slow so that it's still readable).

Finally, some buttons were needed to interact with the game. In staying consistent with other GUI elements, I looked to Buch’s Golden UI atlas for these designs. Luckily, buttons such as play and exit were already part of the atlas, so the only work on my end was adding outlines for the mouse hover states. Staying true to most games, the buttons are centered and lined up like so:

You may notice that I also added a small “message board” of sorts that displays a bunch of text to the left. This uses the same backdrop asset as our “quest options” panel (showing available quests for a NPC). The idea is that once the game reaches a complete build state, I will be able to note key items upfront to keep players updated, such as patch info and future plans.

The actual button functionality was not too difficult after working with them extensively in previous updates. The play button will navigate to the below section, while the exit button requires a built-in application close function in Godot. For settings, this will be handled much further down the line. Once keybinds, audio, etc… are in place, the settings page will naturally fall into place (both during game sessions and through the main menu).

Save Slots

Given the nature of the game with procedural generation, different progressions styles, building, and more, restricting gameplay to a single save is not ideal. This is where save slots come to the rescue! For the save slots, I wanted to have these features:

• Chosen character (animated)
• Time played
• Active quest

These elements should help differentiate save slots. I debated showing the active quest as the player could have multiple, but it still seemed worthwhile for providing a “snapshot” of current progression. In terms of art, a mix of existing character models, icon palettes, and GUI elements were combined to form this kind of panel:

Keeping the design simple, these save slots are laid out in a new scene with an identical background to the main menu. The logo is also added again near the top (in case you happen to forget the game’s name after reaching this page!).

Finally, a few options can be navigated through for selecting existing saves, deleting saves, and creating new saves. All of this simply uses common OS functions through Godot to create and edit directories. Each save is given its own folder for easy management, both as a developer to keep things organized and for players who like to backup their saves to be safe (highly recommend!).

What’s Next?

With the main menu and save slots in place, the core interface is starting to come together! Next up is adding a splash screen that plays before the main menu and implementing customization options for new save files. New characters? - Check. Custom world seed? - You bet! Difficulty options? - How could you not!?!

As always, thank you so much for your incredible support!

Keeping Loopholes In

Personally, I find the development process the most exciting when new ideas come up while implementing core features. You may suddenly think of a better approach to use, another way for systems to interconnect, or even a way to add more depth to a mechanic. The unexpected can be the special “sauce” that your game needs to feel complete.

Essentially, you want to keep loopholes present in your game when they open up additional gameplay options and enhance the player’s experience. A good example comes from one of my favorite games - Raft. As you float around the world, entering certain coordinates allows story-based islands to generate. These are meant to be linear in nature and grant items that help you progress at specific points in the story.

The “loophole” here is found in the loot that generates on the islands, as they can reappear whenever the player leaves a story island and then comes back. Narratively, this would not make sense as the player has already retrieved the items once. As a game developer I know this assumption skips many steps, but they could easily patch this out by tracking items picked up after leaving.

The developers purposely chose to leave loot respawning in place though, and there is a good chance that it came down to the gameplay value it adds:

• Players like collecting resources, so another method is enjoyable
• The exclusive items are more reliable to collect
• It opens up end-game content - players can now set up travel routes between story islands
• It gives replayability to story islands

I would not rule out the possibility that there was not enough time to address this loophole. However, once they saw how players responded by using the unintended feature to extend gameplay, there was likely less of a reason to address it.

Keeping Loopholes Out

Conversely, loopholes should be removed when they compromise the intended gameplay experience. If a loophole decreases engagement, then it is simply blocking what the player is trying to achieve in the game.

Imagine playing Super Mario Bros and a specific checkpoint accidentally turns the star ability into a permanent one. Certainly, the player will feel overpowered for a while, but as the element of challenge slips away they will quickly lose interest. It may even be fun for the entire gaming session, but when the player is trying to decide what to play the next day, there is a good chance they will pick up another game that still holds “mystery.” For a game that relies on the vulnerability of the character and the complexities of platforming, this loophole completely erases that intended experience.

There is a popular phrase within the development community that captures this sentiment perfectly - “It’s not a bug, it’s a feature.” At least in my experience, this phrase is used when a loophole appears and provides “valid” reasoning for avoiding the difficult task of making necessary changes. What that decision does however, is push the flaws of the game onto the player in order to explain why “it is not a big deal.”

Suddenly, that loophole causes the player to maintain two tasks. They need to progress through the game while also subconsciously finding ways to explain why a bug still fits. Even if they can look past it, you can begin to see how loopholes can compromise gameplay experiences by breaking immersion.

What About Time Constraints?

Game development is a dedicated process requiring tons of resources, time, motivation, energy, and more. When considering what loopholes to keep or remove from your game, you may also wonder if you have the time for it. Indeed, this can influence what decision you make! This is where the famous “minimum viable product” idea found on every indie game dev thread comes into play. Understanding where your game reaches a “1.0 version” or “pre-alpha state” provides an important threshold.

If you are just starting development, then you are more inclined to keep loopholes in. The goal is to spend the majority of your time achieving the baseline of your game. Unless they prove to be game-breaking, loopholes are oversights in design that are best addressed during the “polishing” stages of development. The best case scenario here is that leaving in loopholes will open up new design opportunities later in development that might not have been considered otherwise. Worst case scenario - you at least achieve a minimum viable product within a reasonable time and can afford to address it.

By the time you near the end of development, this is where you are more inclined to remove loopholes. With a nearly complete game, you are able to carry out testing far easier and have a better idea of how the indented gameplayer experience has translated over time. Essentially, you will have a stronger approach on how best to remove or change loopholes as compared to earlier development stages.

TL;DR

When faced with a loophole - i.e an “unintended gameplay feature” - it is worth considering if it should remain in-game or have it patched out. The best approach is to consider if the loophole adds value to the game without affecting the player’s intended experience. Beyond this, consider what stage of development you are in as a way of making a more informed decision.

Planning

Since the beginning of the game’s development, the idea of having a ring-esque world design was always planned. This design will hopefully bring a unique gameplay experience that creates an interesting dynamic between the player and the world. Here are just some of the items that this new world design should accomplish:

• The player can travel in any direction - it’s a pseudo open world design without being overly complex. If one particular area is not ideal, then they can always travel in a different direction.
• The player is naturally challenged to travel further and further. When starting, they may only be able to go a few spaces out before retreating back to the light. This encourages progression in order to see how far they can go. It’s kind of a roguelite setup while still allowing for the world to be shaped by the player.
• It makes it easier as a game designer to stretch out progression without being severely limited.

With each ring, the distance traveled to reach the next outer ring should increase. For the first ring, the tile distance should range about 50 tiles. It’s enough to feel complete and challenging without being too large as we still want the player to progress in reasonable time. For the second ring then, the tile distance should extend roughly 100 tiles. This is twice as large as the first ring, encouraging the player to use new resources and objects beyond their established strategies. From there, I plan to make the third/final ring about 200 tiles out. By that point, the player will be able to enter the late stages of the game and expand their operations as needed.

Remaining Setup

Between the rings, there should be a few tiles that clearly show the division. At a later point, a bridge-esque object will be added into the game that the player can use to travel to new rings. The design is super basic as it should stick out to the player as a sort of “boundary” object:

Plain, unexpected, and hard to see? Awesome, that was the goal!

With this “void tile” created, the only item left beyond importing the assets into the editor is creating a moveable camera scene. The camera currently follows the player, meaning that all of the new world generation will only be viewable as the player moves around. For testing purposes, we need a new camera that can be navigated with the mouse in order to have a better idea of how the world is formed. Rather than reinvent the wheel for a feature that is only used for testing, I referenced the following tutorial:

https://www.youtube.com/watch?v=6CfhXBdhE2s

A little magic here and there….and….there we go! A controllable camera!

New World Generation (Finally!)

As with everything in Godot, all features simply become a bunch of nodes and scenes. For this new world generation, a new scene is created with several tilemaps in one. While every potential tile could be piled into one tilemap, I have found the current editor to be a little clunky when making edits. If I need to make changes to a certain tile in the future, I would prefer to only deal with tilemaps that have 1-9 tiles total. That way, if one of the tiles is incorrectly numbered or does not align properly, I can avoid touching the entire generation system. Here is a top level view of this MapGenerator scene containing all of the tilemaps:

You may notice that the void tilemap has two entries - one with collision and one without. This does not come into play initially for world generation, but will be relevant when bridge pieces are made later on. Essentially, a unique workaround is being used to turn collisions off and on as doing this on specific tiles in a single tilemap becomes a bit tricky to manage. A similar workaround will be used on the other “liquid” tiles as well - just ignore the collision/no-collision for now though!

With these tilemaps in place, we can focus on the core logic of generation. The first thought is always to go through each tile separately and determine what type it should be in one “sweep.” This is difficult to code however, in which I chose to split out tile types by function and work through a list of “generation sweeps.”

First, we need to generate a filled-in circle of basic tiles. Until we set up an interface for the player to create a seed, a default value is needed. This seed is leveraged to determine which basic tiles are selected so that the generation is more interesting. As part of this step, a perlin noise map is used to create “blotches” throughout the map. Based on a certain radius distance, a certain liquid tilemap is referenced to fill in that blotch. This ensures that only certain kinds of lakes or pools show up within each ring. Here is the first sweep result:

From this point, features are added to this terrain, meaning that tiles need to be removed before new ones are added (to avoid stacked tiles). This is achieved through a basic function that is given a tile coord and then removes any potential tiles there from every tilemap.

Using this function, we can loop back through the entire map to set up void rings. Similar to using radius values to determine what liquid tile types should be placed, we use radius min and max values for each void ring.

Next up is adding in the resource and rock formation tiles. These functions leverage both the seed value and radius values to determine tile type and place them in a randomized fashion throughout the map. By this point, the base world generation is nearly complete.

One small touch to add is clearing out a small rectangular region near the center. Having a random river running through the front of tents and blocking the player would not be an ideal gameplay experience. This uses another function to replace all of the tiles near the center with a plain basic tile. The terrain could certainly use more “spice” since it’s the main area, but for now we’ll keep it blank.

Final Touches

The new world generation is incredible! At the same time, it feels a bit static. Some motion and visual flairs are needed to make this world feel more alive to the player. Since the resource tiles are a core part of gameplay that the player is constantly seeking out, they are the prime candidates for adding some new visual elements.

We already did this a bit with the sparkshroom tiles that glow in the world. Interestingly enough, that glow element is actually tied to the seed now. This gives it a more random “spark” vibe to it rather than a glow that consistently fades in and out.

For now, we can check out visual improvements to three other resource tiles (one per ring). Starting with the ore tile, this classic look features crystal-esque objects within a small crevice. To make these more appealing, a shine effect can be applied like so:

This is achieved by applying a white pixel with a reduced alpha value over 2-3 pixels in the top left corner. From there, that line moves across the crystals until reaching the opposite corner. In terms of applying this effect to the world, we can establish a timer that continually picks out random tiles in the tilemap to overlay the effect.

Next up is the “Sporebell” resource tile. Yup, there is more vegetation beyond Sparkshrooms! This tile is found throughout the second ring and as the name implies, it shoots out spores/puffs periodically. Instead of an animated tile, we can use particle effects to create the spores. For the design of the particle, the “head” of the Sporebell blossom is rotated, slightly recolored, and then painted with the blur tool. It creates this neat transparent effect that fades more evenly outside of individually changing alpha values on each pixel. In Godot, this particle is set up to float upwards in a curved motion. I would like to improve the effect more such as adding more horizontal “swing,” but this should do the trick for now!

Finally, we have the “geyser” resource tile. The name is still pending as it doesn’t quite capture the intended effect, but this tile should have air/steam quickly blowing out. This is also done with a particle effect, in which most of the magic comes from the particle settings rather than the design of the particle. We can actually leverage 3 particles at once and then configure different lifetime values. While all of the particles will go slightly up, this setting only allows some of the particles to go higher up. This creates both a fading effect near the top and a forceful burst from the ground. Here is the final result:

To keep things mysterious, the remaining tiles will be shown off in more detail at a later point. Hopefully you enjoyed seeing this massive update!

What’s Next?

The core gameplay experience is really coming together - it’s exciting, atmospheric, and engaging! To achieve a functional build state though, one crucial piece remains….a main menu! The next few devlogs will focus on this work, attempting to mix in some other neat elements to keep it interesting :)

Thank you as always for your support! If you are enjoying these updates, please consider liking and sharing this post. The more visibility and feedback this game gets, the better the final product will be!

The first solution could be improved graphics like what we see in modern AAA titles. By adding those strikingly realistic models and environments, the line between worlds easily dissolves. This improvement has occurred for decades though in the industry, as seeing better graphics has become more of an expectation than a method of innovating the magic circle experience.

The next solution could be found in new gaming technologies such as VR/AR. Placing the player into the world through spatial means causes us to easily get lost in the magic circle. It is even more fitting that you can look in all directions in these games, granted it is more of a magic sphere, but the idea still stands! The issue though is that not every game can (or should) translate into VR/AR. It is a new tool for developers to explore and has opened up some incredible opportunities, essentially an entirely new art form. It should not be needed for every game to expand on the magic circle.

This leaves us with a final solution - digging into the “meta” magic circle. Picture it as a magic circle within another magic circle (circle-ception). One solid example is “Stardew Valley,” where the player takes on the role of a farmer and develops relationships with the town’s inhabitants. In this case, the first magic circle that you, the human, enter is a foreign countryside land realistically made by pixels and ripe for exploration. We enter this magic circle by controlling the character with physical devices and interacting with the in-game world, which is largely a one-way communication.

A meta magic circle approach then, aims to create smaller magic circles within a larger one. In Stardew Valley, the player can opt to play mini-games inside a community tavern through arcade machines. Here, the fictional character enters its own magic circle within that fictional universe. This creates a level of abstraction where the character can dip in and out of the smaller magic circles to give additional depth to the world. At the real-world level, our physical controls not only move around the environment now, but also seamlessly work to transition between in-game moments. In other words, we the player are the ones who decide what inner magic circles the in-game character enters.

Having games within a game is not the only option though, especially as it has been present in dozens of games over the decades. Another option is to make worlds feel more “lived in” by the characters. This leans into the topic of believable NPCs as many of these characters appear to exist around the player. It is difficult to make them feel like they have their own lives and agendas. To achieve a meta magic circle, we would not just assign schedules to NPCs. Inside each random list of tasks there would be a multitude of ways that the environment changes. Note that these changes are not initiated by the player since that is already a core part of gameplay.

Going back to the tavern example, we could have NPCs that place cups and furniture in different parts of the tavern. Then, based on where items are there the next day, the owner of the tavern has a new list of potential actions caused by other NPCs. When the player finally enters the tavern again, both them AND the in-game character have meta realizations that something has changed.

Indeed, this adds a ton of complexity for developers because it presents dozens of states to account for over time. The changes can be small though. Maybe when a player enters an NPCs house at different times of the day, various dishes, bedsheets, etc… have moved around. The player gets to enjoy additional depth to gameplay, and the in-game character finds themselves in a world that does not necessarily revolve around them. None of these concepts are necessarily new, but I think they are important to consider if we want to continue pushing the boundaries of game development.

TL;DR

Games offer an escape by allowing us to extend what is possible within our own world through the abilities, emotions, and experiences of digital worlds. To take this further as developers, we can consider how the ties between our physical actions allow our in-game characters to escape into their own worlds. Our characters can have feelings too and we have the potential to shape how they view their digital worlds through our own actions!

Proper Lighting

Back in the 4th devlog, some custom lighting was created that could be placed over the larger base camp and Sparkshroom tiles. The idea here was to have a flexible lighting solution that I could apply on different objects that would impact the player’s energy level. For a time, this feature worked well with the limited testing done. With some random tilemap placement however, I found that overlapping light sources did not behave as intended.

This was one of those cases where the design did not cleanly adjust to future changes. Essentially, I assumed that the player’s energy levels would be tied to entering and exiting the area bounds of every light source. It was a simple boolean toggle that would allow the energy bar to either increase or decrease. The overlapping light regions that could potentially generate in the future though would toggle too many times and quickly reverse the behavior. When the player exited a light source, suddenly their energy level would increase and now the game was in a parallel realm where light needed to be avoided. While that could be a cool concept, it is definitely not what this game is built on.

It took me a while to realize what was happening until I recalled similar occurrences in real life. For rooms that have 2 or more light switches, all of them are simply a toggle for the lights. Let’s say that a room is unlit, and we have one light switch near the door and another one against the back wall. I flip the door switch up to light the room and then walk to the back of the room and flick the switch to turn the lights off again. When I return to the door switch and wish to turn the lights back on, now the switch behaves inversely. The door switch has to be flipped down to perform the same lighting action for the room.

If you are doing some face palms right now, I would not blame you! It is one of those things that we all know but hardly ever think about too closely. As indie game developers, we are inspired by real life events to create our games. I think a similar approach can be used for troubleshooting and testing our games as well.

With that, the custom lighting scene was redone to account for this oversight. My solution was to use an array that would contain all of the lighting sources that the player is currently standing in. Whenever they enter or exit any light area, this array is simply updated to either add or remove a listed lighting source. From there, the logic for affecting the energy level of the player is applied only to the individual array. Now, the player has to be removed from all lighting sources in order for the energy level to start dropping.

Oh, and it gets even better! With every lighting source being tracked, this opens up the possibility of energy levels changing at different rates based on how the player interacts with the world. Plus, this fixed some visual issues with the energy bar (which was caused by inconsistent lighting logic from before).

New World Elements

The world of Echolite is supposed to be barren and desolate. On paper, this is a fun aesthetic to work with since the element of the blank and unknown naturally creates a bond with the NPCs in order to not feel lonely. In game though, this means an uninteresting world to explore. If the most detailed area is the main base camp of the nomads, then the player will quickly lose interest in the world around them.

This is where creativity gets to run wild! The plan is to have the world designed in “rings,” so each ring should feel connected but also varied. Here is how we can achieve that visually:

• Add “pools” such as water the player has to navigate around
• Add rock formations that initially serve as obstacles
• New resource tiles

Liquid Tiles

Given that we will have three rings that center around the base camp, the “liquid tiles” will need to form in patches. If we left water as a single tile, then it would not feel different from all of the other nearby resource tiles. To achieve a patch look then, we need to construct an autotile map where the edges of the path will neatly fit together.

I highly recommend the following resource from KidsCanCode that shows how to arrange tilemaps so that all of the possible borders are accounted for: https://kidscancode.org/godot_recipes/2d/autotile_intro/

With this example, I first started with the general outline using the same color palette as the other basic tiles. The general approach was to maintain a distance of 1-4 pixels from the edge of a tile to form the border. Then, instead of straight lines, I moved up and down and placed 1-4 pixels in a line before switching rows again. This helped make the terrain appear more varied and natural without overthinking the design. Here is the initial frame:

The more I do my own artwork, the more encouraged I feel to take risks with the design. This is why I added a lined look around the border to add a slight bit of depth. I also figured that once the tiles are placed in-game, this unique pattern will stand out next to the player under their own light source. The other tiles will have even more elaborate designs!

On a separate layer, I drafted out the look of the actual water. This involved working through one color at a time and filling in the gaps as necessary. I tried to create patterns in what colors followed one another without being too repetitive. Once I had a single tile drafted out, I duplicated it to form a larger sheet and then layered the bordering on top. Ta-da!

Water does not always remain still however, in which I created multiple frames. This was simply achieved by moving the underlying layer of water back and forth in a diagonal fashion. By slowing the movement down, this effect looks quite relaxing.

In terms of seeing this animation plus the other liquid tiles, I will save those for a later reveal - onto the next visual!

Rock Formations

This part was perhaps my favorite artistic challenge yet! In sticking with the same 5 colors as the basic tiles, I wanted to find a way to create several different rock formations that could be scattered around the world. Since the colors remain the same, the actual shaping of each rock needed to be unique in some way.

Here is the very first rock formation I designed:

The design approach was fairly standard. I used a single color to form a shape (random blobs essentially). Then, the other colors were added as shading to help add depth. With new found confidence in this first design, I went wild with many more designs!

This leads me to a brief discussion on the use of both these rock formations and the liquid tiles. While they do not serve a functional purpose yet, my plan for them is to use them as additional resource points in the later stages of the game. Let’s say that the player has traveled far enough to reach the second ring. With the new materials they have collected, now they can build a special machine that collects from the water or rocks. This gives additional gameplay value to the initial area of the world and helps make the player’s progress feel even more important. It’s a light teaser, but also a good reminder that I aim to make every addition to the game multi-purposed so that the world feels more complex and engaging.

New Resource Tiles

So far, we have only seen the first three resource tiles of the game which all exist in the “first ring.” Now, we get an exclusive look at some of the other resource tiles! If you recall back to the 2nd devlog, we had a discussion about the “types” of resource tiles we wanted. Essentially, there should be some variety between the more stoney/shiny elements and the general vegetation/life. The idea here is that anything can be considered a resource in this world.

Here is the result!

While these are always subject to changes, I think they do an excellent job of capturing the vibe of each ring. With the world generation, many of these resource tiles will have animations of particle effects to make them stand out further. The more motion we can add into the world outside of the player, the more the player will want to explore.

What’s Next?

Usually this section is more of a surprise, but given the 50+ mentions of the upcoming world generation, I bet you can guess what is coming next! I will say that the game is coming together more and more everyday. With several references to past devlogs and changes to existing systems, the game is slowly transitioning from the “core features” phase into the “add new side systems and content.”

While it will be quite a bit longer until any sort of alpha stage is reached, this time is just as valuable for gathering critical early feedback. Definitely let me know what you think either in the comments below or through any of the other social platforms (socials tab)

Thank you as always for your support!

With this, we need to have a couple methods for balancing our games that we can rotate between.

Let’s begin!

Make the character overpowered

This idea is prompted from personal experiences with MMO’s. As they tend to retain player bases for many years and require constant updates of new content, they often struggle with balancing. The conventional method of “leveling up” is exciting when going from 1 to 20, but after several years when you have max levels nearing 200 under that same scale, it’s overwhelming. It also becomes challenging to create more interesting encounters in PvE and PvP, where players know exactly how to defeat enemies.

It appears that a bit more forward thinking would help balancing from the start. Essentially, I recommend during playtesting to make everything super powerful and wild. Perhaps the player can collect 100 resources at a time, have endless ammo, or do 15 jumps in rapid succession while midair. The goal is to see how crazy your mechanics can get, and then scale back down from there. You want to find the point in which the player feels powerful without jeopardizing the core experience of the game.

With this baseline established, you can now break up the “maximum power” of your character to scale with the game. This also helps with adding content - if you have an equipable item that gives stats nearing the overpowered threshold, then you can better determine rarity or adjust the values accordingly. Additionally, this prompts the idea of “resets” where the player may retain certain abilities but restart their rank (in order to level again further).

Mix and match certain abilities

This method may not apply for all games, but it aims for flexibility where possible to easily make changes.You want to run the most problematic scenarios where the game is unbalanced, and then randomly cut out certain elements. By using trial and error, you can narrow down which specific aspects of your game lead to an unbalanced experience.

The interesting part of this method is that you may discover items that actually need to be improved. Through different combinations, certain items will stand out that are not having as much impact. By making those items stronger, the unbalanced elements will start to feel more fair for the player.

Gather feedback from others

While we can continue to make changes and re-balance our own games, there will always be inherent bias as developers. We have certain expectations for how players will navigate games and our testing often focuses on those intended experiences. Even if your game feels balanced, players will likely adopt different play styles that will open up problematic solutions.

The best example in this case is online card games. Developers intentionally release new cards that they expect players to synergize into their own decks. Their testing may be extensive (even utilizing the previous methods), but with the number of cards increasing there will naturally be combinations left untouched. This is why card games require continued updates past release to tweak card stats and abilities. Assuming your playerbase is greater than 1, as an indie game developer your audience will exponentially provide more data behind the state of your game.

This is where the method branches off by genre. If your game is able to track this data and aggregate it elsewhere, you will be able to see the real-time information and plan out the necessary changes. If you are unable to gather this live data, then you will want to rely on communication channels with your playerbase to see how they feel. I would recommend a poll with several different options available. This allows every user to contribute and feel like they have an impact on the game. Not every piece of feedback may apply (time constraint, intentional mechanic, etc…), so lean more into the feedback where a majority of players responded similarly.

TL;DR

• Trying to balance a game is challenging, especially with your initial rounds of development, so do not be discouraged if it does not resolve the first time!
• Approaching it from different angles and giving yourself time to analyze both personal and audience feedback will go a long way. Experiment with other methods as well outside of the above points.
• The best way to set yourself up for success is to design your games in a flexible way so that you can more easily make adjustments and run through multiple tests.

Thank you so much for your support!

Finalizing Quests

With the last devlog, we set up basic quest details that allowed the character to select available quests based on several variables. These are all triggered by NPC interactions which helped bring some much needed life into the otherwise barren world. One crucial feature was purposely left out though…actually completing the quests!

There are a few items to consider with a questing system. First, we have to understand the types of quests that the player can complete. We should offer multiple types in order to add variety to the player’s experience. Collecting a few geodes may be exciting at first, but after a few dozen times it becomes a grind that many players are not willing to commit to long-term.

So, what kinds of quests are planned?

• Collect - Fairly standard, but collecting can also be performed by machinery so less grindy. Plus, it does not rely on combat since that feature is not planned for the game.
• Talk - The player needs to talk to specific NPCs in order to progress. A lot of the magic here will boil down to the quality of the dialogue, but for now we will focus on the logic.
• Discovery - We can highlight a specific location on the map with an Area2D that will auto update a “locations visited” attribute on the character. The player will need to reach that location before reporting back.
• Statistics - This will fit into the achievements system since statistics will need to be maintained in order to trigger certain statistics. We can use those same numbers for the more unique quest "events" outside of the other three that are more standard and restrictive in design.

It is worth noting that these titles are moreso for internal reference - to the player, quests will not have a specific label. The dialogue will provide unique context around specific quests without being overly direct about the type of quests the player is completing.

My personal favorite is “statistics” as it enables a more flexible way of writing quests. Rather than focusing on a specific number of actions, quest completion can be tied to external events in the world or specific character relationships. It brings a more immersive experience while still allowing the player to feel in control.

As these types of quests will look at different systems in order to evaluate quest completion, they need to be labeled on the data side. This means updating our questing JSON from last devlog with special tags like "Talk" or "Collect":

Since we already have the file open, we may as well add in the other necessary details. Based on the quest type, we can supply other fields needed to evaluate the status of a quest. For example, if we are collecting resources, we should specify what types of resources and how much:

The second consideration for a questing system is how to reward a player, especially in how those rewards scale with the player. This is where a lot of our early planning for the interactions in this game come into play! We can step a bit outside standard game design (at least to my limited knowledge) and scale quest rewards differently.

In many of the games I have enjoyed, quests will start off with small rewards, such as “25 experience points.” When reaching the late stages of the game however, this number quickly skyrockets to the millions with no realistic end in sight. One way to solve this is with rankings, but that only addresses the actual number from going up and not necessarily making it easier for the designer to plan out quests.

For Echolite, we can bring a closer relationship between quests, dialogue, and ultimately the NPCs we interact with. As a new robot, the nomads have no existing connections in which their rewards will be small (as expected). The more the player interacts with the NPCs though, the more likely they are to give better rewards.

In terms of the logic, we can have different statistics for each NPC that act as multipliers to the various rewards a player can receive. This allows things like “items given” and “experience earned” to properly scale without setting larger values for every quest. It also gives more weight to the player’s decisions during gameplay as they are in charge of what rewards are most valuable.

To keep things simple, a few attributes have been added to NPCs. They do not apply those multipliers to rewards yet, but the data is being saved for future implementation. A proper “relations” GUI will be built down the line and the rest of my TED Talk will appear in that update :)

As a teaser, here is what those stat symbols look like:

You can see those discussions from the “All Things Machines Part 2” devlog applied here. For GUI elements that are moreso icons than backdrops, we have our own 4 color palette to use. This provides a nice level of consistency that helps make the experience feel more complete.

Dialogue System

So, how does the player improve relations with NPCs? That is the fun part - dialogue choices! We return to our quest JSON and add in some new sub-dialogue elements. These entries will detail four “responses” the player can choose from alongside which attributes are impacted. We utilize tags like “SUB” and “ADD” to help signify how the statistics will update, but the player will not be aware of these items until they are chosen. This encourages the player to consider what dynamics should be built with each NPC, especially as they hold different values and perspectives about the world.

For our dialogue system, we can code it nicely into the quest options logic from the last devlog. When the player approaches an NPC, it will first evaluate any quests that apply to them. If any actions are needed, they will proceed to do so before showing any potential new quests. The NPC may need to finish a quest with the player or even resolve mid-dialogue as part of an ongoing quest chain.

We can’t just add a giant system like this without some more artwork though! Credit to Buch once again for his amazing Golden UI assets - like previous works, I have taken elements of his Golden UI atlases and stitched together some new ones. I really like how this dialogue interface turned out:

For animations, a few small effects will add some major “oomph” to the experience. If that isn’t a real word…well, it should be! With the text, the usual dialogue reveal motion should work. Godot offers a nice property for text along the lines of “percent visible.” Using some tween magic, the dialogue is revealed over a set period of time. It is a super simple effect but it adds so much in convincing the player that the NPC is actually talking.

Another effect is the blinking/moving “clicker.” There really should be an official term for this in the game dev world if there isn’t already. Essentially, an indicator will appear in the corner of the dialogue panel that rotates and bobs up and down to tell the player to click. I could have used a tween for this as well, but branching out into different nodes is always good for learning. The AnimationPlayer proved to be useful in adding both effects at once.

Finally, a little popup should be leveraged near the experience bar and dialogue panel for when game elements are changed like experience or NPC stats. Here is a (somewhat buggy but proud) gif of these effects in action:

And finally, here is how the dialogue choices are presented to the player:

What’s Next?

While NPCs need a lot more love in the future, it’s time to branch out further with the game! Our eyes are set on some new, exciting world generation. The next devlog will provide the prep work for this massive change before diving into the bulk of the work. This includes lighting revamps and new terrain elements.

Once again, thank you so much for the incredible support! If you are enjoying these devlogs, please consider adding some reactions and sharing it around your own communities :)

This is indeed one of those questions where the answer is “it depends.” Many factors will influence your answer, such as comfort level with development, what you aim to achieve with your game, established skill sets, and so on. In this dialogue, I’m going to give some pointers to help determine how far out into unfamiliar genres you should branch out. At the very least, it does not hurt to try!

Here are some steps you can walk through to help make an informed decision:

1. Ask Why You Want to Lean Into a New Genre
2. Play The Top Titles In New Spaces
3. Determine Which Aspects Stick Out to You
4. Experiment Through Tutorials

Let's begin!

Ask Why You Want to Lean Into a New Genre

There are dozens of reasons for mixing up the type of game you want to develop. I would assume it narrows down to any of the following cases:

• You want a fresh development experience from what you’ve done before.
• You believe it’s a more niche genre where your game is more likely to succeed.
• You want to expand your knowledge with game development.
• Your ideas (perhaps inspired by other games in the genre) will best fit in a new style.

All of these are valid points - I would not argue against any of them as they all have positive intentions. What separates them though is the stage of development you are likely at. If you are making your first game, for the sake of staying motivated and having clarity in your design, it may be best to stick with the genres you love. There are popular titles in all game genres, so you shouldn’t worry about picking the “wrong” genre.

When indie game devs talk about avoiding certain genres or styles, such as “pixel art, 2d, top down RPG,” they are often noting that the market can feel oversaturated with those types of games. While this is correct, it shouldn’t steer you away from making a game in that space. The oversaturated market means there are more people who will potentially find interest in your game. Additionally, you have more reference points for making ideal design decisions when developing your first game. So for those who are wanting to explore an unfamiliar genre because of the external pressures surrounding familiar ones, perhaps return to those original ideas you have.

If you otherwise feel comfortable with your current game dev skills and are looking for that fresh experience with a new genre, I say at least give it a try. The other points coming up support this direction, but at this time you can recognize that trying out new genres can be a rewarding experience. It may just be temporary as you find certain genres are just outside of your preferences. Overall though, looking to change things up and expand your knowledge will provide benefits in the long run.

Play The Top Titles In New Spaces

No matter the situation, if you’re still unsure on if you should develop in unfamiliar genres, the next best step would simply be to play games of that type!

In playing through the popular games, you may just find that your idea either best fits or contradicts the key elements of that genre. You will have a better understanding of what makes that genre “tick” and if that given “tick” is something you can work off of. Another neat part of this step is that you may have fresh ideas for how to approach the genre. There may be a certain mechanic that is overused or hasn’t been mixed up across the popular games. Having an “outsider” approach in this case will appeal fairly well to the target audience (assuming the core mechanics are not dropped).

Determine Which Aspects Stick Out to You

If you’re still undecided, then evaluate what parts of the above gaming process stuck out to you the most. The answer may be that developing in an unfamiliar genre is too foreign at that time, but there are elements you want to pull. For example, you may not enjoy the grindy aspect of RPG’s, but the side-mechanic of cooking as part of crafting could work in another genre you love.

When you cross these elements across genres, you’re more likely to hit a unique game loop that players unexpectedly fall in love with. It’s also a bonus that audiences from different gaming backgrounds will connect with your game. Even just incorporating one or two elements from another genre will help bridge relationships with audiences you otherwise may have missed.

The one pro tip here is to not mash random game systems together - they need to make sense in the context of gameplay.

Experiment Through Tutorials

Personally, my ideas come up best during development, as I’m seeing systems come together and they are continually tested. This may also be the case for you, in which I would recommend following a tutorial or two under a different genre to see what clicks. Even if you decide early on that a new genre would be perfect for your game idea, I still recommend going through some initial tutorials. The development process always differs from how you picture your game.

Going through tutorials in new genres are a strong indicator on if it’s worth the time invested to branch out. Especially for circumstances where a game needs to be released in a timely manner, going through drastic development differences like from 2D to 3D may interrupt that goal.

TL;DR

As you’ve seen, the decision to branch out into unfamiliar genres for game development is not an easy one to make. Your overarching goals, timelines, and skill sets will influence this decision, among other factors, but it’s certainly worth considering throughout your indie game dev career. The following items we reviewed will help you in weighing the pros and cons, but I trust you’ll make a great game regardless!

Initial Planning

NPCs should add some much needed life into the world, but the challenge is making them believable to the player. Similar to how we added resources, machines, and more, we tried to find ways to make them complex. This complexity should not represent difficulty though. Instead, complexity means that there is a certain amount of depth that supports multiple playstyles.

For NPCs, this means that both their personalities and functions should be multifaceted. It is better to have a limited number of NPCs with several interactions in the world than a large number that only serve a single purpose. Here are the ways we can achieve that:

• NPCs have more than one job/function
• NPCs move around the world
• NPCs allow the player to choose how they respond
• NPCs change the environment over time
• NPCs have established relations with one another outside the player’s view

Some of these items (such as AI movement) will come later since this will require other features to be implemented first. With multiple functions, we can center this around our initial NPC designs.

NPC Designs

Thankfully, I did not have to look too far for some guidance with character creations! Thanks to Buch, who you may recognize from previous devlogs in inspiring the game’s UI, they have also designed various character portraits. This is the original state for reference:

These colors are quite vibrant however, in which a recolor is needed. The idea here is that similar to the UI being an “inner” HUD of the robot/player, the character portraits would be renderings of the people he interacts with. Given this logic, the characters can be reskinned using the UI color palette and then setting it behind gray backgrounds to help stand out. Here is the complete look (minus some characters not being used as they were not needed in-game):

Free starter assets can only get you so far though! I need to continue working on my art skills whenever possible, and floating character portraits in the world are not quite “believable.” With these portraits, I went through many failed attempts before nailing the desired look within the world. It likely still needs a lot of work, but here is how they look so far!

What helped the most in designing these figures was sticking to a basic colored outline of the head, torso, arms, and legs. This provided an easy model to try out different looks while keeping the figures consistent and scaled correctly in the world. Perhaps my favorite phrase (all indie game devs can relate), but in terms of animations, that will come later!

Quest Options

With NPCs in the world, we can finally dive into questing! We will tackle the initial setup here, and then (spoilers!), we will finish it in the next devlog. Questing is rather straightforward as many games approach it the same way. While we could deviate from standard design, staying true to certain proven subsystems is likely the route to take in this case. Essentially, we want the following to happen:

1. Player approaches an NPC
2. Within a certain radius, they can interact
3. The NPC searches through available quests
4. If any are found, pull them up in a panel to be selected

One small thing has been overlooked though…gasp....we haven’t added any quests! Like all other data in the game, we can create a QuestData JSON file. Here is how some of the starting data is structured for what we need right now:

Finally, we can get into the actual logic. Offering 100s of quests all at once to the player would be overwhelming so we need a few factors in place that determine when a quest can be selected. As usual, another fancy list (in no particular order)!

• Pre-req quest completed?
• Correct player level?
• Talking to the right NPC?
• Is the quest already selected?
• Is the quest already completed?

For player levels, we can set some basic numbers for testing until questing is completed, as that will reward XP to level up. For checking the status of each quest, this will be handled by the one and only…arrays! If a quest is already completed, then there is no reason to display it again. If a previous quest that is required however shows up in this completed array, then that should allow us to continue. Furthermore, if a quest is already an active quest, then we can simply ignore it. This is regardless of its status, since active quests could have just been picked up or are ready to be completed by the NPC. For now, we leave a fun little comment in the code to add this next time.

The minimal GUI artwork here is not too wild compared to previous work, so you can just enjoy the magic now! Just excuse the placeholder location - a proper housing update will come :D

What’s Next?

The momentum thus far with questing will continue into the next devlog. When the player selects a quest, they will finally be able to complete it! This does mean that multiple different quest types will be added in order to provide some variety in the gameplay. The NPCs have also been rather quiet - that will change soon through a formal dialogue system.

As always, thank you for the support! <3

If we want to identify what works well in a game during the earlier stages of development, then we need to figure out how to playtest an idea. It sounds silly because an idea is intangible - something we can never physically navigate or directly hand to testers. With testing being a critical part of feedback though, the challenge is worth pursuing so that we can make the most informed game design choices before investing more time and energy.

So, how can we playtest an idea? This is where we bust out a fun list, a “top x ways…” list, if you will! Here they are:

1. Scenario-Building
2. Listen Outside The Box
3. Make It Physical
4. Rotate Ideas

Let’s dive in!

Scenario Building

This strategy involves the famous question that every game developer loves to ask - “what if?” We inherently love to ask this question because it gives us a way to expand ideas while still keeping them connected. For playtesting then, we shape this question to better understand the nuanced behaviors of our ideas. Let’s say that we pitch an idea for a size-based inventory system where an inventory holds a certain number of slots and different items will take up a different amount of slots. To playtest we may ask…

• What if the player wants to swap the placement of items with different sizes?
• What if the player is continually left with a single empty slot?
• What if the player wants to organize items based on size?
• What if an NPC wants to give the player an item?

These questions continue until every situation has been exhaustively identified. You will never anticipate every scenario unfortunately until the idea is brought to life, but many of those design headaches can be caught upfront. If the questions are somewhat answered, then your idea is likely solid and just needs some refinement. Conversely, if all the questions are left with no easy solution, then a completely new idea may be needed.

Listen Outside The Box

Leading off the previous strategy, there is no way to identify every potential scenario. As individuals, we have limited insight into the pros and cons of our ideas. It is easy to get attached to them initially and ignore some of the underlying flaws. To help avoid this, we can turn to other people for feedback. Ideally, these are people who are not close to you and are not necessarily full-fledged game designers. Finding online forums such as Reddit to gather feedback is a great way to meet these kinds of people.

In a concise, organized manner, lay out the idea to these people whether it is the central premise of the game or a specific subsystem/feature. A great way to get people to respond is to present ideas as a choice. Continuing the inventory example, you could propose two ideas, such as a sized-based inventory system versus a weight-based one. By phrasing it as “which idea do you prefer,” you will find that people are naturally inclined to respond because they feel their choice is the best one. It gives direction for how people can respond and allows you to narrow down ideas.

Make It Physical

Nope, this does not mean go straight into prototyping or full-fledged coding! Instead, we want to add physicality to our ideas and arrange them to see how they are interconnected. One great way to do this is to put ideas on separate Post-It notes and place them on the wall. Ideas that are closely related should be grouped together. Then, as you discuss how each idea relates to one another, you can move them around the wall. This allows you to see if any connections between ideas are impacted by new ones.

For example, we may have a bunch of ideas surrounding a statistics system. Then, we introduce separate ideas for quests that rely on tracked data as well as an achievement system. By laying them out physically, we can see how both the questing and the achievement subsystems both rely on a strong statistics system. In this, we can reevaluate how the statistics system can be set up to handle operations with multiple parts of the game at once.

Rotate Ideas

Similar to the physical strategy, we can also use substitution as a way of playtesting ideas. When coming up with an idea, start making small variations to it and saving those as separate ideas. Then, when trying to sequentially line up different systems that all interact with one another, start swapping ideas with each small variation to see which one fits best. Here is an example:

In this example, we would have different ideas for rewarding the player:

• Display above character’s head
• Float towards player (magnet)
• Straight to hotbar
• Drag over from pop-up single slot inventory

All of these involve earning rewards, but they feature different ways of accomplishing that same task. We can walk through this specific case and rotate between the various “middle” ideas to see which path is the most engaging.

TL;DR

Playtesting does not have to be reserved until the game is fully developed! Experiment with playtesting your initial ideas to iron out potential problems and nail down the vision for your game before drawing a single piece of artwork or typing a single line of code. Your future self will thank you!

Planning

Features are only worth including in a game if they add value in multiple ways. Crafting gives a use to resources, but that action alone is not engaging unless some of the resources it produces provide depth to gameplay. Having machines generate resources is a step in the right direction, but it’s not as engaging as it could be. When I set out to add factory-building to this game, I wanted it to feel fresh and different. Factorio and Satisfactory lead the factory-building genre with much of their gameplay revolving around automation and optimization. It's geared towards a niche audience (myself included), so we need to think of ways of expanding factory building to players who aren’t necessarily committed to the “numbers” side of these games.

Part of this challenge will naturally be solved by the roguelite element of going into the darkness and back. This will bring more importance to machines, since they allow the player to “make a mark” in the world and collect resources without having to risk their life every time. As a bit of a tease too, we will eventually add objects like conveyor belts so the player can have resources come towards them without venturing out.

The other part of this challenge can be solved by something “custom” - upgrades! We can allow the player to sink additional resources into their placed machines in order to change how they operate. This is a solid approach for a variety of reasons:

1. It gives general gameplay more value. Instead of placing a machine and calling it a day, the player is now given several choices that allow them to form their own gameplay styles. The players mentioned above who still wish to automate and optimize can do so by maxing out machines and messing around with different configurations. Conversely, players can just place a machine, maybe pick one or two upgrades, and still progress perfectly fine without ever touching it again.
2. It gives resources more value. The player can choose to put resources into basic crafting or into existing machines. Essentially, they get to lean into whichever option they feel will help them progress faster.
3. It gives crafting more value. When a player creates machinery, they are investing a few resources for an item that offers tons of customization. It is like creating several objects and merging them all into one.
4. It gives placement more value. If a player wants to have multiple copies of machines with different configurations, they can choose to arrange/group them in the world based on their primary function.

So, you may ask…what kind of upgrades are there? Here ya go!

• Loot Tables - Each tier in this category offers a new set of potential resources that can be generated by the machine. For example, you can try to go for a more “focused” tier that reliably offers a few different average resources or a “wider” tier that could potentially offer the worst or best resources.
• Fast production - Each tier in this category decreases the amount of time it takes the machine to generate a resource.
• Increased production - Each tier in this category can raise the number of resources generated at once by the machine.
• Auto-Upgrade - Each tier in this category will present a list of resources that, if generated by the machine, will automatically become an improved version. For example, if the machine is about to generate “Emerald Shards,” it may turn those into “Refined Emeralds.”

Already you can begin to see how these upgrades intersect. The player may choose a loot table tier that offers tons of different resources, then stack an auto-upgrade tier to turn the worst potential resources into better ones. Some players may choose to focus entirely on one upgrade category while others will rely on a mix of them.

Perhaps the best part of this “upgrade” mechanic is that it continually makes early game objects relevant. The player may need rare resources in the late-game in order to reach the highest possible upgrade options on basic machines. Or, the player can earn rare resources through better upgrades that allow them to create end-game objects. Even as the player ventures further out into the world, the earlier work they accomplished never feels wasted. They won’t need to discard/swap machines for newer ones and can instead focus on improving their existing machines to better fit new goals.

Data Prep

Similar to other aspects of the game, these upgrades offer established options. Due to this exact data, we can store it in additional JSONs and then reference them as needed. With how large these upgrade categories could become with multiple tiers for each machine, separating them out into separate JSONs is likely the safest option. As an example, here is how the loot table JSON appears:

I think it is valuable to note why I chose to use JSONs in my game. Initially, I was hard-coding my data into scripts because I wanted everything to be “in-editor.” You can imagine the frustration later on as the project grew with numerous moving pieces. It became more difficult to find the spots where changes needed to be made, making the entire process of testing an absolute nightmare. By switching to JSONs, all of the upfront information used in the game is finally organized in one place and easy to manage. This is likely not a novel concept for most developers out there, but it is worth rehashing for the beginners like me out there!

Tying It All Together!

Now that the data is organized, we can dig into the visual aspects of working with machines. First, we need some assets that denote available resources with machines. Cue the “it’s not much, but it’s honest work” meme:

The timer that sits above a machine will simply use text, so luckily no custom artwork is needed there.

Moving to the upgrade categories, we need icons that help represent what that upgrade does. This means a list icon for loot tables, arrows for increased production, and so on. Here is how the icons turned out:

The specific color palette used is rather interesting. You may recognize its prior use in “filling” the resource collection bar that appears above the player when they dig for resources. After using these four colors, it made me consider the use of consistent coloring for icons and other “minor” aspects of GUI panels. We already have a set color palette for the world/environment and larger GUI elements, so another consistent palette for items like icons and indicators is incredibly valuable. Expect to see more of it show up in future features!

Finally, we can design the actual upgrade interface. The nice aspect of this interface is that it merges a lot of the tools we have already created in the past. We are essentially crafting, but this time the output is an unlocked tier instead of an item. Based on which upgrade category is selected, the related tiers will show up on the second page. This allows the player to supply the necessary resources in order to “unlock” and set a certain tier. Here is the final result:

While some components like the description field, unused upgrade slots, etc... will need some additional work to wrap up this upgrade feature, the current progress should suffice for now. I would love to hear what you all think!

What’s Next?

Adding basic machines into the game these last 2 devlogs has been an exciting endeavor, and while there are certainly more ways to expand it further, it is time to forge ahead with more core features! Litebot is rather lonely in the world and luckily there are some survivors living in the base camp that he can interact with. They may also have some special quests to offer…

Thank you as always for the support!

Some of these ideas may seem obvious, while others may feel new - in either regard, I hope this article can reignite your spark of creativity for your games.

Here is a formal list of the 10 items that I follow as a means for staying motivated:

1. Motivation Is Fleeting, Drive Is Not
2. Mix Up The Work You Do Each Day
3. Take More Creative Liberties
4. Stay Accountable Through Communities
5. Be Inspired By Other Game Devs
6. Document Your Progress
7. Play Other Games
8. Make Your Goals Physical
9. Adopt The Growth Mindset
10. Don't Guilt Yourself!

Let's dive deeper!

Motivation Is Fleeting, Drive Is Not

Using "motivation" is a bit misleading, in that it only really captures the feeling you have towards your game. Everyone is excited about their game, even when they don't feel like working on it. In this case, you're always motivated for your game. The real struggle is the "drive" that stems from motivation.

Drive is habitual - it's the ability to continue working on your game no matter the circumstance, because you have specific goals you want to achieve. It shouldn't be unnecessary pressure, but a simple commitment you make to yourself each day to work towards your objectives.

Start with something small each day - if all you do is make a square in MS Paint, import it into your project and call it "Placeholder NPC," then that's already good enough! Every small action you do each day brings you closer to your goal, and it's better than a base of 0% progress. These small actions quickly add up over time until you've suddenly made massive progress on your game.

Just commit to a small amount of development to your game each day, and evaluate from there on if you can commit additional time.

Mix Up The Work You Do Each Day

Game development requires numerous jobs - engine based toggles, scripting, scene setting, environments, music, sound bites, modeling, artwork, texturing, fonts, marketing, level design, brainstorming, testing, etc…

The list could go on forever, because there's just so many different skills that game development requires. Use this to your benefit as a way of continuing to work on your game each day. You may randomly wake up in a "coding" mood and suddenly realize how to fix dozens of bugs. Other days, you don't feel like touching the actual game, and would rather work on community-building and promotion.

Use these feelings as an opportunity to mix duties up every day, and it won't always feel like a chore. I've often found that walking away from a certain aspect of game design for a few days will re-energize my thoughts later on, which enables greater creativity.

Indie game dev affords a luxury that many people dream of - YOU decide what you get to work on each day, and how much effort you put in - use this to your advantage to vary the daily grind!

Take More Creative Liberties

Creativity is what fuels game development, and that simple reminder can help re-fuel your motivation. If a certain aspect of development has become tiring and frustrating, take the time to step back and evaluate the "why" behind what you're trying to achieve.

One example is with my inventory system, specific to dedicated chests in my world that could store items. I spent ages trying to set up item limits for stacked items in chests, and being able to evaluate groups of similar items. At a certain point, I asked myself why this constraint was even necessary. I had only applied it because the mechanic was wide-spread in the genre, but my own experience with it was often annoyance. I decided to drop it and allow any quantity of items to be stored, and this worked wonders! Players during testing have appreciated this small detail, and have

In the end, I was able to cut development time and create a more elegant solution that players enjoyed. It wasn't the original design in mind, but in an effort to stay motivated, taking those creative risks was exactly the confidence boost I needed.

Taking the time to be more creative and open to changes with elements of your game is a direct way to overcome roadblocks that can otherwise tank motivation.

Stay Accountable Through Communities

What's interesting about this point is that I stumbled across it unintentionally. As I've continued learning more about game development, I have been able to connect with tons of amazing individuals through platforms like Discord.

Beyond the help that indie game devs afford one another, there's also a level of accountability that comes up. In tracking the progress of other games, I've found those people to be extremely honest about how their development has progressed or stalled. This leads to rounds of encouragement that is always appreciated.

Development can be lonely, but it doesn't have to be! All developers have similar end goals, so it only makes sense to connect with one another and foster a community of positivity that desires the best for everyone.

Use indie game dev communities as a mechanism of accountability - it's a great way to push yourself in the right direction again when the motivation fades.

Be Inspired By Other Game Devs

In a similar vein to staying accountable, viewing the work of other indie game devs can greatly help with the creativity behind motivation. This is more dependent on how you operate, as some may find a struggle in comparing their works to others. I've found it to be inspirational, where seeing the neat projects other devs are working on pushes me to continue working in order to show off my own progress.

Seeing how other developers approach similar challenges to you can also help reshape how you approach problems. You may find that your own design may need to be reworked, or that the mechanic you thought was crucial to add to your game did not have the same payoff as expected.

I especially recommend watching indie game devlogs, where creators share not only the progress they've made, but the time and effort it takes each day to reach their goals. The player will only see the final product, but other devs can appreciate the amount of time it takes to produce a polished game.

Do not be intimidated by other indie game devs - allow their journeys to be a motivator in order to continue working on your own game.

Document Your Progress

Perfectly connected to devlogs as an example, findings ways to concretely document the progress you make is a great motivator. It's easy to forget just how much work you've already accomplished when there's still a lot to do. I've enjoyed documenting progress through Discord, in that I take the time to write up what I achieved after a few weeks, what lessons I have learned if any, and what I aim to do the next time.

Documenting progress has all of these benefits:

1. Builds up marketing skills by communicating in an effective, engaging tone
2. Provides a solid source of work completed at an overview level to help break down remaining work
3. Excites both players and yourself about changes and new features

It doesn't need to be elaborate - simply logging different types of progress during development wraps up the work in a more satisfying way that keeps you motivated for the next bit of necessary work.

Play Other Games

We make games because we love games! We shouldn't stop playing games just because we start to make them. It's like a musician no longer playing their instrument while trying to compose music - it's doable, but why restrict yourself in that way?

Playing other games is a way to relax from the stresses of development, and also becomes a small reminder of what features make games enjoyable for us. I would also encourage you to branch out into new genres, especially if the genre you are developing is identical to the games you enjoy playing regularly. Using elements of different genres is a great way to mix up your game, and brings a renewed look at design during development.

Don't push yourself to develop 24/7 - Continue to spend time playing games that you enjoy to build motivation for your own game.

Make Your Goals Physical

Whether you're looking to make the next AAA game, simply entertain others, or even just make lots of money, we all have greater goals as part of the indie game dev dream. I would encourage you to write out your larger goals, and place it where you can see it every single day. Maybe that's above your desk, on your fridge, or next to your bed - wherever you know it will be visible.

Having this physical reminder of the goals you wish to attain through game dev helps keep the bigger picture in focus. Yes, you still want all of your smaller, manageable goals lined out for daily work, but it helps to keep your larger-than-life objectives at the back of your mind too.

You may feel motivation slipping when the minor details are confusing, in which a physical, visual reminder of your goals will allow you the space needed to not get too caught up in the daily grind.

Adopt The Growth Mindset

If you've heard about the "Growth" mindset before, I don't blame you for rolling your eyes, as I have a similar reaction as well. Despite its cheesy approach though, I think some elements are certainly worth adopting.

Essentially, the "Growth" mindset details that you're never done learning, and that everything you do should be for the right reasons (ex: get good grades because you want to do your best, not because the pressure is there to). If anything, this represents the strong desire needed to achieve goals, and the acceptance that not everything will always work out like you intended.

For game dev, this especially comes into play when you're either lost on the direction of your game or development becomes stalled due to complexities. The aim here is to change your mindset from "this failure means the game won't be as good" to "I needed to fail in order to succeed."

If motivation is faltering because you feel your skills are lacking or that the game is too ambitious, try to channel this energy into productivity. Instead of thinking of how to get over the roadblock, think of how you can go around it.

When you change how you view "failure," you'll realize you never truly "fail" - you have just taken a unique path to fully understanding the vision for your game.

Don't Guilt Yourself!

I conclude with this point to help relieve any pressure you may feel from indie game development. It's completely okay if you feel lost or confused on the different aspects of development. There's no single right answer for how to approach game development. If there was, then every game would be exactly the same.

Pushing yourself to constantly develop when you're not in the mood will only lower your motivation further. You may finish your game in incredible time, but I doubt it will match the vision you had for it as closely as you desired.

Take the time you need to step away from your game - We all need space for our creative processes to re-adjust, and there's no reason to deny that from yourself.

TL;DR

Motivation is not something you can easily nail overnight. It is a renewed commitment each day to continue working on your projects to the best of your ability. You have a great game to make and we all look forward to seeing it - push through (without jeopardizing your well-being) and it WILL be worth it!