I went and corrected some bugs and UI quirks that were present in the original seven day version.
Also, display font and text size can now be changed via a properties file.
Download here (choose the v1.2 package).
UPDATE: Alright, I screwed up. I left my debug hi-score in the 1.2 package. :( Consider this mistake fixed.
Monday, March 18, 2013
Sunday, March 17, 2013
7DRL Success!
Once more, I triumph! I've successfully completed my 7DRL.
Download coming up really soon, I'm packing up everything for upload right now.
UPDATE: It's now available here!
UPDATE 2: Bugfix version available. It's in the same place as the original version.
UPDATE 3: Now with screenshots.
Download coming up really soon, I'm packing up everything for upload right now.
UPDATE: It's now available here!
UPDATE 2: Bugfix version available. It's in the same place as the original version.
UPDATE 3: Now with screenshots.
Sunday, March 10, 2013
7DRL 2013: hproguelike
As they say: "It's never too late to fall in love. And with love I mean the endless void."
I've just announced (and started) work on my 7DRL for this year. Updates will be posted to the community blog 7drl.org.
I've just announced (and started) work on my 7DRL for this year. Updates will be posted to the community blog 7drl.org.
Saturday, March 2, 2013
House Cleaning
It's been a while since my last post. There have been some changes to my plans.
MagmaHack has been discontinued, and I've pulled it from the page. To be honest, I have failed utterly. The existing code, with its horribly flawed architecture, heavy reliance on libjcsi and sluggish performance was in no way acceptable. Since a complete re-write would have been necessary, and my motivation to work with this language and library has decreased considerably in the meantime, I've decided to let the project die.
However, my basic intentions for the project still remain, and will form the base for my next attempt. We'll see how that one fares. I have high hopes.
As the 7DRL Challenge of 2013 approaches, I find myself in the same position as last year: Without an idea and without existing code to plunder. This will be interesting. :p
MagmaHack has been discontinued, and I've pulled it from the page. To be honest, I have failed utterly. The existing code, with its horribly flawed architecture, heavy reliance on libjcsi and sluggish performance was in no way acceptable. Since a complete re-write would have been necessary, and my motivation to work with this language and library has decreased considerably in the meantime, I've decided to let the project die.
However, my basic intentions for the project still remain, and will form the base for my next attempt. We'll see how that one fares. I have high hopes.
As the 7DRL Challenge of 2013 approaches, I find myself in the same position as last year: Without an idea and without existing code to plunder. This will be interesting. :p
Wednesday, August 22, 2012
How to brainstorm enemy creature types
The Maguana Mace menaces with spikes of iron.
Just recently, someone asked on RogueTemple for enemy names and types. I wasn't able to contribute a lot, but tried to outline how my creative process usually works when I try to come up with cool enemy types. I tend to get weird ideas at the most impossible hours of the day, mostly after obsessing about some weird stuff I've read or seen. Good SciFi is helpful (lots of weird aliens), but I've had great ideas from reading biology articles, too.
I ended the post I wrote in response of said roguetemplar with a short collection of ideas I'd come up with on the fly. Someone had mentioned magma-dwelling salamanders and creatures looking like rocks, and I just threw some stuff together that might fit the theme, to show how easy it is to come up with at least partly original stuff once you have a basic idea to work from.
I've included my full post here; if you don't care for creating interesting enemy types feel free to skip it.
Just recently, someone asked on RogueTemple for enemy names and types. I wasn't able to contribute a lot, but tried to outline how my creative process usually works when I try to come up with cool enemy types. I tend to get weird ideas at the most impossible hours of the day, mostly after obsessing about some weird stuff I've read or seen. Good SciFi is helpful (lots of weird aliens), but I've had great ideas from reading biology articles, too.
I ended the post I wrote in response of said roguetemplar with a short collection of ideas I'd come up with on the fly. Someone had mentioned magma-dwelling salamanders and creatures looking like rocks, and I just threw some stuff together that might fit the theme, to show how easy it is to come up with at least partly original stuff once you have a basic idea to work from.
I've included my full post here; if you don't care for creating interesting enemy types feel free to skip it.
Wednesday, August 8, 2012
Critical Hits in Deterministic Combat Systems
The ork hacks you critically in the common sense with his axe of nondeterminism and the severed part flies off in an arc! You have been struck down!
I'm a big fan of deterministic combat systems. As some have pointed out, the origin of non-deterministic systems were pen&paper RPGs, where all of the dice rolls were clearly visible and actually part of the fun. In most roguelikes, though, they aren't visible anymore. Even worse, some games have adopted complex systems which are extremely hard to understand and - again in contrast to many p&p RPGs - unpredictable if you don't go source-diving. The whole fun of deterministic systems is that you can always predict what's going to happen, which encourages planning ahead and recognizing game-critical moments before they happen.
There's one mechanic, though, that plays an important role in classic and contemporary roguelike games, and that's the concept of a critical hit. ToME4, for example, clearly tells you your chance to crit and offers you many ways of directly improving your crit rate, as well as improving the consequences of such a hit.
The nature of the critical hit system, one might infer, is inherently non-deterministic, and impossible to transfer to a deterministic system. However, I'd like to show a few ways how this mechanic could be adapted to a deterministic system by a developer who cares for it.
Guaranteed Minimum Damage: One (admittedly unclean) possibility would be to set a random crit system on top of a combat system that in itself is deterministic, thus guaranteeing a lower bound of dealt damage. This model treads a fine line between full predictability and full unpredictability, and it is the decision of the developer whether it guarantees enough predictability to be fun.
Critting as action: At a certain point in combat, the player might decide to attempt a critical hit instead of a standard hit. Since the critical hit system here is deterministic, the crit chance must be based on some clearly visible number or formula. This leads to the problem that the player, provided he has access to information about his enemy, will always know whether a crit attempt will succeed. Thus, we must find a way to keep the player from constantly critting the enemy. A nice way to do this would be a combo point model, which at the same time could be used to scale the critical hit in terms of damage. A similar system is used by ToME4's brawler class - the effectiveness of finishing moves is dependent on the generation of combo points generated by combat. The tactical option presented to the player would be the question whether to spend his points on a critical hit or fight on and do a more powerful critical hit later on in the fight. Depending on how much information about the enemy the player knows, this model is more or less fun.
Saving up for a crit: The player might save up his energy for a single, well-aimed strike. This most likely implies the existence of an action like "aim", or in the case of a spellcaster, "charge", which replaces one turn of attacking or moving. These are just examples for how one might present this mechanic to the player. The problem of crits either happening during the entire fight or not at all does not exist in this model. Of course one should take care that saving up energy is only done to a limited degree out of combat, so that the player can't save up for a Quadruple Uber Strike of Greater Doom while hiding cowardly in a corridor far away from the enemy.
Crit depending on enemy status: This is mainly based on the idea of combat consuming a resource, say HP or stamina or armor. Once a certain damage has been done to such a resource, the player might be allowed to land a critical hit instead of a normal hit. The main problem with this model is that it acts much like a body-part model: Once you're past a certain point, you've already lost although you're not completely dead yet. I personally don't think this is a very good approach, but some people might find it interesting.
In summary, I personally think critical hits in deterministic systems work best when they require some effort on the player's side to land. Feel free to disagree and tell me why. :)
I'm a big fan of deterministic combat systems. As some have pointed out, the origin of non-deterministic systems were pen&paper RPGs, where all of the dice rolls were clearly visible and actually part of the fun. In most roguelikes, though, they aren't visible anymore. Even worse, some games have adopted complex systems which are extremely hard to understand and - again in contrast to many p&p RPGs - unpredictable if you don't go source-diving. The whole fun of deterministic systems is that you can always predict what's going to happen, which encourages planning ahead and recognizing game-critical moments before they happen.
There's one mechanic, though, that plays an important role in classic and contemporary roguelike games, and that's the concept of a critical hit. ToME4, for example, clearly tells you your chance to crit and offers you many ways of directly improving your crit rate, as well as improving the consequences of such a hit.
The nature of the critical hit system, one might infer, is inherently non-deterministic, and impossible to transfer to a deterministic system. However, I'd like to show a few ways how this mechanic could be adapted to a deterministic system by a developer who cares for it.
Guaranteed Minimum Damage: One (admittedly unclean) possibility would be to set a random crit system on top of a combat system that in itself is deterministic, thus guaranteeing a lower bound of dealt damage. This model treads a fine line between full predictability and full unpredictability, and it is the decision of the developer whether it guarantees enough predictability to be fun.
Critting as action: At a certain point in combat, the player might decide to attempt a critical hit instead of a standard hit. Since the critical hit system here is deterministic, the crit chance must be based on some clearly visible number or formula. This leads to the problem that the player, provided he has access to information about his enemy, will always know whether a crit attempt will succeed. Thus, we must find a way to keep the player from constantly critting the enemy. A nice way to do this would be a combo point model, which at the same time could be used to scale the critical hit in terms of damage. A similar system is used by ToME4's brawler class - the effectiveness of finishing moves is dependent on the generation of combo points generated by combat. The tactical option presented to the player would be the question whether to spend his points on a critical hit or fight on and do a more powerful critical hit later on in the fight. Depending on how much information about the enemy the player knows, this model is more or less fun.
Saving up for a crit: The player might save up his energy for a single, well-aimed strike. This most likely implies the existence of an action like "aim", or in the case of a spellcaster, "charge", which replaces one turn of attacking or moving. These are just examples for how one might present this mechanic to the player. The problem of crits either happening during the entire fight or not at all does not exist in this model. Of course one should take care that saving up energy is only done to a limited degree out of combat, so that the player can't save up for a Quadruple Uber Strike of Greater Doom while hiding cowardly in a corridor far away from the enemy.
Crit depending on enemy status: This is mainly based on the idea of combat consuming a resource, say HP or stamina or armor. Once a certain damage has been done to such a resource, the player might be allowed to land a critical hit instead of a normal hit. The main problem with this model is that it acts much like a body-part model: Once you're past a certain point, you've already lost although you're not completely dead yet. I personally don't think this is a very good approach, but some people might find it interesting.
In summary, I personally think critical hits in deterministic systems work best when they require some effort on the player's side to land. Feel free to disagree and tell me why. :)
Thursday, July 12, 2012
Races & Classes - a design challenge
Shall I pick a character for you? [ynq]
If you were never asked to pick a race and class in any roguelike, you probably haven't played a lot of them. This approach allowing for different playing styles is present in many games, and the subject of regular criticism. For example, it has been pointed out (by Andrew Doull) that vertically partitioning player abilities across classes is often a waste of mechanics. The advantages and disadvantages of class-based systems are much-discussed and I don't really feel the need to restate what others have said on this subject. Instead, I'd like to focus on race/class combinations here.
Firstly, how are races differentiated from each other? Many roguelike games do this by giving their races affinities for different combat abilities. Dungeon Crawl Stone Soup, for example, features so-called aptitudes for various melee weapons, spellcasting schools, ranged combat etc. Nethack gives them different stat spreads.
This leads to a more or less predictable effect: Some combinations have higher chances for winning than others. Players often describe the easiest combinations as "beginner strategies", implying that they are overpowered or just not challenging/interesting enough for a more seasoned player. Unfortunately, it also often leads to the existence of very underpowered combinations. Why would anyone ever want to play a troll wizard if trolls have an abysmally low magic stat? Why would you choose to play a race/class combination in which your race is reducing the capabilities of your class? Only if there was something else that made them attractive. Both in Crawl and Nethack, there are additional racial features that may alleviate racial penalties. For most of these underpowered combinations, this doesn't really result in any additional survivability. Consequently. Crawl explicitly marks them as not recommended, and Nethack even removes some combinations entirely. In-universe this might make sense. Your game might be set in a fantasy universe where elves are feeble and dwarves are stupid. Thus, you might want to forbid the existence of elf fighters, or dwarf mages, or whatever. However, from a gameplay point of view, there's a lot of gameplay potential that's just plain wasted.
What if races had something to offer for all classes? Take the example of ToME4. The dwarves, the race with the highest magic penalty in the game, are a popular choice for archmages precisely because of their high constitution and saves. ToME4 defines races not just via stat bonuses and penalties, but also via their racial talent trees. Another example highlighting this is the Shalore race: These elves have the highest magic bonus in the game, make excellent archmages. But ironically, Shaloren Berserkers used to be very powerful because of one of their racial talents, and despite their strength penalty.
I think this approach has some merit. Imagine a race/class model, where all combinations are equally playable. Where the choice of your race does not limit your choice of class, and vice versa. Of course, there could still be beginner options and expert options, but they would be this by design. I haven't really seen a roguelike game that implements such a model (ToME4 has or at least used to have its own problems with classes themselves having balance issues) and my own experiments are immature enough to not be a good proof of concept.
Subscribe to:
Posts (Atom)