Minecraft Legends
|
The Game
Minecraft Legends is a unique action strategy game. It is a 3rd person, open-world co-op Real Time Strategy game with elements of other genre (tower defense) sprinkled in to create a brand new kind of experience.
The game received very polarizing reviews due to its nature, and I'm quoting from the positives:
|
My Role
I was a senior game designer on the project. The project was incredibly unique - there were no other open world co-op RTS to draw from, so we had to try out new things constantly to see what works in a new genre. All the scripting here was done in a custom language - a variation of Javascript we called B#.
1. I was the product owner of the survival/tower defense sections of the game: village defence. Players could build multiple "bases" (villages), each of which gave resources - so depending on meta-game state and plan (which enemy base they want to attack next), players would have to decide which bases to maintain and update. Dependent on the overall game-state, villages may get attacked at night. Players could stay in certain bases to defend directly (build structures, maintain and command armies to fend off waves of attacks), or hope their reinforcements can fend it off. I was respoonsible for both the on-screen and off-screen simulation (wrote the algorithms to do players midway-joining an attack and damage calculations as well). The game factored in all this since when multiple bases get attacked together late-game players would have to decide which ones to defend directly and which ones to reinforce and leave.
2. I was brought onto the quest team when it was just forming - with only another designer there at that point. I came to be in charge of the Horde Of The Hunt, one of the three enemy factions in the game, and used it as the platform to set tech design and scripting standards for all the factions, that other designers would follow. The defining trait of this faction is constant aggression and almost no defence. I wrote the algorithms to procedurally generate the bases - one of the challenges we faced was actually not having much defence in the base, and so we had to come up with environmental hazards (lava, fire damage) in the base itself, instead of leaning heavily towards structures or terraforming like the other factions. I did all the encounter scripting for this faction as well - how bases would strategize, how they would send out groups, how their roaming bases and caravans would behave. I set the scripting standards used by other factions as well.
3. I was heavily involved with encounter AI design, and we went from purely scripted responses earlier on (a structure was attacked, send x% of units depending on priority) to a more calculated system I created with the engineers - which we called the "Rallyman" system. It aimed at creating certain rally points with "ideal" compositions for enemies. Depending on unit generation, the bases would try to fill up these rally groups with the desired compositions (compositions would be for "light patrol", "heavy defence" etc. - however we defined). We wrote the modular system entirely in Javascript (B#). This worked much better and particularly at grouping units, but it was still reactive and not proactive, so by the end of the project, we added a heatmap-based system to complement this. Groups would go towards where the "heat" is, and heat could be generated in a multitude of ways (by the player existing, player's units in range, units attacking buildings due to priority, units getting attacked etc.) and collectively "heat" would dictate the reactions of rallies. The Horde of the Hunt was primarily the testing ground for most of these systems, and I was at the forefront of designing and implementing them - working closely with other quest and CCC designers and engineering.
4. I was the owner of the "invasion" meta-game system till we hired a meta-game designer (and I had to focus more on the survival gameplay bits). I continued to own technical implementation for it alongside another engineer. This is the system that decided how factions reacted at the world scale. Factions could either build a new base, upgrade their existing base, or attack a player's base or outpost. This depended on the game state and the "game board" - we used to call the world map the "game board" in this sense (Image below). This system was essentially the game difficulty balancing, and we had to try out many, many approaches here - since there were no parallels to this. I worked with another engineer to formulate the testing plan and the automated algorithms to test this as well - where I could script to simulate this is what the game state could look like in a few cycles with certain player and faction actions, which was very important for testing. We used it to target game length and tuned accordingly.
1. I was the product owner of the survival/tower defense sections of the game: village defence. Players could build multiple "bases" (villages), each of which gave resources - so depending on meta-game state and plan (which enemy base they want to attack next), players would have to decide which bases to maintain and update. Dependent on the overall game-state, villages may get attacked at night. Players could stay in certain bases to defend directly (build structures, maintain and command armies to fend off waves of attacks), or hope their reinforcements can fend it off. I was respoonsible for both the on-screen and off-screen simulation (wrote the algorithms to do players midway-joining an attack and damage calculations as well). The game factored in all this since when multiple bases get attacked together late-game players would have to decide which ones to defend directly and which ones to reinforce and leave.
2. I was brought onto the quest team when it was just forming - with only another designer there at that point. I came to be in charge of the Horde Of The Hunt, one of the three enemy factions in the game, and used it as the platform to set tech design and scripting standards for all the factions, that other designers would follow. The defining trait of this faction is constant aggression and almost no defence. I wrote the algorithms to procedurally generate the bases - one of the challenges we faced was actually not having much defence in the base, and so we had to come up with environmental hazards (lava, fire damage) in the base itself, instead of leaning heavily towards structures or terraforming like the other factions. I did all the encounter scripting for this faction as well - how bases would strategize, how they would send out groups, how their roaming bases and caravans would behave. I set the scripting standards used by other factions as well.
3. I was heavily involved with encounter AI design, and we went from purely scripted responses earlier on (a structure was attacked, send x% of units depending on priority) to a more calculated system I created with the engineers - which we called the "Rallyman" system. It aimed at creating certain rally points with "ideal" compositions for enemies. Depending on unit generation, the bases would try to fill up these rally groups with the desired compositions (compositions would be for "light patrol", "heavy defence" etc. - however we defined). We wrote the modular system entirely in Javascript (B#). This worked much better and particularly at grouping units, but it was still reactive and not proactive, so by the end of the project, we added a heatmap-based system to complement this. Groups would go towards where the "heat" is, and heat could be generated in a multitude of ways (by the player existing, player's units in range, units attacking buildings due to priority, units getting attacked etc.) and collectively "heat" would dictate the reactions of rallies. The Horde of the Hunt was primarily the testing ground for most of these systems, and I was at the forefront of designing and implementing them - working closely with other quest and CCC designers and engineering.
4. I was the owner of the "invasion" meta-game system till we hired a meta-game designer (and I had to focus more on the survival gameplay bits). I continued to own technical implementation for it alongside another engineer. This is the system that decided how factions reacted at the world scale. Factions could either build a new base, upgrade their existing base, or attack a player's base or outpost. This depended on the game state and the "game board" - we used to call the world map the "game board" in this sense (Image below). This system was essentially the game difficulty balancing, and we had to try out many, many approaches here - since there were no parallels to this. I worked with another engineer to formulate the testing plan and the automated algorithms to test this as well - where I could script to simulate this is what the game state could look like in a few cycles with certain player and faction actions, which was very important for testing. We used it to target game length and tuned accordingly.
5. I initially joined the team as a World Designer. I was responsible for 3 of the biomes (Fatelands, Jungle, Badlands) at that point of time, tuning how they were generated to get the correct topography in a completely procedural proprietary terrain generation system. Fatelands (the Well Of Fate) was the one I did from the start, and one of my favorite contributions there was to write the script to generate those flower patterns near the Well Of Fate (pic below). I set scripting standards here as well. After this, I was moved to the Quest Team when they were spinning up the team to help set up scripting there, since that was more technically demanding.
