An Evening of Code

Wherein the author spends an evening writing a small project or feature.  

My New Year's resolution to myself was to write more code and write more. As a full time developer that was hard. Motivation was thin on the ground after a day down the code mines. With last year's hellish release out of the way at the start of January things have changed.

To start, my role at work has changed and I'm not writing so much code. Now I get home, not having scratched that itch I've had for the last ten years, and I find it much easier to spend a couple of hours working on something else. I've also got a standing desk at work and sitting for an evening at home doesn't leave me feeling guilty.

So far I've focused on creating small pieces. There's few things I like more than a new project. Creating something from nothing is incredibly satisfying and not something that can be experienced in many jobs.

Anyway. I was in a rut, creatively speaking. For the New Year I decided to make a(nother) go of it. Write more code and write more in general. I don't know if I'll stick with it. Historically my interest tends to tail off over time. Having a few different projects helps. But, also, giving myself permission to work on something else if the current task doesn't interest me today. Having a space to just take one mechanic and work it through is very liberating. Sometimes just knowing that I don't have to do something is motivation to do it.

Rebellious. 

An Evening of Code: Nonoku

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.

An Evening of Code: Scoring

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 ;)

Evening of Code: Endless Runner

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.

An Evening of Code: On Patrol

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.

An Evening of Code: Animated Defence

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.

An Evening of Code: Depth Sorting

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). 

An Evening of Code: Pathfinding

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.

An Evening of Code: The Eye

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

An Evening of Code: Security

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.

An Evening of Code: Isometric

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.

Tools - Omnifocus

Of all the productivity tools I've tried, Omnifocus is the one that's come closest to sticking. It helps that I do most of my work on Macs so I don't usually find myself without access to it. That said, I do often go a few days without checking it or adding new items and I am doing a lot of personal game development work on Windows. It feels like there's a habit I have to develop. All too often, the thought is immediately followed by the action. That's satisfying but not always the best use of time. For a start, there's a number of things I've thought of which, given a little distance, were nowhere near as good as I thought they were at the time.

Still, I just can't develop a habit of maintaining the list and I've not get items in there that are no longer applicable from December. I'll give it another shot but I fear I've spent so much time working by holding what I need in my head (plus pen and paper) that I've trained myself to that mindset. Then again, I used to write code in a text editor because IDEs seemed so much more cumbersome and I wouldn't go back to that for serious work. Though, in all honesty, I was mostly working with J2ME and DoJa at the time so learning all the APIs by heart was actual feasible. I do know that when I have my tasks to hand I can be a lot more efficient so I do want to make it work.

I think I'm going to give it one more shot - read some guides, and schedule a block of time to try and figure out a way to make it work for me... If that fails, maybe I'll just resort to a pocket notebook and pen ;)

An Evening of Code: Smoke and Sliders

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.

An Evening of Code: Cyberpunk

Building from this.

Not sure if I'll take this further. Basic concept is that you fix people's machines and upgrade them so they can run missions (think The Finn upgrading Case's Ono-Sendai). I have a vague idea for an overarching storyline but I'm not sure if the underlying mechanics are fun enough to carry it. There seems to be scope to balance quality of work with the cost the customer is willing to pay versus your reputation. It could be at the point where I need to close out a few more mechanics to know for sure. It could be that a lack of immediate feedback means it's not matching the expectations I have in my head. If I find the inspiration to go back and hook in a few more systems I'll post a playable version up for feedback. 

In terms of implementation, you can drag and drop the different pieces around and they snap into place correctly. You can click on the blobs of solder to remove, or add, them back. If a piece is soldered it can't be removed. The biggest issue I have with this is trying to reconcile the high-tech with the simple components. I can conceive of more complicated innards but then I can't imagine anyway of making it fun. For now I want to keep things simple and recognisable. Alternatively, I could re-purpose the basic mechanics into a more abstract puzzle system and have you as the hacker breaking into systems. That sounds more interesting but I'm willing to spend a little more time with what I have, just to flesh it out a little more, since I can take a lot of it into this other idea.

An Evening of Code: Platforming 2

Updated the platform generation implementation to more reliably generate interesting patterns. Nothing too fancy, just a set of layouts which can be picked consistently. Redid some of the character physics to improve collisions. Added some pick-ups to add a little interest. Also, had a play with Unity's animation system so that the player character goes into an idle animation when they stop.

An Evening of Pixel Art: Cyberpunk

Just messing around with another prototype for a game. Nothing playable yet but I have a few ideas jotted down. I'll try and get something playable this week to determine if the base mechanics will be fun. I'm no artist but pixel art is often forgiving if symmetry is maintained. It also serves the game where realistically I'd have to implement an incredibly complex device that wouldn't be fun. With simplified graphics it requires less work to define . I kind of like the base colour scheme but I'll probably do another pass on it to better serve the mood of the setting if I decide to get more serious with it.

I've been watching a lot of YouTube videos about electronics recently and that's definitely feeding into my ideas for this. I've also always been a fan of Cyberpunk which definitely feeds into the look (those purple hues seem ubiquitous). In terms of laying out the screen, there're two perspectives similar to Papers Please. Having a front on view for the background and top down for the playable area simplifies the control scheme and the burden on the user significantly. I only spent a few minutes with the UI in the same perspective before dismissing it as unworkable. Aside from the complexity there's a lot of wasted space setting up that view in a meaningful way and it doesn't serve the game.

This is a drag and drop into Unity but no logic attached. Whilst it's usually better to get something working, sometimes having some (admittedly crappy) art assets is nice to start. At least it means if I do decide to start adding functionality I've got some distinct parts to work with without having to drop to an editor each time.

An Evening of Code: Platforming

An infinite platformer. No special rules for the platforms except to ensure that the random numbers are always the same. Wrote it in Unity over a few hours with a few rounds of Evolve in the middle. The player sprite is from a sprite sheet Google Images popped up and I couldn't find attribution information for it.

An Evening of Code: Fishing

A simple fishing game. Graphics are just taken from a Google Image Search. Learned a little about collision detection (and particularly how to specify different collision areas). Also, matching the movement of one sprite to that of another. And moving on a sin curve as well, I guess.

An Evening of Code: Flocking

Simple flocking algorithm in Game Maker. Learned a little more about inheritance and functions within GameMaker (and some improved collision detection). The blue boids evade, the red ones move together (and convert blues into reds) and the player is green and can move and shoot freely. The reds and blues interact with each other and the player. 

GameMaker Tutorials

The more code I write, the more comfortable I am letting someone else write the engine. I'd looked at Game Maker before but not really got into it. Tom Francis has been posting a series of tutorials on YouTube and they were approachable enough to get me to take another look. The above screenshot is based on those videos. I don't know that I'll take this particular project any further but I can see spending a little more time with Game Maker.