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: 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

For vertical movement we use this very same idea.

If only the Left Arrow Key is being pressed, then it's safe to assume that VSPEED = 0. We can conclude then:

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_UP = 0.5

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:

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 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:
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);
    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!

Feb 1, 2017

Battle for Enlor Dev Diary 4: Game Balance

2:01 PM Posted by Lucas Izumi , , No comments

In today's dev diary I will discuss some of the decisions I had to take in order to better balance the game. There is this blog called 'Game Balance Concepts' which has taught me a lot on this topic. It has an extensive material that I recomment to anyone interested.

I'll start by talking about my initial design idea for the characters of the game. If you want to understand better all the changes that were made, you can download Battle for Enlor Demo and experience it first hand! All characters cited here are playable in the demo version 😊

Initial Design
The initial game concept had 9 characters: each one representing a class and a race. For their skills, I read a lot of tabletop RPG material in order to distinguish the best abilities that represent those class/race and made a list. With this list in hand I could divide the characters into groups: supportive characters, defensive characters and offensive characters. Since the game is about building parties to defeat powerful enemies, all the characters needed to have abilities that work well with the other characters. That was the first challenge: thinking of a character as a whole. The character needs to be good on its own and have at least one way of interacting with its party. With this in mind, I designed every character to have at least one skill that favors other characters (or allows interaction with others).

Balancing Challenges
When balancing the characters I always had this things in mind:

1. Character power must escalate smoothly
The game uses a party system where you can fit 4 characters. That being said it is important that all characters start with a similar power (in general) that adds to the party without creating any disruptions. In other words, let's consider that characters have an imaginary power that varies from 30 to 35 points, depending on the characters chosen, the maximum power difference of a party will be of 20 points:
30 + 30 + 30 +30 = 120
35 + 35 + 35 + 35 = 140
140-120 = 20

Because of that the difference in power from character to character cannot diverge too much, or else it will be possible to create an overpowered party that will diminish the value of other characters and eventually discourage the player to explore new party combinations and strategies.

This 'power' is translated inside the game as the character's abilities. For each ability you can assign a "power value" based on its effects. Abilities with similar effects must have a similar power value. It may sound simple but actually assigning power values to abilities can be quite challenging. Consider the following scenario:
Character A has an ability: For 3 mana, gain +1 attack power. This effect can be stacked.
Character B has an ability: For 5 mana, give +2 attack power to any ally. This effect cannot stack.
Which one would have a greater power value? Would they be equal?

To answer this there are several factors to consider:
- In Battle for Enlor each character is allowed only 1 action per turn. That being said when Characters A and B uses their ability, their turn will end.
- Character A can only use their ability on self, which means they will only benefit from it in their next turn.
- Character B can use their ability on any ally, which means they can use it on an ally that have yet not used their actions thus benefiting from the ability during this round.
- The mana costs reflects on the attack power gained so it is pretty even.
- Being stackable or not reflects on the late game status. If Character A uses their ability multiple times, they will be way stronger than a character with only Character B's buff.

By considering all this you may say the abilities are very similar in power. However, in Battle for Enlor, immediate effects pay a very important role and because of that, Character B's ability is a little more attractive. Therefore, Character B's ability will have a greater power value than Character A's ability.

2. Always see the whole picture. Analysing a character performance in a group can help balance them individually
In Battle for Enlor you can add a character multiple times to your party (unless it is a Legendary Character). Let's say you want a party composed of 4 Half-Orc Barbarian. You can. So the first thing was to avoid making a character with an ability that, when spammed, could have a great influence in battle. The Halfling Rogue character, for example, has a skill where they have a chance to stun the enemy (make them unable to attack for 1 turn). When using a single Halfling Rogue having a 40% chance of stunning the enemy sounds reasonable. But what if I create a party with 4 of them? The odds increase greatly and can lead to situations where you can spam this ability until you stun the enemy and let the other Halflings attack, killing it slowly but without a single scratch!

What to do in this case? My first approach was to bring down the ability's percentage of success to 15%. It solved the problem of multiple Halfling Rogues but created another: that skill now was almost useless individually. The original concept of this skill was to create a "get me out of this situation" option. The chance of success is solely to set a mood of desperation/relief to the player. With 15% chance the skill won't trigger most of the times, but when it does I'm sure the sensation transmited will feel good. But there is still that problem, this good sensation still does not pay off for the amount of frustration the player will feel during all the times the ability fails. To solve this I created a second effect to the ability: if the stun fails, the enemy's damage will be reduced for 1 turn. The "get me out of this situation" option still works, but in a lower level. It helps ease the frustration of missing a stun and keeps the good feeling when it hits.
Halfling Rogue card.
3. Be careful with numbers
"Because the numbers get prohibitively large very quickly, you have to be careful when using exponential relationships". This is a quote from the Game Concepts blog I mentioned earlier and since I read it I carved this words in my heart.

