Jun 8, 2018

Creating Puzzles for TUAT

12:10 PM Posted by Lucas Izumi No comments
In today's post, I would like to show our creative process while creating puzzles for TUAT.

In TUAT, puzzles are much more than simple game elements. If they are not directly connected with the narrative, they are at least connected with cultural elements of Ancient Egypt. In order to create this connection we have to work with a few limitations, like the restricted use of mechanisms, after all, at that time there was still no variety that we know today.

Historical Limitations
A good example of this was during a discussion we had about a puzzle. It would work very well with the use of cogwheels, but by researching on it we discovered that cogwheels did not yet exist at that time. The Predynastic period of Ancient Egypt dates from around 5500 BC and the first reported use of a cogwheel was in the Antikythera mechanism, from around 200 BC.

In a later research, we then found about the defense mechanism used in the Great Pyramid of Giza. It uses a system of huge granite blocks suspended on grooves. When activated, the blocks would be released and slid to close a passage. The puzzle itself was not about closing something, but we could use the core idea of this system and adapt it to fit our puzzle settings, replacing the cogwheels entirely.

Source: Science Channel
Puzzle Design and Ancient Egypt Culture
Our puzzle creation process starts by asking ourselves a few questions:
- What's the purpose of the puzzle? Is it to teach a new mechanic? To obtain an item?
- Where will the puzzle be located?
- Based on the puzzle location, which basic elements fit that environment?
- Which cultural/mythological elements fit that environment?

By putting all these answers together we have a clear view of what to use in that specific puzzle. From here we take a look at our limitations: are all elements good to use? After doing a research and discarding or replacing some elements, we finally come up with an initial idea. This idea is documented and tested using Paper Prototypes (or simply diagrams). We discuss it and when we all find it interesting enough, we implement a prototype of it in the game itself.

The Ancient Egypt rites and the games played in those times are a great source of inspiration when designing a puzzle. Take for instance the Canopic Jars. They were used during the mummification process and each one of them holds a specific purpose. By exploring their purpose we created a puzzle that teaches the player their use and has a conceptual value that calls upon the beliefs of that era. This is something strong in TUAT. We don't want puzzles to be a mere element between the narrative. We want to use them to further dive into the Ancient Egypt culture and present it to the player in different ways.

The Canopic Jars Puzzle
I really wish I could share more about the game puzzles, but I don't want to spoil your experience! I hope you guys enjoy this post and please keep an eye out for TUAT! We shall be releasing a demo soon!

May 27, 2018

Here's our newest project: know TUAT

11:38 AM Posted by Felipe Marques No comments
In the past months we decided to work in a project different from everything we have done before. So far all the Sonera’s games focused in exploring the mechanical potential of game design. Now we just threw caution to the wind and wanted to try something new that could challenge us of every single way. Here is where we bet:

(The trailer is in Portuguese, our native language, but we hope you can feel what we are trying to do. And it is a little bit out of date, since it was done last year and doesn’t reflect the project’s nowadays. But again: try to feel it, not judge it. Btw, you can use English subtitles if you want.)



TUAT is a game about death. This is our leitmotiv. It was born of our desire to talk about death when everything we see rejects death like if we are going to live forever. We choose the Egyptian religion and society as our general theme because we saw something very precious there, a new attitude towards death, and we hope to bring it in our game.

Technically speaking, TUAT is a 2D game that focuses on exploration and storytelling. You are a boy who wakes up in a weird place and you don’t know how the hell you got there. Everything you want is go back for your daily life, but you have no memories: you don’t remember who you really are.



It is important to say that you are an Egyptian boy. We don’t want to tell a story about a North American or European explorer that comes to Egypt searching for rich treasures or magical objects. We want to go deep in the Egyptian mentality and develop a game from within this culture. That’s why I am studying hieroglyphics and Egyptian thought, so everything in the game will be as accurate as possible, trying to avoid at any cost the anachronism, this ghost that haunts all the historians.

Here are some pics of the expositions of TUAT:




