A Change of Focus

I have decided to discontinue posting to this blog.  My game development stride is not diminishing.  In fact, it has been increasing of late. I am simply prioritizing my time. This blog does not get much traffic, especially compared with my YouTube channel.  It doesn't make sense to me to expense the effort of blogging updates and videos, especially when they are usually similar in content.  I will leave this blog up for posterity.  Perhaps when my game is closer to release or even post-release, I may pick this back up.  I feel like focusing on game development and providing YouTube updates is a much better use of my time. I also realize that blogs are not nearly as popular as they were 10 or 20 years ago.  Such is the day we live in.

If you would like to keep up with the development of my game and/or are interested in my Godot video content, I invite you to consider subscribing to my YouTube Channel.  Thank you for being here.  I appreciate every second of your time.

Bound2bCoding's YouTube Channel

Until Next Time,

I'm Bound2bCoding

Random Thoughts on Making this Game, Software Development, and Happiness!

Almost daily, I am pushing new code to my Git repository.  I thought it might be a good idea for posterity and for curiosity-sake to share some of my Git push descriptions of late.  Here are the ones from this year thus far.

3/14/2024 Added world time system.
3/12/2024 Setup objectSelector, FloraPlaceholder and GroundPile with proper Area2D and Collision Shapes to properly handle click events on world objects.
3/12/2024 Changed selector to toggle via button and click to report tile info (inwork),
3/10/2024 Fixed ObjectSelector not showing.  Fixed GroundPile spawn bug.
3/10/2024 Added Container Proximity code and modified inventory engine to set world x and y position for containers.
3/9/2024  Completed initial implementation of commands.  Added OpenContainerCommand.
3/9/2024  Added 8-position player templates.
3/6/2024  Changed tilesets to 64x64 with a subdued background.  No more overlapping tiles.
3/3/2024  Removed old flora.  Refactored fixed view to 5-step, zoom-sensitive view where view size adjusts based on zoom factor of the camera.
3/1/2024  Changed tile selector sprite.  Limited visibility to 1 tile around player.  Added radius helper method.
2/29/2024 Fixed Y map position issue by using even number due to screen resolution not dividing evenly by 64.
2/28/2024 Fixed positioning of tile selector and player to proper positions based on tile location.
2/26/2024 Renamed InventoryWindowManager to just WindowManager
2/25/2024 Added pocket watch window. Updated hand craft window.
2/23/2024 Added Alpha journals to journal sections.
2/22/2024 Cleaned up mini map zoom, refactored mini map zone colors.  Fixed inconsistent zoom ratio.
2/21/2024 Switched Minimap to round compass design with zoom camera and fixed window size.
2/20/2024 Removed some tree types and  removed the Deciduous forest, leaving Mixed and Coniferous.  Mixed up the tile definition values to create more distinct zones.
2/18/2024 Refactored image references in journal.  Added ability to open/close map via context bar.  Added open/close tween and sounds to map.
2/18/2024 Updated Journal to support image loading referenced directly in the json files using custom markup to identify embedded image references.
2/17/2024 Added Journal features:  animated open/close, sound effects, open close from context bar, JSON data files.
2/14/2024 Added beginnings of the Journal feature
2/11/2024 Added a parchment background to the mini map.  Cleaned up some minimap code.
2/11/2024 Added drag and scale to MiniMap.
2/10/2024 Added Fog to mini-map.  Added toggle for fog setting.
2/10/2024 Some minor refactoring to water tile zones
2/10/2024 Implemented all water styles.  Adjusted Perlin params to produce larger areas.  Adjusted map colors.
2/8/2024  Refactored Water Zones to an instance dictionary.  Added Water Zone Names txt file to store names.
2/6/2024  Optimizations to Water Zone code
2/5/2024  Added water zones, zone names, definitions and water tile data.
2/3/2024  Added scrolling panel minimap
2/1/2024  Implemented water animations using 21 sprite solution.  Added Cottonwood trees, except winter.
1/28/2024 Implemented 5 tier water material shader with water depth based on perlin noise.
1/27/2024 Implemented UI Progress bar.
1/27/2024 Added ability to zoom with middle mouse button.  Cleaned up Accoutrements drag and drop rules.
1/21/2024 Updates to water shader.  Added create ground pile and access from accoutrements window.  Updates to drag and drop for accoutrements
1/19/2024 Implemented Player Inventory Window with standard Window options
1/17/2024 Implemented Inventory UI Category restrictions.  Fixed some bugs with drag and drop.
1/6/2024  Refactored Inventory Categories and fixed issue where mouse indicated illegal drop when categories are restricted and item floats over original source slot.
1/1/2024  Added more clothes and Hudson Bay items.
 

