Categories
Uncategorised

StickyArrow_DevLog

Before Thesis

As my final thesis is about puzzle games, so I decided to make a puzzle game for my final project.

Before the thesis, I thought about what is the core of a puzzle game. How could I design a basic mechanic? What kind of basic mechanic would lead to an Aha moment.

I was quite inspired by GMTK’s video about the catch of the puzzle.

A puzzle seems cannot be solved directly, but you can solve it by using the basic mechanic correctly. This kind of transition always requires changing the perspective of considering the question.

GMTK’s example shows the catch would probably be something that causes conflict.

The most classic and simple puzzle would be the first level in Portal.

Portal Test Chamber 00 - Portal Wiki

Standing on the button opens the door. But walking to the door would raise the button back up.

That is a conflict.

The answer, obviously, is to put the box on the button.

In a good puzzle, a catch would be solved by a deeper understanding of the basic mechanic.

A mechanic with possibilities could leave space for the players to discover.

So, I tried to find some basic mechanics in life with some possibilities.

The first thing that came to my mind was Magnetic. The magnet has two poles, they can attract each other or repel.

I’ve tried this, but it doesn’t work out. It is kind of hard to design such levels.

The puzzle about changing the poles of the magnet is kind of simple. And the interaction of the poles doesn’t have many possibilities. And the interaction between magnets is kind of complex.

With those ideas in mind, I decided to start my essay first. Some research could probably give me some hints about how to design the basic mechanic.

Thesis

I’ve played lots of puzzle games, like BABA IS YOU, WITNESS, A GOOD SNOWMAN IS HARD TO BUILD, SOKOBOND, and so on. They are all well-designed. So, I started to find out what is in common with those games.

BABA IS YOU

SOKOBOND

A GOOD SNOWMAN IS HARD TO BUILD

In my thesis, I have analyzed what in common about those games. And how to design the basic mechanic of the puzzle game.

According to my Theory, A good puzzle game mechanic should:

1 The goal should be clear

2 Mechanic should limit the player’s action

3 The Basic Mechanics should be simple and easy to understand

4 The mechanism allows hidden rules

5 The result of the player’s action should be discrete

Figure Puzzle Game Design Framework

That is the goal.

But how to achieve that?

In my discussion part:

  • Start with everyday life
  • Explore the basic mechanic

Prototype:

According to my framework, The grid-based system seems like a good choice. It could meet two of my rules.

1 The result of the player’s action should be discrete

2 Mechanic should limit the player’s action

Here comes a concept in the hidden rule space.

It means what is behind the rules. The interaction or the use of basic mechanics that could be figured out by the rules, but have not been shown directly to the player.

For example,

Magnet Paper Prototype

+- means the north pole and south pole of the magnet. Or it could mean the positive and negative electronic.

They are like the boxes in Sokoban, the only difference is that they got some electrons.

As you push the boxes with the same electrons together. They would repel.

Different electrons would combine and disappear.

It is kind of hard to design the levels and add a new mechanic.

I also did some research on how electronic particle and magnet works. Unfortunately, physic can not help me get some idea about how to change the mechanic. the prototype doesn’t work.

1Hard to design

2Can get a new mechanic

3Not much of an aha moment

4Not very fun to solve the problem

So, I start with the basics of a puzzle game.

The limit of the player.

I break down the elements of the Sokoban-like game.

For Sokoban, It has already limited something:

Players can only push the boxes. (Not Drag)

This rule cause that

  • The box at the corner cannot be moved
  • The box touching the wall can only move in a vertical or horizontal direction;

Players can only push the box. It seems like a limitation of the player’s actions.

That, I decided to limit the player’s movement.

Players can only move in the direction of collecting the arrow keys.

Same design as a game in GMTK Game Jam Out Control.

It was a 2D platformer game. You can drag the keys to interact with the scene.

Instead of controlling the movement of the character.

The input could control all the arrow keys.

