Saturday, December 31, 2016

Back from a short coding break

I admit it. I spent a few days off without touching the code.

It was partly because I felt like I needed a break, but mostly because I'm now tackling a piece of the code that had been looming over me for a while now: the job system. How it should work, what method I should use. Straight code (without inheriting from MonoBehaviour) and lambdas? A text-based switch directory? Actual job GameObjects that get scattered around my map?

I can't say I know the answers to that, but I have an idea of what it should look and act like. So I'm going to think aloud here for a bit. Don't mind me.

The simple version: we have two ways of queuing up a job. We can right click an item (using raycast) and pick a task from the generated list, or we can grab a mode from the right hand menu and drag and drop.

This means, as per my MVP goals, this should happen:
  • On build (tent or fire) a ghostly outline of the tent or fire follows the mouse. On placement (left click), the unfolded tent or five wood pieces are consumed. Ideally (for later) we'll have the ghostly outline turn red on invalid placement sites.
  • A tree marked for chopping should have an image overlaid on it to show that it's going to be destroyed. Maybe a red X.
  • A patch of land to till should have ghostly tilled tiles on each tile.
  • A human moving to finish a task should have this task's name in their info box.
  • Each task will take a certain amount of energy to fulfill.
  • After the task is done, a method should be called. This will change, destroy, or spawn something depending on the task.
  • Humans should be self-assigning daily need tasks, like eating and sleeping.
So, in short, a job should be able to require elements, and queue tasks ahead of ourselves to fetch and bring those elements to the work site. A job should have the appropriate preview image drawn on assignment. A job will require a certain amount of time spent before completion. On completion, the preview image vanishes, the final on-complete method is triggered, the job is removed from the queue.

... ... Right. So. Big task. Lambdas in the design for certain, no matter how we go about it. ... I think I'm just going to have to dive in, and it'll be complicated no matter which way I go.

Monday, December 26, 2016

Post-Christmas Update

Current Main Menu

Loading Screen

From Christmas eve until now:
  • Main menu is in. (Background will do for now.) 
  • Loading scene animates.
  • Camera zooming with the scroll wheel in, while maintaining a pixel-perfect rendering ratio.
  • UI text has a black outline, so it can be read clearly over the game background.
  • Inventory items and the UI Inventory manager are mostly finished.

Saturday, December 24, 2016

In which many things are accomplished

I've managed to be pretty productive today. :) Objects overlapping each other on the map generator has been fixed, along with a few other small items. I'd disabled the main menu and mouse controls while focusing on the map generator. Today I added it back in.

Some items (the flowers) can be tilled through. But we need to go around the rock.
The stockpile area's been marked! Not functional yet, and I'm not sure how I want to display it long-term.

Friday, December 23, 2016

Tree and rock managers are in.

But mostly, at the moment, I'm having fun dropping art into my map generator and seeing how it looks.

Thursday, December 22, 2016

The Biome Generator is up and running!

It's up!

To make my map now, I go to the map controller, tell it the map size and layout I want (this is a 20x20 tile island map), what biomes to use and in what amounts (meadow, 100% for testing). Boom! Installed landscaping objects that works with my A* pathfinding graph!

I still have a few things to work out, of course:

  1. There's some overlapping, which isn't supposed to happen, so that's one bug to root out. 
  2. In case of overlapping, we shunt the game objects to the next open spot. This should work on some terrain but not others; forest items can bleed into meadows, but not the lake, for instance.
  3. I need to finish the placement method so that it supports multi-tile objects;
  4. Implement padding around certain items, like trees.
  5. Add in secondary terrain splotches (optional, biome-based).
  6. Add in pathways / game trails (optional, biome-based).
  7. Register trees with the tree manager, rocks with the rock manager.
  8. Make the code nice and pretty.
Most of these are small tasks; I could take care of most of them by tonight if the migraine allows and Christmas at the latest, 

Also, having some optional sandy shores automatically slip in between the meadow and water would be nice, but for now it's not needed. MVP first.

Tuesday, December 20, 2016

And back to work

Drugs have been had-- it's a lesser dose than I need, but at least it's been enough that I can think straight again. Yeah! I've been overhauling my random generation methods, and I've got my Voronoi and relaxation methods working now.

For the non-programmers, let me tell you about random numbers. You'd think random numbers would be scattered evenly all over... but it's not how it really works. Random numbers are... well, random. They clump and group and piggy-back onto each other. Semi-random numbers are harder.


Random numbers-- raw out of the random number generator.
So, I went in and started working on a Lloyd's Algorithm (this is the map generation stuff I'd mentioned earlier). It takes about two iterations to start looking nice.
After my new relaxation method-- much more evenly spaced.
I'll be using this on the tiles, for procedural item placement, ect. It's just one method, but it's an important one.