I want to highlight a few things you might have noticed and some not-so-obvious inferences.  Some days involved multiple pushes. Sometimes, an idea gets implemented and then a few days later gets totally yanked from the code and replaced with something else.  It is common to get on a roll and code for days.  But it is also common to have dry spells where nothing seems to work right or go right.  Refactoring (which means changing code or the way a feature is implemented) is par for the course.  Git push descriptions usually start with a verb (Added, Implemented, Refactored, etc.). And notice the frequency of my pushes and the fact that this is just a hobby project!

Last November, I signed up on Reddit so I could monitor the r/Godot, r/IndeGameDevelopment, and r/gamedev threads and others to see, to learn, and to follow along.  It is amazing to see just how many people ask about this thing called Game Development and Software Engineering in general.  Some of the questions and statements are comical, while others are steeped in frustration and fear. Let me just say, software development is not for everyone.  Making software requires dedication beyond belief.  It also requires a certain level of inner-desire to create coupled with the discipline needed to put creativity to use.  I log 40 hours a week at work as a software engineer.  At home, I probably put 25-30 hours a week into this hobby.  Most of us do not have that kind of time to burn, and that's OK.  We all have different lives to live and responsibilities to shoulder.  Fortunately for me, my wife and I are empty-nesters and she encourages me to "unwind" with some good-old game development relaxation, which I am "Bound2" do.  My point in all this is that if you are one of the many who dream about making a game, your attitude and opinion about what constitutes SUCCESS and FAILURE will determine both.  Success is not making the top 10 list on Steam.  It is not making so much money that you can quit your day job and live off your game.  It isn't how many wish-list your game or follow your YoutTube channel, or read your blog!  Success is being happy and content with who you are and what you do with this life you have been given.  For me, as a Christian, success is knowing God and His Son as my Saviour and Lord, and enjoying the many blessings He has given me.  For me, as a life-long gamer and software developer of almost two decades, success is enjoying my job and my hobby.  As a husband, father, and grandpa, it is loving my family and enjoying every moment with them that I can.  What I am trying to say is that fame and fortune can never fill the heart with peace, joy, and happiness.  SUCCESS is found in the heart, not the wallet.  Keep things in perspective.  Do what you do because you love to do it, not because material things are your motivation.  Make your game because YOU want to play it and don't fret if others do not.  If it never makes it "on the shelf" as we use to say but you had fun and learned something and are happy, you have reached success! Having that mindset will make you feel satisfaction and contentment in ways money cannot.  OK, I will stop preaching.

What kind of game am I striving to make?  Simply put, I want to make something different, difficult, educational, old-school, rogue-lite-ish (is that a word?), and fun.  I want to make a survival simulation that challenges the player to survive the brutal realities of life in the Rocky Mountains in the 1820's as a trapper, a prospector, a pioneer, a homesteader, or whatever path the player chooses to trod.  Running into a grizzly (griz) while hunting on foot will likely turn your character into a carnivorous meal.  Hunting buffalo might get you trampled.  Getting your powder wet swimming a river might well turn your expensive flintlock musket into a temporary club.  Failure to purchase enough lead to mold musket balls for the whole year could be very regrettable.  Eating the wrong kind of mushroom, plants, or herbs might make you sick.  Failing to tend to a bite, puncture, or broken bone might lead to gangrene, amputation, or death.  Making friends or enemies with local tribes might wind up saving your character or losing it. Learning to produce peltries to trade at the annual Rendevous (the gathering of mountain men, friendly natives, and Fur companies) will either give you enough for the next year's necessities or leave you struggling even more to live another year. Finding a place to build a cabin and a homestead might establish you as one of the famous mountaineers or leave behind a memory of a life short-lived.  These are the kinds of experiences I want to capture with this game.

The game won't be a fast-paced, hack-n-slash where so many particle effects drown the character from view.  There will be no magic, no Elves, no Trolls, no Dwarves.  Unlimited inventory is unthinkable. Inventory will consist of the characters's accoutrements (clothing, accessories, and whatever else the character can reasonably carry).  Skills will require honing by experience.  The player's character is not larger than life and is not the hero. A player will not finish the game until he decides to stop playing the character or the character dies.  The game's flora, fauna, and NPC's will be historically influenced.  The only exception will possibly be a very rare encounter with "the huge hairy people of the forest," i.e. Bigfoot.