Every week one of us will post some content on the blog concerning the development of TUAT. So you guys can take a look at the game from different perspectives. See you all next time!

Sep 11, 2017

Food Eater - AGBIC 2017 entry

7:36 PM Posted by Lucas Izumi , , , , , , No comments
A Game by its Cover is an annual game jam where participants pick a famicase design and turn it into a game! Last time I joined this jam was in 2015, with SHE. This year I'm going with Food Eater!

Komida-chan can't control herself during her trip to FoodIsland. Please, stop her before it's too late!

Food Eater is a casual arcade game created during "A Game By Its Cover 2017" game jam. It was based on the Food Eater famicase by Ezequiel Nietoš.


Picking a Famicase
From the famicase exhibition page, I first picked my favorites. I really really wanted to create games for all of them, but I knew I wouldn't have enough time. Each famicase has a small synopsis of the game (which the dev may or may not follow). Based on these synopsis, I created an idea for each of them.
A game of skill, strategy and wits.

Idea: The idea here was to make the Rock-Paper-Scissors game more dynamic and unforeseen. Each player would have a whole scenario at their disposal and would choose Rock, Paper or Scissors to interact with an object of that scenario. A player's interaction would trigger something that would affect the other player. For instance: Player 1 chooses Rock on a Hydant. Player 2 chooses Rock on a Manhole Cover. The hydrant fires water at Player 2, but Player 2 covers her/himself with the manhole cover, so nothing happens. Trying different combinations and guessing their results could be very fun.
Chop ‘n Click is a point and click game where you play as a detective trying to unravel a series of murders. Every crime scene shares a common element - each victim has had their pointing finger cut off. Will justice be fulfilled? Will our hero fall into the trap of madness? Play and see for yourself!

Idea: In this game I would follow its synopsis. The player would investigate crime scenes in a static screen, interacting with the objects. Between a scene and other, there would be dialogues (visual novel like). The main catch here would be that, the finger that was cut off would be pointing to the most important clue of each crime scene. By realizing this the player would be able to put everything together and solve the mistery.
Thunders, a strong wind, the storm is approaching ... Raijin and Fuujin have arrived! They are Storm Brothers! Sound the drums and ride the strong wind to get to the top of the sky!

Idea: A rhythm game. Raijin would play the drums and Fuujin would fly up to the sky. Each note you don't miss makes Fuujin go higher. Each note you miss makes Fuujin go down. If you miss enough, Fuujin would touch the ground and you would fail the song. By playing perfectly, Fuujin would reach the stars. This one, actually, was going to be my first choice. I even gathered some resources to study how to detect the beats of a music, but as I digged deep into it I realized I wouldn't be able to finish in time. I want to return to this, though, when I have more time.
Komida-chan can't control herself during his trip to FoodIsland. Please! stop her before it's too late!

Idea: My choice for this jam! I really liked the famicase and the synopsis was fun. I had trouble thinking on what to do with this one. First I thought of a platformer where you were supposed to destroy all the foods so Komida-chan woudn't eat anything, and from time to time she would try to eat you and there would be a boss fight, etc. I discarded this idea, in parts, to make it playable on mobile devices (and to try something different). I usually have trouble thinking of small arcade games, but some concepts of the earlier idea led me to this: use different tools (controlled by mouse or touch) to destroy the foods and make Komida-chan snap out of whatever is making her lose control. The idea is very simple and would lead to a very simple game, exactly what I wanted!


