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!

Oct 20, 2016

Battle for Enlor Dev Diary 3: Introducing the Character Cards

10:39 PM Posted by Lucas Izumi , , No comments

The last few weeks have been crazy. Since the start of the beta tests I've been working like never. There is always something to fix, something to balance (actually lots of things to balance), but it is tremendously satisfying to see the game in its current shape. In today's (very short) dev diary I want to introduce you to character cards.

In Battle for Enlor, Character Cards contains all the information you need to know about a character: its stats, abilities, name and appearance. It will be a crucial element when making choices and building teams.
Gnome Druid character card. Please note that all cards displayed on this post are not final and may have different text and design in the final version of the game.
As you may notice, there are three abilities displayed on the card. Along with it, every character has a basic attack that either can be melee or ranged. The image below was taken from one of the help screens and has some more detailed information about the cards' elements.

Character cards are used solely on the character selection screen. They exist only to help player make decisions by displaying useful information about the selected character. During a combat, you will find all the information  from a character card displayed on the screen in a different way as you can see in the screenshot below:

That's it for today's post. Don't forget to leave a comment, I would love to hear your feedback!
Battle for Enlor is planned to release late 2017 for PC, Mac and Linux. Visit the oficial game page here.

Aug 3, 2016

Battle for Enlor Dev Diary 2: Planning and dealing with the unexpected

11:50 PM Posted by Lucas Izumi , , No comments

This last week taught me a lot about planning and the unexpected. It made me think: how far do you must plan to avoid the unexpected? Is it even possible to avoid it at all?
It all started when I began coding the Dwarf Warrior character actions. After every action I code, I run the game and do a playtest session focusing on that action. During one of those sessions, I noticed that an action I've just implemented wasn't very good. It wasn't interesting and had no appeal to the player. I decided to rework that specific action and came up with a new model for it. The problem was, this model was not used in the game before and it didn't fit with the code structure I was working up until now.

Why planning is so important
In Battle for Enlor, there are 3 different kind of actions: deal damage to the enemy, inflict a status on the enemy and inflict a status on teamates (or yourself). Status inflicted to teamates are generally positive status, while status inflicted to enemies are negative. Every time a player executes an action that targets an enemy, that enemy has a chance to defend it. This is true for all attacks that causes damage. Inflicting status, however, does not trigger the enemy's defense, this means that negative status are sure-hit actions. This was a design decision based on the whole game balance.
This is better explained on the diagrams below:

Note that when I say 'messages' I referring to comunication between game components.
Now, the new action designed for the Dwarf Warrior involved: attacking the boss and, if the boss takes damage, inflict a negative status on it. By using the current structure, the status would be inflicted even if the boss defended or if the player missed the attack. If I had thought about this particular issue during the planning phase, it would be very easy to deal with this. For example, if attacking a boss is basically sending a message with the damage: AttackBoss(Damage), attacking AND inflicting a status could be as simple as: AttackBoss(Damage, Poison). Even so, as simple as it may seem, changing the code to allow that now would be a huge amount of work. This is a small project but imagine on a AAA game where everything is exponential.

This is a lesson I learned the hard way and by making games. I can't stress enough how important is to make games and more games, even small ones, because is doing so that you will learn the most. The big lesson here is that planning is very important. Define how everything will work and playtest that with prototypes: there are several ways you can do this, even with paper. You can face the unexpected, but the more planning you do the less are the chances of facing it.

Dealing with the unexpected
I decided not to go to the route: "let's remake this whole module so now it supports what I need", but decided to try a different approach. I noticed that the only thing I needed to inflict that status was a confirmation that the enemy was hit by the attack. Knowing this there was a solution in sight. In the enemy defense scripts I know exactly when they take damage. My approach was, everytime an enemy takes damage, it sends a message saying that it took damage (refer to the 'messages' meaning above). With this information I can work on a particular script for my new attack:

- Send a message to the enemy with the damage
- The message goes through the enemy defenses
- The enemy sends a message if it was hit or not
- Based on the message received the status is either inflicted or not.

This is illustrated on the diagram below:

With this approach I was able to solve the problem without having to redo a large amount of code. However if this wasn't possible, I would, without thinking, redo it all so I can add it. This added so much value to the game environment to me that it would be pointless to keep the old plain and boring attack just because changing it would led to a lot of work.

There are times where the unexpected happens and we have to sacrifice something to preserve the game. But there are also times when we can deal with it, be it with the exchange of our time, resources or just by applying an idea that wasn't thought before.