Saturday, August 30, 2014

Enigmatic Sale!

Starting Sept 1st Enigmatic will be 50% off exclusively on Desura for a month. Grab a copy for a buck and give it a go!

Tuesday, August 19, 2014

Dev Blog 41 - Feedback needed!


Have you played the Enigmatic demo or full version yet? Got some awesome feedback for us? Hit us up here:

Friday, August 15, 2014

Dev Blog 40 - RELEASE!

Enigmatic is officially released on:
If you haven't already, checkout the gameplay promo video!

Had to deal with some audio and texture compression issues for the Kongregate version, but it's all good now!


Thursday, August 14, 2014

Dev Blog 39 - One. More. Day.

All issues resolved, all tickets closed. Game pages on Desura, itch.io, and Kongregate are being prepared for release with lots of screenshots and box art and logos. Created a kongregate-specific version. Running through the pre-release checklist to make sure not a thing was forgotten!

Wednesday, August 13, 2014

Dev Blog 38 - 2 days left!

Today I cleared the remaining feedback tickets from the queue, and added a couple minor changes (such as the hint during final riddles playing the hint sound fx). All that's left to do by Friday is create a kongregate-specific version, run the builds for both versions, and upload them to kongregate/desura/itch.io.

Also forgot to post a link, I created a promo video yesterday! https://www.youtube.com/watch?v=EIeeDaSvZSE&feature=youtu.be

Monday, August 11, 2014

Dev Blog 37 - Code Review

As we get closer and closer to release, today I decided to review all of the 36 scripts written for Enigmatic. The purpose of this review was to clean out old comments, remove unused variables, and delete forgotten TODO statements so that if anyone uses the publicly available Git repo as a reference or learning tool, they won't be completely lost.

After performing a code review of all scripts in Enigmatic, the following were cleaned up &|| edited:

  • Player.cs - Added comments, removed unused commented out code
  • PlayerAction.cs - Added comments, removed Debug statements
  • ProjectileScript.cs - Added comments
  • RiddleScript.cs - Added comments, removed unused commented out code
  • FinalRiddle1.cs (as well as 2 & 3) - Removed Debug statements
  • FinalRiddleQuit.cs - Added comments
  • FinalRiddleText.cs - Added a commment, deleted unused Update() function
  • levelSelect.js - Deleted, script is no longer used
  • XOnRailsPlatformX.cs - Deleted, script is no longer used
  • mainMenuKeyboard.js - Added comments
  • IntroductionScene.cs - Removed an unused variable
Update: Fixed a small bug where the background music from the final riddles was bleeding over into the end credits.

Sunday, August 10, 2014

Dev Blog 36 - New music, new sound fx, almost done!

5 days until release, the countdown begins! Today I added in 11 new music tracks, a few sound fx, and closed out a few of the remaining tickets.

Over the next 5 days my time will be devoted to implementing the remaining feedback and tweaking and tweaking and tweaking the levels until it feels juuuust right. Will also spend some time to see if I can take better advantage of Kongregate's dev API.

Friday, August 8, 2014

Dev Blog 35 - Closing in on release

Added some new artwork, sound fx, music, and updated credits today. Also closed out 2 more tickets so far.

Steadily closing in on August 15th release. Waiting on some new music tracks, closing out the remaining tickets, and then we should be all set to release on Kongregate, Desura, & itch.io!

Thursday, August 7, 2014

Dev Blog 34 - Non-rant Post

I did complete other tasks today other than rant about Kongregate's API.

Added new artwork (the final riddles have an awesome background now!) and fixed a few minor issues. The middle mouse button was able to trigger deaths, disabled that. And the spacebar/mouse clicks could trigger deaths during finals riddles, disabled. The spacebar is actually never used during the final riddles, but I was afraid that if users thought they could use the spacebar to get hints (like they can in the previous 20 levels) they'd frustratingly die a few times.

Currently working on an issue I noticed while testing Enigmatic on smaller screens (laptops) in Kongregate's cinematic mode. I think all I need is some basic resizing code.

Dev Blog 33 - Kongregate API useful? /rant

So after implementing a basic integration of the API, I made sure it was working with the JavaScript console:



Seems good, right? The messages are being sent! Well today I poked around the Developer Center to see where I could view these statistics. The whole idea behind implementing this API was to track which levels the players were dying most in (AKA the most difficult levels) and what score players finished the game with (AKA gauge the overall difficulty).

In order to gauge these things, I would want to be able to read the statistics being tracked. But guess what? According to this forum post, you can't! The statistics get sent over to Kongregate, and you never see them again. Kongregate can use them to make badges, leaderboards, and whatever else for your game, but any useful statistics a developer might use to tweak difficulty or design won't be a badge or a leaderboard, so they will apparently never see the light of day.

All of this is of course solved if I were hosting the same on my own servers and used API callback URL's to fetch the statistics. But I'm not hosting the game myself, nor do I have plans to. Most forums have suggested using third-party systems, I'll give those a shot.

And now I'm failing to see what the point of the Kongregate API even is. Shiny badges and leaderboards are all fine and dandy, but if I can't take advantage of user statistics to improve my game, why bother recording them?

Update: The only way to "view" the statistics is the have them posted to the publicly available leaderboards. I enabled this, just so I can see them, but will disable them at some point.

Wednesday, August 6, 2014

Dev Blog 32 - Integrating with Kongregate API

Today I spent some time reading the Kongregate API documentation and integrating it. For now I implemented 2 basic statistic saving functions, one when death occurs (logs the level it occurred at) and the other when the game is complete (logs the final score). With these I can identify which levels are troublesome and gauge the overall difficulty of the game (or see if people are even finishing the game at all).

Time permitting, some statistics to be added are:

  • When the game is started
  • The time difference between when a riddle is shown and solved

Tuesday, August 5, 2014

Dev Blog 31 - Workin' the queue

Completed 3 medium priority tickets thus far today, improving the intro and reworking the pause screen.

Update 1: Completed another 2 tickets, reduced gravity and address the issue where falling deaths would frequently occur in the beginning of certain levels. Also began writing up a reflection of the development process thus far.

Update 2: Quickly kicked a low priority ticket, added a link to the feedback form in-game and updated the Kongregate version. Only 10 more tickets to go!

Update 3: Fixed a timer bug, closed yet another ticket.

Monday, August 4, 2014

Dev Blog 30 - Medium Priority Queue, Bug Discovery

While working on the medium priority queue of tickets today, I discovered a bug with the new redesign of the hint system. If the player read a riddle for a while (>20 seconds) and then hit spacebar to continue to the level, the first hint would show up immediately. This has since been fixed.

Also made the dissolving platforms in levels 10, 19, and 20 bigger in size and dissolve faster so that if they player ignored them and didn't jump over them, it would be guaranteed death.

Update 1: After completing a couple of tickets I updated the credits scene so that the GUI was the same as the rest of the game. Not a ticket but did need to get done.

Update 2: Completed 5 medium tickets, started work on a 6th (removing non-essential text in the pause screen) in addition to 1 low priority ticket.

Sunday, August 3, 2014

Dev Blog 29 - High Priority Issues Done

Over the course of Friday/Saturday/Today I've completed all of the high priority issue tickets. I even ended up adding 2 additional high priority issues that I subsequently resolved.

With the completion of these high priority tickets comes:

  • A hint system redesign
  • The fixing of 4 bugs
  • The addition of a requirement for players to hit spacebar to continue past the instructions as well as every riddle (to make sure they read it, and can read it at their own leisure)
  • Implementation of new ambient sound fx (enemy dying, level complete, hint showing up, menu interaction, platform dissolving)
  • Implementation of a GUI timer

