Year One Milestone - A Year In Retrospect

It is hard to believe that I have passed the one year mark in this game development journey.  Poking round my list of backups, I noticed the first one was dated Dec. 16th, 2019.  But the actual start of this Unity project began in November during Thanksgiving week.  For those of you who have not read my first post in this developer blog, the game I am currently working on started out as a web-based project.  I decided to abandoned that project when I reached the inventory system features and realized the game I was imagining would not be feasible running on the technology stack I was using.  This led me to researching an alternative, which you can read about here.  This post is about my thoughts on the first year; a retrospect of sorts.  If you have ever wondered what it is like to develop a game, then permit me to share some thoughts on the subject.

A Gamer and A Game

Computers have always been my fascination since childhood and getting my first Commodore 64 in the 1980's.  I have been an avid gamer for over 35 years.  My first MMO was Meridian59 which came out in 1996.  Being a gamer and making my own game has always sounded like a perfect match.  Maybe you know the feeling of playing your favorite games and thinking to yourself how awesome it would be to make something similar.  Something better!  Perhaps you are like me and have notebooks of ideas you have scratched-down over the years about game designs, systems, rules, etc.  One can become obsessed with this build-a-better-mousetrap mentality, especially a gamer!

Before I move on, I must in good conscience warn you about something that has happened to me.  Making a game has mostly ruined my gaming experiences.  Let me explain.  Ever since I started working on Survive and Thrive in a serious capacity, i.e. the last year, my game time has suffered greatly!  I dare say I have played less time this past year than any year ever.  Here is my problem.  Every time I log into a game and begin playing, I get filled with an overwhelming sense of guilt that I am wasting time because I am not working on my game.  The days of relaxing in my favorite MMO for hours-on-end have all but vanished.  My wife tells me all the time that I should not feel guilty taking a break and enjoying my hobby.  Of course, she is right.  But for some reason the drive to make a game has taken me into directions  that lead me away from gaming.  I use to wonder why game developers seldom spend time playing the games they developed.  I do not have to wonder that any longer.  If you can relate and have wanted to make a game of your own, just remember that such a commitment may overtake every other aspect of your gaming life.  Making a game can ruin your gaming!  Just saying...

One day I realized my real-life job as a software developer had given me some skills that I could possibly put to use to begin forming all those better ideas into a game of my own.  The hurdles for me have always been learning the tools much more so than having the ideas.  I have libraries of ideas and so do many of you!  One day I finally decided to dedicate some real time and energy into using what tools I had to make something.  This was the genesis of the game I am working on today.

A Year of Unity

This past year was not my first year knowing about the Unity game engine.  It has been installed on my computer for many years.  But it was my first year of focused determination to actually learn the engine and use it to implement my game vision.  What has it been like to learn Unity?  Well, to be honest, it has been both enjoyable and frustrating.  It is not uncommon for me to sit down in a development session and have experiences that range from lofty highs watching my game come to life to agonizing lows fighting with quirky bugs and inexplicable crashes.  Just yesterday I posted a very frustrating Unity form post about two or three bugs-of-the-moment that made me want to consider switching game engines, they were so bad!  But then later that same day I downloaded the next update to the release I am using and they seemed to disappear; the bugs I mean...  

Being a software engineer, I am used to these sorts of highs and lows.  It really does come with the job and game development is no different in that regard.  Remember earlier when I said the hurdles for me have always been learning the tools?  Well, Unity is chock full of them and each one is a college course of content to master.  Add to this the third-party assets from the Unity Store where every developer has a different coding style and things can get messy.

There are two things that drove my decision to go with Unity over some other game engines.  For one, C# is the scripting language and I love C#.  Since I work with it every day in my day job, it feels natural to use it in the game's development.  There are some other game engines that provide C# as a scripting option, but I have not yet found one as mature as Unity.  This brings me to my second reason I chose Unity.  It is a mature platform that is growing in popularity and is continually improving in the tools I need to focus on my game.  These are both pluses for me.  However, there are some negatives to using Unity.  For one, at its core Unity is a 3D game engine.  They are working hard to bring in 2D tooling, but it is still a 3D engine.  This means there will be some baggage that my game will have to carry into release.  Another negative in my book is the pace of development.  With so many changes coming out with multiple releases, I tend to think Unity suffers in the areas of testing and QA.  Patches come out practically every week.  I am always nervous about updating my project to the latest version because I have no idea what will break when I do.  All-in-all I have to say that I have grown comfortable with Unity and I am glad I chose it for this game.

A Year of Survive And Thrive

