Not quite “weekly” this time – the last two weeks turned out to be quite busy, so I spread out the same tasks over twice as much time. That said, it was a pretty good couple weeks, feature-wise.

As described in the last update, this sprint was about ‘coloration’ and ‘pips’. It also became a bit about procedural generation.

Coloration

Previously, a dig site was made of this column of generated ‘materials’, mostly stone. At the surface you got a lot of dirt, and once you got to deeper depths you found more and more precious metal. The entire tile was colored according to this, so a ‘gold tile’ was literally that: a block of gold.

I found this weird – I wanted color to be a little less restricted. If I wanted a planet to be 30% yellow, I can’t just make it 30% gold without completely cheapening the concept of precious metals. Instead, I decided to go a little more abstract – the core colors are shared between blocks and planetary tiles. Now, any given tile can be any color – it doesn’t affect what you get for clearing that tile, nor the difficulty of clearing the tile.

A nice effect of this shift is that I was able to use the color distributions to produce colors for planets. Space looks much more interesting now, and planets seem distinct, different. When you arrive on a planet, you can usually see immediately why it looked a certain color. If it’s purple, it might be made of purple tiles, or it might be blue and red tiles, or some other mixture.

Clearing a tile of a given element gives you one unit of that “element”. Elements are tiles with ‘core’ colors – these will factor into a growth mechanic later, but for now they’re something like a “base crafting material”.

It may be easiest to think of these in Minecraft terms, honestly:

The Elements correspond to ‘stone’, ‘wood’, etc. You’ll be able to sell them as raw materials if you like, but I’m also considering adding another minigame/mode where you smelt them to try to get additional pips out.

Pips

In addition to ‘elements’, clearing a block can yield ‘pips’ of two varieties.

The “Metal Pips” are similar to the metals in Minecraft – you use them as the base material for craft-like work. In BIS you can also sell them for a tidy profit.

The “Special Pips” are 50% “unusual Minecraft materials like Lapis Lazuli”, and 50% skill point. In BIS, I intend to use these as a rare ‘gating’ material for significant upgrade paths. E.g., maybe you need to find two red pips to upgrade your Orbital Laser technology to rank 3.

Pips embedded in a given Element color will have a higher chance of matching that color, so you can go mine a planet with a lot of yellow tiles to increase your chances of finding yellow pips.

The ‘smelting’ mechanic is a way to let players target specific pips even more than that. If you really just need a lot of blue pips, then instead of selling your blue element drops, you can smelt them and hope to get pips. The odds are low, but it would be a parallel activity to mining, and lets you target your growth as needed.

I may or may not implement this mode/mechanic – being able to target planet colors might be sufficient.

Procedural Generation

As I was implementing the Element change above, I recognized it as a good opportunity to add the “hand-crafted” feeling.

By “hand-crafted”, what I mean is that there’s a sense you get when playing a game that helps you tell whether the content you’re experiencing was made by an algorithm or by a human.

In general, I think what makes content feel hand-crafted is patterns. This is of course a huge, nuanced topic, but in the small I think it can be summarized as “patterns”, maybe “templates”.
5/4/16 Edit: Slightly less in the small, I think this feeling is somewhat like the uncanny valley, but as a good thing. Too much order (patterns) and it looks synthetic. Too much chaos and it looks random. The goal is to walk a thin line between these, to impart a sense of meaning to the content without looking formulaic. The template system I describe below does not accomplish this, but it does move in the right direction. How to get BIS closer will be a topic again in future sprints.

So: the Elements a planet has are generated using four types of templates: “Uniform”, “King of the Hill”, “Power of Two”, and “Three-Tier”. For each type, we have at the very least two categories of elements, the ‘heavy’ and the ‘light’. For a couple, there are more.

• Uniform: This splits the elements into two randomly-sized sets. The “light” set elements all have low odds of generation. The “heavy” elements appear at the same rate.

• King of the Hill: One element is selected from the “heavy” elements and promoted to have a majority of the odds. The ratio from King:Heavy is the same as Heavy:Light.

• Power of Two: The heavy elements are assigned a ‘weight’, each weight is 2x the previous weight. So if you have 4 heavy elements, they will be weighted 1:2:4:8. Those are then normalized and the Heavy budget is assigned to them.

• Three-Tier: The elements are split into three categories, heavy, medium, and light. Budget is distributed so that Medium elements are always twice as likely as Light elements, same with Heavy vs. Medium.

The intent of this was to provide distinct patterns to how elements are distributed, rather than choosing random values. Although this is obviously still quite random (rather than “procedural”), the effect should be fairly similar, and can be made procedural very easily.

