Devlog 3/30/16 Update

Did someone say devlog? No? Just me then.

Great news! The puzzle system is almost completely finished, all that needs to be implemented are minor bug fixes and the sound effects and puzzle track, but besides that, it’s done! I’ve added some last minute stuff worth noting today so I’ll go ahead and do that now.

Just an aesthetic change, but an important one nonetheless, I’ve implemented transitions between puzzles! It’s exactly as it sounds, and it’s easier to just show you than explain it, so I shall!

Finalized Puzzle Animations

As per the usual, no matter what I do, the gifs always speed up when I’m uploading them to wordpress, so sorry about that.

The other important change is the progress marker on the battery.

Progress marker

This denotes how low the battery has to be for the bomb to deactivate, which previously for some reason I didn’t have? This makes things a lot clearer for the player from a design perspective, and with a bit of tutorialization, it shouldn’t be any trouble to figure out the exact goal when messing with the wires.

That’s all for today on the progress front! Otherwise, I’d like to announce that officially, while I’ve kept changing it, I’m going to keep the projected price at 5$ USD. It’s been fluctuating on the page for a while, but I’ve decided that the final project should be a bit more available, so bumping the price from 7 or 10 to 5 should help out.


Devlog 3/29/16 Update

I said every other day/every day will have an update and dammit I mean it! So today, I wanted to show off the progress I’ve made since a day and a half ago. It’s mainly more animation stuff! I took the time to finally design the antagonist, Project 80 (Or Project 82, I haven’t decided on that yet), drew the animations for the protag and the antag, and then implemented them into Unity, and they now work in the game without a hitch!

I’ve also fixed a bug where the color of the text wouldn’t change from switching from character to character.

I have a gif of all three of these things, but again, even with a different gif tool, the speed seems a little off, so expect the actual game/demo to have slower animations.

Narrative Animation

And if you want a better look, here’s some regular screenshots instead!


Capture 1

Devlog 3/27/16 Update

I know it’s been a while, but to make up for it, I’m pushing to release the official demo by April 3rd! Going along with that, I’ve got  some progress to show!

First thing, the music for the puzzle levels has been made! It’s relatively short, only about a minute long, but considering it’s my first track, I’m pretty proud of it! The three music tracks for the narrative will be longer, or, at least, that’s what I’m aiming for.

Secondly, the thing that made me postpone this damn devlog for several days, I’ve finally implemented wire animations! With the prototypes so far, wires just sort of switched positions automatically, but no more!


It’s a bit sped up and in reverse because the uploader I used did something funny to the gif, but the main thing is that the wire animations are working! Mostly, since there are still a few bugs I need to squash. I know it might not seem like much, but I wanna show you just a third of the structure for these animations, not even taking in the programming for it.


Needless to say, this is why it took me about 15-16 hours straight to make it all work, but man, I only need an hour more of debugging and it’ll be done with and I don’t have to worry about it until I make more wire colors that is.

Lastly, I wanted to say thank you for all of you who participated in the prototype, and the two most common concerns (Too vague of a help screen and the timer was too hard to see) were looked over and fixed! So if you were worried about either of those being in the demo/final release, you don’t have to anymore!

Hopefully, I’ll be doing one of these devlog updates every day or every other day until I get to the demo release date, tell your friends about it!

Devlog 2/28/16 Update

Well, didn’t get too much done over the week due to personal life nastiness, but I’ve got something kinda big for today’s update! This time, I’ve worked out all of the major kinks in regards to the notepad and UI problems, so I thought it’s finally time to fine-tune the design policies regarding the move limit, and what better way to do that than with playtesting! Yep, got an updated prototype ready for anyone (including you guys) to try out! If you download and play it, please let me know you opinions using the survey link down below. That way, I can better craft the final levels for the game!


Quick tip for people who haven’t played the first prototype, the objective of the prototype is to drain the bomb console of it’s power as indicated by the battery sprite!

Download Link (Linux, Mac, and Windows)

Survey Link

Devlog 2/19/16 Update

Well, not much of an update, I’ve been sick all week, hopefully, I’m past the worst of it, though. Instead of some screenshot worthy stuff, I should probably just recap on what I’ve done before I set up this devlog!

Puzzle System:
Well, I’ve programmed it as such that by editing and adding to text files, I can change the wire’s positions and colors, the port’s colors, and the number of moves that the player has before their bomb goes off! This makes adding in levels much easier than creating a new scene in unity for each new bomb, and it seems to be less computer-intensive, for all I have to do is draw up the level design, and after I take my time with that, I can easily just assign them to the text files, which are later sorted into a string array that’s referenced when the puzzle level starts up. I’m actually pretty happy with this system of doing things, because while I wouldn’t e able to do this sort of thing (or at least not easily) with a platformer or a similar type of game that requires a filled map for their levels, this gameplay method lets me focus more on crafting well-made puzzles instead of worrying about putting it in-game, since it’s as simple as editing a text file.

Narrative System:
Just like the puzzle system, I’ve utilized string arrays to make my job of implementing, and the strain on the player’s computer, much less intense, but they’re used even more so in here due to the number of conversations, the player’s responses, and how much each of those responses add to the narrative stats. Which reminds me, I should probably take the time to explain how I’m handling the narrative splits. At each narrative split, the player’s highest narrative stat determines what path they’re on until the next narrative split, and I’ve labeled each path as ‘Apprehension’, ‘Trust’, and ‘Faith’, respectively. For eahc path type, the player gets an entirely different set of conversations until the next narrative split, where the player moves to a new path. For the first narrative split, their’s only one of each of these paths, but using an image from an earlier post, we can see that the paths split again after 5 conversations, but instead of having one of each path, there’s actually 2 of each path type!

With the 2nd narrative split, although there is two ‘Apprehension’ paths, they don’t have any different dialogue, although they are different from the last path since every next split brings new dialogue. This means that since there is 28 different dialogues, and the split begins after the 10th conversation, there is 64 total conversations in the game. Needless to say, I have my work cut out for me as a writer. Thankfully, writing is my strong suit.

But yeah, that’s an explanation of mostly what I have so far programming wise, I’ll make another post soon explaining more about what progress I have in the narrative system regarding playability, but for now I think this is a good stopping point!

Devlog 2/16/16 Update

Great news!! Thanks to a wonderful site known as HacknPlan, I was not only able to organize my tasks in a much better manner, I was also able to get 5 hours of work done! And in those 5 hours, I not only finished this lovely animation

Notepad for ‘Move Limits’

-but also, I was able to implement the move limits into the game! I should have a new testable prototype soon, but for now, all I can show is some screenshots, sorry!

(Bugged) Move Limit being used up

Losing by using too many moves

Yeaaah, that bug wasn’t happening in the editor, only when Unity built the prototype and I ran the executable version, odd, but I’ll fix it soon.

I’ve wanted to add in move limits for a long time. This not only helps assure that players don’t just switch wires randomly until they win, but also helps the mechanics to reinforce the tone of the story, with the main tones being anxiety and apprehension.

Devlog 2/15/16 Update

Sorry about the late update, came down with something today and only remembered to do this just now.

First off, I realized I didn’t even post the protaganist! I have an idle animation done for him, which aslo doubles as his general design.

Aaand, I whipped these up Saturday, these are the sketches done for the protag’s talksprites. I actually plan on taking the final talksprites at this resolution and then sizing them down to create a more pixelated effect, like the Aladdin NES game did by taking stills from the movie and resizing them for the game.