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.