Design for Magic Writer. Blog post 3, The ever-moving focus

The information players can gather from the screen is very important. It's extra important in a game of stress where they need to know the situation at just a glance to be able to plan their next move in time. It's time to give them that information.

Welcome back to another Magic Writer design post.

One issue which came up in a recent discussion with our teacher and senior was the focus of our game. And when I say focus, I'm talking about visual focus. The monsters in Magic Writer is very eye-catching, but you also need to look at the words at the bottom of the screen and type them correctly.

And thus a problem arises. The game becomes unintuitive to play, since your eyes goes all over the screen during game time. With this, we also realized we needed somewhere to place the lives and score so that the player could easily take them into account when needed.

This blogs artifact: Visual focus in Magic Writer

Early mockup which mirrors an early build

The thought bubbles

The main problems are the thought bubbles. They are statically placed at the bottom of the screen which leads them to becoming uninteresting even though they are supposed to be where most of the game takes place.

The bubbles themselves already fill an important UI function, telling which property the item it holds is of. It does this with a light change of color in the outline.

Progress

In one version, we moved the bubbles to the top of the screen. This was done so the player could write where he/she saw the monsters coming and could plan thereafter. This failed, as people thought the items inside the bubbles represented which monsters came(I think this might be because of the relation to Tetris).

Next, we tried moving the bubbles to the wizard. Since they are thought bubbles, we could make them a part of the game world by having them float around the wizard and maybe even follow him when he changed lanes!

We cannot have the bubbles in front of the wizard since the items go there. Behind him works, but it's still kinda dull. The bubbles does follow him, but they still don't draw attention to themselves. We did one more thing which can't be seen in the picture, but the bubbles are pulsating. This was to make them more exciting to focus on.

The end?

I'm sad to have to end it here, but we still haven't found the right place for the UI yet. We still have 4 weeks to complete the game, and if there is something that's going to keep changing, it's the UI.

The aim for our game is to be pick up and play, and the UI plays a big part in making that happen.

There is also a discussion regarding the lives, score and monster HP which will happen in the future. But right now, the bubbles are the main concern. Which is why I decided to write about it.

Summary

Knowing where the players eyes will be when playing the game is extremely important.

The player needs to receive information about their status and get a grasp of what is happening.

The UI needs to know where the players look before it can be places on the screen.

The iterative process of playtesting is the solution for this problem.

I hope you liked this tour of Magic Writer design and tune in next week for another design related blog post.

Design for Magic Writer. Blog post 2, Designing the Weakness System

After playtesting and iterating, one thing the team still tries to improve is the weakness system of magic writer. Why is it there and how did we change it.

The high concept of  our vision of magic writer is the the following:
  Scibblenaut meets typing of the dead.



At it's core, magic writer is about writing funny items into existing (Scribblenauts) and having a tactical shooter (typing of the dead) at the same time.

At this point, we're having fun with the basic gameplay. Typing words and throwing them works, but now we're going to expand on that.

There are a lot of ways to go about expanding on the game's core idea to make it more interesting. I'm going to firstly talk about how we did it and reached where we are now and then I'm going to take up ideas we didn't use and our reasoning behind excluding them.

This blog's artifact: The Weakness System

The weakness system

Straight from the concept document on which the game is based came the weakness system. The weakness system was set up in the current fashion:

• Each items has two properties connected to them.
• These are either Dead or Alive and Hard or Soft.
• Meaning a Skeleon would be Dead and Hard and a Panda would be Alive and Soft.

• Each monster have 10Hp.
• Each monster have one weakness which is randomized.
• You cannot see which weakness the monsters have.

• Items deal 1 damage.
• And item with a property which a monster is weak to deals 3 damage instead.

The idea of this system was:

1. Almost every item could be categorized with the properties.
2. It would create a search dynamic for finding the right property to throw at the monster, making you remember items.

How we changed it and why

During playtesting, we noticed that people had expectancy for what items would have for effect. For example, they thought spiky items would do more damage than soft items and that cold items might have a freezing effect. Due to these observations and testimonies we set out to rework the weakness system so it could fit the game better.

We changed it so that every monster have a unique visual based on their property.
We changed monsters HP to 4.
We changed critical damage to 2.
We changed the properties to Fire, Ice, Dead and Alive.
We changed it so every item only have 1 property.

We reasoned that the previous weakness system wasn't logical enough to use in the game. Even though each item could be categorized, the reason why they would be super effective against monsters were unclear.