Time will be consumed when the player does something and be paused when the player is not doing something.  Timers will be very short but may consume large chunks of the game's clock.  For example, a player's character might chop down a tree in 2-3 real-life seconds.  But that action might consume 3 hours of the game day.  Sleeping at night will be an instant sleep-wake-up action that moves the clock forward by how many hours the player wants to sleep or the character must sleep.  Time management will be crucial to survival.  Situations will dictate priorities.  Food and drink will be more than just a nuisance.  Several potential starting scenarios are planned.  Decisions made at the start of the game will have meaningful impact on the player's experience.  There are no trading posts early in the game.  The player's character might be filthy but not rich.  The player must make what is needed, or trade with natives, or hold out until the annual Rendevous to trade with the Fur companies providing goods from the East, or simply do without.  The Rendevous will be instanced locations only available once a year - ready or not.  The historical information from each real-life Rendevous will have significance in the game.  They will eventually end and be replaced by trading posts, just as they were in history. If the player wants to know what time it is, he had better procure a watch.  The journal he keeps will be invaluable and readily available -- if he remembers to pack it in his character's shirt or saddlebag before setting out.  Ground-hitching a mule or horse will probably keep it from running off in the night, unless it is stolen.

I could go on and on about my plans.  But now, all this writing has me itching to code something, so I will stop here.  I hope this post ignites some interest in this hobby project of mine.

Until next time, I'm

Bound2bCoding 

Using Zoom to Control View Size

Zoom-based View Sizing

On the heels of a lot of UI work, I took a step back to re-think the camera zoom features.  Those of you who are following this blog (thanks a million!) already know that I am not currently chunking my tilemap tiles.  Every movement of the player forces a refresh of the tilemap based on a set viewport size.  For example, if the view size is set to 25x18y, a tilemap "view" is created virtually instantly showing all of the (25x18=450) tiles in the view minus a few tiles on the outside edges which are just out of view but able to load the flora and other objects so they appear to enter the view as if they are always there.  Each movement wipes the entire tilemap and redraws it.  This means that my game world tiles are not ever entirely loaded into the tilemap, only the ones around the player out to a fixed view size.

I have changed this approach slightly after thinking about the camera zoom.  If the view is 25x18 = 450 tiles but I zoom in to a view that only shows 15x9 = 135 tiles, why load all 450?  It actually isn't necessary.  To solve this, I decided to implement a flexible view-zoom-based viewsize and tilemap loading scheme.  By that, I mean when the player zooms the camera in or out, I alter the size of the view and the tilemap tile loading to accommodate the smaller or larger view size.  This works amazingly well.  Naturally, when zoomed all the way out, there is more noticeable stutter in the refresh of the view.  Conversely, zooming all the way in loads fewer tiles and thus less stutter.  As of this writing, zooming all the way out or all the way in will result in a view that looks like these respectively.

Zoomed Out

Zoomed In

Where things have changed is when the player starts moving around in whatever zoom the camera is in.  Zoomed out loads a tilemap of 1590 tiles.  However, zooming all the way in will reduce the amount of tiles loaded down to just 336.  This really optimizes the view and the tilemap in ways I had not considered before.  This also allowed me to zoom out farther than before so that a player can see more of the immediate area.

Smaller Flora

Sometimes a feature can creep into something that is really not worth it in the grand scheme of things.  Such was the case with my flora.  I had 5 age categories for the flora (sapling, young, mature, old, and dead).  This is all well and good, but I started thinking about whether this was too much and came to the conclusion it was.  The old-aged trees were the biggest in size and when you consider that I have to compensate for their vertical and horizontal size when loading tiles around the edge of the view, I was spending quite a bit of resources just to show the bigger trees.  This got me thinking generally about the sizes of my flora and whether they really needed to be as large as I have them.  Dense forests swallow the player in thick foliage that is not pleasant to deal with.  This is before considering the dangers of predators.  I started to play with the flora scene's flora sprite scale.  I reduced it to half size and with the zoom work, the game world really opened up and became more manageable.  To increase the benefit, I deprecated the old-aged trees.  Sapling (planted by the player), young, and mature are quite sufficient for any purpose I have for trees and other flora.  Hence, I removed the old-aged models entirely.  This trims the edge-tile requirements down even more, which improves performance.  Here is a comparison.  Notice how much room the trees take up when the larger models are used.

 

Larger Tree Models

Smaller Tree Models

Smaller trees serve the same purpose but are less obstructive.  What do you think?  Well, that is all for now.  

Until next time, I'm

Bound2bCoding

More User Interface Design Work

February, 2024 is almost in the history books, and with it comes many new pieces to my game's User Interface.  I know these features are considered standard for any game, yet I am excited still to make progress on them and share some screenshots of the work I have completed thus far.  Without further delay, let me introduce you to the following new windows and features.

Mini-Map

Mini-Map