I have only published a few short silent videos of the game.  The reason for this is the fact that most of the development has been under the hood.  There has not been much to showcase.  However, I expect the next year to be very different.  In fact, I plan to publish a few videos on my YouTube channel which will highlight some of the work that has been done in the last month.  But looking back at this year, I have been able to make significant progress on some of the most difficult coding challenges.  Here is a list of first-year milestones.

• A configurable tilemap engine
• Custom world design with configurable terrain types, sub-terrain types and flora.
• Perlin generated with customized parameters and seeding
• Map previewing with saving/loading of templates
• Dynamic chunking system
• Map sizes ranging from thousands to millions of tiles.
• 18 water, grass, stone, and lava tile types
• 22 ore, mineral, metal, and gem tile types
• Saving/Loading of game world
• Player content
• WASD, mouse movement systems
• Walking, running, wading, swimming with associated sounds and animations
• Chopping of trees with fall animations
• Status/Progress bars for player actions
• Flora content
• 5 coniferous tree types
• 4 fruit tree types
• 10 deciduous tree types
• Misc. Systems
• Intro screen and Custom World screens
• Game screen with window bar
• Draggable windows with edge detection and toggle on/off via window bar
• Clock, Food/Water, Player Inventory, Hand Crafting, Info windows
• Hunger/Thirst/Nutrition/Hydration systems
• Game clock with Day/Night cycle and associated ambient sounds
• Beginnings of the crafting system with the first 100 inventory icons completed.

I am sure I am missing one or two things, but this about sums up the first year list of features.  It is very satisfying to be able to learn the Unity game engine sufficiently to be able to produce this list of features within the first year.  I hope that next year will see an explosion of new content, videos, blog posts and more as I work to bring this game to life.  Thanks for following along on my journey.

Until next time...  

A New PC And New Game Features

 A New PC

It has been quite a while since I posted an update on Survive And Thrive.  The game is progressing well, but I had to do a pause in order to take care of something that comes around about every eight to ten years for me.  I had reached the point where it was time to build a new PC!  This one was my fourth build.  I decided November was a good time to do it seeing how holiday sales were abundant.  I had determined to wait until Black Friday to ensure I was getting the best deals for the components.  That didn't happen though.

I started as I usually do by establishing a price target for this build.  When it comes to computers,  I have to set myself a price target, especially when building one.  There is always a cheaper option and there is always a more expensive one.  If I do not set a target, I will spend forever talking myself up to the next level for each component until the build is out of reach.  I have found over the years that a $2000 build is going to get me to that sweet spot in the technology curve where price and performance become balanced enough to take me forward another 8 to 10 years.  This one came in a little above that number but not by much.

A build requires the following components.  A case, a power supply, a motherboard, a processor, heat sink, memory modules, hard drives, an optical drive, a video monitor or two, and now more than ever, a video card.  Of course, an operating system is also needed.  I opted to keep using my existing keyboard and mouse.  The keyboard is a Logitech G710+ mechanical and I just love it!  A mouse is a mouse and ironically, mine died about three weeks after I finished the build.  In case you are interested, here is what I ended up with:

Case:  Antec Dark Phantom DP502 FLUX Mid Tower

Power Supply:  EVGA SuperNOVA 850 GA 80 Plus GOLD modular

Motherboard:  MSI MEG X570 UNIFY AM4 AMD

Processor: AMD Ryzen 7 3800XT 8-core, 16-thread Unlocked 4.38 Ghz.

Processor Heat Sink:  Noctua NH-U12S SE-AM4

Memory:  Corsair Vengeance RGB Pro 32GB 288 pin DDR4 3200

Hard Drives:  Samsung 970 EVO Plus SSD 1tb M.2 NVMe (primary), Samsung 970 EVO SSD 500gb  M.2 NVMe (development), Samsung 860 EVO SSD 1tb (gaming), Seagate ST3100 standard 1tb (archive) for 3.5tb total storage.  I pulled the latter two older drives from my old machine, which were not part of the build price.  I also dropped an optical drive into the build for OS install and also to provide capability to install older software.

Monitor:  GIGABYTE G27Q 27" 144hz 1440P IPS panel.  I also borrowed one of my existing monitors to use as a second.

Video Card:  MSI GeForce GTX 1660 TI PCI Express 3.0 GDDR6 6gig

Operating System:  Windows 10 Pro 64-bit

I had these all picked out and ready to purchase once I noticed them go on sale.  However, as I mentioned above, I had to modify my purchase strategy a bit.  A few weeks before Black Friday, things started to disappear from NewEgg and Amazon!  Some of the components went out of stock and others were backordered.  As I watched each day, I decided it was better to get what I wanted than to wait for a sale and have them snatched up from me.  Once they were back in stock, I did not hesitate to go ahead and get them.