Friday, December 16, 2016

In Which I Proclaim My Love of Drugs

Just a quick check-in. I haven't gotten much further on game things for a little while; long story short, I'd gotten some wonderful drugs two weeks back that bludgeoned the never-ending migraine into submission. Which you'd think would be a good thing.

For a short while I was feeling well enough to walk around, and I even got to sip fancy coffee at my favorite coffee shop and work for a few hours. I watched a whole movie without much pain. It was amazing.

Except there was a problem, with those drugs: one, neurologists are  shy about prescribing them, because they're heavy-duty, and two, they cost the earth, and if the insurance doesn't pay for them there's no way we could afford them.

Then the neurologist who prescribed these drugs went on vacation. His replacement was not okay prescribing me such a large dose. Then, when she finally broke down and ordered a lesser dose, the pharmacy started buckling. So pretty much everything went wrong, and my migraine came rushing back, and I don't know if I'd forgotten what it was like to not be in constant pain or what, but the pain was so bad that I could barely think straight, much less continue programming.


So. Good news: we finally got another dose of those drugs, and once they kick in, I'm going to be a lot more productive. We will see... I'd love to be able to attend Christmas this year. I don't think we'll even have a tree of our own... there's no way I'd be able to decorate it the way I feel now.

Tuesday, December 13, 2016

Blueprints to Built

Roughing out how building will be handled, once a blueprint is laid down, in images. Imagine tiny pixel-people dragging in building materials.

Finished Product (?)

Biome Studies

I got to thinking-- random terrain generation would be easier if I had a clear idea of what my target is first. These are done in Photoshop with LPC tiles, though I did respect the grid. Freshwater beaches, wetland, and ruins will follow.

At the moment I'm using Voronoi's algorithm and Lloyd's relaxer to grab clumps of different terrains and spatter them on their own. Chunk of grass, chunk of dirt, chunk of sand, ect. In the future, based off of these images, I'll be using that algorithm to determine the biome instead.

Forest Study
Meadow Study
(Retro) Mountain Study

Monday, December 12, 2016

A Look Under the Hood: Piecing Tiles Together

It took me a while of trying out different things before I found a way to create a retro map that was procedurally generated and still looked great. Specifically, getting the tiles to render in such a way that they looked correct and seamless, no matter how many terrain types were joining up. I thought I'd share my method for others looking to do the same.

Photoshop View
Transparent .png
(These images are courtesy of Lanea Zimmerman (aka Sharm) and the CC-by-SA 3.0 license; you can find more where that came from here).

You'll need at least two types of terrain for the technique we're working with, sliced into square blocks (these are 32 x 32 pixels). Notice that the graphics are on a transparent background, and that they tile seamlessly. This is very important. The row of solid blocks (6th down) are for variation, and while they're not necessary, they greatly improve the feel of the terrain. The two loners on the top left won't be used at all-- but they make nice decoration.

So, say that you're dealing with a checkerboard of terrain sprites on your 2d game. You have three types of terrain: water, dirt and grass. Pretty simple stuff, all things considered. Just rendering the base, flat tile doesn't look very good, though. In fact, it looks pretty terrible. Hard, unnatural angles. Even the variation blocks don't help that much. (This overview is assuming that your land masses are in semi-random blobs. I can cover how I handled my map generation some day... but not now.)

8 x 8 tiles in three terrains, using only solid blocks.
So, we have our transparent png, we can easily cover up those raw edges. But then you run into another problem. Our 'transitions' take up about half a block's width-- meaning we'll be drawing our grass' edge out onto another tile terrain type. So-- what block takes precedence? Does grass get to creep onto the dirt and tile? Is dirt or water more important? Are we even asking ourselves the right questions?

This was my eventual solution:

Rather than trying to tell what types of tiles should get to keep their land, keep it as simple as possible. We only care about each of these four corners: North, Diagonal, East, and itself (Center). Name the tiles of your terrain like that: Grass_ + whatever corners your grass covers. So for instant, that piece of grass in the upper right corner of our initial graphic would be Grass_NDE, because the lower left corner is where the transparency sits. Just be consistent in your naming conventions, because it'll be important later.

And there it is. The fifteen tiles you really will need. (I just named my block of solid grass Grass.)

Next, I configured my tile game object by making four children, each with its own Sprite Renderer component, and I named them Base, Neighbor1, Neighbor2, Neighbor3.

Then for the code. The short version:

Step 1. I made a dictionary to hold all four corner variables that we were working with. If I'm at the top or the right edge of the map, I use the tile's own terrain for the non-existent neighbor.
Step 2. I made a list of all the different types of terrain present, and then I sorted them in a custom order. Nothing too complicated here, but this step is important. That said, feel free to try out different rendering orders.

