Monday, March 16, 2015
Moving to Tumblr!
Yes! Just as the title says! I've decided to move this blog to Tumblr, so if you end up here and want to see more recent stuff be sure to check out canotico.tumblr.com!! :D
Wednesday, September 3, 2014
Working on a new game: Casmage
I decided to start making a game of my own and by myself (for now). I originally started playing around trying to make some kind of Terraria engine with destructible environment, but when I got the idea for Casmage I dropped the destructible stuff because I thought it didn't fit the kind of game I wanted to make, but who knows, maybe I'll add it later.
Casmage will be a game focused on cooperation between players (yes, that means multiplayer, and I'm not just taking about local multiplayer, I'm talking about the real thing here, online).
I play MOBA's a lot and what I love the most about them is being able to be creative when using your character's abilities and create those moments when you are able to pull off amazing plays to save the day or get out of a difficult situation, those moments when you feel like you are the best player ever. Those are the things I want to evoke in Casmage.
To allow a player to be creative with the kit of skills at their disposal the skills have to be very flexible and have a lot of breadth (was it breadth or depth? I don't remember right now), meaning that beyond the basic mechanics of the skill, there can be certain situations where it can be used differently.
So, flexible skills, amazing plays, and cooperation between players. I want the game to be almost unbeatable if you are playing by yourself, and I mean it. I'm talking about things like if you slip and let an enemy stun you, you will probably die unless a friend comes in to save you. How will this happen? well I'm working on it, but for now there's a way of picking up allies and move them around, so if your friend is unconscious you can just pick them up and take them to somewhere safer, of course there will be enemies on the way to that safe place but that's what the game is about isn't it?
I started a DevLog on TIGsource because I think that it's a bit less formal than this blog and the traffic the forum gets will kinda force me to keep working on the game. Let's say it's because I want as much motivation as possible. I will be updating the DevLog a lot more frequently than this blog tho.
So how much of the game is done? Not so much, since I'm a programmer I started... well... programming. I focused on getting the networking engine out of the way as soon as possible and it is like 95% done, so that's good. I had a bit of a headache last weekend working on it but it's almost finished.
As expected I also have to make the art and... I had to learn real pixel-art for that. I'm not saying that I'm good, but I have very high standards myself so I want to learn enough to make good art.
For now most of the art is placeholder because I want to have a playable demo soon,
Enough talk, seeable stuff!
Sunday, February 16, 2014
Flappy Jam: Risk of Bird
I recently delivered my entry for the Flappy Jam, which consisted of making a game similar to Flappy Bird, to show support to it's maker Nguyen Dong, who had to go through a very distasteful experience of receiving tons of destructive criticism related to Flappy Bird's quality and visual assets, and after not being able to handle the pressure he decided to take the game off the radar to get some peace. Because of this, the Flappy Jam was dedicated to not let hate win.
The premise was to: "Make a hard, almost unplayable game. Use assets inspired (not ripped) from classics..." Honestly I didn't pay much attention to the second sentence because well... while thinking about what game to use as the visuals for my Flappy game I fixed my mind on Risk of Rain, if you havn't played it yet I strongly suggest you do, because it's incredibly fun and with its own visual style it looks beautiful.
I wanted to emulate that visual style because I've always had a thing for pixel-art, and Risk of Rain's is pretty much awesome.
I literally made the game within 1 hour using unity, of course the game only consisted of a bunch of boxes moving from right to left and a small box trying to not get hit. There's something strangely refreshing in making such a small game, maybe it's because I'm not used to actually finishing a game so quickly... yeah, that's it.
Anyway, the gameplay was done and then I set to start making my own version of Risk of Rain. I really need to say that I didn't copy a single pixel from the actual game, all was made using the game itself as a reference (you can tell because the colors are not even the same, and some stuff doesn't look as good).
After I had finished with the art it was time to add some sounds, and wow, I did have a lot of fun making my robot guy explode over and over again after I was finished.
The resulting game was this:
The premise was to: "Make a hard, almost unplayable game. Use assets inspired (not ripped) from classics..." Honestly I didn't pay much attention to the second sentence because well... while thinking about what game to use as the visuals for my Flappy game I fixed my mind on Risk of Rain, if you havn't played it yet I strongly suggest you do, because it's incredibly fun and with its own visual style it looks beautiful.
I wanted to emulate that visual style because I've always had a thing for pixel-art, and Risk of Rain's is pretty much awesome.
I literally made the game within 1 hour using unity, of course the game only consisted of a bunch of boxes moving from right to left and a small box trying to not get hit. There's something strangely refreshing in making such a small game, maybe it's because I'm not used to actually finishing a game so quickly... yeah, that's it.
Anyway, the gameplay was done and then I set to start making my own version of Risk of Rain. I really need to say that I didn't copy a single pixel from the actual game, all was made using the game itself as a reference (you can tell because the colors are not even the same, and some stuff doesn't look as good).
After I had finished with the art it was time to add some sounds, and wow, I did have a lot of fun making my robot guy explode over and over again after I was finished.
The resulting game was this:
I seriously enjoyed making this small and simple game, I feel like I may have learned some pixel-art skills right there, wohooo!
Friday, November 8, 2013
Procedural Content Generation on a MOBA genre videogame - Part 3
This is the last part of my post about my thesis project, I recommend reading Part 1 and Part 2 if you haven't already!
Character Adaptation System
Finally, the last part of this post is here, and I'll be talking about the final part of the project, which is the Character Adaptation System (CAS).
Before getting into implementation details, I'd like to talk about how is the common MOBA character composed.
Traditional MOBA character
The common MOBA character comes from the RPG paradigm, where the player controls a character that is composed by a set of attributes and skills that determine its capacities. When the character accumulates a certain amount of experience points, its level is increased, which allows the player to choose how would he like to improve his characters capacities and therefore be stronger. Because of this, the level is directly mapped to how powerful a character is in the game.
In a MOBA, characters follow the RPG paradigm, where the player needs to increase his character's level in order to increase its attributes and abilities to become stronger. This progression happens in a discrete way, where (leaving modifiers like items aside) the character won't become stronger until the experience threshold is reached, which could take some time.
This way of making a character progress through the game has as a goal the accumulation of experience points in any possible way to reward the player with more power. I'm not saying this is bad or anything, this is what we are all used to do while playing an RPG and it feels just right. But how about changing it a bit??
Why change what isn't broken? You may be right, but I decided to do this to try to address the problem MOBA developers face every time they release new characters into their game: rebalancing.
When a new character is released, they are supposed to be all fun and unique and with a very well made design. The problem here is that the bigger the character pool offered by the game, the harder it seems to be for developers to maintain every character in equal ground. Having played years of League of Legends, I've always criticized the constant rebalancing of characters done with each new champion update, and to me this means that the difficulty of adding new champions to the game is proportional to the size of the champion pool. Meaning that at some point Riot (for this particular example, this applies to most MOBA's in my opinion) will have to stop spitting out new champions, not because they will run out of imagination but because it will be so freaking hard to rebalance so many champions and do it right.
CAS design
Following this train of thought, I decided to change the core by which the characters are created and maybe fix the problem. I decided I would take away the necessity of creating new characters by hand in order to add new content to the game. To do this, I would need to implement some kind of system that would be able to let the player choose how he wanted to play and kinda "create" their own unique character as the game progresses.
For this I created the CAS, which changes the RPG paradigm and removes the level mechanic embedded into the character to switch to a continuous progression system. Players will make their characters stronger not by earning a certain amount of points, but by fighting.
"But fighting happens all the time and is the way you usually earn experience points!", that is completely true, but with no experience point to tell us how much that fight was worth, what do we have left? What happened during the fight, and this is exactly what the CAS system uses to make a character stronger.
When the player gets into combat, he will play his way, using the skills he chose to achieve the results he wants to achieve. When leaving combat, the CAS will interpret every action performed by the player during the combat phase, and will determine a set of attribute bonuses to be applied to his character to encourage the player to keep playing his way and be more effective by doing so.
This is easier to explain with an example: If a player likes to play defensively, during combat he will do things like use shields and protect allies by taking damage for them and things like that. After combat, the CAS will reward him with attribute bonuses that will let him do exactly what he dide during combat more effectively.
It's important to note that the bonuses given by the CAS are all tied to how effective the player was while fighting, meaning that if the player misses an attack, he will not get a bonus for this. Likewise, if the player hits the intended target when he casted the skill, he will get a bigger bonus than if he hits a different target.
By now you should (I really really hope) understand the basic behavior of the CAS and how it differs from the typical character on a MOBA.
CAS implementation
Each skill in the game (all actions besides moving are skills, including auto-attacks) has a special routine that interprets what happened during combat, and then stores the corresponding bonuses for when the character leaves the combat state. We could say that the CAS is actually a set of smaller systems, where each system interprets the combat information in their own way and then define the bonuses to be applied. Therefore, the CAS is actually an abstract system that is not implemented by itself, but is composed of at least one skill monitoring the combat actions of the player.
The important part of the implementation lies on the logic behind the behavior of the skills. The CAS will work as long as there's one skill that follows this loop of events:
Skill acquisition vs Item acquisition
At this point I've talked about skills here and there but I haven't actually explained how is the player supposed to get them. This is another thing I've changed when compared to a common MOBA.
You still earn money by defeating enemies, and this money is used to buy skills (pretty much like having a store in Dota 2 that only sells active items). So by doing this the flow of events of a common MOBA is flipped upside-down.
Normally a player learns or improves his skills by directly defeating enemies, and by defeating enemies they are able to buy skills that increase their attributes. With the CAS, players defeat enemies to increase their attributes and buy skills with the money they earn.
When the players start the game, they all start with characters with the same attribute values, and a 2 skills: the basic-attack chosen by them, which can be either ranged or melee depending on what they want, and another skill that will help them develop their character towards certain play-style.
Well that's all there is to my thesis project. I've tried to give a twist to the MOBA genre and I think I managed to hit something interesting. The map generator neither the CAS are perfect, but I think they are a good starting point to further develop the use of PCG on a MOBA game.
Thanks for reading the whole thing and I hope you enjoyed reading it :)
Please feel free to ask ANYTHING regarding this project, I'll be more than glad to answer your questions!
Character Adaptation System
Finally, the last part of this post is here, and I'll be talking about the final part of the project, which is the Character Adaptation System (CAS).
Before getting into implementation details, I'd like to talk about how is the common MOBA character composed.
Traditional MOBA character
The common MOBA character comes from the RPG paradigm, where the player controls a character that is composed by a set of attributes and skills that determine its capacities. When the character accumulates a certain amount of experience points, its level is increased, which allows the player to choose how would he like to improve his characters capacities and therefore be stronger. Because of this, the level is directly mapped to how powerful a character is in the game.
In a MOBA, characters follow the RPG paradigm, where the player needs to increase his character's level in order to increase its attributes and abilities to become stronger. This progression happens in a discrete way, where (leaving modifiers like items aside) the character won't become stronger until the experience threshold is reached, which could take some time.
This way of making a character progress through the game has as a goal the accumulation of experience points in any possible way to reward the player with more power. I'm not saying this is bad or anything, this is what we are all used to do while playing an RPG and it feels just right. But how about changing it a bit??
Why change what isn't broken? You may be right, but I decided to do this to try to address the problem MOBA developers face every time they release new characters into their game: rebalancing.
When a new character is released, they are supposed to be all fun and unique and with a very well made design. The problem here is that the bigger the character pool offered by the game, the harder it seems to be for developers to maintain every character in equal ground. Having played years of League of Legends, I've always criticized the constant rebalancing of characters done with each new champion update, and to me this means that the difficulty of adding new champions to the game is proportional to the size of the champion pool. Meaning that at some point Riot (for this particular example, this applies to most MOBA's in my opinion) will have to stop spitting out new champions, not because they will run out of imagination but because it will be so freaking hard to rebalance so many champions and do it right.
CAS design
Following this train of thought, I decided to change the core by which the characters are created and maybe fix the problem. I decided I would take away the necessity of creating new characters by hand in order to add new content to the game. To do this, I would need to implement some kind of system that would be able to let the player choose how he wanted to play and kinda "create" their own unique character as the game progresses.
For this I created the CAS, which changes the RPG paradigm and removes the level mechanic embedded into the character to switch to a continuous progression system. Players will make their characters stronger not by earning a certain amount of points, but by fighting.
"But fighting happens all the time and is the way you usually earn experience points!", that is completely true, but with no experience point to tell us how much that fight was worth, what do we have left? What happened during the fight, and this is exactly what the CAS system uses to make a character stronger.
When the player gets into combat, he will play his way, using the skills he chose to achieve the results he wants to achieve. When leaving combat, the CAS will interpret every action performed by the player during the combat phase, and will determine a set of attribute bonuses to be applied to his character to encourage the player to keep playing his way and be more effective by doing so.
This is easier to explain with an example: If a player likes to play defensively, during combat he will do things like use shields and protect allies by taking damage for them and things like that. After combat, the CAS will reward him with attribute bonuses that will let him do exactly what he dide during combat more effectively.
It's important to note that the bonuses given by the CAS are all tied to how effective the player was while fighting, meaning that if the player misses an attack, he will not get a bonus for this. Likewise, if the player hits the intended target when he casted the skill, he will get a bigger bonus than if he hits a different target.
By now you should (I really really hope) understand the basic behavior of the CAS and how it differs from the typical character on a MOBA.
CAS implementation
Each skill in the game (all actions besides moving are skills, including auto-attacks) has a special routine that interprets what happened during combat, and then stores the corresponding bonuses for when the character leaves the combat state. We could say that the CAS is actually a set of smaller systems, where each system interprets the combat information in their own way and then define the bonuses to be applied. Therefore, the CAS is actually an abstract system that is not implemented by itself, but is composed of at least one skill monitoring the combat actions of the player.
The important part of the implementation lies on the logic behind the behavior of the skills. The CAS will work as long as there's one skill that follows this loop of events:
- Use
- The skill does what it has to do
- The outcome of the usage of the skill is interpreted. Did the projectile hit the intended target? Did damage to an enemy? Did the shield broke while absorbing damage? Etc...
- The result of the 3rd step is stored in a buffer inside the skill class. This information represents the bonuses that will be given
- After the character leaves the combat state, the buffer of the skill is read and the corresponding bonuses are applied to the attributes
Skill acquisition vs Item acquisition
At this point I've talked about skills here and there but I haven't actually explained how is the player supposed to get them. This is another thing I've changed when compared to a common MOBA.
You still earn money by defeating enemies, and this money is used to buy skills (pretty much like having a store in Dota 2 that only sells active items). So by doing this the flow of events of a common MOBA is flipped upside-down.
Normally a player learns or improves his skills by directly defeating enemies, and by defeating enemies they are able to buy skills that increase their attributes. With the CAS, players defeat enemies to increase their attributes and buy skills with the money they earn.
When the players start the game, they all start with characters with the same attribute values, and a 2 skills: the basic-attack chosen by them, which can be either ranged or melee depending on what they want, and another skill that will help them develop their character towards certain play-style.
Well that's all there is to my thesis project. I've tried to give a twist to the MOBA genre and I think I managed to hit something interesting. The map generator neither the CAS are perfect, but I think they are a good starting point to further develop the use of PCG on a MOBA game.
Thanks for reading the whole thing and I hope you enjoyed reading it :)
Please feel free to ask ANYTHING regarding this project, I'll be more than glad to answer your questions!
Monday, November 4, 2013
Procedural Content Generation on a MOBA genre videogame - Part 2
This is the last part of my post about my thesis project, I recommend reading Part 1 if you haven't already! If you want to skip to the Character Adaptation System go to Part 3.
Procedural Map Generation
Before starting to implement the algorithm that would generate the map procedurally, I needed to do some research on the design of a common MOBA map. For this I used Dota 2's map because it's asymmetrical, why asymmetrical? well, had I used a mirrored map like League of Legend's then there wouldn't have been much of a challenge in generating the map since the balancing of both sides is guaranteed when it's mirrored.
Dota 2's map design notes:
When I talk about balancing the sides of the map I mean that no team has an advantage related to certain topology on their side of the map. Thus, the first rule of the map generator was that the difficulty of traversing the map should be as similar as possible for opposite sides of the map.
Having defined the first rule, I started to analyze how the Dota 2's map was designed. The map isn't symmetrical and yet it offers very similar possibilities for both teams, which is the target of this map generator.
River: The river represents the fastest way of traveling between lanes, but of course comes at the cost of high risk of being assaulted by the opposing team.
Lanes: These must be traversed entirely in order to access the enemy base, meaning that a team is forced to destroy the towers of at least one lane in order to have a chance to win
Towers: These are placed along the lanes to provide defensive measures for each team. In the case of the outer turrets (the ones outside of a base), these are positioned in a way that will ensure that a player traveling between turrets will have to go through a red zone, thus giving the other team a chance of attacking. Green and yellow areas represent where the player can be near an allied tower and be the safest.
Jungles: If we divide the jungles on the map by lanes and the river we end up with 4 sectors that contain the 4 jungles on the map. These jungles have very different paths but they all offer 3 specific roads that will be shown on the fitness functions section below.
The common genetic algorithm uses a fitness function to determine which of a set of candidates is better. Usually these algorithms iterate over this set of candidates making new generations and mixing their traits to imitate the behavior of genetics in nature.
Using a fitness function F1 we can evaluate if a candidate has a path connecting the points A and B, and therefore determine which candidates have this characteristic. But when using complex candidates (like the maps to be used in the game) where theres a lot of information that needs to be processed in order to determine if its a viable candidate, the fitness function becomes a bit messy.
To address this problem, I used whats called a Multi-Objective Evolutive Algorithm, which basically consists of using more than 1 fitness function to evaluate all the candidates. So we can still have the fitness function F1 doing it's thing, and we can add a fitness function F2 that evaluates if there are obstacles between the point A and B. As you can see, we are interpreting different information from the same set of data, which is exactly what I needed.
Candidates creation:
With the next pseudo-code you can see the process behind the creation of a map candidate:
Displaying the map:
After having selected the best candidate according to the fitness functions defined, the drawing process begins:
Well, that's a really brief explanation of the whole process I used to make the map of a MOBA game be generated procedurally. On Part 3 I'll be explaining the implementation of the Character Adaptation System.
Thanks for reading!
Procedural Map Generation
Before starting to implement the algorithm that would generate the map procedurally, I needed to do some research on the design of a common MOBA map. For this I used Dota 2's map because it's asymmetrical, why asymmetrical? well, had I used a mirrored map like League of Legend's then there wouldn't have been much of a challenge in generating the map since the balancing of both sides is guaranteed when it's mirrored.
Dota 2's map design notes:
When I talk about balancing the sides of the map I mean that no team has an advantage related to certain topology on their side of the map. Thus, the first rule of the map generator was that the difficulty of traversing the map should be as similar as possible for opposite sides of the map.
Having defined the first rule, I started to analyze how the Dota 2's map was designed. The map isn't symmetrical and yet it offers very similar possibilities for both teams, which is the target of this map generator.
River: The river represents the fastest way of traveling between lanes, but of course comes at the cost of high risk of being assaulted by the opposing team.
Lanes: These must be traversed entirely in order to access the enemy base, meaning that a team is forced to destroy the towers of at least one lane in order to have a chance to win
Towers: These are placed along the lanes to provide defensive measures for each team. In the case of the outer turrets (the ones outside of a base), these are positioned in a way that will ensure that a player traveling between turrets will have to go through a red zone, thus giving the other team a chance of attacking. Green and yellow areas represent where the player can be near an allied tower and be the safest.
 |
