Just One Guy Making Low Poly Games In His Spare Time
Just One Guy Making Tutorials and Games In His Spare Time
I thought I'd give the good old video dev log a try. The video shows off some visuals in the first scene and then gets to more game mechanics in the second test scene. There will be a write up of the new mechanics coming soon as well.
Let me know what you think about the format or any questions you may have about the game.
As a solo developer (of an admittedly over scoped game) relying on outside assets is a key to building a game "quickly" and efficiently. I'm not the type of person to subscribe to the idea that I need to build everything from scratch. I have no desire to build my own game engine, but I do understand why folks often prefer to roll their own solution.
I've become very skeptical of assets that run with the game. I have learned that editor tools are more reliable and don't come with performance downsides that many runtime assets do. I've tried using several assets that are overly bloated or have turned out to have poor performance. My snow shader and graphing tool came out of such experiences. It's a tricky to find the balance between using pre-made tools and rolling your own. There are pro's and con's both ways.
Game #2 will allow players to collect and use items - this will in fact be a key mechanic. This means that I need some kind of inventory solution. I did a little research on how to do the basics, but decided to also look at solutions on the Unity Asset Store. If nothing else the Asset Store can be a good source of ideas.
As a Unity Plus subscriber I get discounts on a handful of assets. One of those assets is Inventory Pro. So I figured it was worth a look since I was shopping for a inventory solution and the reviews were nearly flawless.
I watched the tutorials and did as much research as I could. While not "cheap" it's an asset that would take me several days if not weeks to reproduce even in the most basic of forms. Plus it has a level of polish that would take even more work on my part. So why not give it a shot?
I made the purchase and spent some time playing around. My first impression was positive. It has a nice and easy to use editor. Out of the box it handles person inventory, vendors, looting, banks, a skill bar and two styles of crafting. It comes with a pretty decent default look too (but, I suspect almost any developer will want to modify it). What's not to like about it?
Inventory Pro Editor - Item Editor
Inventory Pro also plays nice with several other popular third party add-ons. This includes Playmaker for those who don't want to dink around in C#.
It also has custom functions for Behavior Designer which is a major plus in my book as I intend to use Behavior Designer as my AI engine.
If you are intending on building game with a fairly typical or standard use of inventory then Inventory Pro should be on your short list of assets to check out. However, if your design has some non-standard uses you should keep reading.
As I continued to explore and think more about the custom needs my game was going to have I was becoming discouraged. The code base is all open source, which is greatly appreciated, but it feels like a mess of inherited classes and prefabs. Ugh. The documentation is decent, but doesn't do a great job of describing how to truly customize the tools. The learning curve is moderately steep.
The odd blog post by the developer were very helpful and cut hours out of my work. The needed info is out there, but it can be a little hard to find.
When trying to setup a scene you can't simply drag and drop UI prefabs in the scene. They don't easily slide into a scene because there are too many connections that need to be made. Too many prefabs that need to be dropped into the inspector or combination of components that are required. It's certainly possible, but it's not easy. Adding the UI to a scene is best done by copying from a demo scene and then turning off the parts you don't need - a custom editor to add the parts you want and get them all connected correctly would be a major plus and make the product that much more user friendly.
There is a cost to using someone else's code base... That shouldn't be a real surprise. I got frustrated enough with Inventory Pro that I spent a few hours working to roll my own custom inventory code. It was all going well until I began to write a custom editor to create content. I went running back to Inventory Pro and I'm very glad I did.
I mentioned a chicken, so why not include a image of my chicken?
For Game #2 I need some custom windows for resource consumers and resource processors. A resource consumer could be something such as a steam engine from my previous post that may take in wood or coal and produce a more usable form of energy. While resource processors may be something such as a windmill that will process corn into corn meal that can be used to feed your chickens, i.e. turn items into other items.
Each of these custom windows is easy enough to create from a purely UI perspective, but coding them took a bit more especially as I was to digging through someone else's code.
A resource consumer is very similar to a vendor in that individual objects in a scene will have there own collection that is loaded into a common UI. The main differences being that the resource consumer needs to do something with the items even when the player is not currently using that object, i.e. a steam engine should continue to burn coal and produce energy when the player is busy elsewhere and I don't want to be selling coal to a steam engine...
A snippet of the some of the custom code - All in all there's several hundred lines in the new classes some is copied other bits are mine
Rather than inherit from the vendor classes, which would bring functionality I didn't want, I chose to essentially copy the vendor scripts (ItemCollection and Trigger) and modify the scripts once I had basic functionality working. The result was a custom trigger script, custom UI window (damned ugly at the moment), a custom collection script that controls what is shown in the UI as well as a base class resource consumer that is designed to be extended for a variety of resource consumer objects (steam engine, chicken feeder, etc).
I promise it won't be this ugly in a final build
The resource processor is a bit different. At its core resource processing is very similar to crafting. Items go in and products come out - all following a blueprint. Given that Inventory Pro has a built in crafting system it seemed worth the time to fight through the code to create a custom "crafting" window that would meet my design needs.
The idea here is a that a player (or NPC) drops off some items to be processed and it gets turned into a different item that can later be collected. This means that the UI needs to have an input and a output collection/inventory. It's also required that each individual scene object has it's own input and output collections to that get loaded to the UI when the player interacts with the object. A final two requirements is that the resource processor continues to work when the UI is closed and that the products get assigned to the correct scene object when the processing is done so the product doesn't get lost and the player can collect it later.
A snippet of the Custom Trigger
This last requirement was the biggest hurdles and required about an hour of hunting through code to follow the flow of the information. Inventory Pro has a "craft info" class that contains all the basic information which gets passed through about 8 different methods before an new inventory object is actually created.
I almost lost it at this point. Lots of deep breaths needed.
To get it all working required an addition to the CraftInfo class to track what object had ordered the product to be created. This allows a finished product to look up where it was supposed to go and assign it to the appropriate collection.
Default Item Types - Plus 3 of My own
While I found the process of adding custom windows and functionality challenging and frustrating, adding custom inventory item types was easy and almost fun. Out of the box Inventory Pro comes with several default item types, but anything beyond the typical RPG will likely require custom item types.
Different types have different properties (oh, shocking). These properties are not particularly well documented or at least I haven't found the documentation. Thankfully most are self explanatory.
Game #2 is not the typical RPG with the collection, crafting or upgrading of gear playing a central role. Rather most inventory will have some use in creating something in the world. This might be a shovel that is used to prepare the ground to plant a crop or coal that will be used by a steam engine to power an industrial building. Inventory Pro's items all inherit from a parent class that calls a Use() function. This function can easily be overridden to perform any actions needed. The Use() function is called when the player uses the object. Which can be done from inside the inventory or from the skill bar.
A sample custom USE() function for a tool item type.
The Use() function returns an integer that indicates whether the object can be used.
In the case shown using the tool will call an outside public function that toggles a mode of the game (i.e. use a shovel and you can dig to plant seeds).
The inventory item can also have public variables that will be displayed in the Inventory Pro editor. For example the Tool Type enum can be set for each inventory item of this type inside the editor which makes for easy and organized content creation.
The ease of creating custom inventory items was a stark contrast to making custom windows and triggers. Why can't the rest be this easy?
Inventory Pro caused me a good amount frustration, plenty of swearing but also gave me a much more functional inventory system than I could have created on my own.
If you are looking to build a game with non-standard use of inventory and aren't comfortable with C# then you should probably look else where or be willing to hire a programmer to code up some custom solutions.
But if you don't need custom functionality or if you are comfortable with C# and reading someone else's code then Inventory Pro can solve your inventory needs far quicker than you'll be able to roll your own solution. Mucking around with the custom windows wasn't particularly fun, but the end product was worth the time and money.
Game #2's design is fairly well established in my head and on paper, but I'm still very much in the stage of exploring what I can reasonably do from a technical perspective - not to mention from a time perspective. (Read as: I'm trimming down the scope by figuring out what I can or can't do.) I'm running through the big picture list of features to make sure that each can be implemented in a way that I like and fits the vision for the game. This is an iterative process. As features are implemented other aspects of the game are getting adjusted or redesigned, but that's not exactly news worthy...
A core feature/game mechanic of Game #2 is going to be energy. Energy is everything. With more energy we become more productive. With more efficient use of energy we can do more with less. The use of energy is what allows for modern society to function and, to hint at a game mechanic, use of more energy allows for a higher standard of living.
There's of course a dark side to energy consumption.Increases in efficiency allows more to be produced with less. That might be less workers, less energy or less effort. All of which improve the quality of life. While this can drive down prices, increase production and consumption it also has the effect of higher unemployment or underemployment - i.e. the current stat of the rust belt.
A rigged and animated steam engine model. This was also the first animation I'd ever rendered in Blender - GIF made with GIMP.
This give and take concept is something I very much want to explore in Game #2. The first step of which means I need to develop an energy mechanic. The mechanic requires the "generation" of energy (the physics teacher in me cringes writing that), the distribution of the energy, and the "consumption" of that energy.
The game is likely to be set in the industrial revolution time period. So... Steam engines!
Steam engines can provide a local source of energy. They can be fed with wood, charcoal or coal - really anything that'll burn. All of which can be found or produced easily with low tech methods. Steam engines can be built on site in a variety of sizes. Seems like a win. So off to Blender I went to see if I could produce something that I liked.
A view of the rig in Blender.
Nothing profound in the modeling department, but rigging and animating is still pretty new to me. I didn't want to "fudge" the animation I wanted a rig that with the rotation of a single object could animated the entire model. I wanted this for ease of animation as well as for a degree of realism.
A combination of bones and constraints to tie the mechanism together and allow smooth animation. The constraints of copying location, rotation and or scale were all new to me and opened my eyes to a new world of possibilities. I'm excited to play with more mechanical animations...
There are very few tutorials on mechanical rigging - I might put one together in the future. Who knows?
I'd like to work renewable or at least pollution free energy sources into the game as well. At first glance windmills are a pretty obvious choice - so those will be added at some time in the future. At the moment I've avoided rivers (as I have no idea how to make a good looking low poly river) so water power is more or less out for the moment.
Power Lines - Mostly eye candy at the moment
The industrial revolution largely used mechanical energy which (clearly) has limitations. Moving towards electrical power as a way to transfer energy could help in several design areas, but could break the immersion or at least a sense of believably.
While it may not fit with the (current) intended time period I spent a little time playing around with power lines. Being able to generate power in a centralized location could lead to higher efficiency and more contained pollution. This is further specialization would allow workers (and the player) to spend more time doing something besides feeding fuel into a steam engine.
Borrowed Code that when passed an Array of Points with Return a larger but smoother array of points - Don't Remember the Source, Oops.
I can see the game going away from a historically accurate time period (ha, as if I'm capable of historical accuracy), but I don't want to delve to far in to fantasy or steampunk styles either...
The power poles are just to cubes scaled to look like modern poles. The lines are line renderers that start with three points and then are smoothed by some (borrowed) code to add additional points.
The performance of moving the poles is pretty bad and will need some optimization if the code makes it into a build. I have to redraw all the lines when a pole moves - at the moment EVERY line is redrawn.
To be honest the power lines came out of frustration (lack of creativity) with another idea. They may just be a short lived idea that goes away.
Some form of energy transfer mechanic will need to make it into the game whether that is power lines or not I have decided. At the moment the energy transfer mechanic is simply the player or hired workers stoking the fires of steam engines - I think a step up in sophistication would be good.
Plenty more to iterate on...
A download link to my graphing asset is at the bottom of the post - if you want to try it out.
Game #2 will likely be centered around economics as well as climate (change). Deciding where to build a farm will likely be best done when looking at some climate data. Does it rain enough? Maybe too much? How hot does it get? Is the ground water polluted? Or looking at historical prices of commodities may help a player decide what type of business to pursue or how much they can afford to pay NPC employees. I don't want the game to be a data crunch fest, but data will be a part of the game. So naturally I'll be needing a way to visualize that data and graphs seem like a good way to do that. Pretty sure players don't want to read a list of float values.
Visualization - Basic line (scatter) graph
I'd seen Graph Maker on the Unity Asset store and bookmarked it many months back. The reviews are pretty decent and it is definitely capable of a lot of heavy lifting. I'm aware of at least one reasonably successful game that has made use of it. So it seemed worth the risk of a few bucks. Graph maker clearly has had hundreds of hours poured into it. It's polished and feature rich.
All those features have also caused it to be fairly complicated. Each graph has several nested prefab elements each with scripts attached. The documentation is also a bit rough. As a new user the number one thing I want to know how to do is send the graph a list or array of my data and have it graph it.That's it. One simple function. So where is it?
I spent a while clicking around trying to figure out where the data was stored (turns out to be in the series prefab/script). I opened the documentation and couldn't find clear directions of how to send my data to the graph via script. I opened the scripts in search of the list or function that would import my data... Couldn't find what I was looking for.
There is a neat reflection script that can be attached to gameObjects and looks like it could do some handy stuff, but I couldn't get it to do what I wanted. All in all the asset looked way bigger than what I needed. Do I need radial graphs? I don't think so...
The second thing I want to do is modify the appearance of the graph. The shear number of (nested) prefabs not to mention the number of settings in the main script it seemed like it was going to be a long battle to customize the looks of a graph.
So as I so often do, when I can't figure out an asset I start down the path of rolling my own asset. If you have more patience than I do, I know that Graph Maker is a good asset and will make pretty graphs for you.
The goal of rolling my own graphing asset was to make something simple, lightweight and easy to use. As of writing this post my graphing asset has 6 prefabs and three scripts (one of which is a custom inspector to allow graph updates in edit mode - another detects mouse hovering). The prefabs largely consist of gameObjects with just an image component. A few such as "tick marks" or "axis labels" have children with Text components, but nothing gets more complex than that. Sending data to the graph is done with 1 of 3 functions. Pretty simple.
Just send the data and let the graph do the rest.
In the end it's taken me way longer to roll my own graphing script then it would have taken to figure out Graph Maker. Is mine as pretty? No. Does mine do nice tweening animations? No. But I know how mine works and I know how to modify mine if I need to.
The feature list is short. It can switch between line (scatter) and bar graphs. The axes, points, connecting lines, and tick marks can all be tweaked in size and color.
Bar graph of the same data as at the top of the post
Fonts, font size and font colors are all of course adjustable as well. Modification of the images was left out of the inspector/script and can be done with the prefabs. This was done for simplicity and the simple fact that changing images is less of a "tweak" than font size might be.
I still have one feature to figure out and that's auto-scaling. Currently the axes will auto scale and adjust to fit the data, but the values displayed on the axes does not. I'd like to figure out some basic auto scaling to keep things simple - sure I can manually adjust the values in the inspector (or by script if I expose the variables or add a new function), but that's hard to do when the game is published... I like to be involved the community, but manually adjusting each player's graphs is a bit much. I'll keep the linked package up to date if anyone has ideas of how to auto scale I'd love to hear them.
Edit: The auto scaling is now working.
I may polish the asset a bit more and put it on the Unity Asset store, but that's a lot of work for not much of a return. Until then I'll happily handout a free download (box via goo.gl). Feel free to use it or modify it. Just don't flip it and sell it - don't steal my $12 in potential sales! If you do use it I'd love to hear about bugs or ways to improve it (but not bloat it).
Not until writing this post did I realize I named my asset the same as the one I'd purchased. Oops.
My last post was about adding snow visualizations into Game #2. In the end I came up with a custom shader that ran faster than an asset I found on the Unity Asset Store. In my (quick) research I didn't find a tutorial showing what I needed, so I thought I'd do a quick series and show my project. The tutorial series covers the full creation of the shader (in Shader Forge) as well as a simple script to control the snow effect scene wide.
If you want to see more details about the creation of the shader or if you'd like to try it out (download link in the video description) then check out my tutorials series. The first video is just an intro and explanation of what's to come. If you want to get to the meat then click here to skip to Video #1.
Intro video showing what will be created in the rest of the tutorial. Shader Forge: https://www.assetstore.unity3d.com/#!/content/14147?aid=1100lHSw Tutorial Assets: https://app.box.com/s/npupei7px4tjavkkg4gtbz3y3mj6b73b
With the environmental simulation getting near to finished it was time to start looking at how to visualize the weather. I'm using Tenkuko Dynamic Sky for my overall lighting and day/night cycle. It's not perfect, but makes my scenes look so much better than I could do on my own. It's worth every dollar.
Seriously. This looks good. This took about 3 clicks...
Tenkuko does a great job for general lighting it also has functionality to support rain, snow, fog and clouds. The clouds aren't perfect and probably won't work for a low poly game. What Tenkuko doesn't have is snow accumulation. So I started doing a bit of research to find a solution.
I headed over to the Unity Asset store and picked up Global Snow. It's beautiful. Truly. It supports flat shaded snow as well as two other modes that produce more realistic snow. The asset doesn't require you to change shaders or materials, but simply adds a script to your camera.
Global Snow with Flat Shaded Snow
I was seriously impressed. It took maybe 5-10 minutes of messing around with settings and I was pretty happy with how my scene looked. The bummer came when looking at the performance hit. Now a little performance hit is no big deal. The the snow scripts are not going to be used all the time. Plus the game is not an action game so a small frame rate drop is not a big deal. All the same I'm still aiming for 60+ fps on reasonable hardware.
On average I saw a 5-10 ms hit... At max settings it was sometimes 20 ms.
Full disclosure, the scene I'm running this in is huge. The terrain is roughly 2 km square and its totally NOT optimized. Meshes are not joined and no occlusion culling is being used. Many of my trees have no LOD on top of all that. Unity says it's rendering 10+ million verts, so not a tiny scene. Still a 5-10 ms hit is a lot. Not a deal breaker, but enough to make me look for another solution. The last line in the profiler is a script I'm using to control my custom shader.
If I had a smaller scene or a simpler game I'd definitely look at Global Snow as a potential snow solution. I may give it another try once my scene is more optimized too.
This is probably what I should have done first, but like a lot of us out there in game developer shaders scare me and seem like black magic. I watched a video or two and dusted off an old shader book I had. The result was the creation of a custom low poly (flat shaded) snow shader using Shader Forge to create the shader.
If you haven't seen Shader Forge it's worth a look. The interface is all visual/nodes but it compiles as a proper shader script. This means that shaders can be shared and run on computers that don't have Shader Forge. In theory this should also make the shader run more efficiently - not sure how it would compare to a carefully coded shader.
The final shader all wired up in shader forge.
The snow shader has height dependent snow and frost (upper left nodes). The frost essentially eases or fades in/out the snow. The shader also has a snow coverage slider that allows a selection based on normals so that snow can be just on top all over or somewhere in between (middle nodes).
Show Material Options
Producing the shader took me a handful of hours. Mostly because I'm totally new to shaders. But the result is pretty decent. Granted it's not a complex shader, but I'm still pretty happy with it. Below is a screenshot using my shader (same angle), compare it to the earlier screenshot using Global Snow.
Same angle as with Global Snow, but using my custom shader.
Is mine better? No. No way. But it is a whole lot faster. I didn't get exact numbers but at most I saw 0.5 ms difference between my shader and the standard shader (I'm rendering 10+ million verts in a very un-optimized scene). I suspect that was just random fluctuations more than anything.
Some work on the "snow texture" to give a bit more depth and variety will make the two very comparable. Probably moving the snow color just a bit away from pure white will also help.
I'll probably make another post, but if you're interested to see what I've done or better yet try it out and tell me how to do it better. You can check out my YouTube series on the snow shader.
This post is a continuation of a earlier post - find it here.
Continuing the journey of an environmental simulation we have now come to the hard part. Or at least the part that has been giving me fits for the past several weeks.
Creating the water cycle was a fair amount of additional code. Most of what is described in the previous post is controlled by two scripts - a climate manager and a data containing script attached to each climate block. Adding the ability for water to get transported by clouds added just a couple more scripts but plenty more interactivity between those scripts. Which makes for so many more potential bugs, wrong ideas and as it turns out a few floating point issues.
Water is stored in the ground as (shocking I know) "ground water." This will represent water that plants and crops can use to grow - with plants having ideal or preferred conditions that allow optimal growth. Ground water flows between neighboring climate blocks and evaporates depending on temperature. All evaporation and ground water flow stop if the temperature is below freezing - not totally physically accurate, but maybe to a first approximation it is... I'm not about to start modeling sublimation! This causes water to build up during the winter and provides wet soils for spring crops. All in all this matches with what I want to accomplish, but will likely need lots of tweaks and balancing.
Early Attempts playing around with rising sea level
The final step to the water cycle was to enable clouds that could carry water while being pushed by the seasonal winds. The ground water or ocean water evaporates and generates localized humidity. When this humidity hits a cloud formation threshold a cloud is spawned and the moisture contained in the humidity is transferred to the cloud. The cloud is then free to ride the winds and will begin to drop is water when it certain conditions for a climate block are met - essentially cumulative humidity plus cloud water content equals a given threshold.
Getting the basic mechanics up and running was fairly easy. Isn't that true of most game design elements?
The struggle came in balancing the cycle. Now it wouldn't be hard to simply have the ground water fluctuate with the seasons, but I want more variability than that solution could provide. I want rain shadows from hills, I want the coastal regions to be wetter, I want localized flooding, I want rain fall to be tied into larger climate factors... I want a simulation rather than hard coded weather or totally random weather.
Getting the clouds to move over land and drop water has been tricky. If the cloud drops all of its water back in the ocean that's okay, but if every cloud does that then there's no rain... Creating a on and off shore breeze was key to this. Hot ground with cool atmosphere above it causes an on shore breeze, while cool ground tends to cause off shore breezes.
Once the water has made it to the ground it then needs to cycle out via evaporation (cloud formation) or flowing back to the ocean. For simplicity (haha, I can anyone say over scoped?) I don't have rivers in the terrain. So they aren't an avenue for the water. The water must flow through a climate block's neighbors until it reaches the ocean.
Since the world should react to the players actions, but do so in a way that is "reasonable" the water cycle needs to somehow dynamically balance itself. I think the fancy term for this is "stability." Yes I want the water cycle to speed up or slow down, but it shouldn't be unstable - the "butterfly effect" is cool and all but makes for lousy game play. So far most simulations have been very unstable with tendencies towards drought or flood being very common. Hmm.
Basic climate stats plus ground water heat map
At first I tried an open water system. The ocean for my purposes would be an infinite source and sink of water. After every cycle the water content of each ocean climate block would be reset. This seemed to make sense as the amount of evaporation from the ocean would not be heavily dependent on how soaked the ground might be (since evaporation rate is dependent on ground water content). This led to a highly unstable system. Small tweaks in variables would cause massive and consistent flooding. While other tweaks would cause complete drought. Not good.
To add to the struggle a year in-game takes about 5 hours to simulate (at current settings). So Each major or minor tweak required 10+ hours (2 in-game years) to see what difference had been made. Ugh.
Why did I choose this game? I keep telling myself either "I'm an idiot" or "good things only come with hard work." The longer this balancing takes the more I tend to hear the first message.
With plenty of moaning, groaning and head scratching I tried desperately to find a new mechanism for water transport - not different from clouds and rain, but different in the mathematical sense.
I realized that my ground water flow simply wasn't cutting it. It wasn't moving water fast enough and it was generally moving the system away from stability (flood or drought).
The new model has 3 significant changes to the water cycle.
Early Implementation of a PID controller for the ground water
At first blush this approach didn't work. The result was still an unstable system quickly alternating between floods and droughts. To add to the challenge the system wasn't actually closed... Oops.
At this point I was ready to give up. Really and truly. It had been weeks of struggle with little that would work in a commercial game (even a small time indie one). I took a little time off while I ran 12-24 hour long simulations - I was irrationally hopping to find stability with small tweaks in parameters.
Once I pulled my head out of my butt I started to rethink the cause of the system not being closed and how I transported the water.
The cloud mechanism made a lot of sense as water transport, but it added substantial complexity and inter-connectivity that I wasn't excited about. The clouds had the added bummer of being physics based which needs to run on the main thread in Unity. This not only results in a (slight) slow down, but a decent amount of interplay between the a "cloud thread" and the main thread that's running the physics engine. This seemed like a very good potential candidate for causing the system to not be closed - errors given the complexity and syncing data between threads.
I rewrote the water transport code to get rid of the cloud and to use humidity to move water from neighbor to neighbor based on relative levels of humidity as well as the direction of the wind. This allows humidity to both spread around the map and to move with the wind. Since only the direction and magnitude of the wind is needed all of these calculations could be run off the main thread. Nice bonus!
I ran a few simulations with this new mechanism and was generally happy with the result, except the system was still not closed. After 30-60 minutes there was a noticeable error in the total amount of water in the system... Shit.
The errors per simulation cycle were tiny. Almost not there. I tracked down a few to simple small mistakes in coding. Simple mistakes that with larger numbers would have shown up much earlier and easier - when you're changing a value in the 6th or 7th decimal it can be hard to see the problem. Some of the others were harder to find.
Some of the error was simple floating point errors. Most values in the simulation are between 0 and 1, but a few such as the total water are in the hundreds. Now I don't claim to be smart enough to fully and deeply understand floating point errors, but I know they exist and I could see them creeping into my simulation. The errors in some of the larger values were bigger than the changes in other values...
Since I'm targeting PC (and maybe OSX) I'm not too worried about memory - at least not yet - I switched the whole simulation to double precision floats.
AND?
At long last the simulation was stable. Not perfect. Not balanced. But stable. I ran the simulation for over 30,000 cycles and saw an accumulated error of 0.00001 in a value that was close to 1000. I may have danced a little when this happened. Which led to the most wonderfully boring GIF I've made (watch that last digit change).
ground water is stable!!!
I have a dream that the hard part of creating the simulation is over. Let me have my dreams!
In reverse order... The green house effects are already "coded" but currently have no effect (multiplying by 1 type of thing). So adding that functionality might fall under the tweaks and balancing as much as anything. Not too worried about that aspect. I am interested to see how the cloud based green house effect will effect the system. The wind flows from hot to cold and clouds will have a tendency to insulate. So areas shouldn't get as warm or get as cold. Hmm. Maybe a net zero effect?
The CO2 will of course have a similar effect, but will be global rather than local like the clouds. The difference with the CO2 effect is it has a lot of interacting parts. There will be several CO2 sources and several sinks. Once again getting that balance could be difficult. The first phase of the game is unlikely to have substantial sources of CO2 so full implementation of the greenhouse effect may wait until large industrial structures are available.
I wanted one more picture in the post. So here's some poppies.
Pollution will just be a double precision float variable like ground water. My plan at the moment is simple, have pollution move with ground water. A percent of the pollution will move with each cycle and spread to neighboring climate blocks as well as into the ocean. There will be some decay of pollution - i.e. it just goes away. How exactly that will work is unclear. My thinking is that pollution will accumulate in the ocean and break down while there. This leaves the door open to allow pollution to make its way to the player and NPCs via drinking water and eating fish or other food containing pollution. We'll see.
With the simulation now stable, I'll be turning my attention back to creating a playable game loop. There'll likely be a "Part 3" to this series of posts, but that might be a while.
When I settled on the current game design idea a central piece was an environment simulation that would effect player experiences and that player choices could in turn effect - creating a feedback cycle.
Iteration 737 - Humidity Heat Map
The goal wasn't (and still isn't) to create an environmental simulation that was "physically accurate." The goal was to create a simulation that was an abstraction of reality or at least had some of the key features seen day to day and year to year. I wanted the player to be able to alter the world around them in a way that reflects reality but that doesn't need to be 100% realistic.
The first step in creating the simulation was to break up the environment into a series of blocks. Each box would have it's own set of environmental variables (temperature, humidity, ground water, wind, etc). These "climate blocks" would interact with it's neighbors to create localized weather and also to allow local variances such as terrain height and cloud density to impact the weather.
Test Terrain with Climate Blocks
As the simulation developed and more complex interactions were add a few changes/additions to the climate blocks were needed. The first critical piece was the addition of an "atmosphere block" on top of each climate block. The atmosphere block is simulated air space above that often has a different temperature than the air on the ground/ocean. This allowed for up and down drafts that could help move clouds and cause an on or off shore wind depending on the season (more about this later). Without an onshore wind clouds and more importantly rain rarely make it to the land.
A second key addition was the classification of terrain types. At the time of writing this the simulation is only using three types of terrain ocean, grassland and mountains. This largely controls the "target" temperature of climate block and in the case of the ocean maintains a constant saturation of ground water. Oceans have moderate target temps with smaller seasonal and daily fluctuations. Grasslands have a higher target temp than the mountains but both have larger daily and seasonal fluctuations than the ocean.
Seasonal sun intensity is controlled by an animation curve that is sinusoidal in shape. Max values occurring during the "summer" and of course minimum values occurring during the "winter." A second curve was used for daily fluctuations. The curves are currently identical... That may change in the future.
At first these curves were used and tuned to be a true energy flux with energy being added during the day and energy lost during the night. While more physically accurate and potentially allowing for more emergent weather, it also made it far more difficult to tune and balance. After significant testing and tuning this method was abandoned for a more controlled method.
Each terrain type has a median temperature that serves as a target temperature. There are also values for seasonal and daily fluctuations of that temperature. This means that median temperatures + seasonal flux + daily flux is roughly the high temp and likewise median temperature - seasonal flux - daily flux is roughly the low temp. Variance from this is caused by the connection of neighbors and other factors.
One of the other factors that adds some variability is the average height of the terrain. In the real world the higher the terrain the cooler the air. To reflect this each climate block samples the terrain height at multiple points and calculates an average height. From this the median temperature is adjusted slightly. This provides variation in the climate that (hopefully) lends itself to more interesting and emergent weather.
Wind in the simulation does not have a physical presence and is simply a Vector3 that stores the wind velocity. The wind for an individual climate block is calculated based on the temperatures of the neighboring climate blocks, including the upper atmosphere. The inclusion of the upper atmosphere allows up and down drafts which allows for onshore or offshore breezes (as mentioned above).
To calculate the wind the simulation calculates a temperature difference between the climate block and a neighbor and then multiplies that by a vector that goes from the climate block to the neighbor. Final direction (sign) of the wind is based on blowing from hot to cold.
The simulation sums all the winds due to neighbors to arrive at a (nearly) final wind value.
A prevailing wind is then added. This allows larger global winds to be added to create larger and different weather patterns. The strength of the prevailing wind is a tune-able variable. Current testing is with an in/out pattern that helps to blow clouds away from land in the summer.
An early WEather Prototype
After the prevailing wind is added the vector is normalized. There was some debate about normalizing the wind... In the end the choice was made to keep the normalization as this meant that clouds always would have some wind. It also prevents unrealistically large or small winds that become problematic when trying to transport clouds/moisture.
The final step is a check on the vertical component of the wind. Since the upper atmosphere is often at a very different temperature it can therefore be the dominant contribution to the wind. This is a problem due to only simulating two layers of atmosphere rather than more layers or the ideal of a continuous atmosphere. Effectively the vertical component is clamped to a range between -0.5 and 0.5. This helps to keep clouds generally moving horizontally.
Additional controls are needed to avoid the clouds going too high or going through the ground. The altitude of the clouds is mostly visual as the horizontal location determines where clouds can deliver rain. Because of the this a simple min and max altitude are set. Clouds check against these values and degrees of freedom are restricted in the rigidbody to prevent clouds from going outside the bounds. Checks on vertical velocity are also necessary to allow the clouds to move away from the limits.
In Part 2 I'll discuss the most difficult part (so far) of the simulation that being the Water and Rain Cycle. Or more specifically the balancing of that cycle.
Game #2 (still unnamed) is centered around economics and the environment. So a natural starting point (at least to me) when thinking about a game loop is farming. Yep. Farming. Does the world need another farming game? Hopefully!
A farming loop needs to allow the player to plant, harvest and sell crops. Nice and simple. Right?
Sunflower Farm: Testing visuals for setting up simple farming.
This means that models need to be built, stores need to be coded and basic UI needs to be added. So I setup a quick and dirty (ugly) inventory that allows the collection and basic handling of items. Items are stacked for organization and stacks can be split and recombined. Nothing fancy, just enough to play test. (A good tutorial to get you started.)
An ugly but functional inventory UI
Basic animations allow a player to dig and get some tilled soil in which to plant a crop. Crops can be added, but I didn't grab a image.
Testing of basic digging mechanics.
On top of this crops should respond to the environment. Crops should grow when the conditions are right - it doesn't make much sense for corn to sprout when it's below freezing or there's no moisture in the soil. So this means setting up each plant with ideal conditions and scripting growth. Still not too hard.
This is apparently what I think a carrot should look like... The jury is still out on this one.
Which brings me to the current struggle...
Getting a working environmental simulation was a matter of a few hours of coding - okay probably double digit hours of coding, but still a very reasonable effort.
So far the wind is working, temperatures are reasonable, seasonal changes are working, it's even multi-threaded (not coroutines!) so there's no real performance hit. All good so far.
And then comes the water cycle. Damn the water cycle!
Ground water and ocean water evaporates into clouds. Clouds move and release water as rain. Sounds easy enough, but we all know what happens when you assume things.
The problem is getting a stable amount of ground water from season to season. How fast does the water evaporate? How fast can the clouds move? How much water can the clouds hold? How fast does a cloud release its water? How quickly does water drain back into the ocean? How many hours can I spent looking at a heat map?
Visual Feedback on ground water...
So many variables. Each with the ability to muck up the whole simulation. I could hard code values, but then I'd lose the players ability to screw up the world... And that has to be part of the game. Its part of the real world!
So who's idea was this game anyways? Why couldn't I try to make a 2D platformer like everyone else?
A few changes, including fixing a stupid mistake, are giving me some hope. I have now seemly stabilized the lowest ground water level for a given thermal input/output. This should allow players to mess up the CO2 level and get a higher evaporation rate and thus drier soil... Or allow other season to season changes to impact crop growth.
One change was to make the ground water flow rate respond to the amount of water in the soil. It is also a function of how many environmental cycles there are per game year.
This basically slows the rate if the average ground water dips below 0.5 and raise the rate if it climbs above 0.5 (almost all of the environmental setting are floats between 0 and 1). Not a perfect feedback loop, but seems to help contain the crazy swings. This would seemly allow the (minimum) average ground water to be a function of ground water flow rate, evaporation and temperature.
If I can stabilize a minimum ground water level then I should be quite a bit closer to getting a overall stable and reproducible water cycle.
Fingers crossed.
Fracture the Flag is my first and only game. Not the only game that I've published. It's my only game, period.
I'm pretty damn proud of FTF. Sure I had dreams of selling 100k copies or 50k copies or even 10k copies. None of which happened, but the real goal was to learn, to build a (small) community and create a game that at least some people thought wasn't total garbage.
While the code base is a mess of poorly written spaghetti code it mostly works. I learned how to better organize my code and how to create more efficient code. I discovered that multiplayer is great idea, but like so many before me, I also learned it's freaking hard to implement. What works well on two test machines on my desk is very different from two players that are on opposite sides of the Atlantic. I figured out a basic workflow from Blender to Unity. I stumbled through the process of creating basic editor extensions to make my game development a little easier. I also learned I had no idea how to set up the lighting in a scene and still don't.
Managing the game and community surrounding the game after the initial Early Access release was stressful, but still more rewarding than I could have expected. I had no idea how buggy the game was. Not really. I had no idea how thoughtful and kind some people would be. So many people were constantly giving feedback and helping make the product better. My biggest lesson in taking a game from Greenlight to Early Access through to Full Release is simple:
Folks can smell from miles away a developer that just wants a quick paycheck. While not every interaction in the FTF Steam community was positive I found most can be turned that direction with a little humility and honest listening. Not every customer has a good idea or even a valid complaint, but most do. So I did my best to listen.
Case and point: Two friends each bought a copy of FTF hoping to play together. They quickly found several game breaking bugs that earlier players had simply ignored or hadn't noticed. These two players proceeded to rip FTF to shreds on Steam reviews - yes plural, they each wrote one. Both brutal and brutally honest. I didn't respond to the review, but when they posted in the forums I took the opportunity to start a conversation. After the exchange of several comments I had great feedback from the players and removed several sizable bugs from the code base. They dropped their negative reviews and decided not to ask for refunds. I never saw if they left positive reviews, but the huge negative reviews were gone. That's a huge win for a solo developer and worth every ounce of effort.
When I first had a vision for FTF I thought surely the game must be worth $10-12. I mean I've worked so hard on it! It's got multiplayer for crying out loud. As it got closer to the Early Access release date I got a bit gun-shy. I refocused on my main goals. Making money would be nice, but it wasn't the primary goal. So I cut the price. I cut it a lot. Down to $2.99 in the US market. This seemly had the effect of lowering expectations and doing so in a helpful way.
The early reviews were incredibly positive. Early on FTF has a 90+ percent positive rating - and not from people who got free keys. The game sold reasonably well in its first week with sales continuing to trickle in as the weeks passed.
I fixed bugs and added features before the full release. I added so much! So many good ideas came pouring in from the community. So I decided to raise the price. To the price of a latte in Aspen... All of $4.99. Sales slowed and expectations seemed to rise while the rating on Steam dropped to what it is now, 78%. Was it a mistake?
Sales were modest but better than I hoped. The first day as a full release saw almost no exposure on Steam but was still the best sales day in the short history of FTF. More copies of FTF were sold in the those first three days then in the entire first week of Early Access. Not too shabby.
I hear people say you only get one release. Maybe that's true. But I think building a community and getting positive reviews helped to serve up more sales then FTF would have seen had it jumped straight in as a full release. I know I'm more likely to buy a game that has decent reviews and has been "out" for at least a little while. But who really knows, maybe I'm just seeing what I want to see.
7 months after the initial Early Access release FTF is essentially "finished." No, it doesn't have every possible feature. Yes, there are still bugs. And no, I didn't make enough to quit my day job - not even close. Sales are generally within the margin of error shown by Steam Spy but I have often seen the numbers dip too low (but I've never seen them go too high). I made enough to easily pay for a high-end mountain bike and new set of skis and boots. For a guy who's day job requires bikes and skis... Not a bad result.
My hourly wage? Probably didn't make it to minimum wage... No, let me rephrase that. I didn't make minimum wage.
You can see sales spike on the release day and then again during sales and of course the day FTF came out of Early Access.
So now the game is in the long tail. Sales have slowed as expected, but the trickle is still going. At least enough to buy my wife and I dinner out once a week.
No multiplayer. While I nearly dipped my toes into that pond again for game #2, a quick read of some FTF comments reminded me of the horrors of trying to sell a multiplayer game as a solo developer. This might be a lesson I have to learn more than once...
For game #2 I want to find an outlet for early builds beyond Early Access. Find a smaller market. Find a community interested in giving feedback and more willing to take risks on a title. Take the time to polish the game before heading to Steam.
As a solo developer I need my games to be more procedural. With FTF building a level took days and the way I built the level meant I often couldn't even make small changes without completely scrapping the level and starting over. Got a rock in the wrong spot? Combined the wrong meshes and can't get good occlusion culling? Too bad.
Game #2 needs to be a game I want to play. FTF started as memories of playing Crossbows and Catapults a kid. I loved that game. Then FTF started to morph. It turned into something totally different. Sometimes for good reasons and sometimes not. It's not even close to the game I first set out to make. As a result I tried to squeeze into an already defined genre and all the expectations that came with it. Slowly, with each added feature FTF became a game I wasn't really interested in. So, now I dream of the game that I simply want to keep working on. Wouldn't that be magical?
Game #2 is next. I have a vision, but not a complete plan. I want to create something different. (Shocking I know). I am fascinated by how poorly we treat each other as humans and how poorly we treat our beautiful planet. I dream of a game that could explore those very real issues while still being fun and challenging. In my head the game is so hopelessly over scoped I worry I may never be able to finish it or if I do it will turn to total shit.
So ignoring common sense, step one is to create a game world that I want to spend more time in...
I know that's ass backwards for most folk, but a world that is pleasant and enjoyable to walk around it seems like the first step in learning to appreciate that world.
The page has just begun to be built, but you can see what there is to see about #2 here.
Support for FTF will continue but will be focused on fixing bugs rather than adding content. I look forward to taking all that I learned over the last few years and applying it my next game...
Two years ago, I talked my school into allowing me to teach an intro game development class. I still can't believe it and I get a huge grin on my face when I think about how lucky I am. This fall I convinced folks that I should be allowed to run a week long intensive course about making low poly renders with Blender...
Sure I've done enough "box art" for Fracture the Flag to know the basics and produce work that's "good," but I've spent almost no time making non-game art.
Oops.
So in my game dev course I assigned a project where the students had to make box art for a new game. Basically an excuse to work more with Blender and dig a bit deeper into the program. The first part of the assignment was to find a published low poly image and use it as inspiration and guidance.
I joined my students and began to create my own low poly render. I choose Winter Night by Vitaliy Prusakov. I loved the lighting and the simple, but elegant colors.
My result was far from perfect or as tasteful as the original.
 |
| Snowy Village |
Not bad, but I thought I could do better. Those roofs? Where'd the snow on the fences go? The fence rails are too straight...
I was having so much fun I wanted to do another. So I started working on the view from my front door.
The result is (obviously) highly stylized and somewhat idealized. I think its also step up in overall quality.
 |
| Backyard |
Creating these images has been such great practice, not to mention great fun. I'm sure I'll make a few more, but I'm dreaming of getting a similar style into Unity for my next game...
I think I've figured out the light baking and textured needed to make it work at 60 fps and I'm pretty excited about it. It would be such a step up from Fracture the Flag's art work :)
Portfolio and Development Log for One Wheel Studio.
Powered by Squarespace.