With all these in mind, I built my first paper prototype.

Luckily worked!

It could meet all of my thesis.

The goal and rules are simple, clear, and easy to understand.

The mechanic allows hidden rules.

How the arrow combines would influence the final result, such as the shape of the combination.

Based on the paper prototype. I made the first version.

The exit is changed to the star. This change allows me to create more levels.

Having the prototype playtested, I found the player would lose interest after some levels.

So, the next thing that needs to be solved is the new mechanic.

I came up with some ideas about destroy, trap, button door, and so on.

But then I found those seem not to connect to my theme—-arrow key.

So, I tried to add some narrative to my name.

What could an arrow mean?

Maybe not only the arrow keys on the keyboard. But also something with direction. Wind, beam, light everything in our life. I was quite excited about the idea.

But how to design the new mechanic. Should I change the basic mechanic?

If I keep it, how can I make the new mechanic looks like a coherent part of my game.

I struggled for a long time.

But when I take a step back. What is the core of the puzzle game? —Puzzles, Of course.

The narrative may make it better but is not the key. The well-designed puzzle should be.

Based on the basic mechanic. I created some new mechanics:

  • Destroy
  • White Block
  • Rotate

The key point of testing the new mechanic is to find the hidden rules of each mechanic:

But the common point is multiuse of new mechanics.

Depending on how to use it, it could be annoying or useful.

Example:

Destroy tiles could be dangerous, but also could be a useful tool to change the shape of a combination of arrow blocks.

Art Style:

I want to keep the game looking simple and clear. In the prototype, the art style looks like the old flash game. I made some changes to it.

Here is the second version of it.

The second version is more colorful. The color of the arrow blocks could show their direction; I always add some board to each block, which could help the player to know that the arrow would combine when they touch each other.

However, the board of the combination doesn’t work well.

So I tried another approach to show the combination—Meteballs Effect.

The meatball looks nice but cannot work in low pixels. To make the metaball effect looks nice, I have to change all the code of my basic mechanic. So, I give up on using the meatball effect.

To be honest, I am not good at drawing or coloring. After trying to change the color of my second version, It doesn’t work. Also, I got a little bit worried that the different colors would distract the player.

To avoid drawing assets, I use AI to generate some pictures for me to reference.

The little arrow at the right corner suddenly catches my eye. And it helped me to set the art style of my game.

By using just black and white color, my game looks simple and nice.

I am quite satisfied with the art style. The feedback of players also commended the art style XD.

Level Design:

Despite the same old things like(Difficulty curve, and tutorial).

One thing that I learned most was that player needs to get some achievement. After the tutorial teaches the player something, an easy level for them to practice what they have learned is important.

This is something I had been ignoring. I just kept focusing on the hidden rules, the core of each puzzle. Even for puzzle games, Two familiar puzzles may seem too easy, but it is also necessary for players to practice, to help them get a deep understanding of the game.

The way I would do the level design for the puzzle games is in three steps:

  • Create interesting puzzles:

We are not talking about procedural generating like Sodoku. An interesting handmade puzzle might take lots of effort to make. We might create lots of puzzles, but it is necessary to just keep the good puzzles.

  • Put them in order

We could sort them by difficulty. One more thing that we should pay attention to is the players’ thoughts. The order is not only about the difficulty, but also should follow the player’s thinking. Are they excepting something new or just more complex levels? Despite the difficulty, the player’s feeling is also important.

  • Filled with some buffer

The buffer here means some space for the player. It could be a place for them to practice what they have learned. Or an easy level for them to have a break before introducing a new mechanic. Any kind of buffer would be a great idea to improve the player experience.

Photos of PlayTesting

Categories
Uncategorised

Mood Dev_Log

Start

DevLog
There are two of us in the group. Me and ZiXuanwang.
I was responsible for the code part of the game and she was responsible for the art part.
The game design was carried out by discussion.