| Danger zones near outer towers. |
Jungles: If we divide the jungles on the map by lanes and the river we end up with 4 sectors that contain the 4 jungles on the map. These jungles have very different paths but they all offer 3 specific roads that will be shown on the fitness functions section below.
After analyzing these aspects I realized something, the MOBA is, at the very core, just a game of attacking and defending turrets. We could get rid of the Ancient, bases and even the lanes, as long as there are turrets and ways of attacking and defending them effectively, the game would still be played as a MOBA. Through this reasoning I decided that I could take a lot of freedom modifying the composition of the map to my liking, but to not overscope the project, I decided to just focus on the generation of the jungles, which covers a big chunk of the map and modifying them haves great implications in the overall flow of the game.
Implementing the map generator
The objective then was to create procedurally a map that followed the design rules taken from Dota 2's. Everything would be procedurally generated, although only the jungle and river would change enough to have an actual impact on the game.
After doing some research on the best ways to create complex maps (contaning structures and a lot of constraints) I found 2 ways of doing this:
- Generating the map by chunks:
- Add a first random chunk
- Evaluate if all the chunks follow the rules defined. If they don't, go to step 4, else go to step 3. If the map is full this loop is terminated
- Add a new chunk and go to step 2
- Delete the last chunk added and go to step 3
- Generating the map randomly:
- Generate a complete map randomly
- Evaluate if it follows the rules defined. If not, go to step 3, else terminate the loop
- Create a new randomly generated map and go to step 2
The common genetic algorithm uses a fitness function to determine which of a set of candidates is better. Usually these algorithms iterate over this set of candidates making new generations and mixing their traits to imitate the behavior of genetics in nature.
Using a fitness function F1 we can evaluate if a candidate has a path connecting the points A and B, and therefore determine which candidates have this characteristic. But when using complex candidates (like the maps to be used in the game) where theres a lot of information that needs to be processed in order to determine if its a viable candidate, the fitness function becomes a bit messy.
To address this problem, I used whats called a Multi-Objective Evolutive Algorithm, which basically consists of using more than 1 fitness function to evaluate all the candidates. So we can still have the fitness function F1 doing it's thing, and we can add a fitness function F2 that evaluates if there are obstacles between the point A and B. As you can see, we are interpreting different information from the same set of data, which is exactly what I needed.
Candidates creation:
With the next pseudo-code you can see the process behind the creation of a map candidate:
The jungles are created using a fractal algorithm provided by the AccidentalNoiseLibrary and the camps of each jungle are placed near unwalkable areas where the size of the camps fit.
Fitness functions:
- Jungle roads: Each of the 4 jungles must guarantee that there exists:
- A road from the outer turret of the side lane to nearly 1/3 of the river
- A road from that point of the river to the center of the middle lane
- A road from the center of the middle lane to the starting point
 |
| The red lines represent the boundaries of the jungle. The roads must exist within these boundaries. |
- Camps difference: The difference between the amount of camps on the 2 jungles on each side of the map mustn't exceed a certain threshold
Displaying the map:
After having selected the best candidate according to the fitness functions defined, the drawing process begins:
- A Bezier curve is drawn between each control point outlining the river to make a nice and smooth river.
- The intersection points between the 3 lanes is placed near the diagonal of the map. The position of each base is placed and then the lanes and bases are drawn.
- Using the intersection points of the lanes and the position of the bases, 4 triangles are drawn that represent the boundaries of each of the 4 jungles. Inside these triangles, the fractal algorithm draw the roads.
- The camps are drawn according to their positions.
- Trees are placed along the green or unwalkable areas.
- Structures are placed and the game can begin.
 |
| Sample map generated procedurally. Yellow dots are the camps and green areas are unwalkable. |
Well, that's a really brief explanation of the whole process I used to make the map of a MOBA game be generated procedurally. On Part 3 I'll be explaining the implementation of the Character Adaptation System.
Thanks for reading!
Subscribe to:
Posts (Atom)