Temple of The Roguelike Forums

Development => Design => Topic started by: SomeGuy on June 08, 2015, 12:24:30 PM

Title: Roguelike mechanics idea
Post by: SomeGuy on June 08, 2015, 12:24:30 PM

I'm starting to design a new roguelike, and I have been thinking about the game mechanics before starting coding anything.

The game will require some degree of strategy from the player to be successful. Losing the game will be due to the player commiting many smaller errors, so it is possible for the player to realize that something was done wrong, and mend the error.

Let me explain what I have planned so far, and give me your oppinion and which things would you change.

First, the game is about a mage which has been trapped in a dungeon/dymension/cave/castle/whatever. He must climb to the top floor and find the portal back to home.

At first sight, the game will be slightly based on Drakefire Chasm in what there are several elements (fire, ice, lightning, whatever) and each enemy is resistant or weak against a certain element, but the player won't know this information first hand, since the enemies' names will be "frenzied zombie" instead of "fire zombie". In this case, this will be a zombie made of fire, so it is resistant (or immune) to fire spells, then, the player will have to adapt to that type of enemies.

The player can only attack using magic attacks. There won't be close combat at all. And magic is organized in different schools of magic, and increasing your proficiency on a specific school will give you more spells (not necesarily more damaging spells), so, lets say, you increase your fire magic proficiency, you will get fireball, fireblast, but also utility and buffing spells.

The schools of magic are organized in such a way that increasing a certain school will decrease the opposite one.
For example, increasing Fire will decrease ice, and increasing death will decrease life, and the other way around.

This may look a bit counterproductive if you are full fire and you find a fire-immune enemy. Well, actually, the game will provide two methods to avoid this:

1.- The game will reward the player when creating an hybrid class. For example, increasing Fire could grant access to utility spells that increase ice damage, so even your low level ice spells may deal good damage. It is basically a synergy system, that may reward players that are 50% fire and 50% ice rather than 90% fire and 10% ice.
For example, lets say the maximun school proficiency is 10. It may be possible that fire level 5 will provide a utility spell that absorbs heat from enemies greatly reducing their resistance to ice. Or a level 5 Ice spell which may see its damage increased by 100% if the player has certain fire buff that is also a level 5 fire spell.

2.- After completing each level, the player will be able to redistribute or change the spells proficiency, so s/he can try different builds which can match his/her playing style. But changing proficiencies doesn't come for free: along the level the player will find mastery orbs/scrolls/jewels/... that will allow to change assigned points. One orb/scroll/jewel/... will be consumed when you reassign a mastery point. Of course, these orbs will rather easy to find, but won't be as easy as letting the player to completely rebuild the all of the proficiencies each level. The player must decide either to continue with the current build and save orbs for later, or keep doing small changes.

Now, when enemies attack, there won't be a random dice throw to check if they hit, or even for calculating damage.
Combat will be deterministic, and the way in which the player builds the character will have a lot of weight in combat.

First, the same as enemies, the player will have resistances to different schools of magic. These resistances change when the player increases the mastery of his/her magic proficiencies in each school.
For the player, resistances will be granted to the opposite school of magic that is mastered. For example, increasing Fire, will increase Cold resistance.

So, in this aspect, the game is rewarding pure builds rather than hybrid. A full fire build will be immune to ice, but will receive full damage from fire attacks.
Of course, hybrid builds will have some benefit, such as buffs that slightly increase your resistance to a certain element.

Combat mechanics, as I mentioned before, will be deterministic.
Spells will deal a fixed amount of damage. Or maybe wil deal random damage in a set range, such as 10 - 20.
Spells from both, player and enemies, will always hit their target, but damage will be reduced according to resistances.

Now, how do you increase your proficiencies? I didn't thought too much about this but I have three possibilities: either give 1 proficiency point at the end of each level, OR allow the player to find "proficiency scrolls" that will increase proficiency in a certain school or magic, OR my prefered one, increase proficiency when you use spells of such school, making each time harder and harder to increase that school. Something like a experience but for each school of magic.

Now about the "mana system". There won't be "mana" as is, but rather, an "overcharge" system. Let me explain: we will have one "overcharge bar" per each school of magic. Casting spells of such school of magic will fill its corresponding bar for a certain amount (more powerfull spells will fill more). The more filled the bar is, the more powerful the spells of such school will become.
For example, fireball may deal 10 - 20 damage, but that damage will be increased by 1 per each point of "fire overcharge", so if "fire overcharge" equals 20, then fireball will deal 30 - 40. BUT, if the fire overcharge bar reaches its limit, the player won't be able to cast fire spells anymore.
After a set duration, the bar will fully empty.

About the overcharge system, if the bar is not full, you can decrease it a little bit by casting spells of the oposite school of magic.
Of course, the amount reduced will be small, so situations like "infinite mana" won't be possible. It is more like a delaying a filled bar, letting the player to develop a good strategy.

So far, that is what I have been thinking so far.
Any thoughts?
Title: Re: Roguelike mechanics idea
Post by: guest509 on June 09, 2015, 12:39:43 AM
Do you have a link to the game?
Title: Re: Roguelike mechanics idea
Post by: SomeGuy on June 09, 2015, 11:29:03 AM
Do you have a link to the game?

Have you read the title of the topic and/or beyond the first line of my message?
Title: Re: Roguelike mechanics idea
Post by: guest509 on June 09, 2015, 06:07:00 PM
The point being that until you see it in an .exe it's nearly impossible to comment on or give feedback. Especially when presented as a wall of text.

Ideas are funny like that. Every idea is dynamite, awesome. Your ideas above sound awesome, but how it works out in play is the only thing that matters. When I first started making games I had to learn this, took a few years. Ideas are super fun to toy around with, design concepts are great, I have hundreds of documents devoted to various ideas and mechanics. Play testing is the only way to know if they are fun or interesting or workable.

In board game making a common design rule is to not even bother writing down a mechanic unless you've play tested it. It's a waste of time. That's a bit extreme, but the concept holds. Play test first. Play test often.

You might get people commenting on this idea or that if they are presented in a simple way, we all like ideas or we wouldn't be designers. You'll not likely get much feedback with this big wall of text, but more limited questions will garner at least something.

However, no feedback is of real value at the idea stage. Any feedback would be based on how one imagines things might work, which is different than how you imagine it will work and is totally different than how it will actually work.

Krice saw fit to give me this lesson years ago when I posted an idea, which I actually turned into a game. He was much more of a dick head about it, as you can imagine if you've seen him post.

Don't be discouraged. We'll be around if you have a concept to test.