First of all, our goal was to create a small game with a message and interesting mechanics.
In terms of getting the message across, we chose to go for an emotionally relevant message.
A

First of all, from the very beginning, our goal was to make a game that conveys a message and has interesting mechanics.
In terms of conveying a message, we chose something that was emotionally relevant.
My initial idea was to create a game that was related to cognitive biases, possibly with a contrast of colors to reflect the sense of contrast. However, after about a week of trying to design it, nothing worked out in the end.
We then combined emotion-related factors and planned to make a game that would be related to the transfer of emotions between people.
“Our emotions are influenced by the people around us, while the atmosphere is also influencing our emotions”
This is basically the core idea of our game.
With this in mind, we have created several prototypes.


1
The ball is influenced by the change in the area
T

Balls are influenced by changes in the region
Areas also change with the state of the balls.
Happy areas will score more points, while sad areas will lose points.
Whether each level is passed or not is finally determined by the player’s score.

2
Balls colliding with each other will change their state

Players can drag and drop the balls to move them. When the balls collide, they affect each other and change.
The goal is to make all the characters happy.

After playtesting we chose the first version. The second one is too limited and the drag operation is not very interesting. The first option has more strategic in terms of gameplay.
We then modified the game and added animations, sound effects, scores system, etc. to the prototype.

The final version.

Changes were made in the final version.

  1. UI
    The target has been improved by placing it at the bottom of the table, with glowing effects to make it more noticeable to the player.
  2. Changes to the winning mechanism
    Changed from a score to a star rating, becoming more intuitive.
  3. Adjustments to the layout
    The three-game areas have been standardized to make the interface more concise.

Rather than rehashing the mechanics and gameplay of the final version of the game in the Devlog. Instead, I wanted to document some of the difficult design questions that I encountered. Many times it was just a case of skipping them or choosing another solution.

1. How to design a deep game?

  • Personally, I think that perhaps a deep game that involves our own experiences is a better, simpler way to design. It is because of the personal experience that we have the ability to bring it out in the game so that the player can understand the message we want to convey.
  • But how do you go about it when it is just an abstract concept? Cognitive biases, for example, have some psychological effects. How do we design them? It may be possible to look in the literature for ways to do this, perhaps in books such as Making Deep Games, or in the context of successful games such as WBWWB, where abstract relationships are represented in the game and the message is conveyed to the player.

2. What exactly is a prototype? How do you decide if a prototype works?

  • My early understanding of a prototype was that it was simply a game that tested the mechanics without the artwork, sound effects, etc. If this was the case then would the prototype of Elden Ring be a bunch of boxes to run around in? Would it be fun if I had adventures in a box world like that? Maybe the World Of Worldcraft might have to be renamed World Of Boxcraft XD.
  • I don’t think so, prototypes need to be tested by making the most important parts of the game’s mechanics at a minimal cost. For example, using simple models instead of high precision models, abstract colors instead of textures, etc. Every element in it should not lose its original meaning. The result of such a test may be more in line with what we expect the full version of the game to look like.

3. How to design a game with unique mechanics?

  • Today there are already many game genres. We have FPS, RTS, RPG, etc. It’s difficult to innovate on top of the existing framework, I think. There is so much homogenization today that if our goal is to make a game with unique mechanics, then we should try to avoid that.
  • We could combine certain mechanics, as in the Mexican pizza theory in Level Up, where good things always taste better together. However, I think this may result in a lack of uniqueness to achieve the goal.
  • When we think about mechanics, we might want to consider existing mechanics as little as possible and instead approach the design more from an experienced perspective. What kind of experience do we want players to have when they play? What mechanics might be needed to create that experience?A design approach that starts with the experience may make it easier to design games with unique mechanics.

Categories
Uncategorised

Reverse Dev Log

Introduction To The Game Reverse:

Game Type

•3D narrative game

Game Narrative

•The protagonist travels through a Parallel Universe. •He accidentally met another himself and was involved in another life in Parallel Universe.

