A distraction. Took a few minutes just to implement a basic mechanic. Not sure what this is to do with anything but into the Experiments/ dir it goes.
The elevator has a collision box and, when the player touches it we can activate the 'elevator' functionality on a keypress. The system allows up and down movement so you could have multiple floors.
Fixed a couple of bugs which was keeping the generation from truly finishing which makes increasing the frequency of the branches more feasible. I tweaked the previous generation to increase how often it branched as it approaches the centre. It's still way to messy and chaotic to be a workable solution but for something so basic and naive it actually does better than I expected.
Tweaking values - went a little high on the mountain frequency.
Refining it down. Kind of fun to jump around right until you fall to the bottom ;)
That's more like it!
The 9th iteration of the Sierpinski triangle.
An extension of yesterday's work with L-Systems. The Sierpinski Triangle.
Firstly, I updated the implementation to draw the shape over a number of frames. This is not the end goal of this work so I'm doing it in Unity by drawing to a texture which is easy to implement but far from the most efficient ;) In this case it was best to limit the texture size to 512x512 to avoid a severe performance hit when redrawing the texture. If I needed to, I could simulate a larger texture by mapping it to multiple smaller ones but that's out of scope for the moment.
Next I updated the rules implementation to support multiple rules. Previously I used a single string and a regular expression. This no longer worked because the rules have to be applied simultaneously. Instead, I used a Dictionary to store the rules and, since the rules I need at the moment are only applied to a single character I could simply enumerate the axiom and use the character as the key to the dictionary. If there's a match I append the rule to a new string. If not I append the character.
There is one additional change that is not described in the notation - after each iteration the angle gets flipped so that it goes from 60 to -60, and back again. This is required to keep the triangle facing the same way at each iteration.
A= Step forward
B = Step forward
+ = +60 degrees
- = -60 degrees
A → B-A-B
B → A+B+A
Axiom: A
After 9 iterations the string has gone from 1 to 39,365 characters.
string Iterate(string axiom) { string newAxiom = ""; foreach (char c in axiom) { string ch = c.ToString(); string replace = null; rules.TryGetValue(ch, out replace); if (replace != null) { newAxiom += replace; } else { newAxiom += ch; } } angle = -angle; Debug.Log ("Axiom Length: " + newAxiom.Length); return newAxiom; } void FixedUpdate() { int length = axiom.Length; for (int i = 0; i < 200; i++) { if (index < axiom.Length) { char c = axiom[index]; if (c == 'F' || c == 'A' || c == 'B') { Vector2 newPoint = NewPoint(currentPoint, stepLength, angle); DrawLine (new Line(currentPoint, newPoint), colors[colIndex % 3]); colIndex++; currentPoint = newPoint; } else if (c == '-') { angle -= angleStep; } else if (c == '+') { angle += angleStep; } index++; } } texture2D.Apply(); }
The Koch Snowflake is the one of the first, and simplest, of the fractals.
Starting with an equilateral triangle:
In total, we've added four new lines and increased the total length of the shape by 1/3. Repeat for the remaining lines and we have completed an iteration. Starting again on the new shape we can repeat the same steps for each of the new lines. As can be seen from the above animation, which only iterates 5 times, the complexity rapidly increases.
Technically this is not actually a Koch Snowflake as that is the shape we approach as we iterate. However, we would need to iterate an infinite number of times to generate a true Snowflake.
Iterating on a single line generates a Koch Curve. The Snowflake, starting from a triangle, is made of three curves.
The Koch Curve can be described by a Lindenmayer (L-) System. This is where we create a string and, each iteration, run a set of rules to replace characters in the string with others. Each character defines a drawing rule which we can follow to draw the shape after the iterations have completed.
F = Step Forward
+ = Rotate 60 degrees right
- = Rotate 60 degrees left
Rules
F → F-F++F-F
Starting with: F++F++F++
Our drawing instructions give us our starting triangle. Iterating, we increase the size of the string and generate more rules. Following them generate the animation above.
float stepLength = 256; string rule = "F-F++F-F"; Vector2 start = new Vector2(128, 128); protected override void Draw () { string axiom = "F++F++F++"; for (int i = 0; i < 5; i++) { axiom = Iterate(axiom); } int index = 0; Color[] colors = new Color[3]{Color.black, Color.red, Color.blue}; int length = axiom.Length; Vector2 currentPoint = start; float angle = 0; int colIndex = 0; while(index < axiom.Length) { char c = axiom[index]; if (c == 'F') { Vector2 newPoint = NewPoint(currentPoint, stepLength, angle); DrawLine (new Line(currentPoint, newPoint), colors[colIndex % 3]); colIndex++; currentPoint = newPoint; } else if (c == '-') { angle -= 60; } else if (c == '+') { angle += 60; } index++; } } string Iterate(string axiom) { Regex regex = new Regex("F"); stepLength /= 3; return regex.Replace(axiom, rule); } Vector2 NewPoint(Vector2 point, float step, float angle) { float radAngle = angle * Mathf.Deg2Rad; float x1 = (point.x + (step * Mathf.Cos(radAngle))); float y1 = (point.y + (step * Mathf.Sin(radAngle))); return new Vector2(x1, y1); }
Try modifying the above to generate new shapes. For example, replacing the '+' with '-' symbols in the starting axiom will create the equilateral triangle facing in the other direction and which starts a different pattern which will never exceed the bounds of the initial equilateral triangle.
Not hugely exciting but I did also spend a little time cleaning up an old project. Didn't end up doing as much as I thought was needed so instead I started looking at ways to start learning L-systems. To begin, I'll need a way to get them on the screen. For the first go I figured being able to draw lines to a texture would be sufficient. This is a quick and dirty implementation of Bresenham's line algorithm. I don't need it to be fast so substituted floats for the bit shifting just to make it easy. Nothing to be proud of here but it does get me what I need for tonight.
public void DrawLine(int x0, int y0, int x1, int y1, Color color) { int dy = y1 - y0; int dx = x1 - x0; float error = 0; float deltaError = 0; if (dx != 0 && dy != 0) { deltaError = Mathf.Abs((float)dy / (float)dx); } int y = y0; int x = x0; for (int i = 0; i < Mathf.Abs(dx); i++) { texture2D.SetPixel(x, y, color); error = error + deltaError; while (error >= 0.5f) { texture2D.SetPixel (x, y, color); y += Mathf.RoundToInt(Mathf.Sign(dy)); error = error - 1.0f; } x += Mathf.RoundToInt(Mathf.Sign(dx)); } }
On advice from the tutorials out there I've moved to using Simplex noise. It also now creates two layers of noise so that we can have dirt on top of the stone.
Probably the biggest single change is that chunks now generate a mesh, rather than instantiating a cube for each voxel. This is (unsurprisingly) a lot faster and actually allows me to have stacks of blocks.
Creating a mesh in Unity is pretty straightforward. Specify four Vector3s and define as two triangles to form a square face. Use 6 square faces to form a cube.
// Top Face
Vector3[] vertices = new Vector3[4];
vertices[0] = new Vector3 (x, y, z + 1);
vertices[1] = new Vector3 (x + 1, y, z + 1);
vertices[2] = new Vector3 (x + 1, y, z );
vertices[3] new Vector3 (x, y, z );
// Triangles
int[] triangles = new int[6]; // Two triangles, 3 points each, 2 verts are shared
triangles[0] = 0;
triangles[1] = 1;
triangles[2] = 2;
triangles[3] = 0;
triangles[4] = 2;
triangles[5] = 3;
mesh.Clear();
mesh.vertices = vertices;
mesh.triangles = triangles;
mesh.Optimize();
mesh.RecalculateNormals();
col.sharedMesh = mesh; // Use render mesh for collisionsA simple optimisation then is to check if there is another cube adjacent. Since there is no gap we don't need to include the face on that side.
Lastly, track the block type and assign the appropriate texture.
It's lacking a lot of features that would make it a game. I might look into some basic changes like supporting just because it's straightforward. Really though, this was to serve as a refresher in how to think about 3D and procedural content. In that, it's served its purpose.
It took a while but I think I'm finally feeling comfortable working in Unity.The other night I built a minimum viable prototype of one of my iOS games over the course over just a couple of hours. I feel like I'm still learning the flow of the engine, particularly with regards to threading, but there's a lot of power and potential to be tapped and getting started with it is easy. That said, I do miss the more advanced debugging tools I get with something like IntelliJ, or Xcode. And MonoDevelop is pretty awful ;)
Because sometimes you just have to rip off Minecraft.
Naive voxel based terrain generated using Perlin noise. Nothing too special, I just wanted to get a feeling for how it works. Quite satisfying to jump about and simple to implement. Terrain is generated in chunks and has colliders. It's not particularly fast to instantiate the chunks but this was just a 'getting things on the screen' type of experiment. There are plenty of tutorials on this and I'm sure I'll have a look before going much further but doing a bit upfront was a good learning process and a nice way to get thinking about 3D again. No particular plans for this but a fun change of pace.
Just took a few hours to recreate the first puzzle from my iOS game, Nonoku, in Unity. Good timing as it was almost one year ago since it launched. You can play this version in your web browser here (opens in new window).
Nonoku is a tile based game where you have to reveal tiles by working out what colour they are. When you select a revealed tile it will show you how many unrevealed tiles of that colour there are in each direction. Games play out on a 10x10 grid and there can be up to four colours in a puzzle. Some of the later ones get quite tricky. The one here is from the tutorial.
Didn't encounter any major issues in getting the core game play implemented. In fact, it went even quicker than I'd hoped to get to this point. There would be plenty more to do in order to finish it out as a game but as I'd already solved most of the problems a year or two ago it felt like coming back to a really familiar project. Even though the original version was written in Objective-C in Xcode having a solution already in my head meant I could focus on getting it to a playable state.
I nearly didn't bother with the draggable cursor. I started with just being able to select a single tile but it becomes a huge pain to play. Adding it in meant a small re-write and a little more time spent than I was planning, but not by much. It's a little glitchy still but generally reliable and much better than only being able to fill one tile at a time.
The launch trailer for the original iOS version is below and you can find it in the app store here.
Added a basic scoring implementation to the runner so you can see how far you get and compare it to a previous run. Does not persist between sessions for now. Cleaned up a few implementation details but nothing major.
Play it here (opens new window). Let me know how far you get ;)
Play it here (opens new window).
A little more than an evening since I also wanted to experiment with animating a 2D sprite from pieces rather than separately drawn animation frames. A simple run loop lent itself to an Endless Runner style game. A quick jaunt to photoshop and I had a building and background. I'm no artist so I checked out Game Art Guppy and picked up the free Ninja sprite which was handily broken into separate elements already. Ideal for what I needed.
In terms of implementation, this is about as simple as it gets. A Game Object for the Ninja, Sky, and another to hold a script for loading in buildings. The building prefab is just a Sprite and will draw in 2 - 6 instances in a row before adding a gap and creating the next set. There's a small y-offset just to add a little challenge. Would be nice to separate it and add a little parallax but that wasn't the purpose of the exercise. To move the player, the buildings scroll to the left and wrap to create an endless play field.
Most of the tweaking was then on finding a good speed and jump height for the player. The main complication here was when I accidentally attached the player to the camera, instead of the other way round, and suddenly saw speeds increasing massively as the player was moving, and then the camera was moved to keep up which moved the player again.
The hierarchy looks like this. The "~Ground~" is an empty game object with an icon attached so I could visualise roughly where the ground would be whilst animating the sprite. It's laid out as a tree. 'Ninja' is the parent object for convenience. SpritePelvis acts as the anchor for the rest of the sprite. Technically it could be the parent but that felt a little confusing for naming. Everything follows from there. The arms and head attach to the torso, the legs to the pelvis. The top and bottom of the body can move independently.
This is the animation curve for the RightArmUpper sprite rotation during the run. A full run loop runs for 15 frames so for every piece I wanted to animate I positioned them were they needed to be and created key frames at the start and end so it loops seamlessly. Setting the curves to be flat at those points ensures a smooth transition (if needed). At the mid-point (not quite) I added another key frame and rotated to the correct place. This particular curve takes the right arm from back behind the character to in front and back again.
In addition to the run, I also added an idle animation just to have something to start from as a little refresher. As an extra touch, I set the animation speed to be a percentage of the player's current velocity relative to the maximum velocity so that the animation starts slow and speeds up with the movement.
Finally, the only way to fail is to miss a jump and fall. I added a check to the player's y position and if it exceeded a value I knew would cause it to drop off the page I reload the level. Instant restart.
Refactored the player code into a parent class so I can use it with NPCs. Added a new sprite, a recoloured version of the player to serve as the enemy. Gave it a basic left/right patrol path to confirm that the navigation works correctly.
Cleaning up the code after a mad rush of feature adding is always beneficial and, in this case, let me get a new character up and running very quickly. It also allowed me to clear out a lot of code from the player character. There's more that can be done but it's sufficient for the moment.
A quick one this time. A check for impassable tiles around a location and a collection of shields around the highlighted area shows which directions the player is protected from. Also, created a new player sprite with orientation changes. Added an animator to it which updates based on the orientation to the next tile to improve the sense of movement.
Whew... This one took way longer than expected. I'm using the 2D Toolkit Unity plugin to handle the tile map with a Unity 2D Sprite for the player character. Arguably overkill for what I need at the moment but I already had the plugin and it let me get up and running really quickly. Whilst it wasn't supported out of the gate I figured that it wouldn't been too difficult to add. Get the z-coords of the current tile and stand the player on it. Done.
Nope, fortunately this had already come up in the forums. That put me on the right track (Transparent Cutout shader on the Sprite - I started writing my own but spotted the Unity Unlit/Transparent Cutout shader before I got too far and it seems to work fine). Modifying the code shown in the forum post and then reviewing the updated scene whilst the game was running showed me how the offsets worked for both tiles and chunks. After some tweakery it was close but not quite right. Eventually, I realised that each chunk was offset by 0.0001 on the z-axis. Just removing that value fixed the problem without causing any issues (I could have accounted for it and if I see a problem in the future I might).
Added A* based path finding to the isometric project. Still needs a little tweaking as there's a couple of places where the scoring doesn't appear to give the most obvious answer. Added a Debug line to visualise the path. Added the rocks on a separate layer for foreground objects to provide the collisions.
Would be nice to correct the z-ordering on the player character relative to the map next.
Updated the deck layout to be a little more complicated. Added additional buttons for all the existing Components. Plus a new one which animates when it's connected (I'll correct that initial animating state later). Behind the scenes, I've re-written a lot of the code to make it tidier and fix some issues. You now need to solder a component into place before it becomes active. Before it was active as soon as it snapped into place. Some general cleaning and tidy up to simplify adding to this
Added the concept of a security check. Components can have different properties, such as 'broken', or 'secure'. The game can check for those as the player adds and removes them. Also added a little bit of UI to make it possible to spawn prefabs and a quick collision on the burn box to destroy them.
A quick isometric map with (very) basic path finding. Made in Unity with 2D Toolkit. Threw in some quick art. The player can click on an area on the map and the character will 'walk' there. Movement can happen in 8 directions by crossing tiles on the diagonals. The magenta line is a debug line to show where the tile is being checked for.
All graphics were drawn using Piskel.
Spent a couple of hours adding a little smoke animation (a few frames added to the sprite sheet then animated) when you solder a component. Also added checks for broken components. The slider is a temporary visual indicator that the functional state of the hardware has changed. Had a little problem with the sprite animator generating a load of errors after destroying the smoke object (an event on the animator firing a function to the Smoke GameObject). Turned out the animation was set to loop so just unchecking the box fixed the problem.
The rain is a particle system with a pixel style texture applied.