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