•The protagonist found his original intention of creating games when he was young.

•Finally, the protagonist returns to his original Parallel Universe and makes some changes to his life.

Game Mechanics

•Using the mouse and keyboard for game interaction. •Many different spaces in the game to show different narrative contents and emotions. •The player’s perspective will switch between the first person and the third person due to different spaces.

Inspiration

Collaborate

This image has an empty alt attribute; its file name is image-3.png

My Part

I am responsible for the code part of the project. My part is more about the special mechanisms and some of the interactions in the scene. Throughout the project, I was in charge of the implementation of some of the scenes and special interactions.

For example the Minigame Storyboard in scene 2 and the photo and barbecue mini-game in scene 5.

This image has an empty alt attribute; its file name is image-7.png
StoryBoard
Claw game machine
Barbecue
Teddy Bear Maze
Take Photo

Feedback and changes

We playtested our game and have some feedback and great advice about how to improve our games. I’ll list some examples.

Stage01

Feedback: More interaction about other objects would be interesting.

Players are confused about what to do next.

Changes:

Interaction with light

Interaction with flower

Lead players with the vision and text

BoardMinigame StoryTelling

Mechanic: Filling in blanks to complete the word. Take an adventure!

Version 1

Too Many Words. Lack of tutorial.

Input: For Example Hold Z, X, C to start the first scene.

FeedBack: The letters are not related to the story and picture. Players were confused about what to do next.

Version 2(Current Version)

Changes:

Less word. Add background pictures to the textbox. Change the input method to “fill the blanks”. (Blinks could be the tutorial of how to do it)

Blinking text box
Cloud Textbox & Fewer words than Version 1

Categories
Uncategorised

Dev_Log

Procedural Art

The earliest ideas came from some mottled patterns, and when you put circles of different colors together , it often makes for some quite beautiful patterns. But this tends to look a bit monotonous. Dynamic art may look more interesting.

(Windows Bubbles)

Also, there is a kind of moving bubble between the screensavers from Windows that is very interesting.

By combining the two types. Also adding a way to make the bubbles feel more active.

Turning a normal bubble into a nesting of bubbles and bubbles. The bubbles inside can move the bubbles outside.

The player can decide the color and number of bubbles.

To make the whole collision process surprise, the direction and force of movement are created random. This way each collision is unpredictable.

Feedback

The majority of players found the collision method interesting.

Some players wanted to be able to manipulate the direction of the collision.

Some players would like to have more choices of color palette.

So, it is possible to add the option of automatic collision and manual collision to the game, with players. On the basis of this prototype, it might be possible to allow players to export these versions to be designed as screensavers or desktops.

Unity Engine

Personal aims and objectives

The game is a very simple game where the objective is to get the ball to the end of the level and to pass the level.

Most physics-based games are controlled via the keyboard, but the mouse was chosen as a way to change the input method.

In the end, the drag-and-drop method was chosen, which allows the player to control the direction and force of the shot. The first levels are relatively easy, as the player just keeps shooting towards the end. In the later levels, the player has to control the ball as carefully as possible to avoid obstacles and reach the end.

Feedback from playtesting

I asked my friends to playtest the game.

By observing their performance, I found that they were very comfortable with the drag-and-drop style of control, and that it was easy to pick up and play the character in a few minutes.

In terms of level design, there was no problem with the difficulty design. Players generally responded that the third level was a little difficult.

It was also suggested that there could be some adjustments.

As a prototype to test this approach. I think it’s still very good. There is still a lot to improve in terms of level design. If we would create another mechanic in levels that could interact with a drag-and-drop shooting method. I think that could definitely make the game more interesting.

No component

For developing a game without component there is actually still a big challenge.

This is because the history of the game is old enough. There are all sorts of different no component games from all countries. It seems that all games that can be thought of has basically been discovered by everyone. There are basically two types of games. Linguistic games and games that use body language.