Next up is to begin working on the Medium Priority queue!

Friday, August 1, 2014

Dev Blog 28 - Addressing Feedback all day

In order to address the 23 feedback tickets from yesterday, I've begun going through in a systematic fashion and addressing them by priority tags. I of course started with the High Priority tickets and managed to get 7* done today.

My goal is to get at least 5 tickets done per day. At that rate, I should be done with this feedback in no-time and have plenty of time to implement the last bits of music and art I receive before release.

*Updated to 7 issue fixes for today

Thursday, July 31, 2014

Dev Blog 28 - Bi-weekly meeting, playtesting session, updated goals

Today I had another meeting with my professor, got some feedback and discussed progress with him. Then I met Max, a young game designer at Northeastern University. We had an awesome playtesting session during which Max played through Enigmatic - I got a LOT of great feedback from this, and uncovered a few things that need fixing (took 3 pages worth of notes).

We also played through a game Max is designing along with my professor Casper Harteveld; it was an early stage paper prototype but damn was it interesting! A Ph.D student at Northeastern is going to be programming the digital game to have PCG, so I can't wait to see how it develops. I probably can't (or at least shouldn't) divulge specifics of the game, but it's aimed at teaching middle school students basic Computer Science (not programming, but actual CS concepts that almost all middle/highschool classes don't teach). It's got a noble cause and buckets of potential for great gameplay.

Anyway back to Enigmatic:
There's exactly 2 weeks until release, so I've updated the goals of Enigmatic to incorporate the feedback and ideas I received today. If everything goes accoridng to plan (ie: I receive the remaining music and art on time, which should happen) we should be releasing right on time.

On the programming and level design side of things, we were slightly ahead of schedule by 5 levels for this past milestone, so deciding to incorporate a ton of feedback won't be setting us back, as we planned for it anyways.

Update: I realized "updated the goals" is pretty vague of me to say. To be more specific I added exactly 23 GitHub issue tickets (here and below). Tons of bug fixes, existing gameplay enhancements, and design changes. All to be implemented in the next 2 weeks. Coffee and I are about to become the best of friends.


Wednesday, July 30, 2014

Dev Blog 27 - End game, credits update, new art

Today I updated the end game scene so it's a lot more than just "Thanks for playing!". There's a short bit of storyline text and then scrolling credits. I also updated the credits to reflect recent changes in the team composition (one of our artists dropped out, added a few special thanks). 

Also added some new artwork as well - a new main menu background (below) and a whole plethora of props throughout several levels.


Tuesday, July 29, 2014

Dev Blog 26 - Level Design Cues, Sound FX

Got a few updated sound fx implemented today, and also tweaked a few levels to add little cues. For DropPlatforms (the platforms that fall out from underneath the player when touched) I added 2 different subtle cues to let the player know what will happen.

The first cue is on some levels, the DropPlatforms are different colors from the other platforms. In some levels this different in quite obvious (dark brown vs light brown) but on others a little more subtle.

The second cue is on some levels, the DropPlatforms are at a slightly lower Y position then the rest of the platforms.

For consistency, both of these cues are never used together, it's always one or the other in a level. Also for consistency, every DropPlatform in a given level has the same cue. No reason to fool the player into thinking a platform is safe by not having the cue applied to it, only to have the player die and get frustrated. That's just mean design.

Also finished cutting up the final riddle instructions. Now it's much shorter, and during the first final riddle after 60/120/180 seconds a tip will come up explaining how to solve a final riddle, in case the player doesn't figure it out immediately.

The next two things on the docket are disabling some things that make the gameplay a little annoying. The first is disabling shoot-spamming, so the player had to hit the key each time they want to shoot. The second is to disable sound FX spamming, so a sound effect won't play again until it's finished playing.

Update @ 6:30PM: Fixed the two issues mentioned above (I suppose you could consider them bugs). Now the player must press the right key multiple times if they want to shoot multiple times, and holding the key down or pressing the key rapidly won't spam the sound effect, but it can still be heard multiple times in a level (the shooting levels or multiple jump levels for example).

Monday, July 28, 2014

Dev Blog 25 - New sound FX, weekend project

Got another batch of awesome sound effects from the amazing Ronny Mraz, implementing those today.

Also working on cutting down the amount of text in the final riddle instructions (maybe removing them entirely) and switching to a hint-like system.

In other news:
Over the weekend I started a sizable hobby project, I'm building my very own coffee table (never done any major woodworking projects before). It's a fun project, and a great way to learn basic woodworking. It's slow going, but I'm enjoying it very much so far. This won't detract much from Enigmatic's development as I'll be working on it during downtime and on the weekends, though if I do fall behind schedule I'll postpone the table until after Enigmatic is released. I'm doing a blog about it on my personal website (with lots of pictures!).

Friday, July 25, 2014

Dev Blog 24 - Introduction Scene

Spent today adding a short introduction scene explaining the backstory and instructions for Enigmatic (screenshot below). Quite happy with how it turned out, not a ton of text but still very explanatory.

Also planning on editing down the instructions for final riddles a lot. It's far to much text in comparison to the introduction I created today. I plan on removing most (if not all) of the instructions and having them fade in over time, similar to the hint system, in case players can't figure out how to complete a final riddle 60-90 seconds in.


Thursday, July 24, 2014

Dev Blog 23 - Level Design

Spent a few hours today improving the level design of levels 12-20, and also went back and tweaked a few earlier levels to increase difficulty. Had to completely redesign level 12 since it was either impossible for some players or far too easy for others (players could just hold down the right key and you'd get by, no fun, no challenge).

Also tweaked the spear obstacle so it can go in both directions, now you'll never know which side it'll be coming from! Another dev screenshot below!



Wednesday, July 23, 2014

Dev Blog 22 - Fixed a small persistent issue

Fixed a persistent issue I had been having with some of the obstacles. The falling obstacles can kill the player just fine, regardless of if the player is moving or not. However the sideways spear obstacles and the "crushing platforms" obstacles had a issue where collisions were inconsistently detected when the player wasn't moving.

If the player was moving and hit one of these two problem obstacles, he would die guaranteed. But if the player stopped moving just before collision, death would sometimes not occur. I managed to solve the problem by reversing the way I was detecting collisions. Instead of checking from the Player.cs script to see if the player had hit any obstacles, I modified the obstacle's scripts to check if they had hit the player.

In order to do this I had to add Rigidbodies to the obstacles, which after collidiing with the player would get all screwy and rotated, so I had to take some additional steps to reset the obstacle properly after collision. Also the sideways spears would sometimes double, triple, or quadruple kill the player for a single collision. So I also had to write some code to temporarily disable the spear's collider on collision and then re-enable it later.

All of this was well worth the effort since collisions now occur with (as far as I can tell) 100% consistency.

Update: Just discovered the constraints you can set for rigidbodies, used Freeze Rotation so now I can go delete all of the rotation resetting code I wrote! Quite a nifty setting!

Update 2 @ 5PM: I inadvertently discovered some really cool behavior of the Crushing Platform obstacles. I had accidentally assigned the script responsible for the behavior twice to one of the gameObjects. The waitTime and repeatTime variables (responsible for how long the script waits to begin and how often it repeats, respectively) were different for each assignment of the script.

Normally 2 assignment of the same script would make the gameObject really screwy, but the behavior it created was actually very very cool. The platform would go up and come back down all the way, as expected. Then it would go up, and as it was coming back down, stop halfway and pause. It would stay paused for a second or two, and then come down all the day, and then repeat the entire process.

This "pause" effect created by the two script assignments effectively "fighting" with each other could actually fake out the player, make it seem like the platform is about to come down, then stop cold, making the player think it's safe to cross. And then just when the player might decide to go for it, BAM the platform comes crashing down! Totally unintentional but so very cool. Definitely going to spend some time playing with assigning the same script twice and seeing which values can create interesting behavior. The scripts "fighting" with each other doesn't seem to affect runtime or FPS noticeably, and no errors are coming up.

Tuesday, July 22, 2014

Dev Blog 21 - Working on more levels, feedback

Today I added a bunch of new artwork and implemented basic levels for 15-20. One could say that all 20 levels are "done" in a sense, but I'm already planning to test these newly created levels and expect to be changing them quite a bit, to have a nice difficultly curve. I'm also keeping in mind the difficulty of solving the riddles themselves, so many of these levels aren't highly challenging to beat in terms of a platformer. Only the last 3 or so will be difficult both to solve and play.

Additionally I've been working on implementing feedback from my professor and friends. A few notable pieces of feedback were that certain levels were quite difficult to get past, some were too easy/boring. I'm working on adding more variety to the level gameplay to address these issues.

Update @ 10PM: I implemented a sideways flying obstacle to address the variety concerns. These obstacles, just like the falling ones, kill the player on impact. To avoid them the player needs to time jumps well, adding a slightly new gameplay mechanic. Dev screenshot below!




Update 2 @ 10:15PM: Also resized several backgrounds that weren't big enough to cover the whole level. Updated the Kongregate beta, here: http://www.kongregate.com/games/incendiaryindus/enigmatic

Monday, July 21, 2014

Dev Blog 20 - Bug Fixes

Over the weekend thanks to feedback from my professor I was able to find and reproduce 2 important bugs. The first was the hint system breaking after players quit. If the player quit and played again straightaway, only the hints for the first level would show up, regardless of which level was being played. Clearly some variable wasn't being reset properly on quit.

The second was the hints would still be visible when the player paused the game, which would often overlap the riddle text and make it difficult to read.

Both of these bugs are now fixed, and the beta on Kongregate has been updated.

On a lighter note: in the original prototype of Engimatic, I had used a riddle from The Hobbit, one that Bilbo uses against Smeagol. A few weeks ago I replaced this riddle (along with a few others) to avoid any copyright issues. Of course what do I absent-mindedly replace it with? Another riddle from The Hobbit. D'oh. Thankfully our sound FX artist was leisurely reading The Hobbit when he noticed an all-too familiar riddle.

Update @ 7:30PM: So these 2 bugs actually persisted when I uploaded the supposed "fix" to Kongregate. Apparently the Web version of the build still had these bugs, but the desktop version does not. Not quite sure how it's possible to fix a bug for desktop but not for web.

In any case, I took a closer look and realized that part of the problem was that after the player quit and hit play again, there was a duplicate RiddleScript.cs object that was throwing NullReferenceExceptions out the wazoo. In order to get rid of this duplicate but still keep the original I had to implement a Singleton Pattern (thanks Comp Sci classes!). I should have realized this would be necessary from the start, but you gotta live and learn eh?

Just uploaded the fix to Kongregate (luckily I didn't publish the earlier "fix" to the public) and both bugs are now resolved, even if the player quits and plays again.

Update 2 @ 9PM: Also added some new artwork, and tweaked a few levels to increase variety of gameplay.

Update 3 @ 11:30PM: Removed the 2nd Hobbit riddle and added a great replacement! Also working on fleshing out a few more levels currently.

Friday, July 18, 2014

Dev Blog 19 - New Sound FX

This morning I got the first batch of updated sounds from our Sound FX artist Ronny Mraz, spent some time implementing these and slightly rewriting the sound FX script to be more organized/work better.

Also noticed a small bug, when the player quits a level the background music persists, leading to a duplicate track, until the player hits "play". Fixed this issue as well.

Thursday, July 17, 2014

Dev Blog 18 - Skype meeting, Kongregate, Promo Materials

After another Skype chat with my professor, I uploaded a beta version of Engimatic to Kongregate.com.

During our discussion, we realized that beta testing would be more difficult since we are no longer publishing on Google Play. We realized that because the game required keyboard input, it would be difficult to port to mobile. I'm working working on a few design solutions for  a mobile version of the game, but that's for later down the line.

In order to replace Google Play and get some beta testing done easily, we decide to upload it to the popular gaming site Kongregate, you can check it out here!

Additionally, I quickly created some promo materials in Photoshop (below). I'll be spending the rest of the day adding the in-game credits and fleshing out levels 12-15.




Wednesday, July 16, 2014

Dev Blog 17 - Added tips, music

Added in a tiny new feature, for every other from 2-10 riddle a tooltip will appear to let players know about little things such as:
  • Finished reading a riddle? Press ESC to skip it!
  • Is the cat on fire again? Need to pause? Hit ESC!
  • Miss part of a riddle? No worries, hit ESC during a level to read at your own pace.
  • Careful! Progress is not saved and quitting will put back at Level 1.
  • Check out our first platformer game "Chromacore" on Desura and Google Play!


  • Also implemented new music tracks for levels 1-10! Wrote a quick script that loads a new background music track for each riddle from the Resources/MusicTracks folder.
  • Tuesday, July 15, 2014

    Dev Blog 16 - Bug fixed, new art

    The serious bug I wrote about a few days ago has now been fixed. Some details on the fix itself:

    In the OnGui() function of Player.cs, the sceneIndex of RiddleScript.cs is reset to zero once the player quits. Additionally, the bigHintText and smallHintText gameObjects are destroyed to avoid duplicate gameObjects. Had add some code in RiddleScript.cs to reassign the references for these gameObjects.

    I decided not to pursue an exploit of this bug to save game progress, in order to stick to the original design decision of having players play all levels consecutively.

    Also implemented some more artwork into the game today, it's all starting to come together!

    Update: Implemented a new background animation for Levels 9-12 as well

    Update 2 @ 8PM: Adjusted several levels for difficulty, reworked moving enemies script.

    Update 3 @ 9PM: Implemented barebone versions of levels 13-20, to improved throughout development. Mostly to test the Final Riddles transitions, but also to just get that out of the way.

    Monday, July 14, 2014

    Dev Blog 15 - Short Update

    Implemented more artwork, added intro scenes before final riddles 2 & 3. Still working on fixing the bug discovered yesterday.

    Sunday, July 13, 2014

    Dev Blog 14 - Bug Discovery

    While implementing some new artwork, I stumbled across a serious bug.

    If the player gets past the first two riddles and quits during Level 3 (owl level), and immediately hits play again, the first level is loaded (as expected). After beating the first level, the riddle for the 4th level is shown ("shoe" riddle) as opposed to the expected "Map" riddle.

    The scene index on the RiddleScript is shown as 3, while the expected indices for Riddle 2 is 4, for riddle 3 is 6, and for riddle 4 is 8.

    There is clearly a bug in the quitting code, some variable needs to be reset. Potentially this bug could actually be exploited and used to save progress during a game session.

    Additionally there appears to be a bug with the scene expectations code. When matching a scene index of 3 with an ExpectedSceneIndex of 8, something should go wrong. Looking into how the ExpectedSceneIndex is used and compared to the scene index.

    I'll be working on fixing this all day tomorrow, and perhaps taking advantage of it to easily save game progress.

    Saturday, July 12, 2014

    Dev Blog 13 - Final Riddles, Animation

    Over the past few days I've implemented some new artwork, including the talking animation for the Sphinx that tells the riddles. One point of common confusion was players weren't aware this was who the riddles were being told by, so I wrote a script to animate the Sphinx at different speeds of talking.

    Additionally I fine tuned Final Riddle 1's script and am now working on FR 2 and 3.

    Update @ 9PM: Final Riddles 2 & 3 have been implemented. I still need to add a transitional scene in-between 1 - 2 and 2 - 3 to introduce each riddle.

    Thursday, July 10, 2014

    Dev Blog 12 - Short Update

    Death counter is now hooked into the final riddle script, so incorrect guesses add to the death count. There's a peculiar issue going on with this however. Initially I thought that this:

        // If any key is pressed, and it isn't the current correct key,
        // increment death count
        if(Input.anyKeyDown && (!Input.GetKeyUp(CorrectKeys[0]))){
            deathCntScript.deathCount++;
        }

    would do the trick of increment the death counter when the incorrect keys were pressed. It does, but for some reason also increments the death counter when the correct key is pressed as well. I thought this workaround would achieve the result I wanted:

        // If any key is pressed, if it's the correct key, do nothing.
        // Else, increment death counter.
        if(Input.anyKeyDown){
           if(Input.GetKeyUp (CorrectKeys[0])){
    return;
    }else{
    deathCntScript.deathCount++;
    }
        }

    But that has the same issue as well. As a temporary fix I'm not decrementing the death counter when the correct key is pressed, to mitigate the false incrementation when the correct key is pressed. I can't tell where this incrementation is coming from or why it's occurs. Maybe because it's in the Update( ) function, return isn't doing anything, but that doesn't explain why the first code example doesn't work.

    Working on implementing Final Riddles 2 & 3.

    Wednesday, July 9, 2014

    Dev Blog 11 - Final Riddle Systems

    Today, after adding the rest of the 20 riddles into the game as well as some new artwork, I decided to bang out the bulk of the Final Riddle implementation today. I have to say, I'm pretty satisfied with the results.

    I implemented a series of fading text animations using coroutines. This text congratulates the player on beating the first 20 riddles, tells them only 3 Final Riddles remain, and instructs them on how to solve the Final 3 Riddles (along with an example).

    I then wrote the code for the first Final Riddle (FR). At first I thought using an array of KeyCodes would be the simplest way, but I quickly found that due to C#'s lack of dimensional arrays, it would prove overly complex to try and use an array. I instead rewrote it as a List<KeyCode> which proved much easier to work with. This way, I could easily check if the correct keys for the answer to the riddle are being pressed in order. Initially with my array implementation I thought I'd need to write some additional code to check if the keys were being pressed in order, but with a List it was as simple as popping the first element of the list after it was correctly pressed.

    Now the FR implementation isn't completely done, I still have to hook in the death counter so that wrong key presses increment it. And I of course also have to implement FR 2 and 3 (but those will be straightforward now that the groundwork was laid with FR 1).

    Admittedly I did ignore some goals for the upcoming milestone in order to implement FR's. I'm going to try to play catch-up and implement all of the new features planning for the upcoming July 15th milestone, but if it doesn't happen I'm OK with falling a little behind. I think the addition of FR's definitely make Enigmatic a much, much better game, and I'm glad I got the bulk of the work done for that today.

    Below is the FR 1 screen, with the riddle and word bank of previous answers blurred out of course ;)




    Tuesday, July 8, 2014

    Dev Blog 10 - Decisions, Decisions

    After consulting with my professor many great ideas and decisions were made, while many doubts were put to rest.

    I've 100% decided to remove level selection. I've now remembered that some of the games I'm using as inspiration and reference (such as One Button Bob) don't have level selection screens. Through my own play experiences, these games don't have any of the negative side effects I've been worried about.

    Additionally, I've decided to add an exciting gameplay element at the end of the 20 levels. After the 20 riddles are solved and their levels are completed, there will be 3 final riddles. Unlike the previous riddles, there will be no playable level paired with the riddle. Instead players will be given a sort of "word bank" of answers to some of the previous 20 riddles. This word bank will be used to find the answer to each of the 3 final riddles, with the bank changing after each one. Not all words in the bank are part of the answer.

    For example if the answer to a final riddle is FORT, players will see _ _ _ _ four dashes, and a word bank of 8-10 answers to previous levels. The first letter of 4 of these answers will be F, O, R, and T (such as Find, Oar, Rent, and Tent) while the others are erroneous.

    No hints will be given to the player as to what the answer is, the only hint provided is the length of the word and the fact that the word bank contains the hidden answer (and of course, the riddle itself).

    This gameplay addition will add a lot of cohesion and consistency to the game, and will be quite challenging for most players. I'm most excited, and spent a lot of time crafting these final 3 riddles myself. Additionally the first 20 riddles have now been decided on. All that's left now is to churn out the artwork, music, sound FX, and code to bring everything together.

    This will be a fun 5 weeks =)

    Monday, July 7, 2014

    Dev Blog 9 - An Odd Design Decision

    So after a few hours of fruitless tinkering (and some time away to think) I've made a somewhat odd decision. This could totally bite me in the ass or be the wrong design decision, and I'm gunna consult my professor on this, but I think I'm going to remove level selection altogether.

    The reasons are two-fold. First, the obvious one, is the issues I'm having with the consecutive loading requirements I wrote about in Dev Blog 8 (below). Second, is because I think this could add some decent challenge to the game.

    Right now, Enigmatic is fairly easy. Once you've solved the riddle, there's some challenge in the gameplay itself, but not much. Once you've solved all 20 riddles, game over.You can breeze through the entire game multiple times to get a perfect score easily after that.

    But if players had to play each level consecutively, that might do 2 things:

    • Engage the player more - if the player knows they have to beat all 20 levels in 1 sitting, lest they have to repeat levels they've already played, they might be more engaged (or they might just uninstall the game straightaway).
    • Challenge the player more - along the same vein, if the player gets stuck on a riddle, they can't simply quit and think about it for a day or two and come back (they could leave it paused of course!). This challenges the player to defeat that riddle on the spot, or accept that they'll have to replay some levels.
    And now here's where things get interesting: my professor suggested an awesome idea to make Enigmatic more cohesive - have 1 final riddle that is a culmination of all of the answers to the 20 riddles. This "final boss" so to speak, would add a decent amount of challenge to the game, but would REALLY add a lot of challenge if paired with the removal of level selection functionality.

    Admittedly, this could be a terrible design decision and make the game much less fun. But hey, I can't learn without making mistakes, right?

    Dev Blog 8 - Reworking level selection

    After implementing a few small features, I began working on a big big issue. Because of the way the prototype was programmed, all levels load consecutively, and break if loaded out of order. This is obviously a big deal, since players would have to play through every single level every time they played the game.

    Thus far, it's been a pretty hairy situation. Initially I thought it would be as simple as including a bunch of gameObjects in every scene, that was normally preserved through DontDestroyOnLoad. Unfortunately that isn't the case.

    I'm going to continue to try to work at this issue, but I'm already thinking of alternative solutions, such as saving level progress locally so players don't have to repeat levels they've already beaten. The down side of that is players can't go back and replay levels without restarting the entire save. It would be best if I fixed these issues and enabled proper level selection.

    Sunday, July 6, 2014

    Dev Blog 7 - Features, Redesign

    Today I implemented a few more features, and come across an interesting design decision.

    So I had moving platforms in both X & Y directions, and I thought to myself "When is the Y direction platform ever going to be useful? The levels themselves are very short and small, so trying to squeeze a Y direction  platform into a level won't create any interesting gameplay or challenge".

    But why waste good code? I decided these Y direction platforms would be better suited as obstacles, rather than means of transportation (though one could definitely interpret a moving platform as an obstacle, not the point here). I decided to re-purpose these platforms into the classic "crusher" obstacle - a big thing that moves down to smush the player, moves back up to it's resting position, and comes crashing down again. That I can definitely fit into these smaller levels.

    Thursday, July 3, 2014

    Dev Blog 6 - Progress Update

    Had a quick Skype meeting with my professor to recap progress thus far. The best part of Enigmatic's development has been the unified progression on all fronts of art, music, and programming. Part of the problems we experienced with Chromacore was broken, inconsistent progression (every week only 2 of the 3 categories of art/music/programming would see progress).

    Today we'll be publishing Enigmatic to the Google Play store to being beta testing and iteration. Trying to get a few more features done before that happens, but we'll publish by the end of today regardless.

    Edit: I decided to update Unity to 4.5.1 as well as update a few plug-ins to get rid of a bunch of incessant errors. It took a while to update everything, but well worth it since the errors are cleared now.

    Wednesday, July 2, 2014

    Dev Blog 5 - New Artwork, Bug Fixing

    We got some kick-ass new artwork done by our newest addition to the team, Chris Vales. He'll be helping with the artwork creation for Enigmatic. Check out his work here.

    Over the last few days I've been working to implement various kinds of moving platforms. I was able to get moving platforms in the X and Y directions, but rotating proved to be more challenging. The implementation I tried caused some pretty neat bugs, so I'm working through rewriting the moving platforms systems so it can function for all 3 platform types.

    Monday, June 30, 2014

    Dev Blog 4 - Implementing New Features

    Today I implemented "on-rails" platforms that move in x & y directions (besides falling, which was already done) and rotating platforms.

    After implementing these I stopped and thought for a bit about how I wanted the player to interact with these platforms. 

    On one hand I can have the player character automatically move with the moving platform like in many platformer games. This removes any challenge associated with a moving platform, which is usually compensated for by adding challenge elsewhere. For example, in some platformers when you jump on a moving platform and your character moves with it automatically, you will have to time when you jump off of the platform perfectly to avoid death or enemies or some obstacle. If no challenge is added elsewhere, and the platform movement is done for the player, there's really no challenge presented and you might as well have a static platform.

    On the other hand, I could force the players to keep moving with the platform in order to avoid falling of and dying. This adds some challenge, but not a lot - it's fairly easy to keep holding the movement key and continue moving with the platform.

    I ended up going with the 2nd option - players have to keep moving if they want to stay on the platform. However, I added a slight additional challenge and have plans to combine it with parts of option 1. The slight additional challenge is that the player moves faster than the platforms, so they can't just blindly hold the movement key down and steamroll past the platform's challenge. And my plans for further down the line in more challenging levels is to combine moving platforms with enemies, moving obstacles, and gaps to add more unique challenges to the moving platform.

    Friday, June 27, 2014

    Dev Blog 3 - Reworking gravity, new features

    Today I rewrote how gravity works in Enigmatic - the way gravity was written didn't work well with the implementation of one of the new features (dissolving platforms). When a platform dissolved, if the player was still above it and not moving, they would just float above nothing, and could continue the level without dying if the next platform was close enough. Obviously this isn't intended, so I changed gravity around, and made it slightly stronger, so that if the player decides to stick around while a platform dissolves beneath their feet, they're sure to die.

    Next up, I'll be implementing platforms that move in x & y directions (besides falling, which is already done) and rotating platforms.

    Side note: "Alive" 2007 by Daft Punk is my new favorite album to listen to while writing C# scripts =)


    Thursday, June 26, 2014

    Dev Blog 2 - Setting up music & art production

    I spent a considerable amount of time today communicating with Efe, one of our background music composers, Ronny, our sound FX maestro, and Cheyenne, our talented artist. It's good to setup up this production pipeline early (much earlier than we did with Chromacore) and clearly communicate Enigmatic's needs to everyone contributing.

    I'm spending the rest of the day implementing new features and fixing up the riddle script. I quickly discovered that the way we programmed the prototype last semester wasn't the brightest way of doing it.

    The way riddles and levels alternate, and the way we have the right riddle paired with the right level hinges entirely on if the scene index is odd or even. Every riddle scene's index is even, every level's index odd. This worked just fine for the prototype's purposes, but for a real fully fleshed out game, we're adding a menu system and level selection, which needs to be added at the earliest scene indices. Adding the menus and level select throws off the indices of the riddles and levels, which breaks the riddle script.

    I'm now in the process of rewriting it so it no longer depends on the absolute scene index, but rather a scene index assigned to the riddle or level manually via an empty gameobject in the scene.

    Edit: Finished up rewriting the riddle script, it no longer depends on the absolute scene index, but rather a modified scene index assigned to each scene individually.

    Edit 2 @ 8:30PM: Implemented falling obstacles, dissolving platforms, and working on having moving enemies now. Might decide against including moving enemies, since the levels themselves are quite short and small, there might not be much room for them to move!

    Wednesday, June 25, 2014

    Dev Blog 1 - Engimatic Alpha Development

    Here's a sneakpeak screenshot of alpha development for our 2nd title "Engimatic", a 2D riddle/trivia platformer!!


    Wednesday, June 4, 2014

    Back to work!

    After a short stint abroad (and a quick visit to a Serbian hospital, no worries, nothing serious) I'm back in the US and starting development of our next 2D game "Enigmatic" - already prototyped and designed!


    Thursday, May 22, 2014

    Greetings from Turkey!

    On a short break from game development to see family. Development of our 2nd game, Enigmatic, will start in about 1.5 weeks upon my return to Boston. It's already designed and prototyped, all of the core mechanics are written and functional. Enigmatic is a 2D riddle-trivia platformer. If that description makes you go "huh?" or "what?" I don't blame you!

    The core idea of the game is players are given a short riddle or piece of trivia before each level, usually with a one-word answer. The answer is the key to playing the corresponding level...more to come soon!





    Friday, May 16, 2014

    Dev Blog 96 - Post-release

    With release comes a big weight off my shoulders - countless hours of work, worrying, and nerves all finally all gone! But that doesn't mean I'm done, or that I don't have anything to do anymore.

    First and foremost, today I'll be addressing a few minor issues:
    • Version number in-game is different from build number
    • End of level credits need updating
    • Add a message before Main Menu loads to disable "vertical only" phone settings, don't load game until landscape is enabled.
    Next, I'll work on getting cosmetic skins completely working, but that's a bigger issue than I can address today. I'll be hopping on a plane to leave the country and see family late tonight, but I will take care of these simpler issues and continue working while I'm gone (I'm bringing my laptop of course!).

    Update: Just completed all of the minor fixes, uploading new builds for all platforms now.

    Update 2: All platforms have been updated to the latest version 2.2. Gunna go submit to the iOS App Store to begin the 1-2 week approval process now.



    Get it on Google Play




    Thursday, May 15, 2014

    Dev Blog 95 - Released!

    Chromacore has been released across all targeted platforms! Now live on Google Play, Desura, and itch.io:


    Get it on Google Play






    Chromacore will soon be available via a Humble Store widget, the Bundle Bandits game bundle, and on iOS.

    Dev Blog 94 - Release Day!

    Today's the day, release! Running builds for Windows, Mac, and Linux now. Everything should be up and ready by 5PM!

    Unfortunately it's looking like I'll have to push without the in-game shop completed. I just published one last effort to fix the problem, we'll see how that goes. I wrote all of the equip and unlock functionality last night, but I'm still running into the same issues.

    Update 1 @ 2PM: Heh. So I may have fixed the equip bug (it's almost poetic how close to release this occurred). I'm going to go ahead with release and then continue working on the in-game shop. Pending the results of the push I just published, I may temporarily disable the store.

    Update 2 @ 4PM: I did make some headway on the equip bug, I think that it's fixed. But some of the functionality for the skins appearing during play isn't there. I've temporarily disabled the skins and started running the release builds to get the game out there. I'll work on cosmetic skin functionality post-release. Didn't want to have to do it, but I simply didn't have enough time between when I actually received the skins and release to get all of the functionality implemented. Maybe if everything worked perfectly the first time it'd be done on time, but that almost never happens.

    Wednesday, May 14, 2014

    Dev Blog 93 - Last day of development

    Today's the last day of serious-crunch-time-development, I plan on spending all of tomorrow running builds, uploading the release versions across multiple websites, and getting the word out. Speaking of which, keep an eye out! Chromacore will be available on IndieCity, itch.io, and the the Bundle Bandit  soon after release.

    So, on the last day, what is there to do?

    Well, first and foremost fixing the equip bugs. The insight I wrote about last night wasn't correct - I thought perhaps an Update( ) function was failing to run every frame, but that wasn't the case. However, after proving the Update function did run every frame via Time.timeSinceLevelLoad, that actually gave me a clue for a potential fix, which I pushed this morning and will test soon.

    Next, implementing some last minute artwork I got this morning.

    Next, re-cutting level 6 (or cutting it entirely).

    Lastly, cleaning out the project. Deleting old/unused files to reduce file size.

    Other than the bug fixes, all of this is straightforward and should be done within an hour or two. I also moved some of the levels around this morning, I switched levels 2 and 4, as well as 3 and 7. Level 4 is a pretty great exemplification of Chromacore's gameplay, and I felt it should be the very next level players try after the tutorial.

    Excited for release tomorrow, but fairly nervous about getting the shop bugs fixed in time. I might need to disable the in-game shop and enable it sometime after release once it's fixed. If that's the case I'll probably scrap everything I have and re-write all the code from scratch. It would suck to have to do this, since I pushed back the release date and worked my ass off the past 2 weeks specifically to get an in-game shop done.

    Update 1 @ 3PM: All of the straightforward stuff is done - new art added, old files deleted, level 6 and 8 have been cut.

    Still working on a the equip bug fix, pretty much the last thing I need to do to be release-ready.

    Update 2 @ 8:30PM: Still working on the bug fix, I'm making headway on it. Spent some time contacting dozens of press and youtubers about release. Also fixed up level 20's background transitions, they weren't working properly.

    Update 3 @ 10:30PM: Just pushed another update with more debugging code. I've made the decision, I'm going to make a backup of the in-game code and then scrap all of it and re-write everything. I originally wrote this code during the tail-end of an all nighter, so I must have done something wrong that I'm not seeing now. I'll use this last update to better understand what wasn't working (hopefully) and use that to write it better and write it right.

    Tuesday, May 13, 2014

    Dev Blog 92 - Cutting levels 6, 8

    I spent a few hours re-cutting level 8 (in-between debugging the equip code). Boy oh boy did that go awry. The original level 8 wasn't very good, a few notes were mis-timed and the gameplay wasn't very exciting. So I re-cut the parts that were mistimed, and I don't know what I did but it broke the latter half of the whole level.

    I ran my automated suite of tools for building the levels just as I always do (and just as I did when I re-cut levels 4 & 5) but somehow Notes 78-90 got mixed up, and placed all over the level, completely out of position and mis-timed. I tried resetting and starting over a few times to no avail.

    So this brings me to a tough decision. Release is Thursday. No chance I'm pushing it back, because I've already pushed it back weeks (and I leave the country Thursday night to see family). If I cut the level from release entirely, that leaves me with 19 levels. I don't like the odd number much, and I still have to redo level 6 tomorrow. I'm thinking if level 6 is even remotely a pain in the ass, I'll cut that from release too so it's an even 18 levels upon release.

    If I do decide to take this course of action (the decision will come tomorrow night) I plan on re-cutting these 2 levels at some point, and adding them to release later down the line for free. The music and art for these levels are too awesome not to have in the game, it sucks to have to even consider cutting them, but time is a finite resource unfortunately. With release impending, and after working from 8am to 11pm today, I don't have much more of it to spare.

    Update 1 @ Midnight: So the workaround I wrote about in the last update of Dev Blog #91 didn't fix everything, but it did give me a small clue. Just wrote some more debug code to see if the insight the workaround gave me is correct - if so I have a fix in mind. Bedtime for now, will see the results in the morning.

    Dev Blog 91 - Refacotoring

    Spent some time refactoring the equip code, hopefully to fix the functionality problems, but more so to get an idea of where the problem may be.

    While I'm waiting for the results to show up on Google Play I'll be re-cutting the earlier levels.

    Update 1 @ 1:45PM: So there's been some puzzling progress. The equip functionality code works for Teli, but apparently doesn't work for the 2 other skins. The code is almost identical for both - the only difference is an additional if statement for the other 2 to check if they've been purchased, which I've confirmed is true and should pass the if statement.

    I've added additional debug code to find out if what I just said is true, whether or not the if statement passes. If it does pass the if statement, that's actually bad news since I'll truly have no idea why the 2 skins' code behave differently from Teli's. If it fails, that means that the boolean flag for purchase checking must be altered between where I have debug code tell me it's value, and when the if statement checks it.

    Update 2 @ 4:30PM: I cut off the last 30 seconds or so of Level 10 to improve the timing, and after re-playing level 8 I actually couldn't find anything wrong with it. My notes say Notes #20-22 and the last 10 notes are off-timed, but I played 8 several times and couldn't reproduce it. About to address level 6, this might be the hardest one. I'm considering re-cutting it entirely; the problem is everything after Note 39 is off (there's 60 total). Re-cutting the only latter half might not do it.

    Update 3 @ 5PM: Out of suspicion, I played level 8 again. I dunno why I didn't hear it earlier, but it's actually pretty off-timed starting after Note #22 until the end. Might re-cut this level entirely as well.

    Update 4 @ 10PM: This one bug is damn mind boggling. I've narrowed it down to a single if statement, in fact the if statement I was referring to in update #1.

    The reason it's so confusing is because I have a debug log in Update( ) showing me the value of the boolean flag checked in this if statement every frame. It returns true, every frame. Yet somehow, right before the if statement is checked, it's false. There are only two places it's set to false, when it's declared as a variable (which only happens once upon initialization) and if the skin isn't purchased (and that code is only run once). Neither of these take place anywhere near the if statement (in terms of order of execution) which is why it makes zero damn sense.

    Either there's some black magic going on, the Devil chose today to screw with me, or I'm seriously dense and can't figure this out. As a work-around I changed the if statement, so instead of checking the boolean flag, it checks the text value of the equip buttons. If the text reads "Equip" then it's eligible to be equipped. Additionally I made sure that the text is only set to "Equip" if the skin's been purchased, otherwise it's "Locked". That way, this still functions as the check for "isPurchased" that the boolean flag was supposed to be. Hopefully this work-around will nix it. I still want to figure out the actual bug though.

    Monday, May 12, 2014

    Dev Blog 90 - Bundle Bandits, Bug Fixes

    We're happy to announce Chromacore will be part of the Bundle Bandits game bundle, coming out just a few days after release this Thursday! More info to come!

    An update on the in-game store: It's half working now. I say half working because it looks like I've solved the problem of an item purchase being communicated from Google Play to Soomla to my code, which is a big step in the right direction. Now I think the problem is with my own code's logic, which I'm going to run through and check now, hopefully this will all be resolved shortly.

    Side note: The bug on the NVIDIA Shield has been fixed, the directional pad and auxiliary joysticks are now disabled, which means they cannot trigger the persistent pause bug either. Hooray!

    Update 1 @ 5PM: Just discovered and fixed one bug within my own code. This could potentially fix everything, or there could be more bugs - just pushed to Google Play beta to test. Also added a few more sprites to clarify the ability to switch between skins.

    Update 2 @ 8PM: Discovered and fixed yet another small bug. Testing.

    Update 3 @ 11PM: Getting closer, rewrote some of the equip code so it's cleaner and simpler, to help identify any bugs I'm not seeing. Also added respawning sprites for the cosmetic skins, as well as one of the animations that was missing.

    Sunday, May 11, 2014

    Dev Blog 89 - Crunch time

    Just finished purchase and equip functionality for the in-game store. Now when skins are purchased, the skins will change accordingly, and players can switch from skin to skin. This functionality has been pushed to the Google Play beta for testing, not yet confirmed to work.

    It's officially crunch time! In order to release on the 15th we need to:
    • Make sure the skins are 100% functional 
    • Finish re-cutting levels 6/8/10
    • Fix the thumbpad and directional pad bugs causing persistent pause

    Once these 3 things are done, we can officially release on Google Play and Desura, and submit to the iOS App Store for approval and a delayed release.

    Update @ 1AM: Ran into a few bugs with the store purchase and equip functionality, worked on fixing these all day. Published the first wave of fixes around 5PM, just published another wave that I'm currently testing.

    Update @ 4AM: Decided to pull an all-nighter to address these bugs. After a lot of reading and research I'm not entirely sure what's going wrong. I believe the issue is one of two things:

    • Soomla (the open-source framework I'm using) isn't properly getting or sending the message that a purchase has occurred. Users can make a skin purchase and get charged for it, but nothing changes in-game.
    • If Soomla is working properly, the in-game logic I wrote isn't working properly.
    Going to add some debugging code, maybe run the Soomla_debug.jar, try to get an idea of where the problem is.

    Also working on re-cutting 6 now.

    Saturday, May 10, 2014

    Dev Blog 88 - New skins implemented!

    New cosmetic skins are finally finished and implemented! These new skins Scarf and Skull Kid, done by artist Jen Tella, are incredibly unique and awesome!

    Since we're giving Chromacore away for free, these skins can be bought for $0.99 each, as a way to support the developers. For Desura, since the default lowest price is $1.99, the game comes with both skins unlocked!

    Spending the rest of today writing the code to actually unlock and equip these skins, and will probs start re-cutting 6 if I have time.

    Friday, May 9, 2014

    Deb Blog 87 - Finished feedback, cleaning files

    Finished implementing Casper's feedback, the menu screens are much cleaner and consistent now. Also cleaned out a bunch of old and unused mp3 files today to reduce build size. Will begin re-cutting 6, 8, & 10 today, hopefully I can blow through all 3. Once these are done I'll get to work fixing a few bugs I found on the NVIDIA Shield that I *think* are device specific.

    Update 1 @ 6PM: Decided the bug fixes were more important - just pushed a fix for them to Android beta test. Disabled all joystick inputs besides XYAB which should resolve 2 bugs. The first was that the thumbpad and directional pads on the NVIDIA Shield were causing pause triggers, and the second was that these would be persistent pauses (as in, you couldn't unpause the game without quitting and restarting).

    Update @ 7PM: Also fixed an issue where the death sound FX was playing multiple times during a falling death. This will now only play once or twice before respawn.

    Thursday, May 8, 2014

    Dev Blog 86 - Level 5 almost done

    Level 5 has been re-cut, still in the process of re-implementing the Notes (adjusting their positions, adjusting MasterNotes for proper background transitions). This part is a little slow going since there are now 194 Notes (up from 113) with the new cut, making Level 5 our new record holder for highest amount of notes!

    Once 5 is done I'll get started on 6, 8, & 10. About to leave for another meeting with my game designer professor Casper!

    Update @ 9PM: Level 5 is finally done. Took forever, but it's done and much much better. I found 2 bugs while working on level 5, one was that some obstacles were throwing NullReferenceExceptions because I wasn't assigning the player character programmatically. The other was the last 10 obstacles' audio clips were double the volume of others, making them inconsistently loud.

    I got a handful of awesome feedback from Casper today. I'm gunna switch gears for the rest of the night (to give my brain a light rest) and start implementing his feedback. I just don't have it in me to start re-cutting levels 6/8/10, I'll get to those tomorrow.

    Update @ 1:15AM: Implemented most of Casper's feedback, will finish tomorrow. Bedtime!

    Wednesday, May 7, 2014

    Dev Blog 85 - Recutting

    Still recutting level 5's background track (it's an 8 minute level). Once I'm done I plan on taking a look at 6, 8, and 10 to re-cut as well.

    The plus side is these 3 aren't complete trash, level 6 is off-time starting after the 39th note, only 2 notes in 8 are off, and the last 2 minutes of 10 (another 8 minute level) so these won't be as time consuming.

    Tuesday, May 6, 2014

    Dev Blog 84 - Working on Respawn

    Working on re-designing and improving the respawn system to both clarify that the player has died and is respawning, as well as lessen the impact/jarring nature of the immediate respawn.




    So far I've tried a few different approaches. My first idea was to pause right after respawn, have Teli's alpha fade in and out a few times to denote "respawning", and then unpause. This proved impossible after I discovered that any coroutines or invocations called before a "pause" is triggered, will exit after Time.timeScale is set to 0. So there wasn't a way I could pause, wait for the animation to finish, and then unpause. I tried a few tricks involving Invoke( ) and coroutines, which got me a little closer to what I wanted but ultimately didn't solve the problem.

    The solution I will end up implementing (after writing this post) is two-fold:

    First, right when death occurs I will have a text exclamation point pop up over Teli's head, paired with the death animation it should make it super clear the player character has died.

    Second, after respawn occurs, instead of pausing I will let Teli continue as normal. However, here is where I will mess with the alpha values to fade in & out, to denote that Teli has respawned.

    I think that this solution may still be a little jarring, but it's an improvement.

    Update 1 @ 3PM: Respawning is done, successfully implemented the above two-fold solution. Also added a death sound effect.

    Update 2 @ 8PM: Re-cutting level 4, trying to improve timing

    Update 3 @ 9:30PM: Level 4 re-cut and re-implemented, sounds much better, timed perfectly. Re-cutting level 5 now.

    Monday, May 5, 2014

    Dev Blog 83 - Nothin' New

    Not much to report, just grinding away on finishing feedback and re-cutting certain levels that don't sound as good as the latter levels.

    Update 1 @ 10:45PM: Got a high-quality version of the complete Chromacore Soundtrack by Whizbang Music Productions up on YouTube and SoundCloud!


    Also implemented update checking into the Main Menu. Now when the game loads it'll check a webpage against it's own in-game version number and see if it needs updating. This is targeted for desktop and mobile users that don't have automatic updates enabled. If it's an old version, Main Menu provides a "Update Available!" text link to the proper page (depending on platform) to grab it.


    Almost finished with feedback implementation. The very last piece I am going to attempt to implement before release is improving the respawn system so it's less jarring as well as clearer. There are a few more pieces of feedback I haven't implemented, but at this stage I've decided to cut them. I'm setting a hard deadline of May 15th for release on Android and Desktop, with a delayed release on iOS (Apple approval process is 1-2 weeks). With less than 9 days to go, the final things on the docket are:



    • Improve respawning
    • Improve some earlier levels by re-cutting music tracks
    • Implementing last minute artwork
    • Last minute bug fixes (no known & unresolved bugs exist at this time)
    • Publishing on iOS
    • Spreading the word as much as possible

    Looking ahead, I've already begun designing future gameplay modes for a Chromacore expansion pack, and have a 2nd separate game prototyped and ready to begin development.

    Friday, May 2, 2014

    Dev Blog 82 - Up and At 'Em

    Despite working late till 3AM, I somehow woke up at a reasonable hour and got working. Just added new background art to levels 8 & 9, will spend the rest of today finishing off feedback implementation and start re-cutting certain levels (such as 4 & 5) that don't sound great at the moment.



    Thursday, May 1, 2014

    Dev Blog 81 - Late night tutorial improvement, small bug fix

    Completely re-worked the tutorial to better convey some information, added a few nifty sprites to help teach the player the basics. Replaced entire soundtrack for tutorial level, and shortened it considerably, simply to teach player basics and jump into level 2.

    While doing this work I discovered and fixed a small bug, the tutorial billboard text wasn't being displayed in the right order.

    Got some rad new background art pieces, can't wait to implement them tomorrow.

    Bed time now though =)



    Dev Blog 80 - Implementation of Feedback (success/failure)

    Today I fixed the level 9 master notes that were causing proper color transition issues, and pushed out a fix for the in-game shop to resolve the Google Play errors (yet to be tested).

    I spent a few hours trying to implement feedback from game design professors and students. Gravity is now a little stronger (increased to 14 from 9.8) to make Teli fall a little hard and faster. I had to bump up his jumping speed from 6 to 7.5 to compensate, so Teli can still jump the same heights but fall down harder. This way I don't have to go through and re-design every level.

    I also attempted to implement double jump and hold for extra high jump (separately) based on feedback. Both proved difficult, irritating, and seemingly impossible given the current way movement/gravity is implemented.

    These would be straightforward implementations if I knew about them 8 months ago when I first wrote the movement/gravity code. Because I'm using a Character Controller and modifying the movement direction for jumping and gravity, I couldn't figure out a way to implement a double jump or extra jump. I tried dozens of different methods. Online resources proved unhelpful, most leveraged rigidbodies instead of Character Controllers.

    I actually did get the "hold for extra jump" working, but in the opposite way it should have. If the player tapped the jump key Teli would jump  higher than if the player held it down (by a negligible and unnoticeable amount).

    I decided to scrap both of these pieces of feedback. These would help improve gameplay a little bit, but are not essential. I would have to rewrite the entire movement/gravity system (which the entire game hinges on). Rewriting the system could potentially be very short and simple. Or it could be catastrophic and break everything. I don't intend on finding on which, since I've already sunk hours into this. This late in development, it simply isn't worth the effort. I'll be moving on the other feedback and features.

    Update: Just got the chance to test the in-game shop fix, it worked!!! Purchases can now (probably) go through. I say probably because while the Google Play error is gone, I have yet to actually make the purchase to see if it goes through. I have the option to spend money or cancel, so it very likely will. I won't go through with an actual test purchase until I have the actual skins implemented, waiting on artist for that.

    Luckily my friend's Android device that I'm using for testing has $1 on it from when I gave him a $5 Google Play gift card I received before interviewing with Google! Funny how that credit comes full circle.

    Wednesday, April 30, 2014

    Dev Blog 79 - Moar QA, Feedback

    Level 18 is all polished up now - I went nuts with the level design so it's quite the unique level now. Spending the rest of today implementing feedback and finishing up the QA checklist.


    In case you missed it, we broke 1,000 pageviews yesterday! As a celebration, here are some beta keys for you wonderful readers:

    L8F27-BGEF9-P4E7R-AIF3K-YKBBT
    G6CL4-2HTC3-IM54L-WHQR8-EOFZS
    JSD4U-BWEF3-KKHPE-KEXPW-52I5J

    You can redeem these keys via the Desura desktop client!


    Update 1 @ 9PM: Just spent several hours playing through all 20 levels, bug hunting and looking for things to fix. I found 2 small bugs and a huuuuge list of little things, mostly in levels 1-10, that need to get fixed. Things like props being out of place, notes being out of sync, or certain backgrounds not color transitioning properly.

    The good news is, once all of these items are fixed, the in-app store is completed, and all of the final art & sound is in, I think we'll be ready for release!!!


    Update 2 @ 11:59PM: Completed a lot of the little fixes like prop positions and backgrounds, still need to recut a few music tracks which will be time consuming. Also fixed both of the small bugs I found. Calling an "early" night after working for 10 hours, gunna start bright and early tomorrow. Got a lot of work to do in the comes days.

    Tuesday, April 29, 2014

    Dev Blog 78 - QA, Feedback

    Spending all of today doing QA - making sure all of the levels are good, balanced, fun, and free of bugs. Specifically I've been working on levels 16, 17, and 18.

    Additionally I'll be implementing feedback I've gotten from a few game design professors and students at Northeastern (relating to gravity, gameplay, and game updates).

    In case you missed the updates in yesterday's post, we're now on BandCamp as well as SoundCloud (and hopefully Spotify soon as well, pending approval). BJ over at Whizbang Music Productions is working on HQ versions of the music tracks he's done for us, which will be uploaded to these accounts!


    Update 1 @ 10PM: 16 and 17 are polished quite well now, still working on 18. Just noticed this blog broke 1,000 pageviews! As a celebration and thank you, here's a few free beta keys for the Desura build of the Chromacore:

    L8F27-BGEF9-P4E7R-AIF3K-YKBBT
    G6CL4-2HTC3-IM54L-WHQR8-EOFZS
    JSD4U-BWEF3-KKHPE-KEXPW-52I5J

    You can redeem these keys via the Desura desktop client!

    Update 2 @ 1AM: Level 18 is almost perfect, just need to playthrough a few times and balance note positioning.

    Monday, April 28, 2014

    Dev Blog 78 - Reflection on Progress Thus Far

    Just had a quick meeting with Casper - the grade for the first half of my independent study was due today! I wrote a quick reflection about progress thus far, how much I've learned, what worked, and what didn't. You can check it out here - be warned it hasn't been edited or formatted yet, it's just my raw thoughts thrown on paper.

    I plan on spending rest of today working on the in-game shop and implementing feedback.

    Update 1 @ 6PM: Went through all 20 levels, checking that checkpoints were in good spots (and that there were enough of them). Each level usually has about 8 checkpoints, but the longer 8 minute levels need a lot more (around 23!). Also did some garbage collection (deleting unneeded assets, props, platforms, backgrounds) to cut down on file size.

    Update 2 @ 7:15PM: I decided it would be better to methodically go through each level and check for specific things that might need to be adjusted. Today turned into a QA day!

    Update 3 @ 11PM: We've expanded to BandCamp! You can listen to our awesome tracks there as well as on SoundCloud!

    Update 4 @ 1AM: Implemented a small portion of feedback - punching to destroy obstacles is much more visible and clear now, with the addition of a small text animation that plays when the player successfully destroys an obstacle.