Move around with the arrow keys. An experiment with surfaces. The world is broken up into tiles which are rendered to surfaces so that we only have to re-draw the tiles when something changes. No real gameplay but surfaces are a powerful tool so well worth starting to learn them.
Nonoku - SpriteKit Shader
A quick one because I was having trouble with this:
let node = SKShapeNode(rectOf: CGSize(width: 100, height: 100), cornerRadius: 5)
let dashedShader = SKShader(source: "void main() {" +
"float diff = u_path_length / 5.0;" +
"float stripe = u_path_length / diff;" +
"float distance = v_path_distance;" +
"int h = int(mod(distance / stripe, 2.0));" +
"gl_FragColor = vec4(h, h, h, h);" +
"}")
node.strokeShader = dashedShader
node.fillColor = SKColor.clear
node.lineWidth = 2
I've not done much with shaders before so when it didn't work I was short on tools to debug it. In the end it was a bunch of little things I had to solve, from converting the original version to one that would work against the iOS GL ES version, to making sure I converted to int before setting the colour.
Nonoku - Taking Shape
It's now possible to select areas and fill them in based on the colour selected. Incorrectly coloured tiles will not be revealed. This feels like a very big step and, ultimately, it all fell into place in just a few lines of code.
Looking back, I've clearly grown as a developer since I wrote the first version. Whilst I've made decisions that simplify the interface, I've also implemented a lot of the functionality that caused me a lot of pain before in just a few lines now. Part of that is making better technical decisions up front, another part is using the right tools. Another big piece is just having more experience in more areas so I have more ideas of what is going to be available to me before I start coding.
Overall, I'm happy with the progress so far and I'm glad I'm making the time to go back update an old project.
Nonoku - A Quick Update
Trying to keep things going as and when I can. This is a super quick-update just to display the correct buttons for the current puzzle. I know I'll be swamped for the next few days so grabbing 15 mins just to get another little piece done is going to be vital.
Nonoku- Selecting Things
Nonoku - Something Familiar
A quick recreation of the first puzzle from Nonoku’s original release. Underpinning it is a simple struct that holds the board layout and colours (I didn’t update the button handling to show them yet).
The actual tiles are hardcoded as a string that gets parsed into a 2D array. I’ll need something a bit more flexible in future but this will suffice for getting content on screen.
I’m now testing it on actual hardware, instead of just running in the simulator. The signing process seems to have been improved a lot in Xcode 8 which is nice.
About as basic as it gets...
Nonoku - Coloured Buttons
The eternal question when writing from a coder’s perspective, UK English, or US English, spelling. Context seems important to me. Mostly I will spell using US English standards since that’s the environment I’m coding in (Color, Center, Synthesize). When writing documentation, except when specifically referencing code, I’ll default to UK English (Colour, Centre, Synthesise). In an IDE it’s hard to type the UK English variant, in a document editor, it’s hard to type the US English spelling. Maybe it’s purely contextual and if I was updating a document that was in US English I’d automatically switch. I certainly find that with the minor differences between Windows and OS X keyboard layouts when I switch between them.
Anyway… More buttons. These ones are in the game itself and allow the selection of different colours to fill in the puzzle. It automatically scales to allow different numbers of colours. Eight seems to be the upper practical limit for fitting them into the UI.
More PaintCode shenanigans. I’ve also got Telekinesis working. I’m not really doing anything fancy enough to warrant it but it’s fun to play with a little. These buttons are two separate elements. One rounded rectangle that I can scale whilst maintaining the aspect ratio, and the circular ‘button’ part which has an inner shadow (as a highlight) and an outer shadow to give it a little depth. The highlight and the shadow are set according to the colour of the button. Not being familiar with PaintCode, I tried doing it as a single element. Since I needed different scaling that proved tricky. I got close with the Frames and Constraints but it wasn’t quite right. In the end, it was faster (and more logical) to split it out into separate pieces.
And yes, I am procrastinating on the next part. I need to add the game part of this game. I mostly have the shape of it in my head and I’ve messed with a couple of implementations but I’m waiting for it to feel right before I commit to something.
Nonoku - Buttons
Real life caught up so only a little progress. Started experimenting with some graphics tools just to change things up. Nothing final yet but this was quick enough to implement. I used PaintCode to draw out the button and add a gradient fill I could swap with the flat background by setting a flag. Then all I had to do was create a custom UIControl
to draw the button.
The text is defined at run-time so could be localised in future if I stick with this style.
override func draw(_ rect: CGRect) {
NonokuKit.drawMenuButton(frame: bounds, tapped: tapped, text: text)
}
So simple it's barely even worth including.
Acquisition: Live on the App Store
So I started with (not so) grand ambitions of walking through the process of reviving Acquisition. What actually happened was a few flurries of activity which eventually got it working again across all device sizes in a way that will hopefully hold up. The only real pain point in the end was fixing the iPad issues. Since I couldn't change from a universal app to an iPhone only one (intended as a temporary fix since resolving the iPhone issues was slightly easier and would ensure that everyone has a working version) I had to get it all working in one go.
The most important thing is that it's working properly, again (and has been for a couple of months now). So far, no crashes.
You can download it from the app store.
Game Jam: Werewolves of War
Swift: Initialising a 2D Array
I have a struct called Tile, which has (for now) a position defined as a tuple:
struct Tile { let pos: (Int, Int) }
And a class called Board, which has a 2D array of Tile objects:
class Board { let tiles: [[Tile]] init() { var tilesArray = [[Tile]]() for row in 0..<Board.rows { var rowTiles = [Tile]() for column in 0..<Board.columns { let tile = Tile(pos:(column, row)) rowTiles.append(tile) } tilesArray.append(rowTiles) } tiles = tilesArray } }
This works, though it feels a little messy... I'll have to come back and look at this again.
Xcode 7 and Swift 2: Unit Testing (again)
Some follow up from creating a new project and adding tests.
I hadn't really noticed in the last one but I hadn't added the new classes to the test target, as I would under Obj-C. In Swift 2 there's a new @testable keyword. I found it blogged by Natasha the Robot when I started looking to find out why I wasn't seeing any code coverage showing up for my classes.
Then I started wondering why I was getting Undefined Symbol errors. I could resolve them by including the classes, but then I wouldn't get coverage and everything I saw on @testable assured me I didn't need to include them. Finally, I remembered I'd been getting a bit click happy earlier. I'd disabled Allow testing Host Application APIs.
One checkbox later and I'm a happy camper...
Okay, not a lot done tonight but I feel like a few pieces fell into place.
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.
Unity & Playmaker - Building a Keypad
Update: There's an updated version of this post, complete with source code and the full project here: http://www.stephen-gurnett.org/unlikely-objects/2014/11/20/unity-playmaker-building-a-keypad
I've been experimenting with Unity for making games and prototypes more quickly. One of the things I picked up in the recent Unity sale was Playmaker. When I first started out programming I wanted to do everything myself. I'm in two minds about the benefits of this. On the one hand, I learnt a lot of things (mostly what not to do but that is kind of useful as well). On the other, now I know those things I also know I don't have the time to spend on them.
I want to put together a quick project to provide as a little birthday gift to someone. It's little more than an animated card but I wanted to put some interactivity in there just to provide a little entertainment. It's also a good excuse to learn putting how to work with Unity (and Blender as well).
The GUI is built from standard Unity components. The keypad is represented by the small box on the wall. When the player gets close enough it triggers automatically. This could be refined but works well enough for testing.
And here's the Finite State Machine (FSM) as depicted in Playmaker's editor. It starts in the 'Off' state. On entering the triggering state we progress to 'On'. This state handles drawing the GUI and also fires an event to the player controller to enter an 'interacting' state which freezes the player in place and enables the mouse cursor.
On pressing a number button a modified version of Playmaker's GUIButton class is called. This sets a string on a specified variable equal to that of the number of the button. We go to Error Check to see if the current value should be cleared, and, finally, append the number string to the code. On pressing OK we validate the entered code by comparing it to the correct version, and, if it's correct, we open the doors. We go to the Exit state from there so we can send an event to restore motion to the player and they can exit the area of the trigger. Once done, the FSM is reset and will trigger again if the player hits the trigger. If the code does not match, we update the display to show an error message and set a flag so we know to clear the display when the user presses another button.
There's some small improvements that could be made but, otherwise, this is working nicely. It's easy to modify and could be used in a number of places if required. Overall, it was a useful learning exercise and picking something slightly more complicated than a light switch forced me to learn a few different ways of using Playmaker.