Game save/load functionality is nearly complete! (Through console commands SAVEGAME/LOADGAME with index of the save slot used). 

Shelter remembers map structure of levels you visited, which in theory allows for maps to be mutilated by Player in a variety of ways.

At this point, I will limit environment alteration to just "blowing things up in select instances".

Also, I am considering changing the "Diablo" player-centered camera back to Fallout-style roaming camera (which at the moment only activates in COMBAT).

Maybe I should start posting a random screenshot every week. Here's one.

Shelter setting and skeletal quest flow summary fits on one printed page, which is good, as it is the only format I can manage.

Previous attempts to detail every little thing were cumbersome and imprecise, because of the need to sync the document back and forth with the game itself. When the game can't manage to accomplish "textual quest description", the quest needs to be altered to fit into existing game mechanics,which would send me back to the document every time...

So, as it stands, on many "how-tos", the game IS the document. It has examples of functionality, and it also generates area and quest reports.

* * *

The next feature will be "game saving and loading", because it will be required to troubleshoot Shelter, and recreating all the conditions involved every time would be a horrific waste.

If I need to troubleshoot a scenario where 3 quests are complete and I'm wearing leather armor and I have 5 doctor skill and no ammo and standing on the edge of the map when something weird happens, I NEED to have that savegame.

Hope to make some actual progress before manager at work dumps "Project #2" on my head.

I made the new HUD optional so that Shelter takes up less screen space in a window for development purposes...

Other than that and a few internal tweaks, nothing.

In the past two weeks I've been given two projects to write in a horrendous language called PERL. I just handed in the first one to my manager, for which no doubt I'll receive a beating tomorrow during code review.

Shelter is written in C (core game), Pascal (dialogue/quest compiler), and SSL (Shelter Scripting Language, which makes for most of the active content).

I have decades of experience in building complex things, an abstract skill that has little to do with programming languages, yet lack of which makes projects of this magnitude fail.

I am not one of those "programmer" types. I don't make beautiful code, and I can't hold 5 languages in my head. I can barely hold ONE at a time, and it takes me effort to switch.

Being forced to work with PERL pretty much renders me 98% useless when I come home and try to work on my so-called "hobby".

A "hobby". What a riot. Normal people have hobbies. Y'know, collecting stamps, or kicking homeless into traffic.

Shelter is far beyond a "hobby". No sane person would keep at it. It is an obsession. I debug parts of it in my sleep.

Dear Reader,

This was the least productive week ever. Hardly anything was done whatsoever. I could go on about just how little was done, or why, but I won't.

This week I created 5 different iterations of document describing Shelter setting and game start. Simplifying. Distilling the setting&start to fit into 7 sentences.

It is hard to comprehend the iron grip that the game mechanics hold on the setting itself, until you work on these at the lowest level.

For instance, in Fallout, one of the first goals was to make the Player discover Shady Sands, seemingly on their own. Discovering things on your own is a vital part of feeling like an adventurer. How can you accomplish that without explicitly revealing the town on the map, and pulling back the curtain in the process?

The solution was interesting: reveal a DIFFERENT place on Player's  map, and put Shady Sands between start area and THAT place. Seems basic, but it was necessary, and, as it seems, irreplaceable.

Such problems and solutions defined the majority of Fallout. Another example: there's a main quest, with a suitably "epic" goal. But just how urgent should it be?

Let's imagine for a moment that the very game area is crumbling due to massive earthquakes, and your goal is to stabilize the planet's core by launching a Subatomic Stabilizer Device(tm) into it.

While the planet around you is falling apart, does it really make any sense to go around killing Radscorpions or rescuing someone's daughter from the local hostiles?

This is why Fallout's threat was more subtle. Not all mutants were hostile. Some you could talk to (even The Master himself). Their threat was a slower, creeping one, and it wasn't out of intentions that were 100% evil in nature. The threat loomed on the horizon, instead of trampling over the Player's sensibilities with an overblown urgency.

On the other hand... in earlier documents, Shelter's "threat" was a totalitarian regime. Now, that may work in a movie like Equilibrium, but in a game, that is just too passive. The regime is always there. People have lived with it before your do-gooder quest, and they can continue to do so. It can't expand anymore than it already has... unless you strap on some convoluted catalyst on top of it. 

In the Player, fighting against a faceless regime is more likely to generate apathy rather than interest.

This is why, in current iteration of Shelter document, the game's main threat is a takeover by robots. They mean well, but they go about it entirely the wrong way.

Note: this is not final :|