The mini-map allows the player to get a bird's-eye view of the surrounding area.  It has four levels of zoom (zoomed all the way out shown).  In addition to being centered on the player, it also provides a visual indication of where the player has traveled.  The map defaults to shades of brown which identify unexplored types of tiles such as mountains, forests, plains, rivers, etc..  As the player moves around, the path the player takes becomes colored with colors more indicative of the landscape, as seen above where my character traversed a green, grassy plain in springtime.  A developer feature of the map, which I actually think makes sense to leave in the game, is the seed value of the randomly-generated map shown below the map.  This could be useful for players who wish to re-play a favorite map seed.

Pocket Watch

Pocket Watch

For those players who can afford it, the purchase of a pocket watch at St. Louis or one of the annual  Rendevous will provide this new window which may be positioned on the screen to keep track of time while surviving in the Rocky Mountains.  The second hand is shown here, which I added for testing.  But in the game, the second hand will not appear.  This is because time will be accelerated quite a bit from real time, making the second hand not practical.  In the  absence of a watch, the player will only have the position of the sun to judge the hour of the day or the moon and stars for nighttime.  I think the watch will be a coveted item for any would-be mountaineer.

Hand Craft 

Hand Craft

Crafting system design is really tough!  Screens must be intuitive, easy to use, and provide enjoyment and practicality.  I have attempted (once again) to come up with a concept for hand crafting, which is the crafting a player can do anytime and anywhere without crafting stations and such.  I hope this design lends to a more interesting experience than what I had in Godot 3.  Starting at the top, the orange arrows button will be used to reset the recipe and slots.  The textbox allows the player to free-type the name of a known recipe to quickly set the materials, tools, and results slots with the required item templates.  In lieu of remembering the name of a recipe, the magnifying glass will open a popup showing a list of recipes the player has acquired.  The third button will toggle a repeat action allowing the player to automate the crafting of a recipe by only clicking the hands button once, repeating the process until all loaded materials have been spent.  The lower left bag icon, when clicked, will create an inventory container on the ground at the players feet, where items can be deposited for convenience.  The time spent and skill gains (if any) will be shown in the bottom right.

Journal

The journal was by far the most interesting and exciting window to work on.  Upon opening, it animates an opening of a book, revealing the ten sections accessed via the bookmarks at the top.  Each section is also further separated into five alphabetical sub-sections.  Each section-sub-section is fed from an independent JSON data file.  Clicking the arrows at the bottom left and right will cycle paging for the selected section and sub-section according to the JSON file's dictionary records.  The animations were so very easy to do in Godot 4!  The bookmarks tween up and down as the mouse runs over them.  I think the most challenging part of this feature was inserting images into the RichTextLabel control.  Since I know I will be spending many hundreds of hours filling this journal with valuable content about the game, I created a set of codes I can embed into the JSON data files to target the desired .PNG files that I want to show, making the creation of pages as easy as typing out the content.  I am sure I will do some sort of video about this exciting feature of the game at some point in the future.  Keep an eye on this blog or my YouTube channel for more information about it.

Well, as you can see, 2024 is already shaping up to be an epic year for this little survival game of mine.  I am happy you were interested enough to find this blog and please let me know if you have any suggestions or feedback.

Until next time, I'm

Bound2bCoding

Weekend Project: Water Zones

I had quite a busy weekend.  First, I  created a rudimentary world map window.  For larger maps, the scroll bars allow scrolling around to see the entire map.  I still have a lot to do to it, but it is a start.

Water Zones.  A YouTube video showing how to do this is now up on my channel, here.

Next, well, I did not expect to tackle this feature so soon.  But inspiration struck and here I am with a first-pass at a water zone system.  The world builder has been updated to separate all water tiles into zones.  A zone is defined as a group of touching water tiles.  Depending upon the total count of the zone, the water tiles range from a natural spring to a river.  The following features are in place:

• 100% procedurally generated water zones.
  
• 7 water zone types, from smallest to largest: well, natural spring, watering hole, pond, lake, creek, river.
• 5 water depths.
  
• Ponds, Lakes, Creeks, and Rivers are randomly named using historical and fictional names.
• Mousing over a zone will identify it and provide some basic details (see photos).
• New water tiles (the best ever!) with 8 water styles from calm to raging.
• Depracated the water shader approach (from my previous post) and decided to create tilemap animated water tiles.  This was my first look at the tilemap animated tiles in Godot 4.  I love it!!!
  
• Animations include 21-tile flowing animations from an amazing free resource:
• https://opengameart.org/content/the-battle-for-wesnoth-water-animation
• JSON definitions for 80 named water zones with many more to come.

The North Platte River!

There were two very challenging parts to this feature.  First, I had to write some translation logic for the Perlin noise water tiles in order to ensure that shoreline tiles were shallow and tiles out in the middle would be deepest.  Next, I had to write the zone detection and selection feature.  After a dozen failed approaches, I finally figured out how to group adjacent tiles into their own zones.  It takes exponentially longer to run the calculations for larger maps, but it is working well.  I will keep on optimizing.  What do you think?

