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.

Observe:

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.

Sigh.

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) {
spriteList.Add(terrainSprites[terrain]);
continue;
}

// 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)) {
spriteList.Add(terrainSprites[spriteName]);
}
}

this.AssignTerrainBackgrounds(spriteList);

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.

Timber!

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

Trees!

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.

Observe:
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 ConceptArt.org.

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.

Wednesday, November 30, 2016

So, that code I was struggling with the other day, trying to match the GUI menu thing to the pixel screenspace versus the world space?

optionMenu.transform.position = Input.mousePosition;

So. Yes. That happened. :facepalm: The option menu works wonderfully now. Except for the functionality, anyway. Today, we'll be getting the job queue back online, and ideally I'll have tiny people harvesting food and trees and visiting tiles soon.

Monday, November 28, 2016

Not dead (it just feels that way)

No new posts over the weekend; I was hospitalized and large amounts of drugs flowed through my veins. Quite literally-- I'm still feeling sick from all the IVs. Programming is really hard under these conditions. Particularly when you have a giant needle sticking through the top of your hand.

I'm fiddling with getting a right click 'action' menu up and running at the moment. No luck yet. I need to figure out how to transfer a GUI menu from screen space to world space, which is probably dead easy once my brain can think straight.

Anyway, just dropping in a note.

Friday, November 25, 2016

Imagine all the people...

Thanksgiving was lovely, but trying to attend a noisy family function for even a short while completely destroyed me. Stupid migraine. So putting in the job system hasn't happened yet (though I may try tonight after a nap).

In the meantime, I found pretty things: a GitHub LPC characters repository!

I'll need to do standardization and color corrections and such when I can look at bright lights again, but for now this is more than enough.


Thursday, November 24, 2016

Hair and inheritance, the sequel

10 hair colors is probably too much... but it's pretty?
I was working on a good system to place and stack inanimate objects on a tile in ways that made sense, then took a break to play with more hair. Since I've gotten a lot of different art pieces from several artists (I've added a credits page), I get hair that's not all standard hues. This cheat sheet should help.

That's the problem with procedural games, really. A lot of 2d game sprites were made to be placed by an artist, not a foolproof-all-angles set up. Having ten hair colors means I should have ten hair colors in short, medium, and long hair. It really adds up quickly.

But, we'll make the genetics and hair growth much, much later. For now, I'll continue using my current code (and a four-options switch) and put the rainbow aside.

In the meantime-- I give you completely procedural forests and corn plants. This time, it's the actual tree and corn plants, not just their image stamped over and over, which means it will work with our pathfinding system. Which is now installed!

Next up-- re-installing the job queue classes that I made while following Quill's tutorial. The people will wander (idle) by walking a few steps this way and that when they have no jobs, and they'll navigate through the forest to cut down a specified tree, ect.

I know this looks like other screenshots I've posted... but those are real, proper trees. ... We'll work on variety later.

Wednesday, November 23, 2016

Getting back on track

It's a tiny, uncomplicated structure right now-- but that's rather the point, I think.


Later on, I'll be expanding on those-- different types of animals, different types of plants. Equipable items will be a category under InanimateObjects. But it gets my point across.

Instead of having the tile tell us how many 'slots' of room it has in it, I'm considering letting the items tell if theres' room for any more objects. I'm not sure how that'll work with items that are multiple tiles wide and high, though. Still thinking about it.

Monday, November 21, 2016

In which hairdos are more fun than hierarchy

Today started with the best of intentions. Get the A* pathfinding system going. Install the tree's trunk (and only the trunk) to the tile to prevent characters from walking through them. Juggle several different sample plants to make sure the system is running well.

... And then I thought, "But first, let's try out some hairstyles." ... And then the rest of my day was shot.

But they're cute at least?

Editing the pretty dress to fit on all female bases...


Clothes for all!

Post Code Restructure!

Tadah!

So-- question. I've got five skin colors, and I'm dubious about the mid-range one, which I'm calling 'olive'. The character on the left edge of the third row is an olive.

