Devlog-12 Seconds Physical Game

Inspiration

For a 12 seconds game, the mechanics should not be very complex so that players can easily to understand how to operate and achieve the target. As for a Physical game, I got some reference from Tabletop Game and Traditional Game that using reality components. So I want to make a gameplay that already exists in reality.

Main Idea

Player can press the right-click button to control the rotation of the maze, and the ball can move by the effect of gravity. The goal of the game is to make the ball reach the end within 12 seconds.

Coding

  • A restart button is necessary because players will try many times.
  • I tried many ways about how to control the rotation, above keyboard button or mouse, the current approach is not entirely reasonable, but modifying the code logic means that the gameplay and levels need to be changed, which requires a lot of time. I’m still exploring new method to solve the problem.

Play-testing & Feedback

  • Rotation controls are too sensitive. A bit hard to control.
  • The collision of the ball with the wall always causes some bugs.
  • 12 seconds is too short.

Devlog-Procedure Art

Inspiration

As my Interactive Picture Devlog (Devlog-Interactive Picture – A developer’s site (arts.ac.uk)) said, I will continue to explore the interaction with cubes. At the same time, I also preparing for the 12 seconds physical game. Gravity could be a good way to describe “procedure”, so I can make cubes just falling down and seeing the dynamic influence.

Coding

  • Cubes can be created in a random X range from +9 to -9.
  • Cubes’ color controls by SpriteRenderer. I use X and Y position as the RGB numerical value so that they can have procedure color change.

Main Idea

You can just sit there and waiting for cubes filling the whole screen.

Play-testing

  • Can add various of sprites.
  • more variable colors.

Devlog-Interactive Picture

Inspiration

When I developing the A&C game, I found it interesting to design a series of interactions around cubes and boxes. I have made some mini demo before, so I planned to explore the connection about position and color.

Mechanic

The mechanic of the game is simple that you can click everywhere on the screen, every time your clicking will create a cube at the clicked block position. Cubes will change color basis on the mouse’s position so players can see gradually color changes.

Coding

  • Cube interaction: I filled the screen with cubes and set the alpha to 0 so they are invisible when game start. Can set the alpha to 255 by clicking.
  • I use the x,y position of mouse as cube’s SpriteRenderer RGB to get a dynamic cube color.

Play-testing & Feedback

  • Firstly I made this game as the Procedure Art work, but David told me that it is more like a Interactive Picture, so I decided to change the game’s theme and do another new Procedure Art.
  • The color gradient looks good.
  • Can add some optical illusion tricks.

Devlog-Bitsy Narrative Game

Inspiration

This game’s idea comes from The International 10, which is the most important DOTA2 competition in a year. DOTA2 has a great number of fans and players in China, Chinese players expected the Chinese team to win the TI10 championship because it has been 5 years since the last champion. But things went contrary to their wishes, LGD Gaming lost the final match. It is a bit of unacceptable for Chinese players, Much of the debate was about decisions made at the Ban & Pick stage, a lot of people even thought it was a fake match.

Main Idea

So I want to express some of my thinking about the phenomenon via the Bitsy game, it could be simple, just focusing on dialogues and less of interaction game play.

The game names “Why Not Ban Magnus?”. The main character in the game is magnus, a hero from DOTA2. Magnus played well in the finals and destroyed the Chinese team so players wonder why they didn’t ban Magnus.

I think that people just didn’t want to accept the truth, they lost their impartiality and the mindset to enjoy the game. So my train of thought is to express my opinion through Magnus’s dialogues.

Play-testing & Feedback

  • Could be more trick in the game process.
  • The end of the game needs more feedback.
  • Text doesn’t convey ideas well.
  • Maybe a longer process?

Devlog-Avoid&Collect

This is my first work of the mini brief, It is a challenge for me that I hardly ever solo a electronic game before but do some graphic work like 3D art or concept art in a team. So I thought that I could find some ideas which can be implemented with relatively basic code.

I found some inspiration while thinking and the code learning process, push box could be a suitable mechanic for me. I also managed to use some mechanics like Rhythm Dungeon to approach the A&C theme.

Early Design

Firstly, like other push box games, player’s aim is to push box to the target position. You should avoid the enemies(blue boxes) who have a behavior logic that every time player moves a block, they will also move along their own direction, they will turn to the opposite direction when they attach the wall.

Coding Problem

I tried many ways to develop my character moving code, the code should also have effect when pushing box. I spent a lot of time on how to interact with the box and enemy, finally I got some method to solve this problem: Raycast is a effective measure.

I also learnt a lot about how to use Unity tools to make my work efficient and stable, this is very helpful for my future project development.

Play-testing & Feedback

Some main problems and opinions:

  • Hell taker has a similar mechanic, so the puzzle design is important.
  • The logic of three kinds of cubes motion sequence should be more clearly. Sometimes they will crush and create bugs.
  • Some collider problem.
  • Enemy’s motion logic should be more easy to understand.