List<string> sortedTerrains = new List<string>();
if (unsortedTerrains.Contains("Sand")) { sortedTerrains.Add("Sand"); }
if (unsortedTerrains.Contains("Tilled")) { sortedTerrains.Add("Tilled"); }
if (unsortedTerrains.Contains("Dirt")) { sortedTerrains.Add("Dirt"); }
if (unsortedTerrains.Contains("Stone")) { sortedTerrains.Add("Stone"); }
if (unsortedTerrains.Contains("Water")) { sortedTerrains.Add("Water"); }
if (unsortedTerrains.Contains("Grass")) { sortedTerrains.Add("Grass"); }
return sortedTerrains;

Now we have a list of terrains in the order we're going to render them. Stick that sucker in a foreach loop. Solid base, each further terrain type will take a corner.

List<Sprite> spriteList = new List<Sprite>();
foreach (string terrain in terrains) {
// The bottom layer will have a solid tile.
if (spriteList.Count == 0) {

// tileTypes is our dictionary with our corner data from step one
spriteName = terrain + "_";
if (tileTypes["N"] == terrain) { spriteName += "N"; }
if (tileTypes["D"] == terrain) { spriteName += "D"; }
if (tileTypes["E"] == terrain) { spriteName += "E"; }
if (tileTypes["C"] == terrain) { spriteName += "C"; }

if (IsTerrainValid(spriteName)) {


And... that's pretty much it, with some error checking and such. The additive naming convention does all the work for us. Stick each sprite into the appropriate SpriteRenderer component of our tile game object, and you have a layered tile without much work.

Sunday, December 11, 2016

To-List Update

So, here's a list of things I haven't done, and what needs to happen with them. Feedback encouraged!

Random, distinct biomes. I've been reading some very good articles about faux random placement of objects (the best one was Random Scattering: Creating Realistic Landscapes by Mick West). Right now, my object placement is a mess. I have C# dictionaries of different terrain types, and to place the trees I pick a random point, see if I already have a tree there, and if not I place it. Too many failures to place a tree means the space is filled, and I quit out of the method.

It might work for the trees, but what about the crops? What about the rocks? What about the small plants I'll be scattering around? Do I pick random tiles and duck out if they're occupied too? How will I even know if they're occupied? I haven't put that code on the tile; it doesn't know what's on it yet. Maybe a 2d array of booleans on the Map class and create a GetClosestEmptyTile(Tile tile) method?

I have some ideas about hand-placing distinct areas in Photoshop, then analyzing what makes them look that way, some ideas on a Random Distribution Manager to track random objects and the likelihood of them spawning, several ways to address the 'is this space empty?' problem. I haven't settled on the best approach.

Inventories and inventory items. I have a few small items that characters should be able to carry around, place in stockpiles, ect: wood piles of various sizes, apples, and corn. Right now, they're just game object prefabs with art. I haven't thought of the best approach to handle them yet. What's the difference between a wood pile that spawns beside a cut tree and a stack of wood sitting in a stockpile? Decisions.

Pathfinding and jobs. Okay, I actually do have the pathfinding system set up and ready to go. I haven't put it in yet because I'm not sure how to queue up such a huge range of jobs. Instant gratification tilling and tree chopping have worked well as the end result, but that won't stick around.

(Also, I haven't added pathfinding yet because I haven't decided on that 'what's on me?' tile dilemma, and I need a system in place so I can properly add in movement costs per tile for pathfinding weighting. You wouldn't walk through a wall to chop down a tree on the other side.)

Stockpiles and storage zones. The other way the tile expects things to be placed on it. It'd be dead easy to tell tiles to accept one stack of inventory items (once I decide how inventory items should work), but again, movement cost and inventory. Also, having each character have their own, small inventory so that they can carry things.

* * *

So if you look at my game goals list, most of them involve these four things. Falling hunger bars for the characters isn't going to get done without a self-assigning 'eat food' job. I need to make some code architecture decisions and knock off these items next.


Destroying the environment, one tree at a time.
The trees now have falling animations! I spent some time completing the apple tree paintings today, then put a few hours into coding it in. I'll have a particle effect make the area explode with leaves between the crash and the appearance of the log graphic. (Which will be a new learning curve: I don't know much about particle effects at all.)

It'll look less repetitive once I get more trees in. Birch and oak, I think, to start with, but I haven't settled on any one thing yet.

That said, I need to remember to keep the game as small as possible. One type of tree means I can perfect how trees are set up and managed, and clean up the code to be as single-purpose as possible. Having corn as my only crop means I can focus on how the crop grows, and identify any complications while the code is still simple. There are a lot more crops on my to-do list than just corn, but while adding them all it at once would be a lot of fun, it won't get the game built faster.

Note to self-- get a better random object placement system. The placeholder I have now is a hackneyed jumble of nonsense duct taped together.

Friday, December 9, 2016

Tilled Fields!

And-- I'm working on getting the right-hand menu buttons to work. This one was the first:

Dirt and grass tiles can be tilled! Rejoice!
Right now we're doing instant-gratification tilling, and I don't have a nice UI up yet to show where the user is dragging and dropping.

I'm thinking about doing the UI next, followed by the chop wood feature, followed by mining since both those things will follow essentially the same format.

Edit: drag-and-drop select-drag box added and functional! Fancy cursor added in for clarity.

Crop fields AND a select box to show where they'll be dragged.

Thursday, December 8, 2016


So... there is a small problem. My own art style does not match the LPC art that I've been using (which is Creative Commons-by-SA 3.0). So... if I want an apple tree to appear with fruit, I need to go make the fruit myself and add it in, and then you have a style shift.

The original tree, by Johann C.

My original artwork. (License CC3-by-SA)

I mean, granted. Mine doesn't look that bad. ... Except that if I use it, I'm going to have to draw so much art for this game... I can't even imagine.

I'm trying them out in the game anyway. We'll see how well they go. I'm going to have trouble if my own art clashes too much with everything else.

Tuesday, December 6, 2016

State of the Game 2016-12-06

Just a quick check-in!

Had another doctor's appointment. Completely exhausted by the end of it, but I managed to work several hours on the game anyway. The escape menu is installed and fully functional, except for the save and load buttons (I put a save-game Unity asset in my Christmas list, so I'm hoping on that). I've also finished the right hand menu, minus the mini-map functionality. Buttons can be highlighted and pressed (but the features don't work yet). More importantly, I've implemented a basic speed system, so the game can now be paused, played, and fast-forwarded, and my test army responds accordingly.