Oh, and I also managed to add a new tree to the game.  Cottonwood, a very common tree in 1820 Wyoming, and even today!  You can see them in the second screenshot above.

Until next time!

I'm Bound2bCoding

2024 New Year Update!

Inventory Updates

There has been a whole lot of development accomplished since my last post.  The inventory system has been updated to provide a customized window for the player inventory.  Up to this point, the player inventory was using the standard container window scene which looks like this.

Now, there is a custom scene that will be used for the player's inventory.  I am calling it the Accoutrements scene.  It comes with a paper doll and slots for various clothing, tools, and weapons, hence the name Accoutrements.  The current version looks like this.

With this new scene I am able to apply some custom drag and drop rules.  For example, when the player adds a belt in the belt slot, five more slots become usable.  The three slots along the belt and the two middle slots on the right side can hold four small and one medium attachment.  I have thought long and hard about inventory management since I have been working on this new version of the inventory engine.  Being this is a survival game set in 1820 and the player is a mountain man, it would not make sense that a player could trek around the forest carrying 15,000 items.  Rather, I think it is fitting and more immersive to consider player inventory within the bounds of what a mountain man might carry around.  A pack on the back can add additional storage slots when traveling.  If the player has a mule or a horse, they will also have storage slots.  I know there is a fine balance between immersion and frustration.  I aim to find that sweet spot with this design.  We shall see how it goes.

Water Tiles with Depth

I am excited to share that I have completed a first pass at coding water depth using materials and shaders.  This was a huge improvement over my old Unity solution.  I have a video on my YouTube Channel that demonstrates how to create a procedurally generated world.

What you see above are water tiles, with lighter colored tiles representing shallow water and darker tiles representing deeper and deeper water.  This was achieved using the following water shader and individual Materials placed on each of five atlas tiles.  Here is the code for the shader.  Here is also a link to the video where I found this shader implemented.  Note, I am not endorsing any person or project, just providing you with my source.

======================

shader_type canvas_item;
//https://www.youtube.com/watch?v=eU-F-xuEo7s&t=14s

uniform sampler2D waterSource : repeat_enable;
uniform sampler2D noise1 : repeat_enable;
uniform sampler2D noise2 : repeat_enable;
uniform vec2 scroll1 = vec2(0.05, 0.05);
uniform vec2 scroll2 = vec2(-0.05, -0.05);
uniform float distortion : hint_range(-1, 1) = 0.1;
uniform vec4 tone_color : source_color;
uniform vec4 top_color : source_color;
uniform float light_start : hint_range(0.0, 1.0) = 0.275;
uniform float light_end : hint_range(0.0, 1.0) = 0.4;

void fragment() {
    float depth = texture(noise1, UV + scroll1 * TIME).r * texture(noise2, UV + scroll2 * TIME).r;
    vec4 water = texture(waterSource, UV + distortion * vec2(depth));
    vec4 top_light = smoothstep(light_start, light_end, depth) * top_color;
    //COLOR = water;
    COLOR = water * tone_color + top_light;   
    COLOR.a = 1.0;
}

=====================

Moving into February, I am focused on my ItemAction engine which will be coupled with my Inventory engine to handle most game actions and will provide the ability to build out my crafting system.  I am very happy to get started on that.

In closing, my YouTube channel has been steadily growing.  I welcome you to join and follow along if you are so inclined.

Until next time,

I'm Bound2bCoding.

Inventory System Port to Godot 4 C# Complete!

Greetings to all and a Happy Thanksgiving to those of us in America.  As my wonderful wife is hard at work preparing for Thanksgiving tomorrow, I am finishing what has been a very huge re-write of my game's inventory system from Godot 3 and GDScript to Godot 4 and C#.  It took longer than I expected, but then I did chase many rabbits which resulted in many great new features.

I want to talk a little bit about what the process was like and compare the two implementations.  Permit me to dive right in.

Godot 3: (March 2023)

Godot 3 Alpha

The Godot 3 version stored static inventory item definitions in Resource files.  This worked well and made updating the properties of each inventory item easy to do directly from the Godot user interface.  All instanced data was stored in Godot dictionaries.  The system was comprised of a Singleton for much of the inventory system logic, three UI nodes for the slots (small, medium, large) and a UI node for the base inventory window (shown below).  The inventory window dynamically builds itself based on the configuration of the properties stored in the Resource file for the respective container object.  The system had two types of objects, being containers and items.  Liquids were considered items.  It offered basic drag and drop, stack splitting and animated opening and closing.  Finally, it supported weight values shown in standard and metric systems.

