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.