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.

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.

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

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

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.

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!

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.

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

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.

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.

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.

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.

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.

Dev Blog 15 - Short Update

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

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.

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.

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.

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

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

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.

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.

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.

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.