Levels And Clean-up

These past couple of days I've been working On a few test levels, clean-up and a few bug tweaks so I can release my test to the waterfront games website (and elsewhere if need-be) for testing.

The first glitch I had was unusual - I couldn't joint a yellow plug to a yellow socket; which really threw me because there shouldn't have been any reason for it. After a LOT of printing values into the console I found that unity defines all of it's main pre-set colours using ones and zeros APART from yellow, which is defined as (1,0.922,0.016) instead of (1,1,0). Typical.

The second problem I found was that despite what I thought, the plugs and inputs and outputs were being instantiated straight onto the main scene, rather than inside of their respective hubs - causing messiness and possible problems in later developments. after a reasonable amount of research I found that making something a child of another is as simple as the following;

Newobject.transform.parent = gameObject.transform;

before parents/child's

After parenting (function inputs/outputs INSIDE functionhubs

Black is the new White

I managed to change the creation of hubs into a much more versatile array as I was speaking about in my last post - It is a lot more complicated now, but it is more versatile  which should make things a. easier in the long run and b. more fun.

I've also found some time making some hubs using the new versatile creation arrays and the  "any" input/output colour, black. So far I have two special types of hub; a primary colour combiner and an any colour splitter (names in progress). By putting any two primary colour inputs into the primary combiner, you get a new secondary colour (yellow, cyan or magenta).
The any colour splitter simply takes the colour you put into it and makes two outputs of the same colour.

You could easily make a hub which splits one red input into two, or combines red and blue into magenta. But the fact that you can do this with whatever colours at your disposal means that the player will have choice and will have to think about what they are doing. e.g. "Oh, I need to combine these two colours to get ___, but I also need to keep that colour in order to finish.... OH! so I must have to split that colour first so I have one left over."

there was a problems with the black input/output, because if you disconnected something in front of it, it would de-activate and turn back to black again, but it would stay connected - causing problems when trying to re-connect things again (is black, but thinks it is the old colour, or black, which doesn't connect to anything ; so now there is a fail-safe  so that if something is connected turns black, it is automatically disconnected.

There are a few small tweaks I need to make in regards to the "active" light displaying properly in the primary combiner. after that I will perhaps make a few more special hubs, such as a de-saturating hub (any colour to white). I was going to do an any-colour combiner (as well as  splitter) but now I'm wondering why I would ever use it (it would make two plugs into one, which would make things harder and be seemingly useless at the moment).

Might give this projects  small break and work on some of my others which are dragging further behind; we'll see.

all three output possibilities of the combiner plus inactive. note,  all  4 pictures are of the same hub

A few examples of colours put into the splitter, and inactive; note,  all  4 pictures are of the same hub

Rainbow Problems

Since my last post I have managed to complete the range indicators (they are not pretty, but they work), add in end hubs (hubs which have no outputs and count towards level completion) and the adding and removal of hubs between levels (after all of the end hubs have been powered). I'm very pleased with what I have done, however I have just come across a major problem:

Currently the hubs that are added to the level are defined by 4 parameters;

X position, Y position, Type, Inside Inventory?

x position defines x position, y for y position, Type is a number which defines the number of inputs and outputs and their colour (based on a numbered list of pre-sets), and inventory is not used yet but will be used to define whether the hub is in the inventory at the start of the level or not.

The problem arises from the "type" parameter; simply because it is not versatile enough. The hubs have far too many options which will need to be changed between each hub and level, and unless I have several thousand pre-sets - it's going to be very difficult to get the options I need.

I've decided the very minimum parameters I need to specify are as follows:
hub parameters needed: X, Y, SpecialType,Inventory?, List of colours (of inputs), List of colours (of outputs).

As it stands I specify the current parameters I need as numbers using a 'Vector4'. It seemed a smart idea when I created it (as I didn't have much of an understanding on unity arrays). Now though it is too simple,and the parameters are constrained to numbers, whereas i need to use numbers, boolean and sub-arrays.

This might be a timely process to figure out, but it needs to be done in order for the game to be puzzling.

As an additional problem, I was thinking about having an "any" input type. This would mean that you could use any colour onto it. This might be possible and useful in the game, but I have no idea how I would show the player that any colour could be placed on it. Currently I use colours to show what colours can be used, and the only real colours I have left are block and grey - and using those might be confusing for the player.

Simple Fixes

The extra scrolling wasn't so bad when just getting down to it, although i might need chris' help in order to get the background tiling evenly on each level (for some reason it doesn't seem to do it any more, but I can't remember what I changed or had before in order for it to work. I also got the colour display working, and after a few tweaks I got power transfer working too.

Start hub - it knows it is a start hub because it doesn't have any inputs, so it automatically sets it to "powered"

Generic hub, un-powered - this means you can connect the outputs to things, but it won't power them until all of the inputs are powered.

same function hub after a powered plug has been attached to it, all outputs are powered because all the inputs (only one on this) were powered.

I had quite a few problems with removing power after the plugs were moved around. for instance  you used to be able to connect a plug to power something, remove it. and the hub you removed it from would still be powered, I had to change the script on the plug removal a bit to fix this.
 the really nice thing with this now is that you can make a chain of powered hubs, but if you remove the power on the first it causes a chain effect down the line, and they all become un-powered.

My next step i think will be adding distance limits to how far you can drag the plugs - at the moment you can connect plugs over any distance, which A. gets messy and B. doesn't have much of a puzzle element to it.

unfortunately I'm a bit rusty on distance calculations (I've been using box2D to do such things in other projects for so long) I'll have to have another read-up on it.

I'll also have to design a range indicator too... That will be interesting.