This is a project that I’ve been spending the past 4 months working on in my free time outside of my day job. It’s still FAR from completed, but I feel like I’ve made enough progress on it to finally show it off. As you can probably tell, most of the art assets that I’m using are just placeholder ones for right now, since nearly all of my time has been spent on making the gameplay mechanics function. My goal is to make a short, playable demo and try to fund the game through crowdfunding sites like Kickstarter or GoFundMe so that I can quit my retail job and work on this full-time.

Zein is going to be a 2D turn-based roguelike fantasy RPG where the player must travel across a procedurally-generated world, assemble a party of distinct characters, and vanquish several evil abominations to save the world. The game overworld is a 3D hexagon grid with different region tiles, and the combat encounters are shown in a rectangular 2D grid. The inspiration for this game came from a comment that one of my game design teachers said a few years ago about a lot of “Lord of the Rings” games. He said that it’s really difficult to do the games well, because if you adhere to the plot in the books/movies, the player will never be surprised by anything, but if you divert too much from them the fans will dislike it for being non-cannon. Since I was just starting to get into the roguelike genre of games at the time, I had the idea that making one that captured the feeling of a story like “Lord of the Rings” but wouldn’t have to stick with the same characters or setting the whole time. I’ve also taken a lot of inspiration from the “Dungeons & Dragons” and “Pathfinder” tabletop games in regards to how combat encounters play out, but more on that later.

So far, I’ve been spending the most amount of time building a lot groundwork for gameplay mechanics, characters, and items so that when everything is more fleshed-out, I can create and iterate extremely quickly. One of the big mechanics that I’m still polishing is the map generation for the overworld. I have different types of land tiles and regions, each of which can be customized to have different enemy encounters and loot. I created a few algorithms that let me generate large, blotchy areas or lines of the same type of region tile. This works surprisingly well on a large scale to create a map that looks like a country, but I’m having a problem implementing it correctly on a smaller scale. The issue that I’m seeing is that I need to somehow design a way to rank each region in terms of difficulty and write another algorithm to position the regions in a way that will scale with player progression while also looking like it isn’t a random collage of tiles.

All of the player characters and a fair number of enemies are all built off of the same base character object, since they all require the same component scripts. This makes it really simple to just adjust all of the public variables for the characters to create radically different characters. Along with the character architecture components, I’ve also made gameplay UI panels that track their conditions for everyone in the player’s party. There’s a scrollbar that displays how good at each skill the characters are, which includes their proficiency with different weapons and magic types. I have a page that shows some physical characteristics about them (the ones that can’t be seen in the combat screen). The same page also shows how hungry, thirsty, and tired they all are. If any of those stats get too low, their overall energy level will drop, which hinders their speed and strength in combat, as well as cause damage if it goes on for too long. The Inventory system that I have set up is also drag-and-drop, so it’s a simple task to rearrange weapon and armor loadouts between party members.

As for my combat system, I’ve tried to make it a hybrid of early “Final Fantasy” games, “Fire Emblem”, and “Dungeons & Dragons.” When a combat encounter begins, all player characters are placed onto the tile grid (as shown above). The positions can be rearranged using the combat position UI so that the player can fight at range, in close quarters, or somewhere in the middle. Enemy encounters also have their own preferred combat distance, which can also make it so that the player party is flanked.

After that, each character has an initiative meter that fills up based on their initiative speed and their energy level, similar to how earlier “Final Fantasy” combat handled player turns. I’m still working on how the enemy AI will work, but at the moment I’m trying to base it off of the enemy threat system that “World of Warcraft” has, but with some more fine-tuning. When a player character’s turn happens, the actions panel pops up and displays all of the actions that they can perform based on their types. I’m very proud of how I designed this system, because it’s extremely modular.

Every action is a game object that can be created and made into a prefab within a minute. The actions can either be given to characters to use whenever they want, or can be attached to items that they’re holding and swapped out. Because all of the different action types inherit from the parent Action.cs script, it’s easy to cycle through each character at the start of combat, find every action object, and sort them based on what type of action it is. This way, I don’t need to make my combat manager handle EVERY different action that abilities could perform. Instead, each action type is handled using methods they’ve inherited from the parent script and the combat manager just hands off functionality to it. If I need to balance or change abilities for whatever reason, all I need to do is go to the saved prefab and modify the action with a few quick clicks. Because of how versatile the actions can be, I’ll be able to make all sorts of abilities for players to use, which is how I love to play games like “Dungeons & Dragons.”

Hopefully Zein will gain some traction when I put it up on the crowdfunding sites next month, but even if it doesn’t I’ll still be working on it in my free time. I’ve had this idea in my head for a few years now, and whenever I tried to start working on it before, I didn’t know where to start and how to make a lot of the systems. Now that I’ve had a couple years of practice as a mechanics designer, it’s a lot easier for me to break those harder tasks down into manageable ones. I’ll also try to post updates every few weeks of my progress.