Designing the Game
I started designing this game by thinking of its screen. I then made a mockup of it (in MS Paint because I didn't have any paper with me atm)

In this screen I'm trying to balance the visual elements. The conveyor belts are placed at each side of the screen, Komida-chan is at the top center and the Saciety Bar (which diplays your progress towards winning or losing) is placed ate the central point of the screen - where the eyes of the player usually rest. This way the player knows, most of the time, if he/she is winning or losing. The lower area of the screen was reserved for the tools the player would use.

The next step was to define which tools I wanted in the game. I was trying to think of something kitchen-related, but decided it would be more fun if the tools were something different. I then thought of a Torch and a Fan - putting fire and blowing food off seems a good way of making someone stop eating. A hammer to 'destroy' food and a vacuum to suck it also seems pretty good.

With all the elements defined, I started designing a prettier mockup. I would use the objects on it as the backgrounds and sprites for the game later.

For each tool I chose a 'matching' food. Lettuce for the Torch, Fries for the Fan, Cake for the Hammer and a Flan for the Vacuum. By interacting with each of theses foods with the correspondent tool would make it inedible, decreasing Komida-chan's Saciety Bar.

Making the game more interesting
Managing the tools in order to destroy the food before it reaches Komida-chan was pretty fun, but it didn't have any replay element. Once the player wins once, there is absolutely no reason for them to replay the game. To try to fix this I added 2 very common elements: different dificulties and a combo system.

I divided the game into 3 different dificulties: Easy, Medium and Hard. Each of them impacts on the speed of the conveyor belt and how full the Saciety Bar starts. Since it's a reflex based game, the player can try different modes until they find one that suits them. Once that is set, they can try another mode to challenge themselves.

The combo system walks side by side with the different modes. Combos intuitively leads the player to aim for the highest possible value. If they break the combo somehow, some may be motivated to try again and keep the combo going. Mixing this with harder modes creates challenges that increase the game's replayability (like trying to beat Hard Mode with a full combo).


Porting to Winnitron
Winnitron is an open source platform for indie arcade machines and games. This year's AGBIC suggested the devs to make the games created during the jam compatible with Winnitron machines.

Food Eater was primarily designed to be played with mouse or touch controls. Porting the game to an arcade system like Winnitron was quite a challenge. The core of the game would have to change for this to work and at the same time, the changes couldn't be so dramatic to the point of making the game lose in gameplay.

The solution I found to this was to divide the gameplay mechanics in two groups:
- Choosing the tool
- Using the tool
Since Winnitron only uses 2 buttons and a stick, each mechanic has to be simple enough to fit it.

Choosing the tool
A player can choose which tool he/she wants to use at the moment by simply pressing Button 1 or Button 2. Button 1 will select the next tool on the left and Button 2 will select the next tool on the right. This will cycle through all the tools available, meaning that if you have the last tool on the right selected and press Button 2, it will return to the first tool on the left. With this system players can pick tools with more ease during the flow of the game.

Using the tool
Using the tool is the most important part of the game, since it's your winning condition: use the right tools on the right foods. To use a tool a player simply needs to press either LEFT or RIGHT in the stick. Different from the original version, in the Winnitron port you will be aiming ALWAYS at the first plate that contains food in the conveyor belt. This way, if the first plate contains a cake, when pressing the stick in that plate's direction, you will be aiming at it (you will know at all times at which plate you will be aiming because it will have a arrow above it). If a plate contains nothing or inedible food, you will aim in the next plate that contains food of that conveyor belt.

I made several tests using a keyboard, but it will never replace the feeling of playing in a arcade machine. If you end up playing Food Eater in a Winnitron, let me know how was the experience!

Aug 28, 2017

Medjed's Arena of Madness - #PaintGameJam entry

5:36 PM Posted by Lucas Izumi , , , , , No comments

Medjed's Arena of Madness is a chaotic twin stick shooter created during #PaintGameJam. You can play through your browser or by downloading the Windows version. The game supports gamepads and can also be played with a keyboard and mouse.

The MS Paint Game Jam started on August 24 and will go until August 31. The proposal was to create a game using MS Paint art style, to honor the legacy of the software.

Since the day I joined this jam, I has some sort of theme to work on in mind. This month I discovered this egyptian god name Medjed through the game Fate Gran Order. I had seen him before but never thought he was actually a god. Due to his looks, he even became an internet meme in Japan. I loved him so I decided to use him in this game. I had no idea, however, what kind of game to make.

There is absolute no information on Medjed, besides him being able to shoot lasers from his eyes. Based on this information I first thought of a game where the player would have to do everything by just using the lasers: moving, jumping, attacking, etc. It could result in something really interesting: a simple platformer where the challenge would be controlling the intensity and direction of the lasers so you can travel though the level. Then I thought of a Twin Stick Shooter. Even being a well known genre (and a little cliché), the idea of working with gamepads (something I didn't have the opportunity to do yet) plus the idea of designing enemies for it (I just love it) led me this way.

Character and Enemy Design
Let's talk about Medjed first. His appearance is already funny, but I wanted to go beyond that. Then I remebered this guy:

Sanic's walking cycle would fit perfect in all of Medjed's goofiness. This was the result:

With that done, it was time to focus on the enemies. Twin Stick Shooters kind of have a default set of enemies: a big guy that explodes and help clear the mobs, regular guys with no special effects but in large quantity and the tough one, something big and strong. I decided to skip the tough one and focus on enemies with special abilities.

Disclaimer: I was drawing the enemies without thinking, really. I was just having fun, just like I did when drawing on Paint when I was a kid. Because of that I can't quite explain why Rah is sitting in a bathtub with the sun in it while riding a BeyBlade nor why there is a Xatu Salaryman in this game.

Enemy 1: Xatu Salaryman
This is the regular guy I was talking about. All they do is follow the player, damaging him when in contact. They appear in numbers.

Enemy 2: BeyBlade Rah
At first I was going to place boss fights every 10 waves and the first boss I was going to add was this guy that just spints through the screen randomly. When I discarded the boss fight idea, I still used this 'boss' as a regular minion. BeyBlade Rah just bounces off walls, damaging the player when in contact. This enemy is kind of important to add variety and to create a chaotic sensation to the game environment (we can't make everything just follow the player).

Enemy 3: Minigun Anubis
Why is Anubis holding a minigun? Is he pissed? Maybe. With this enemy I tried to add a "bullet hell" element to the game. The bullets do not follow the player, but when shot, they go in the player's direction, just adding to the hazards the player will need to avoid. An Anubis enemy do not move, and each spawn point can only have one Anubis at a time. This rule was necessary so the players won't be overwhelmed by thousands of bullets in the screen at the same time.

Enemy 4: Fangirl Isis
Isis concept is really simple and perhaps the one I like the most in this game. Isis basically grabs the player when in contact for a few seconds. While grabbed the player can't do anything, which means: they can't dodge other enemies and projectiles. Isis itself doesn't damage the player. She just wanna hug this cute little god.


Enemy 5: Bomb Carrier Slave
This is the "big guy" of this game. He is slow, have very low health and when he dies an explosion occurs, damaging all enemies (and player) around it. He also explodes if in direct contact with the player, so be careful!

Enemy 6: Tourist Zeus
Well... yeah. He shoots lightning bolts that follow the player until it hits or until Zeus is killed. Just like Anubis it helps adding hazards to the game. He also stands still and only one Zeus can be spawned at a time. In order to balance him there is also a delay between each of his attacks so the player have time to deal with it.

What I learned by making this game
Besides having fun, in each game jam I participate I try to learn something new. Sometimes I know what I will learn when making the game, sometimes I learn something I could never imagine. While I was making the game, both things happened. I will use this section to share it with you.

Please note that the engine used here was GameMaker Studio and while the following tips may be heavily engine based, the overall knowledge can still be used elsewhere.

Fixing Diagonal Movement when Using a Gamepad
First, it is important to know how movement work in GameMaker. Let's assume our character's movement speed is set to 7. This means that every time you press a movement button, the character will move 7 pixels.

So how do you know if the character needs to move 7 pixels to the left or to the right?
A 2D environment is built upon a cartesian plane, with a x-axis and a y-axis. This plane however is slightly different from the usual cartesian plane we see in Math. Computer Graphics use the 4th quadrant of the cartesian plane (see figure below).

Which means that the coordinate (0,0) is located ate the top left corner of the screen. If you notice, in this quadrant, y values are all negative. In order to make it easier to work with it, they inverted the y-axis.

In this setting:
- If something moves LEFT, its value is descreased;
- If something moves RIGHT, its value is increased;
- If something moves DOWN, its value is increased;
- If something moves UP, its value is decreased;

Now it is possible to know the direction our character will be moving.
- If it's UP, then it needs to move -7 pixels in the y-axis
- If it's DOWN, then it needs to move 7 pixels in the y-axis
- If it's RIGHT, then it needs to move 7 pixels in the x-asis
- If it's LEFT, then it needs to move -7 pixels in the x-asis

When using a keyboard we know exactly when the player pressed each of the keys. So assuming our movement keys are the arrow keys, we can create a basic logic. We can evaluate if a key is being pressed in real time by checking the value returned by them: 0 or 1. If the value is 1 then that key is being pressed. If the value is 0 then that key is not being pressed.

Our horizontal movement can be expressed by the following formula:
HSPEED = ((KEY_LEFT*-1) + KEY_RIGHT) * SPEED
Where:
HSPEED: Horizontal Speed
KEY_LEFT: the value returned by the left arrow key. This value must be multiplied by -1 because to move left we use negative values, remember?
KEY_RIGHT: the value returned by the right arrow key.
SPEED: the player's movement speed (we are using the value 7 in this example)

Let's assume only the Left Arrow Key is being pressed. The result would be:
HSPEED = ((1*-1) + 0) * 7
HSPEED = (-1 + 0) * 7
HSPEED = -1 * 7
HSPEED = -7

For vertical movement we use this very same idea.
VSPEED = ((KEY_UP*-1) + KEY_DOWN) * SPEED

If only the Left Arrow Key is being pressed, then it's safe to assume that VSPEED = 0. We can conclude then:
UP: VSPEED = -7, HSPEED = 0
DOWN: VSPEED = 7, HSPEED = 0
LEFT: VSPEED = 0, HSPEED = -7
RIGHT: VSPEED = 0, HSPEED = 7

Now that we know this, let's talk about Diagonal Movement. When using a keyboard, we need to press two keys in order to move diagonally. For example, Left Arrow Key + Up Arrow Key to move diagonally up left, etc. Knowing this, when this setting is applied to the mentioned formulas, we get the following:
HSPEED = ((1*-1) + 0) * 7 = -7
VSPEED = ((1*-1) + 0) * 7 = -7

This means that we are telling the game that our character must move -7 pixels in the y-axis e -7 pixels at the x-axis at the same time. This way we will maintain the movement speed (in this example, 7) and the character will move diagonally.

This concept, however, is slightly different when using a gamepad. When evaluating if a direction is being pressed in a gamepad stick we get 0 if nothing is being pressed, 1 if Up, Left, Right or Down is being pressed AND a value between 0.99 and 0.5 if any other direction is being pressed (and this includes the diagonals).

A gamepad stick uses this setting because it must be very precise so it can deal with all kinds of games (3D most of all). Because of that we can't just jump from one state to another. The image below illustrate the states.

Let's assume we are pressing the up left diagonal. If we place the stick in the exact spot it will return:
KEY_LEFT = 0.5
KEY_RIGHT = 0
KEY_UP = 0.5
KEY_DOWN = 0

Let's return to those formulas to check the consequences of this:
HSPEED = ((0.5*-1) + 0) * 7 = -3.5
VSPEED = ((0.5*-1) + 0) * 7 = -3.5

Our character will be moving -3.5 pixels on the y-axis and -3.5 pixels on the x-axis, which is half the speed he was supposed to move.

Now, fixing this is very simple: after calculating the HSPEED and VSPEED, we just need to evaluate them:
- To move diagonally up left
if both HSPEED and VSPEED are less than 0 and greater than -SPEED (in this case, -7), then we set both HSPEED and VSPEED to -SPEED (-7).

Let's pick the previous example: HSPEED = -3.5 and VSPEED = -3.5
Is HSPEED less than 0? Yes.
Is HSPEED greater than -7? Yes.
The same applies to VSPEED, so now we manually set their values:
HSPEED = -7
VSPEED = -7

To the other diagonals, the requirements are as follows:
- To move diagonally up right
if HSPEED is greater than 0 and less than SPEED and VSPEED is greater than -SPEED and less than 0, then we set HSPEED to SPEED and VSPEED to -SPEED.

- To move diagonally down left
if HSPEED is less than 0 and greater than -SPEED and VSPEED is greater than 0 and less than SPEED, then we set HSPEED to -SPEED and VSPEED to SPEED.

- To move diagonally down right
if both HSPEED and VSPEED are greater than 0 and less than SPEED, then we set both HSPEED and VSPEED to SPEED.

All of this is just to check whether the gamepad stick is in the "diagonal region", so we can normalize the movement. Please note that this solution "removes" the precision the gamepad stick offers by basically "transforming" it in a 8-direction pad which is what I wanted for this game.

Scaling Game Screen for Browsers
This was a problem I faced when publishing the game as HTML 5. The game's resolution is 1280x720 which is really large to play in a browser. I tried setting it to a lower resolution on itch.io website but the game did not scale. In the lower resolution you could only see a piece of the screen.

I ended up finding this article that covers how scaling works and how to do that with your game:
https://www.yoyogames.com/blog/67/scaling-for-html5
In my case I was working with views and it all worked very well. The GUI however, did not scale. After some seaching I found out about the display_set_gui_size() function. By adding it to my script, the whole game scaled perfectly. This is my scale_canvas() script updated to scale the GUI as well.

/// scale_canvas(base width, base height, current width, current height, center);
//argument0 = base width;
//argument1 = base height;
//argument2 = current width
//argument3 = current height
//argument4 = center window (true, false);
var aspect = argument0 / argument1;
if ((argument2 / aspect) > argument3)
    {
    window_set_size((argument3 * aspect), argument3);
    }
else
    {
    window_set_size(argument2, (argument2 / aspect));
    }
if (argument4) window_center();
view_wport[0] = window_get_width();
view_hport[0] = window_get_height();
display_set_gui_size(view_wview[0], view_hview[0]);
surface_resize(application_surface, min(window_get_width(), argument0), min(window_get_height(), argument1));

This concludes this postmortem. I hope you enjoy the game! Don't forget to share your highscores in the comments section!

May 4, 2017

An old project returns!

9:44 PM Posted by Lucas Izumi , , , No comments


Recently I've been searching my game projects' folder for a new game to work on. I noticed most of them would require a larger team and a lot of time. At the very end of the list, there was this game: the first one I've coded in my life. Its name is WAN. Back in the day it was a very bold project, but I never could finish it (heck, I couldn't even finish the first level) due to lack of experience. Today I'm able to code those ideas and since there are already tons of puzzles designed for it, I decided to start it from scratch in Game Maker Studio.

WAN is a puzzle platformer where the main character has magnetic powers. By cycling through colors they are able to pull or push different blocks and by using this power they must solve puzzles to advance in the game.

Since the mechanics are really simple I should be able to provide a quick-look into it soon! The game still uses colored blocks, just for testing. Until there I'll probably cover with with some art made by me (so you all know what to expect) just to make it look a little better.

In other news, I'm really happy with Battle for Enlor reach. There are some negative reviews (which made me learn a few things, personally) and there are a few people really engaged in the game. It's a shame that most of the engaged ones are playing a pirated version :(
I'm working on the first DLC (that will be free) and planning on releasing it together with the Mac OS version of the game. Follow @sonerags on Twitter for future updates!

Feb 22, 2017

Feb 17, 2017

Battle for Enlor is on Steam Greenlight!

2:18 AM Posted by Lucas Izumi , , , , No comments


Battle for Enlor Steam Greenlight Campaign just launched! Visit the game's page and leave your vote!

We are also holding awareness campaigns on our social networks!
Share the post below on Facebook to help unlock bonus content for the game (new bosses!)

Battle for Enlor está no Steam Greenlight! Visite nossa página e deixe seu voto!...

Publicado por Sonera Game Studio em Quinta, 16 de fevereiro de 2017

Retweet the post below on Twitter to help unlock even more bonus content (new characters!)


All your support is deeply appreciated!