Over the course of two weeks I was able to purchase all the components. I finished the build just before Thanksgiving.  I expect this new machine to carry me for the next 8-10 years.  The only part that I typically have to upgrade is the video card during the life of the PC.  I expect this one to be no different.  Once I had completed the new build and migrated my data over from the old PC, it was back to work on the game.

Game Time Simulation

I wrote a rudimentary day and night cycle quite a while back.  The Main Camera has a game object with a Light 2D (Experimental) Global light type component attached to it.  The only other light in my sandbox scene is one attached to the player prefab.  I fondly called it the Newbie Light since I plan to disable it at a certain difficulty level and/or after a certain amount of play time.  This is a survival game after-all.  It is also a Light 2D (Experimental) light but it is a Point light.

I had several goals for a Game Time Simulation (GTS).  Many survival games use the concept of survival days rather than a typical calendar approach.  This decision is subject to change, but for now I want to do the same.  Simple enough, the game begins on Day 1.  Another goal was being able to control the game speed during certain events.  For example, sleeping will occur at an advanced rate.  Crafting items will also cause the game time to advance at a much faster rate.  The GTS can be set to one of fifteen speeds.  A setting of 1 will progress the game clock at the normal rate and 15 will speed up that rate 15X when necessary.  Different events will advance the clock at different rates.  Another configurable option for a custom game will be to select sunrise and sunset times.  The defaults for a standard game are sunset beginning at 6PM and sunrise at 6AM.

I wanted the clock to be presented as a simple string value in the game UI without using C# DateTime types.  Seconds are really not shown and I know from my day job as a software engineer that DateTime calculations are costly compared to just building a string value.  It is simple enough to simulate.  The following method takes in the calculated hour and minute values from the GTS with the hours ranging from 0 to 23.  The method returns a nicely formatted 12 hour time string with AM and PM designations.  

1 2 3 4 5 6 7 8 9 10 11

private string FormatGameTime(int hour, int minute) { if (hour == 0) return $"{hour + 12}:{minute:00} AM"; else if (hour < 12) return $"{hour}:{minute:00} AM"; else if(hour == 12) return $"{hour}:{minute:00} PM"; else return $"{hour - 12}:{minute:00} PM"; }

Since the GTS is built on the 24 hour variation by default, building that string is a single line of code.

1	DateTimeDisplay.text = $"Day: {day} Time: {hour:00}:{minute:00}";

Day-Night Cycle

The GTS gave some sense of purpose to my existing day and night cycle once I had completed refactoring to accommodate the clock display. The sunrise and sunset events at this stage only involve incrementally adjusting the sun light's intensity along with the Newbie light's intensity in a smooth transition from one light source to the other.  During testing, I discovered that activating and deactivating the 2D light sources in the scene after they reached their polar intensities caused major issues with the game's framerate.  It was so different that daytime clock ticks were visibly slower than nighttime.  At first I did not know why.  After some time working through this, I was able to realize a stabilized framerate by simply leaving both lights set to active but adjusting the intensity to 0f to simulate turning off rather than actually setting them to disable.  I never realized how much lighting impacts a scene!  I know it is lighting because unchecking the object in the scene is the only thing necessary to produce the issue. Plus, I have reference objects on the script, so my code is not doing any kind of tag searching to locate them.  In fact, to date, I believe I have not used a single GameObject.FindGameObjectsWithTag method.  Searching thousands of objects in the scene is  not to be considered a best-practice in my book.

Tree Shadows

With light sources changing, I thought it would be appropriate to introduce some shadows.  Survive And Thrive is mostly a 2D, orthographic, oblique-perspective game, but I wanted to explore some ways to alter that perspective just a little to add a sense of one more dimension.  Swapping z-axis values on the player and the tree on the player's tile is one way to present a less flat game world and allows the player to walk in front and behind trees.  Another is the use of shadows.  While digging around Unity's API, I discovered the URP 2D lighting system comes with a component that somewhat simulates shadows.  It is called the Shadow Caster 2D (Experimental) component.  I decided to experiment with it.  

Shadow Caster 2D (Experimental)

Please excuse the baked shadows of this tree.  If you have been reading along, you know I took photos of real trees to use for the game trees.  I didn't bother removing them. While configuring the shadow Shape (the white square in the image above), it was only necessary to make it the same width as the tree trunk and roughly a square.  It simulates the shadow being cast from the base of the tree in a quite basic way.  The shadows are cast upon the tilemap tiles when the player's Newbie Light gets close.  The shadow stretches opposite the player's position to the tree and into infinity.  I wish it were more like the shape of the tree, but it will have to do for now unless I find the time to write something custom or find a product on the Asset Store that works better.  I will leave you with a screenshot of the night shadows and a sneak-peek at some of the new features I am currently working on.

Tree Shadows

Until next time...