The new system aims to make things clearer. All monsters now have a visual look which tells the player which property it is weak against. Together with this, we lowered the HP of each monster to make the game faster since less effort is put into discovering what weakness the monster has.

With changed to monsters, came changed to items. We removed Hard and Soft, since visual representations of a monster weak to only those two did not make sense.

Instead we introduced Fire and Ice, since a fire monster and ice monster have easily understood weaknesses. We kept Dead and Alive since we could create a Dark and Light theme with the monsters. All items now only have one weakness, since there are too few items who have a shared property between dead/alive and fire/ice. This is another reason the monsters HP changed to 4, because it's harder to get an item with the property you need all the time.

Summary

Artifact: The Weakness System

The design:

We changed the design of the old Weakness system to one that would make more logic sense. The biggest one is monsters now have a visual style. This also changed the gameplay into to make it faster.

I hope you liked this tour of Magic Writer design and tune in next week for another design related blog post.

Design for Magic Writer. Blog post 1, Every Pixel a Message

The First weeks of Scrum has passed. What have we accomplished? Hidden storytelling in design.

Not actual picture from the game. But it looks nice!

Design

The first weeks has passed and Magic Writer is coming along fine.

As the lead designer on the project my first main task is writing the design document, which turns out to be much more work than anticipated. But that part is coming along fine ever since we allocated time for me to do it.

For this blog post I'm going to pic one artifact I've been working on and give some insight on my decisions regarding it's design. Inspired from the "Every Frame a Painting" Youtube channel (https://www.youtube.com/user/everyframeapainting), I tried to get creative.

This blog's artifact: How to tell the story/setting in magic writer.

Storytelling through backgrounds
Every Frame a Painting often talks about what the director decides to put into the frame, and the story implication it brings. Trying to convert this idea into game design would mean looking for a way to sneak in the story without it getting in the way of the gameplay.

Since Magic Writer's gameplay is very focus intensive (spelling words does that). it becomes hard to implement story into the gameplay. So we're looking for different ways to create the sense of a story in the game.

Picture from concept document

Moving the Story

Magic Writer is the story of a wizard trying to save a beach from invading monsters. The monsters (like the ones in the picture) convey the enemies. The wizard conjuring the items shows off the defender of the beach.
But we have currently have no way of representing the people being saved at the beach. Our goal for this time is finding ways to show the people being saved. Let's start looking for ways to include them.

The Main Menu

We have a place the player visits at least once before starting the main game. The main menu! We have a lot of options, but I want to keep it simple but effective.

Mockup of the main menu

The background image can convey the situation with a picture. In this mockup, the monsters are positioned to the left with aggressive looks. In the middle ready to go is the wizard, standing between the monsters and the beach. And to the right, a bit afraid, stands the people.

The placement of the characters are important because when we get into the main game mode the people won't be on the screen. But since we've established that the wizard stands between the monsters and the people, between the sea and the beach, we help the players imagine the people being off screen.

Sound

The wizard and the monsters have sounds. It's a pretty standard thing to have on your enemies and player. But what more can we do with sound as design space?

We can also establish the people by having them make noise. But where is the best place to make some noise? Since we're trying to save the people, it makes sense that they would shout if we failed to save them. So when a monsters pass through and the player loses a life, the screams of the people will be heard. This is good since it doubles as feedback for the player losing a life and make logical sense.

Since this worked well, can we take it further?

What if we can use the sound of the people to double on something else? But what could the people's voices double on?

What if the people cheered when the player hits a monster? That does make sense, since the people are happy that the wizard is succeeding. But that would get annoying fast, and it would get dull hearing it too much.

But what if they only cheered at critical attacks? Now we're getting somewhere! If you've played Hearthstone, then you might know of how this works. When you attack with a minion in Hearthstone, you get a crowd cheer based on how much attack that minion have. This creates the feeling of people standing around the board of the game and being invested in the game through cheering. THIS is what we want to recreate.

A crowd cheering also doubles as feedback for critical hits in magic writer, making this design double effective.

Summary
Artifact: How to tell the story/setting in magic writer

The design:

Our main menu shows an image of the story and setting with an importance of left = monsters, middle= wizard, right = people. When we later turn the world 90*, this relationship is kept with the monsters on top, the wizard in the middle and people below the screen.

Through sound we will keep the illusion of trying to save people from monsters. This is done through screams when the player loses a life (a monsters passes onto the beach) and cheering when the player gets a critical hit.

I hope you liked this tour of Magic Writer design and tune in next week for another design related blog post.