So far it feels pretty good, though I think there might be a bit too many “chaotic” options – it doesn’t look great when there are a bunch of single-element tiles scattered around the top of the dig. It doesn’t feel intentional.

I’ll leave it as-is until I have time to implement “micro-templates”, then re-evaluate. Micro-templates are a way to add patterns within the dig in addition to simple color distribution. E.g., the “great storm” from Jupiter, mineral veins, stripes, zig-zags, etc. Things people do if they were manually designing levels.

Next Sprint

The main two topics next sprint are Difficulty and Stations/Shops.

Difficulty:

The effort to clear tiles is currently static in a dig site, and the same between planets. The first change is to make it so that as you get deeper in a dig site, difficulty goes up. That is, each tile becomes harder to clear, demanding better blocks or better use of color/combo/etc. (Which isn’t in, yet.)

To provide some more difference between planets/moons/etc., I’ll be giving planets a ‘density’ parameter, which determines how fast difficulty increases. For moons, it will usually be slow. For planets, it depends on the size and density of the planet. Density will generally correspond to the richness of tiles as well, so you are rewarded for the extra work.

Stations/Shops:

Currently, stations/shops are mostly placeholder code. The inventories are fixed, all stations are identical, etc. Moreover, their inventories are pointless – you can’t buy real blocks, real upgrades, anymore.

The first change will be to give shops a real inventory of new blocks to sell, so that players can start to customize their block deck. This will also include the ability to sell your own blocks to the store, so long as you have enough to build a minimal deck.

Roadmap

• Tinker Mode: With these two changes in place, I should be ready to add tinkering, so you can start upgrading blocks. With Tinkering, I’ll also be adding “ship inventory”, in the sense that your ship has certain modules equipped. Those modules can also be upgraded with Tinkering (so you can tinker to improve your tinker lab, etc.)
• Persistent Space: Currently the solar system you’re in generates anew each time you reload the game. Dig sites are impermanent as well. Once this is fixed, you’ll be able to select which dig site you want to dig at on a planet – or so I intend. There are some risks to enjoyment around that feature, so I’ll be evaluating it.
• Basic Coloration and Combo gameplay: With the coloration work finished in this sprint, and the difficulty work next sprint, I’ll ready to introduce mechanics to take advantage of the two. “Combo” for now simply means the traditional “clearing more lines = bonus!” idea, but will soon grow to something much more nifty.

As I mentioned last week, this week was all about adding the Block Inventory feature.

This turned out fairly straightforward, albeit a bit tedious. Mostly this was because when I built the way blocks are handled/spawned/scored in the first place, I wasn’t intending there to be an arbitrary number of unique blocks. So I had to refactor a fair bit of code to create a way to hook it up to the player’s new inventory.

The UI/panels didn’t cause me much pain this week, which is a good sign. They’re still kind of ugly, using the same old boundary artwork as everywhere else, but it’s a start.

I did have some trouble with gesture controls, though. Normally it’s pretty easy to set up a chunk of content to scroll using Unity’s ScrollRect component, as I have in the shop menu. This time I had two large-ish problems:

1. Scrolling doesn’t naturally snap to units. With “full-screen” horizontal scrolling (one block visible at a time), it really needs to snap appropriately. This is a bit involved, and I’ve delayed it for a future sprint.
2. My block rendering prefab is not a UI element, but an in-world SpriteRenderer element. I did this for various reasons that may no longer apply, but it remains nevertheless. The problem with this is that SpriteRenderers are not affected by normal masking, so as you swipe left/right, you see the blocks just sort of scooting into the screen without the panels behind them. There are ways to fix this, but again, a tiny bit too involved to fit in this sprint.

Since the scrolling didn’t work out, I added a couple of left/right buttons that provide the functionality for now. Like other parts of the UI that don’t show any sort of visual movement/tweening, this feels a bit too abrupt, but it will have to do for now.

All in all I’m pretty happy with this new chunk of gameplay, though it will need more support elsewhere in the game before it feels particularly meaningful.

Next up: “Pips” and Coloration

As preparation for mechanics planned for future sprints, I’ve decided to shift how planets in mining mode generate and render tiles. Currently, they’re a somewhat 2D-Minecraft-esque approximation of actual planetary soil, minerals, etc.

The change will be to partially remove the concept of real-world materials from the mining gameplay. You’ll still find gold in them thar hills, but now it’ll appear in any given generated tile as a small gold-colored circle, what I’m calling a ‘pip’. This dissociation between the material found in the tile and the color of the tile allows for future strategic gameplay around coloration.

This will also provide additional differentiation between planets – you’ll be able to tell from the starmap what sort of coloration a planet is likely to have, and eventually, tailor the set of blocks you bring with you to increase your effectiveness on that planet.