Haven't finished the animation bits yet-- will get to that soon. I've also found an open-sourced 2d highlighting script, which I mean to try out. No idea how easy or hard it'll be to make it do what I want, and I'm too brain-dead today to read over the code, but if it is, you'll see the left-click 'selection' stuff done really soon.

Also, I'm a GIT perfectionist and I need to just commit my non-perfect code... but maybe tomorrow. :)

Sunday, December 4, 2016

UI designs!

Current status: most of the human bodies have been animated and hooked up properly. Once done, I'll need to do the same to the hair and clothes, so sadly I'm going to be limiting their outfits pretty severely to start. It just takes up so much time.

I've taken a break from animation to start working on the HUD (heads up display), though. My current drafts, done in Photoshop:

Main Game Menu
Pause Menu

The UI graphics are made by Buch at

The right menu buttons go in this order: Harvest, Till, Chop Mine, Build, Blueprints, Zones (which includes stockpiles). The round shape in the upper right hand corner will be the mini-map. I'm wondering if a 'plant' icon would be good there-- or, given I'm tracking seeds in the inventory, right click on seeds, click 'plant' then drag-and-drop on a tilled field. ... The last sounds pretty good, actually.
(on right click)

I also haven't decided on how to do days / months yet-- it's one of those things I'm still thinking about. Stardew Valley did full day/nights, but limited each season to 28 days, which had a good pace to it. Rimworld does the same, though the seasons are shorter. Towns just counted the days without a firm day-night cycle. Don't Starve made nights interesting by making them hostile and madness inducing.

Next up-- finish the animations for people, clothes, and hair. Make the right-click action menu UI (added!). Make the left click 'selection' quickview UI. Get a lot of people's opinions and critique about the HUD, then program all these UIs into the game.

Saturday, December 3, 2016

Hum 'The Flight of the Valkyrie' as you press play

More not-entertaining programming stuff-- I ran into a hard block trying to select objects on the screen by clicking on them (long, technical story that involves OOP butting heads with the component system used in Unity-- I'm trying out some new approaches).

And then I tested a very rough 'idle' script, and... well. Watch it.

Thursday, December 1, 2016

Navigation! Skin edits! Standardizing hair!

Lots of little updates-- the front side of the right click panel is in, and when over a tree 'Chop Tree' is an option. When over ripe crops, 'Harvest Crop' appears. I can also tell characters to go to a certain point, as below:


Rocks are now randomly spawning on the sand biomes, but after looking at my map generation functions I've come to the conclusion that that needs a massive update, and maybe a level editor interface so I can fine-tune the settings.

I have also been working on the characters' and my color scheme, and I've been using the Humanae Project to get a better sample of skin for my five skin tones. (By the way, anyone who wants to get good at sketching out a lot of different types of faces very quickly? That's a great place to practice.)

My previous five skins.
After Humanae.
It may be just a little thing, but I'm really loving the new gradient, particularly since that previous 'olive' shade never felt right. The adult skins will follow. I'm going to take a coding break to get the animations in and settled, then I'll be back to finish the job-system.