I think the most fundamental behavior of people in these games is interaction.

People communicate with each other through words or body language.

Through these messages they compete or cooperate to achieve the same goal. For example, saying the same word.

I wanted my game to be easy to test, so I set the number of players to two.

The rules of the game are very simple

After a countdown of three , each player reaches out a hand. The player needs to points with one finger in one of four directions: up, down, left or right. Two players choose their direction at the same time. If the directions are different, then continue and restart the countdown again. If the directions are the same, the players need to clap as quickly as possible. The first person to clap wins. If someone makes a mistake and claps when the directions are different, he loses.

Tips: Some misdirection techniques can be used in this game, such as moving the hand downwards but actually pointing the thumb upwards.

I would still really like to improve this prototype or come up with some new ideas for a no component game. I think I need more feedback to help me improve it.

Avoid and Collect

Personal aims and objectives

The game is a avoid and collect game. Since the theme was already in place, I hoped to be creative. After playing several games in the genre, I didn’t choose to innovate in terms of avoiding and collecting items, as many games already do it very well. So, I decided to try to be creative in terms of the mechanics.

In my game, I have deconstructed the whole theme.

So, the left half of the game is about dodging and the right half is about collecting.

Often in this type of game, the player controls one character.

This time the player has to control two characters that move simultaneously.

I hope that this will create a different kind of experience for the player.

Feedback

Some of the players are good at this type of gameplay, they can do both screens at the same time and find it more interesting, they expect to have more areas to control, 3-4 screens or something like that.

Some players are not so good at this type of action and feel it is a strange way of doing things. They tend to concentrate on one screen only.

Taking these comments into account, I adjusted the levels a bit and separated collecting and dodging as much as possible. The player-controlled character is perfectly safe on the levels where he collects. So even if the player is not comfortable with this way of controlling, the game can be played at a slow pace.

Narrative

The starting point of the game is the future of the game designer.

A large part of this game is actually part of my anxious thoughts right now. I don’t know what I’m going to do in the future.

Even if I can master some skills as an indie game designer, will I be able to continue as an indie game designer afterward. I wanted to use this game to document this part of my thoughts.

Ideas: Even if you learn about game design now, you may not necessarily get into a game-related career afterward.

If you are lucky enough to be in a game-related industry, or if you get into a company, there is a good chance that you will follow someone else’s idea for a game. Life will gradually remain the same, it would make people unable to escape from such a whirlpool. Eventually, it’s just about working for money. If you are really lucky to become an indie game designer, the first thing you will worry about is whether you are able to design and implement a game on your own and make a living out of it.

There are many challenges, but not so many that can be reflected in the game. There are only four endings, one for success and one for failure at a game company or as an indie game designer.

At the branching options for the good and bad endings, the player is not given any other hints and is expected to choose purely by luck, as if you never know what will happen next in life.

Feedback

Those who have played the game have had more fun with the relatively short game animations.

The more curious players will try a few more times to check out all the endings.

Most people like this game.

Interactive Picture

Personal aims and objectives

I saw some animations of anthropomorphic characters and I thought about some interesting ideas for keyboards.

What would happen if the keys on the keyboard were anthropomorphized and met each other.

For example, if ctrl+z can be used to undo an action, then when ctrl and z meet, they will return to the previous position.

I thought this would be an interesting way of inputting and a game that would show people some of the shortcuts they don’t often use. In the process of making it, I found that it would take a very long time to animate each of the shortcuts separately, so I ended up changing the format. Instead of animations, the shortcuts are shown in text.

Feedback

In the process of making it, I found that it would take a very long time to animate each of the shortcuts separately, so I ended up changing the format. Instead of animations, the shortcuts are shown in text.

Feedback

Some people thought it was a fun little piece of work and people generally liked it.

There are still a few key combinations that can be entered and players would like to have more combinations.

If I had enough time, I would prefer to create some interesting animations for the shortcuts.