I enjoyed learning about the Resource system in Godot and I only have one critique about it.  Sometimes my data structures were complex and when my resource contained an array, it was very difficult to add something to the array without having to re-key the data into the array in order to pick up a change.  GD Script was also fun to learn and I was able to quickly put together a basic system.

Godot 4: (November 2023)

Godot 4 Alpha

The Godot 4 version of the inventory system was essentially a complete re-write from GDScript to C#.  I switched from Godot Resources to JSON files and from Godot dictionaries to C# dictionaries.  I also switched from using Godot Signals to using C# Event Handlers.  Hum... what else...  I structured my Visual Studio solution to be close to a Clean Architecture style where I have my scripts broken down into an Application folder for the UI scripts, a Domain folder for my inventory classes, and an infrastructure folder for injections like my JSON implementation., etc.  It's not completely Clean Architecture simply because everything is on one DLL.  But it helps me organize my code.

There are so many new features as I found myself chasing rabbits. Even so, it was a rewarding experience to put this system together (again).  Let me share some feature highlights with you.

Inventory Window Base Scene

• Inventory container window scenes build dynamically from JSON definitions where each container can have up to three slot sizes in any combination of slot counts and slot columns.
• Container windows can be dragged anywhere in the game and locked in a set position.
• Containers that have child containers can be opened via double-click or clicking the bottom right icon to open/close all child containers at once.
• Weights can be configured to show in standard or metric measures.
  
• Static JSON-based inventory definition files for image locations and data for items, containers, and liquids.  The goal is to allow players to be able to introduce their own items into the game or tweak any item to customize the game experience.
• Instance game data will also be saved as JSON files.
  
