Devlog #6 (On Puzzles and Difficulty)

Welcome To Another Devlog

Lots done this month, but i’m gonna try and keep it brief and not get into all kinds of itty-bitty changes. Let’s look at some big stuff. But first some thoughts about difficulty which ties in nicely with the puzzles that were added.

“DevDifficulty”

This is an interesting concept that I’ve only been introduced to recently but seems so incredibly obvious that it’s easy to miss.

After running through your game over and over and over and over and over again it can become very easy to lose track of what the experience will be like for a totally new player. You can start to ramp up the difficulty for fear of the game being too easy, and suddenly you introduce tons of frustration for the new player.

It’s important to get people’s hands on the game and see how they react. I was quite surprised. There really needed to be a better difficulty curve, especially if you don’t intend to make a game strictly for masochists. 🙂

So a lot of the damage has been scaled back, it is meant to be a demo. Would be a shame if the player couldn’t make their way all the way through. Give them player an idea of what to expect in the full game. Later on you can add difficult content. I always liked how Mario games scale, they often don’t get really hard till later in the game, and there’s always tons of optional content (World S for example) that take everything you learned and ramps in up and really tests your skills.

There’s lots to be said that has been said already about how Nintendo does a great job of easing players into new mechanics.

Puzzles and New NPCs

So I decided to add in some simple puzzle mechanics. It’s not a puzzle game, but it would make for a nice little change of pace between platforming and shooting stuff in the face.

Below is a rough mockup I was testing. basically, you can fire into a “node” and it shoots out in a direction.

There are “target” nodes that will unlock doors or what not. Very quickly I realized that it would be too easy if you coud just shoot into any node, basically circumventing the puzzle, so it was decided that there would be different nodes with different uses. And they would have to be easily identifiable.

A test of the puzzle nodes

Some of the properties that were added to these nodes include:

• Can/Cannot receive Normal player (Otherwise they can only receive fire passed from a “Fire” node)

• Can/Cannot be rotated by the player hitting it

• Rotates on its own (for some timing puzzles

• Multiplies the inputted shots by a certain factor

• Has a delay after receiving a “shot” (again for timing puzzles)

After some tests were created I testing them out on people. But I realized I ramped up the complexity of the puzzle's way too quickly, there was a basic one and then a really complex one with multiple screens… d’oh!

That second one would be fine, if it were later in the game. So, I scaled it back. Again, the issue was that I having designed the thing and thought about its implementation was falling into that devDifficulty trap.

Teaching the Player

The next challenge is how do you teach the player how the thing works? What I really wanted to avoid is a bunch of text. (Though admittedly I used text and images to explain the basics of the game when you first fire up the demo. But that’s mostly to save time for now, a more natural gameplay-oriented demo is planned for the game)

Concept art for the miners for the “tutorial”

So, I decided we could show by example. When you enter the area before the puzzles you see these little alien minors basically showing how puzzle pieces are manipulated by interacting with them. One is hitting it to cause a rotation, the other is shooting into another one to have it shoot out a “puzzle beam”.

It’s more interesting to integrate the “tutorial” into the world in a more natural way

As for the design of the puzzle pieces, I decided to go with some sort of alien bulb creatures, each a different colour for their use to make it clear visually.

• BLUE: can rotate and receive player fire (these guys are the start of the puzzle)

• YELLOW: can be rotated when hit, usually different increments (45, 180 degrees)

• WHITE: only transfers received shots, cannot be manipulated

• RED: These guys are for fun in some combat spots. They blast out deadly fire at a high rate.

• PURPLE: They are the targets who open doors when hit with a “puzzle beam”

Originally was thinking of making the puzzle pieces crystals or mechanical devices, but these seemed more fun

Health Regen

So far in the game I’ve been mulling over how health will work. The current idea is having health regenerate when you get your combo up. It encourages agressive play, risk/reward. The higher you get your combo up the faster your health regenerates. Of course, getting hit ends your combo and thus the health regeneration effect.

The idea would potentially include some relics/perks that affect your regen rate.

Main Menu Art

Created some art for the main menu, including some animations. Figuring out a UI style has been a massive pain in the *** from the start. Not sure if this will end up being final, but I’m happy with it for now.

Quinn sort of fades in and slides to the left of the screen. There are some simple particles. I kind of liked the idea of going for a minimalist start screen. But that might change in the future

In Closing

Ok I guess I said this log would be brief. I guess it wasn’t in the end 🙂

I thank you for taking the time to read through it and hope it was interesting and of course I thank you for taking the time to share this with me.

Until next time!

Cheers,

M.