I'm really not good at judging / adjusting digital color at the moment, because the never-ending migraine bludgeons me into a whimpering puddle if I try to look at a screen without my screen-dimmer. Anyway, I keep thinking that maybe that olive is too gray or too green for skin, but since everything on this screen is kind of gray anyway, I just can't tell. Opinions, anyone?

All in one nice little block. For now.

B.T. - Before Trees

After Trees!
(Okay, the trees aren't really in yet. Not properly anyway. Going to work on getting them installed the right way next.)

Sunday, November 20, 2016

Brief Update: Structural Decisions

A quick note-- still working on design and structure and such decisions. Things like "Wait, do we want to track animals' hunger and diets?" and "If we have a world map and a local map, and some of the characters leave their starter map to scavenge from the local town, do the other characters get paused? Does the AI take over for them??". There's also the famous "to OOP or not OOP?" question; lately, a lot of people on the internet are insisting that a component-based system will be easier and cleaner, and there's no doubt that this is Unity's focus.

All these things are kinda important, but not really fancy enough to put on a blog.

That said, I'm shifting my MVP to include satiating hunger and having kids. Because, really, that's probably the core mechanics of the game. For later, I have dreams of tracking some basic traits and doing Punnett squares and watching what happens... but I might put in skin tone genes early. Particularly since I may have done all their walk cycle sprites ahead of time.

Getting distracted? What? Me? No!


Anyway. Back to pounding on the keyboard.

Friday, November 18, 2016

Basic Saves Complete! ... To refactor or not refactor...

Character position is now saving and loading properly, and I've played around with some UI elements. As promised, I've removed the 'Build [...]' buttons that were in the last screenshot, and I'm backtracking away from Quill18's work.

The UI buttons may be too fancy. We will see.

New Buttons!
Now, here's my current issue: my hierarchy for constructed objects (fences and misc. furnishings) is woefully unorganized. Quill's tutorial doesn't make use of inheritance, and he calls everything-- even the walls-- furniture in his project. I know I won't keep it like that, but I'm also trying to think of a good, logical structure with idiomatic naming conventions.

So, what does a tree, a rowboat, and a bucket have in common?

None of these things are quite like the other...
Some of these items are man-made. Some aren't.

Some of these things stop characters from walking through. Others will just slow them down.

Some can be equipped. Some are containers for other objects. Some can be cut down (the tree), some can be harvested (the corn). Most will be placed on a tile, but the walls and fences will be aligned to the tile edges. Some can have smaller items stacked on top-- you'd logically want to be able to set things atop a table, for instance.

But! All these things can be interacted with in some way. I want to be able to right click all of them and see a context menu, and I want to left click on them and have them 'selected'. So if I'm to use inheritance (which I think I should), I'm going to need to figure out a natural way to build them. Ideally, this 'tree' will contain minimal amounts of duplicate code.

Spending the day restructuring; we'll see how this goes.

Thursday, November 17, 2016

State of the Game: 2016-11-17

Hey there!

So, a short, short backstory, since this is my first post. My name's Eliza, and I'm a fantasy author / artist / software engineer. Early summer 2016 I got very sick with what's basically a long-term migraine. It's about as much fun as it sounds.

I'm currently confined to our homemade sensory deprivation tank (aka, the windowless office), popping the latest pills the neurologist has thrown at me, and would probably have gone crazy if I wasn't such a nerd. Because clearly, the logical thing to do in this situation is to make that video game I've been thinking about.


At the moment, I'm working on saving the character information-- as soon as I have that, my short-term saving goals will be met and I'll be able to move ahead to other things.

I've been working through Quill18's Base-Building Game Tutorial (which is a fantastic resource-- anyone who wants to dip their toes into game programming, take a look at the free Unity game engine and Quill18's tutorials). 

As of the end of Episode 28, though, my game design and Quill's are starting to go in very different directions. Walls and fences aren't part of my MVP (minimum viable product), for instance. Spawning resources, assigning jobs, and creating stockpiles are my main concern, and I mean to implement a 'Blueprint Mode' building system instead of grid blocks..

SO. Next step-- I'm skipping to stockpiles, and I'll be disabling the (functional) fence building system. We'll add that in later.