• Sound effects for valid and invalid actions, including liquids pouring from one container to another with the sound effect selected based on how much liquid is actually being moved around.
• Extensive drag and drop scenarios (item to slot, item to container, item to item, container to container, etc.
• Shift-drag-and-drop to split stacks in half.
• Ctrl-drag-and-drop to bring up a quantity dialog for specific amounts.
• Auto-merge and auto-fill when dragging items onto slots and containers while respecting volume constraints.
• Containers have max volume constraints and separate liquid unit measurements for those containers that can hold liquid.
• Dragging an item from a slot will double the size of the item visually
• Custom tooltips which display summary information for containers, items, and liquids.

These are some of the features currently coded for the inventory system.  Some features I want to add in the future include selecting multiple slots at one time for drag-and-drop between containers, the ability to sort items inside containers based on name, type, etc., and the ability to pick up all items and deposit them into the player's inventory from a loot drop.

What's next on my list?  I am now going to move on to finishing my flora system along with all remaining features of the Godot 3 version that have not yet been ported over.  I hope you have enjoyed reading about my game.  Feel free to comment or suggest here in my blog, or on Twitter.

Until next time,

I'm Bound2bCoding

November Update

I want to mention briefly that I have changed my YouTube and Twitter handles.  Eyesgood is a name I have long used in gaming and I have really wanted to identify with a different handle in the context of my game development life.  Yesterday, I had a moment of inspiration and came up with:  Bound2bCoding.  Look for that name going forward as I sunset the use of Eyesgood in my dev life.

October was an amazing month of development work.  While working on converting the inventory engine to C#, I expanded the capabilities of the inventory system to handle scenarios that were not even considered in Godot 3.  I am still in the midst of this translating and refactoring process which I expect to run out to the end of the year.

C# Tip:  Unsubscribe C# Events Before Removing Scenes

One thing I discovered while testing my C# version may be of interest to any developers reading this.  I learned that C# events that are subscribed to are NOT unsubscribed just because the node is removed from the scene tree in Godot.  For example, I have a singleton named InventoryEngine which handles all the drag and drop transactions among other things.  I also have an InventoryWindow scene that subscribes to an event in the InventoryEngine.  The window node is instantiated each time a container is opened.  When the inventory window is closed, it is removed from the scene tree along with all its children.  

InventoryEngine (singleton)  

    public event EventHandler<int> RefreshContainerWindow;

InventoryWindow (node)    

    _inventoryEngine.RefreshContainerWindow += On_InventoryEngine_RefreshContainerWindow;   

InventoryWindow (node)

        _inventoryEngine.RefreshContainerWindow += On_InventoryEngine_RefreshContainerWindow;

I was having weird issues with my inventory windows not refreshing when dragging and dropping items.  It took me a long while to realize that events were firing from nodes that were no longer in the scene.  This was because I was not using Godot Signals, but rather ordinary C# event handlers.  According to the documentation, Godot handles the Godot Signals for disposed objects, but it does NOT handle any C# event listeners.  To fix this, I had to unsubscribe those subscribers in the InventoryWindow code behind before deleting the window node.  This is done in the _ExitTree() method.

public override void _ExitTree()
{
    _inventoryEngine.RefreshContainerWindow -= On_InventoryEngine_RefreshContainerWindow;          
    base._ExitTree();
}

I hope this helps someone else who may be pulling their hair out trying to track down this kind of issue.

Visual Studio Tip:  Don't forget to point your debug to the new DLL when upgrading Godot.

Here is another gotcha for Visual Studio.  When you upgrade your Godot version, Visual Studio => {project name}Debug Properties => Path to the executable, and click Browse to locate the new Godot executable.  This will allow debugging in the version you have upgraded to.

That's all for now.  I hope you have learned something useful.

Until next time...

I'm Bound2bCoding

September Update

August and September have been really excellent months for progress on my conversion from Godot 3 to Godot 4.  The tilemap conversion work is pretty much done.  The flora engine work is almost done.  I started writing the C# version of the inventory engine and that is almost done.  I also started bringing over some of the user interface.  There has just been a lot of progress all-around.

I have been quite surprised at how many hits I have been getting on this blog lately.  I don't know if it has anything to do with the UNITY fiasco or not, but it is encouraging to see thousands of hits per month now.  The YouTube channel subscriptions are up as well, although not from me giving attention to it.  I have been meaning to get another video posted to share my tilemap implementation, but I selfishly opted for more coding over more videos of coding.  The end of the year is typically when I have more time to devote to my hobbies (like this game) and I expect to be able to provide some informative videos on my channel very soon.  If you are one of the many who have asked me for videos, thank you for your patience.

In this post I want to mention a few things about Godot 4 and the tilemap terrain features.  For one, the terrain is too slow for my purposes.  The bottleneck seems to be the tilemap.set_cells_terrain_connect method, which paints the atlas sprites onto the tilemap using the auto-tiling terrain masks.  That method is brutally slow, while the Godot 3 counterpart tilemap.update_bitmask_region method is amazingly fast.  I eventually wrote my own bitmask solution for auto-tiling.  I will cover that in a future video.  I read recently that tilemaps have been given some optimization attention in the upcoming 4.2 update.  We shall see if the performance at least matches Godot 3.  I can tell you honestly that Godot 3 outshines Godot 4 in the area of terrain bitmasking by leaps and bounds.

Another issue I have discovered with Godot 4 has to do with the fact that physics interpolation has not been implemented yet.  What that means for me is that I have to endure the constant, nagging studder in my tilemap implementation until the feature makes it into Godot 4. That is frustrating.

There are also some heavy discussions happening regarding C# and Godot 4 as of this writing.  Some major changes are in the works, and while I welcome them, it makes moving to Godot 4 that much more challenging.  On a positive note, the C# code runs much faster than the GDScript.  

 

Until next time...

Godot 4 Upgrade and Migration from GDScript to C# August Breakthrough!

The month of August is already proving to be a great month for progress in my attempts to upgrade my game from Godot 3 to Godot 4.  Until this weekend, the tilemap had been a huge setback for me.  Coming into the conversion with only limited understanding of the new tilemap system, I made the mistake of assuming it was similar enough to Godot 3 that I could just create the tilesets, add the terrain, and convert my script to C# and it would work.  That was surely a mistaken assumption!

Once I debugged the C# code, I discovered my method of creating a chunk-less map that refreshed the visible tiles for each player movement wasn't going to work the same way in Godot 4 because the method to handle auto-tiling in Godot 4 is slow.  Extremely slow!  I had to step back and re-think my approach. By the end of the weekend I had the system working again and I am very impressed so far with how smooth the refresh is.  I haven't added the trees into the scene yet, but everything looks promising.  Already, I can tell this is going to be amazing!

Getting past the tilemap hurdle, I see wide-open highway in front of me.  Next on my list is completing the flora system conversion, which is already well underway.  Then, I will focus on the inventory system and finally the user interface.  Thanks for following along on this project.

Until next time...

Godot 4 Upgrade and Migration from GDScript to C# Continued

The upgrade from Godot 3.5.2 to Godot 4.0.3 continues into July.  Nothing much to mention, although I did learn that Godot signals cannot pass C# objects as parameters.  Since I am replacing all my GDScripts with C# files, I needed to fall back to using C# Events and Handlers when the need to pass List<T> and C# Dictionary data was desired.  Another change I am making involves discarding Godot resource files.  While they are convenient for storing static data, I find them a bit cumbersome if the data structure is the least bit complex.  Crafting recipes readily comes to mind as an example.  If the resource defines Dictionaries and Arrays, the .tres files can be really frustrating to manage especially when I need to add or remove some piece of dictionary or array data.  In Godot 3.5.2, I sometimes have to re-enter dictionary data just to add a new record.  Therefore, part of this migration of scenes, scripts, and resources includes moving away from resource and tres files towards using json files to store game data.  They are much easier to work with, produce smaller files, and they can be managed using proven 3rd party libraries like Newtonsoft's Json library.  There is still so much to do and I will plug along until I get it done.  I can't wait to see the fruit of all this labor.

Until next time...

Godot 4 Upgrade and Migration from GDScript to C#

This is just a quick note to say that I have decided to move forward with upgrading my game project from Godot 3.5.2 to Godot 4.0.3.  I am not planning to use the upgrade tool because, quite frankly, I don't trust it.  Instead, I am creating a new project where I can open the V3 and the V4 projects side by side to create the scenes and scripts anew.  My reason for doing this is to master the translation of GDScript to my professional language of C# and to ensure all existing scenes are the way I want them to be moving forward.  When I am done, I will have a new codebase written in C# using classes to store domain structure and JSON to store both game and player data. 

This will likely take me several months, after which I will do a comparison video showing any performance boosts achieved from this process.  For now, I am heads down with this task and will check back in once I am ready to showcase the changes.

Until next time...

Marching Into Crafting

March is in the history books.  I made significant progress on my crafting engine.  I will demo it on my YouTube channel shortly.  But I would like to share with you my first design concept and why I felt it ultimately failed.  Then, I will show you my second one and why I feel it is a much better design.

First Concept:  Craftwork With Integrated Inventory Window

In this initial design, I thought to allow the player to open the Inventory window and the Craftwork window so that ingredients and tools could be dragged and dropped based on the recipe requirements. In order to provide for the drag-and-drop feature, I modified the inventory window code to hide buttons and other pieces of the inventory window so that I could instantiate an inventory window within the Craftwork window.  The result looked like this.

Instantiating the Inventory window scene was easy enough and the hidden controls were only hidden when the Inventory scene was instantiated by the Craftwork scene.  What I hoped to provide was selective ingredients.  By that, I mean I wanted the player to be able to choose the specific inventory items to be used in the crafting recipe by providing drag-and-drop capability.  Once that part of the design was implemented, I starting thinking about the user experience and the coding needed to pull it all together.  The user experience was first and foremost the most important concern in the design.  So, I thought through it carefully.  The steps were as follows.

1. The player opens the Craftwork window

2. The player opens the Inventory window.

3. The player chooses the recipe from the list on the left.  Line 1 and Line 2 give details about the recipe such as ingredients and tools required.  

4. The player then drags over from Inventory the ingredients and tools into the corresponding slot sizes.  The colored bars have not yet been coded, but they will be Percentage of Success, Resulting Quality, Amount of Focus applied (more time means a better outcome), and horizontally a progress bar.  The hammer tabs will provide lists of recipes by category.  

5. The player clicks the Craft button and the crafting process begins providing the items in the slots matched the recipe selected.

It all looked really fine to me until I realized how draggy and clicky it was.  There was so much the user had to do just to craft something.  But also, behind the scenes I had to manage two sets of inventory containers, coordinate passing back to the Inventory all non-consumable tools and items along with the crafted item and clean up if the user decided to cancel the session.  It was a huge lift for the player and fairly complicated for the developer.  I wasn't satisfied with it at all.

Focusing my attention on the draginess and clickiness (are those even words?) I decided to toss out the Inventory window and replace it with an image of the crafted item.  I did away with drag-and-drop altogether.  I also eliminated the necessity of opening Inventory unless the player just wants to.  Here is the second design.

Second Concept: Independent Craftwork Window With Auto-Ingredient Tracking

The second concept is much less work for the user and the developer.  The steps are as follows:

1. The Player opens the Craftwork window.

2. The Player selects a recipe.

3. The Player clicks the Craft button.

Behind the scenes when the player selects a recipe, the code checks for the existence of the ingredients and tools in the Inventory and holds a reference to their object id's.  There are two additional buttons above the Craft button.  The Down arrow allows the player to indicate he wants to use the lowest quality ingredients and tools from Inventory.  The Up arrow will select the highest quality ingredients and tools.  While not as specific as the first design, I think I can bake in some additional features to the Inventory window to allow more precise selection, such as active tool slotting.  When the player clicks the Craft button, all ingredients are immediately removed from Inventory and the timer and associated crafting sounds are presented.  Upon success, the item displayed in the Craftwork window is deposited in Inventory.  If the player does not have the proper ingredients and tools, a message is presented in the message window.  This solution is smaller, easier on the player and much easier to maintain.  I feel it is a superior design all around.

In the month of April, I intend to focus on building out the features of the Craftwork system and provide many new recipes.  If you have any suggestions for me, please feel free to post them here.  You can also check out my YouTube channel for the latest Dev Blog videos.

Until next time...