Initially, the Half-Orc Barbarian character had this ability:
- Your next attack will deal TRIPLE DAMAGE and you will take DOUBLE DAMAGE from the next enemy attack.

This clearly got out of hand as the development progressed. With the addition of characters with abilities that increase other character's attacks, dealing triple damage made the Half-Orc Barbarian an extreme powerful character. On the other hand, the ill effect of using this ability also had a great impact. Taking double damage meant that, in some occasions, an enemy could instant kill a Half-Orc Barbarian. This ability, in general, became a high risk high reward kinda of thing and that was bad. It created scenarios where all was left to luck. If the boss misses the attack, if the character dodges... There were several 'ifs' that the players could use to justify to himself/herself that it was good to use this character until the "tactic" worked.

I had to rework this ability several times and I was only satisfied with it when I got rid of the exponential relationships. Below is the change log of the ability:

  • (Version 1) Your next attack will deal TRIPLE DAMAGE and you will take DOUBLE DAMAGE from the next enemy attack.
  • (Version 2) Your next attack will deal 10 more damage and you will take DOUBLE DAMAGE from the next enemy attack.
  • (Version 3) Your next attack will deal 10 more damage and you will take 5 more damage from the next enemy attack.
  • (Version 4) Your next attack will deal 10 more damage and you will take 3 more damage from the next enemy attack.
Half-Orc Barbarian card

4. Observe your players
One of the most important ones. By observing your players you can collect valuable information on your characters, enemies and systems. The players will put to test everything you did and, most of the times, show to you things that can be improved within the game. Most of the balances made in Battle for Enlor were thanks to player feedback.

Collect feedback regularly. See which characters players are using and why they are using them. With this feedback you can make a few tweaks or corrections. Game balance is something that needs constant monitoring: keeping a close eye and changing things that can affect the game negatively helps to keep the game alive.

Thank you for reading, see you in the next dev diary!

Nov 10, 2016

infinite loop - PROCJAM 2016 entry

7:24 PM Posted by Lucas Izumi , , , , No comments

Taken direclty from PROCJAM's page, "PROCJAM is a jam about making stuff that makes other stuff". I was always interested on procedural generation but never really tried doing anything. When I saw this jam was being hosted I thought "Why not?".

The Game
infinite loop is a puzzle game that uses the mechanics of a game I've previously released called "SHE". Solve puzzles, race against the clock and compete in online leaderboards!

You can download the game in the link below

Since I released "SHE" for A Game By Its Cover game jam I thought of making a system that creates puzzles automatically for it and I decided to try it during this jam. The idea was defining the rules that creates valid board states and using it to generate countless combinations. Each of these combinations is a puzzle for the player to solve.

To add a little more into it than just solving puzzles after puzzles without any other motivator, I added  the concept of level progression and online leaderboards. The game has a countdown timer which represents how much time the player will have to solve a puzzle. After solving a puzzle the player progresses a level and a bonus is added to the remaning time. The leaderboards (or highscores) are computed based on which level the player reached. For example, if a player solved 10 puzzles, he/she will be at level 10. Whoever solve the most puzzles (without quiting the game) will grab the top of the leaderboards.

Procedural Generation
In this section I'll explain my algorithm for procedural generation of puzzles in the game.
First of all, you'll need to understand how the mechanics work. The images below are screenshots taken from the "How to Play" section of the game (click on the image to zoom):

Given how green and red panels work, it is necessary to have at least 1 green panel in each column and 1 red panel in each row, otherwise it would be impossible to color some rows and columns with the given colors.
For example, once the board reaches the state in the image below, it is impossible to color any of the panels of the bottom row red.

If the player accidentally creates one of these states, he/she can reset the board and try again. The algorithm to create a board works similarly.

Player's Board Creation Algorithm
1) Each panel is assigned a random number. Based on this number the panel is colored red or green.

2) The algorithm starts checking all the rows and flagging them. If a row contains at least 1 red panel, the row is flagged as VALID.

3) When all the rows are checked, then it's time for the columns. The process is the same, but this time it checks whether there is at least 1 green panel in each column. If there is the column is flagged as VALID.

4) If, at any time, a row or column is flagged INVALID, the algorithm stops the checking process and start over (Go to step 1).

This process is repeated until all rows and columns are flagged as VALID, which means we have a board with a valid combination of panels.

Solution's Board Creation Algorithm
For the creation of solutions, the steps are much simpler. Since a solution can be a board with ANY combination of colors, we just need to use the previous algorithm's Step 1. Once the colors are sorted, that is already acceptable as a solution to the puzzle.

This game jam really helped me learn about new things and apply them directly into the game. Let me know what are your thoughts about the game, write a comment! :)

Until next time!