http://roguebasin.com/api.php?action=feedcontributions&user=Harblcat&feedformat=atomRogueBasin - User contributions [en]2024-03-28T23:08:39ZUser contributionsMediaWiki 1.36.0http://roguebasin.com/index.php?title=Talk:Thoughts_on_Combat_Models&diff=14790Talk:Thoughts on Combat Models2009-02-15T06:05:31Z<p>Harblcat: typo</p>
<hr />
<div>All these possibilities look very nice, but what are the differences? We need to have some more in depth study what the different variants do, and what the consequences of each choice are. For example:<br />
Enemy.HP -= min(Player.ATK - Enemy.DEF, 0);<br />
this variant makes your enemy always immune to attack if their def > atk.<br />
<br />
I think that ideally you would like to have systems that have bell curves of damage and chances to hit. But these subjects are not even considered here. Currently the page is just a list of different systems that you can use without any consideration why or how. Any ideas what more could be included here? --[[User:Soyweiser|Soyweiser]] 15:45, 4 August 2008 (CEST)<br />
<br />
My program is already designed to have chances to hit, but I'm not planning for bell curves for damage. I have thought about bell curves to hit in many other older programs as well. This is a example of a bell curve program in QBASIC:<br />
c1# = 2.506628#<br />
c2# = .3193815#<br />
c3# = -.3565638#<br />
c4# = 1.7814779#<br />
c5# = -1.821256#<br />
c6# = 1.3302744#<br />
IF z# > 0 OR z# = 0 THEN<br />
w# = 1<br />
ELSE<br />
w# = -1<br />
END IF<br />
y# = 1 / (1 + .2316419# * w# * z#)<br />
z3# = (c4# + y# * (c5# + y# * c6#))<br />
z2# = (y# * (c2# + y# * (c3# + y# * z3#)))<br />
z1# = .5 - (EXP(-z# * z# / 2) / c1#) * z2#<br />
BellCurve# = .5 + w# * z1#<br />
--[[User:Zzo38|Zzo38]] 18:42, 4 August 2008 (CEST)</div>Harblcathttp://roguebasin.com/index.php?title=Permadeath&diff=14764Permadeath2009-02-12T09:58:58Z<p>Harblcat: Tiiiiiiiny s/wont/won't</p>
<hr />
<div>== Definition ==<br />
<br />
'''Permadeath''' (short for '''permanent death''') is one of the [[Definition|main features]] of roguelikes. It consists in the fact that once your character dies in the game, you can't restore him to a previous status via save-files or save-states. This means that once your character dies, he is dead for good.<br />
<br />
Although the feature is commonly referred to as "Permadeath", it applies not only to death: whatever bad (or good) thing happens to your character, you cannot go back in time. (One exception: roguelikes should allow the player to restore character if the game crashes due to a bug or external reason.)<br />
<br />
The idea may scare people from other RPG genres, such as console and common "plot" RPGs, as it is common custom to reload the game after something bad happens to the main character or his party; however, this feature makes roguelikes unique, demanding all your attention and thinking your best moves because the life of your character must be kept.<br />
<br />
There are only a few roguelikes that lack permanent death, see ''[[Alternatives to Permadeath]]''.<br />
<br />
== Description ==<br />
<br />
Permadeath is not as horrible as it might sound at first. The design of roguelikes is built around this concept. This is one of the reasons why they tend to be light in plot. Unlike an RPG, where starting over can involve doing the same hundred page conversation over again, a roguelike presents you with fresh challenges every game. Some other traditional roguelike features, like hidden [[trap]]s and requirement to identify [[potion]]s, also make more sense with permadeath.<br />
<br />
As a good example of a game feature which makes more sense with permadeath, [[ADOM]] has pools which you can drink from. Every time you do, you get a random effect, which can be good or bad. For example, you have a small chance (1%) of getting a wish, which is a very good thing. It is also possible (with chance, say, 10%) that the pool will dry up, making you unable to drink from it anymore. By saving the game after getting each wish or another good effect, and reloading the game each time the pool dries up or you get something unpleasant, you could easily get all the good effects and as many wishes as you want from a single pool. Permadeath makes sure that the pool is unpredictable as it was supposed to be: you have a chance to get a wish or even several wishes, but you also have a chance to become doomed. Some players will instantly drink from each pool they come across, some players will wait with it until their character will be able to overcome any potential bad effects, and some will decide to never drink from pools for fear of their bad effects. Similar features exist in other roguelikes, like [[NetHack]] and [[IVAN]].<br />
<br />
Of course, roguelikes have saving facilities that allow long games to be played for several days, weeks or even months; but the save-file is deleted upon the death of the character.<br />
<br />
The Permadeath can usually easily be avoided via backup of save files, however this is widely considered as cheating, and not the right way of playing the games. Using backups of save files is known as [[Savescumming]].<br />
<br />
Some argue, that Permadeath is just a obsolete heritage from systems that couldn't handle proper save/load, that it is taking away the freedom of the player to play with the game, yet the concept has still a strong support in the roguelike world.<br />
<br />
== Advantages ==<br />
<br />
Some commonly accepted advantages of permadeath are:<br />
<br />
* It produces the feeling of responsibility&mdash;you will be responsible for your actions. If you fail on a quest, it's all your fault and you have to live with it. If you attack a friendly and he dies&mdash;you will suffer the consequences. The player is more attached to his character, for he knows he may lose him. This increases immersion.<br />
* It produces the feeling of anticipation/fear&mdash;will you win? Or will you not? If I go into those caves now it might be the end of me, if I attack that dragon will I stand a chance? If not these 2 weeks of playing will be lost! Again&mdash;it increases the immersion.<br />
* It cautions the player against doing stupid actions&mdash;the player will play more realistically, won't go for unnecessary risks, and hence feel that the world is more real&mdash;immersion.<br />
* It makes the game harder&mdash;if you fail at a task after playing for a while, you need to cope with it, and try to rise back. What means that you will face more challenges. And feel more satisfaction if you win&mdash;for you know you could lose and have to live with it. The reward for the player when winning is hence a lot bigger&mdash;a lot more satisfaction.<br />
<br />
== Permadeath in other genres ==<br />
<br />
The permadeath concept may be excellent and accepted within the roguelike genre, but it wont work with every game. It might however work great with Civilization-type games, in which you can suffer setbacks as well as victories. <br />
<br />
Generally Permadeath may work with games in which:<br />
<br />
# There are not sudden-death situations -- because if they do, then permadeath makes the game really frustrating (some roguelikes suffer from this)<br />
# There are many options of failure that do not lead to lose the game -- failures are very interesting, for they provide a challenge. In roguelikes non-death failures are for example losing a valuable item to a monster attack, getting your levels drained, etc.<br />
# The is enough balance to assure that the failures do not mean game over. If one failure would mean that you don't stand a chance in the rest of the game then it would in fact be a game over, thus violating the sudden-death rule. <br />
<br />
Permadeath would probably be a bad idea in FPS games, as these games violate all of the above requirements. RTS's on the other hand, are fine in mission-scope, but violate the rules in campaing scope; however, if the campaign had a branching system (in which for example if you lose a mission you go to another mission, and if you win, you advance to another mission), then they would work really well, and it would gain a lot of replay value by the way. The branching feature wouldn't work at all with save/load because the work spent on all those missions that are not on the all-win path would be wasted, as most players would load each time they had lost a mission. <br />
<br />
Some games, although not permadeath by nature, are reported to be played without using the save/load features for the sake of challenge, some games that would fit such requirements could belong to the strategy/tactics games, games such as UFO, Sindicate, Civilization and Master Of Magic.<br />
<br />
== Permafailure ==<br />
<br />
In some massive multiplayer games, (OGame for example), one may find permafailure to be an appealing feature, not because of the multiplayer nature of the game, but because for example, each time a fleet is sent, or do something vital has to be decided, there is a feeling of anticipation, and a little nervousness, because the decision will be ''final'', there is no save/load to back up a mistake.<br />
<br />
This concept may be called permafailure, and is related directly to Permadeath.<br />
<br />
[[Category:Articles]]</div>Harblcathttp://roguebasin.com/index.php?title=Permadeath&diff=14763Permadeath2009-02-12T09:57:02Z<p>Harblcat: minor typos and editing</p>
<hr />
<div>== Definition ==<br />
<br />
'''Permadeath''' (short for '''permanent death''') is one of the [[Definition|main features]] of roguelikes. It consists in the fact that once your character dies in the game, you can't restore him to a previous status via save-files or save-states. This means that once your character dies, he is dead for good.<br />
<br />
Although the feature is commonly referred to as "Permadeath", it applies not only to death: whatever bad (or good) thing happens to your character, you cannot go back in time. (One exception: roguelikes should allow the player to restore character if the game crashes due to a bug or external reason.)<br />
<br />
The idea may scare people from other RPG genres, such as console and common "plot" RPGs, as it is common custom to reload the game after something bad happens to the main character or his party; however, this feature makes roguelikes unique, demanding all your attention and thinking your best moves because the life of your character must be kept.<br />
<br />
There are only a few roguelikes that lack permanent death, see ''[[Alternatives to Permadeath]]''.<br />
<br />
== Description ==<br />
<br />
Permadeath is not as horrible as it might sound at first. The design of roguelikes is built around this concept. This is one of the reasons why they tend to be light in plot. Unlike an RPG, where starting over can involve doing the same hundred page conversation over again, a roguelike presents you with fresh challenges every game. Some other traditional roguelike features, like hidden [[trap]]s and requirement to identify [[potion]]s, also make more sense with permadeath.<br />
<br />
As a good example of a game feature which makes more sense with permadeath, [[ADOM]] has pools which you can drink from. Every time you do, you get a random effect, which can be good or bad. For example, you have a small chance (1%) of getting a wish, which is a very good thing. It is also possible (with chance, say, 10%) that the pool will dry up, making you unable to drink from it anymore. By saving the game after getting each wish or another good effect, and reloading the game each time the pool dries up or you get something unpleasant, you could easily get all the good effects and as many wishes as you want from a single pool. Permadeath makes sure that the pool is unpredictable as it was supposed to be: you have a chance to get a wish or even several wishes, but you also have a chance to become doomed. Some players will instantly drink from each pool they come across, some players will wait with it until their character will be able to overcome any potential bad effects, and some will decide to never drink from pools for fear of their bad effects. Similar features exist in other roguelikes, like [[NetHack]] and [[IVAN]].<br />
<br />
Of course, roguelikes have saving facilities that allow long games to be played for several days, weeks or even months; but the save-file is deleted upon the death of the character.<br />
<br />
The Permadeath can usually easily be avoided via backup of save files, however this is widely considered as cheating, and not the right way of playing the games. Using backups of save files is known as [[Savescumming]].<br />
<br />
Some argue, that Permadeath is just a obsolete heritage from systems that couldn't handle proper save/load, that it is taking away the freedom of the player to play with the game, yet the concept has still a strong support in the roguelike world.<br />
<br />
== Advantages ==<br />
<br />
Some commonly accepted advantages of permadeath are:<br />
<br />
* It produces the feeling of responsibility&mdash;you will be responsible for your actions. If you fail on a quest, it's all your fault and you have to live with it. If you attack a friendly and he dies&mdash;you will suffer the consequences. The player is more attached to his character, for he knows he may lose him. This increases immersion.<br />
* It produces the feeling of anticipation/fear&mdash;will you win? Or will you not? If I go into those caves now it might be the end of me, if I attack that dragon will I stand a chance? If not these 2 weeks of playing will be lost! Again&mdash;it increases the immersion.<br />
* It cautions the player against doing stupid actions&mdash;the player will play more realistically, wont go for unnecessary risks, and hence feel that the world is more real&mdash;immersion.<br />
* It makes the game harder&mdash;if you fail at a task after playing for a while, you need to cope with it, and try to rise back. What means that you will face more challenges. And feel more satisfaction if you win&mdash;for you know you could lose and have to live with it. The reward for the player when winning is hence a lot bigger&mdash;a lot more satisfaction.<br />
<br />
== Permadeath in other genres ==<br />
<br />
The permadeath concept may be excellent and accepted within the roguelike genre, but it wont work with every game. It might however work great with Civilization-type games, in which you can suffer setbacks as well as victories. <br />
<br />
Generally Permadeath may work with games in which:<br />
<br />
# There are not sudden-death situations -- because if they do, then permadeath makes the game really frustrating (some roguelikes suffer from this)<br />
# There are many options of failure that do not lead to lose the game -- failures are very interesting, for they provide a challenge. In roguelikes non-death failures are for example losing a valuable item to a monster attack, getting your levels drained, etc.<br />
# The is enough balance to assure that the failures do not mean game over. If one failure would mean that you don't stand a chance in the rest of the game then it would in fact be a game over, thus violating the sudden-death rule. <br />
<br />
Permadeath would probably be a bad idea in FPS games, as these games violate all of the above requirements. RTS's on the other hand, are fine in mission-scope, but violate the rules in campaing scope; however, if the campaign had a branching system (in which for example if you lose a mission you go to another mission, and if you win, you advance to another mission), then they would work really well, and it would gain a lot of replay value by the way. The branching feature wouldn't work at all with save/load because the work spent on all those missions that are not on the all-win path would be wasted, as most players would load each time they had lost a mission. <br />
<br />
Some games, although not permadeath by nature, are reported to be played without using the save/load features for the sake of challenge, some games that would fit such requirements could belong to the strategy/tactics games, games such as UFO, Sindicate, Civilization and Master Of Magic.<br />
<br />
== Permafailure ==<br />
<br />
In some massive multiplayer games, (OGame for example), one may find permafailure to be an appealing feature, not because of the multiplayer nature of the game, but because for example, each time a fleet is sent, or do something vital has to be decided, there is a feeling of anticipation, and a little nervousness, because the decision will be ''final'', there is no save/load to back up a mistake.<br />
<br />
This concept may be called permafailure, and is related directly to Permadeath.<br />
<br />
[[Category:Articles]]</div>Harblcathttp://roguebasin.com/index.php?title=Portals_as_a_gameplay_mechanism&diff=14757Portals as a gameplay mechanism2009-02-10T05:53:47Z<p>Harblcat: added to articles category</p>
<hr />
<div>The following was posted to rec.games.roguelike.development by myself. I reproduce it here with minor modification. --[[User:Harblcat|Harblcat]] 06:40, 10 February 2009 (CET)<br />
<br />
----<br />
<br />
<br />
== Portals ==<br />
-or-<br />
== "This doesn't make any sense..." ==<br />
<br />
So I came across a really interesting article recently. I detailed the<br />
game engine underlying Dungeon Siege, a game that boasted of a seamless<br />
environment. This might not seem like quite the feat, but at the time<br />
of its release it was quite the buzz.<br />
<br />
I've been thinking of the mechanism behind DS's seamless world, a<br />
variation on portals, and wondered about ways to apply the same thing<br />
to a roguelike.<br />
<br />
DS used this technology because they couldn't store large enough<br />
chunks of the map in memory at one time. In a roguelike, I believe it's<br />
theoretically possible to store several levels of the dungeon at one time,<br />
so there is no need for portals to alleviate memory issues.<br />
<br />
No, I was thinking of it more along the lines of how it would affect<br />
gameplay.<br />
<br />
In the real world, one becomes used to the spatial relationships between<br />
objects, and we expect that when we turn a corner around a building,<br />
we see a different wall; or when walk through a doorway, we end up in<br />
a different room. Rooms don't intersect in the real world, and in most<br />
games that 'knowledge' carries over. Players even react adversely to<br />
situations where things do not conform to standards of reality like this,<br />
complaining when instances of clipping or improper z-order arise.<br />
<br />
What if a game implemented portals as a mechanism to purposefully go<br />
against these standards of reality. It's not a new idea in the general<br />
gaming world, with popular games such as Portal bending the player's<br />
mind to great effect. But so far as I know, there aren't any roguelikes<br />
that use this mechanism.<br />
<br />
Before continuing, I would like to clarify. Portals, as I refer to them,<br />
are merely boundaries on two different objects--be they regions, rooms,<br />
or whatnot--that can be joined seamlessly together.<br />
<br />
Take the following rooms:<br />
<pre><br />
:Room A<br />
###-##<br />
#.N..#<br />
#.S..|<br />
######<br />
<br />
:Room B<br />
#-######<br />
#...N..#<br />
#...S..|<br />
########<br />
</pre><br />
The NS is meant to represent orientation, and the -'s and |'s the<br />
portals. If I were to join rooms A and B together in all the possible<br />
ways, I would get the following combinations:<br />
<pre><br />
##-#<br />
#..#<br />
#..#<br />
#NS#<br />
###-##..#<br />
#.N..#..#<br />
#.S..|..#<br />
#########<br />
<br />
###-##<br />
#.N..########<br />
#.S..|..S...#<br />
######..N...#<br />
######-#<br />
<br />
########<br />
|..S...#<br />
#..N...#<br />
######-##<br />
#.N..#<br />
#.S..|<br />
######<br />
<br />
####<br />
#..|<br />
#..#<br />
#..#<br />
#SN#<br />
#..#<br />
#..#<br />
###-##<br />
#.N..#<br />
#.S..|<br />
######<br />
</pre><br />
Note how the orientation of the rooms is not set in stone, demonstrated<br />
by room B's decidedly dizzying nature. This is something that I really<br />
like. When the rooms are generated from their random numbers, you<br />
get many more possibilities than if the orientation of the rooms was<br />
static. Do note that you could very well generate a string of rooms,<br />
and only have portals in certain areas, perhaps where gameplay demanded:<br />
<pre><br />
#####<br />
|...#####<br />
######.N.....#<br />
#......S.#...|<br />
#....#####...#<br />
##-### #####<br />
</pre><br />
I will stick to referencing single rooms, as I don't want to spend a<br />
hundred hours making room clusters by hand. I hope that is alright.<br />
<br />
As I said, when you randomly generate these rooms or clusters of rooms,<br />
you 'automatically' get many more possiblities than you had to generate. I<br />
consider this to be a side-benefit, though. The real reason I'd love to<br />
implement this mechanic is decidedly more on the fringe.<br />
<br />
I'm sure some of you have pondered the following by now:<br />
<pre><br />
:Room A<br />
#####<br />
#...#<br />
#.###<br />
#.|<br />
###<br />
<br />
:Room B<br />
#####<br />
#...#<br />
###.#<br />
|.#<br />
###<br />
</pre><br />
What would happen when these two rooms were combined? Surely not the<br />
following:<br />
<pre><br />
#####<br />
#...#<br />
#####<br />
#.|.#<br />
#####<br />
</pre><br />
That's simply silly.<br />
<br />
Well, it all depends on where the @ is standing, I suppose:<br />
<pre><br />
####<br />
..#<br />
#.#.#<br />
#.|@#<br />
#####<br />
<br />
#####<br />
#..@#<br />
###.#<br />
|.#<br />
####<br />
<br />
## ##<br />
#. .#<br />
#.#.#<br />
#.@.#<br />
#####<br />
<br />
#####<br />
#@..#<br />
#.###<br />
#.|<br />
####<br />
</pre><br />
Well, that seems slightly nonsensical. Less silly than the other<br />
possibility, though. Do you suppose that @ is confused? I sure would be,<br />
if I didn't know what was going on.<br />
<br />
So, you can overlap rooms. It is definitely interesting, but what about<br />
another possibility?<br />
<pre><br />
:Room A<br />
#####<br />
#...|<br />
#...#<br />
#...|<br />
#####<br />
<br />
:Room B<br />
###<br />
|.|<br />
###<br />
<br />
:Room C<br />
########<br />
|......|<br />
########<br />
<br />
:Room D<br />
#####<br />
|...#<br />
#...#<br />
|...#<br />
#####<br />
</pre><br />
If our @ is standing in room A, and the two portals lead to rooms B and C,<br />
which then link to room D's portals, like so:<br />
<pre><br />
###########<br />
#..@|.|...#<br />
#...### ..#<br />
#...|<br />
#####<br />
<br />
#####<br />
#...|<br />
#...########<br />
#..@|......|...#<br />
################<br />
</pre><br />
which way would be most efficient?<br />
<br />
One final case that I have given thought to:<br />
<pre><br />
:Room A<br />
##A##<br />
#...#<br />
B../C<br />
#...#<br />
##D##<br />
</pre><br />
Here I'm using the letters A, B, C and D to represent the portals,<br />
to try and see how a room linking to itself would work. The / is some<br />
random item (perhaps a nice wand of "Make Sense").<br />
<br />
If A links to C, and B to D:<br />
<pre><br />
#-#<br />
.<br />
.<br />
/<br />
##-##<br />
#.@.#<br />
|../|@ <--- This is you, unbelievably.<br />
#...#<br />
##-##<br />
.<br />
.<br />
./.<br />
#-#<br />
@ <--- This is you, again. You look nice.<br />
</pre><br />
I suppose that this scenario would actually want to draw an infinite map,<br />
so there would certainly have to be a cut-off point, before we really<br />
hit ad-absurdum.<br />
<br />
But still, it is a novel idea. Have I missed out on any more obscure<br />
uses for a system such as this?<br />
<br />
Another reason I was thinking of this idea, going off on a tangent,<br />
is the possibility of implementing a roguelike version of the<br />
probably over-mentioned blog posts made by a man named Squidi<br />
(http://www.squidi.net/three/entry.php?id=30) about a Communist Zombie<br />
MUD. So I wanted a system that would be capable of "bigness" while at<br />
the same time being easy on a server. One humongous, persistent world<br />
would be rather difficult to serve, even to a text-based client.<br />
<br />
Let's have a conversation.<br />
<br />
[[Category:articles]]</div>Harblcathttp://roguebasin.com/index.php?title=Portals_as_a_gameplay_mechanism&diff=14756Portals as a gameplay mechanism2009-02-10T05:40:57Z<p>Harblcat: initial w/ wikification</p>
<hr />
<div>The following was posted to rec.games.roguelike.development by myself. I reproduce it here with minor modification. --[[User:Harblcat|Harblcat]] 06:40, 10 February 2009 (CET)<br />
<br />
----<br />
<br />
<br />
== Portals ==<br />
-or-<br />
== "This doesn't make any sense..." ==<br />
<br />
So I came across a really interesting article recently. I detailed the<br />
game engine underlying Dungeon Siege, a game that boasted of a seamless<br />
environment. This might not seem like quite the feat, but at the time<br />
of its release it was quite the buzz.<br />
<br />
I've been thinking of the mechanism behind DS's seamless world, a<br />
variation on portals, and wondered about ways to apply the same thing<br />
to a roguelike.<br />
<br />
DS used this technology because they couldn't store large enough<br />
chunks of the map in memory at one time. In a roguelike, I believe it's<br />
theoretically possible to store several levels of the dungeon at one time,<br />
so there is no need for portals to alleviate memory issues.<br />
<br />
No, I was thinking of it more along the lines of how it would affect<br />
gameplay.<br />
<br />
In the real world, one becomes used to the spatial relationships between<br />
objects, and we expect that when we turn a corner around a building,<br />
we see a different wall; or when walk through a doorway, we end up in<br />
a different room. Rooms don't intersect in the real world, and in most<br />
games that 'knowledge' carries over. Players even react adversely to<br />
situations where things do not conform to standards of reality like this,<br />
complaining when instances of clipping or improper z-order arise.<br />
<br />
What if a game implemented portals as a mechanism to purposefully go<br />
against these standards of reality. It's not a new idea in the general<br />
gaming world, with popular games such as Portal bending the player's<br />
mind to great effect. But so far as I know, there aren't any roguelikes<br />
that use this mechanism.<br />
<br />
Before continuing, I would like to clarify. Portals, as I refer to them,<br />
are merely boundaries on two different objects--be they regions, rooms,<br />
or whatnot--that can be joined seamlessly together.<br />
<br />
Take the following rooms:<br />
<pre><br />
:Room A<br />
###-##<br />
#.N..#<br />
#.S..|<br />
######<br />
<br />
:Room B<br />
#-######<br />
#...N..#<br />
#...S..|<br />
########<br />
</pre><br />
The NS is meant to represent orientation, and the -'s and |'s the<br />
portals. If I were to join rooms A and B together in all the possible<br />
ways, I would get the following combinations:<br />
<pre><br />
##-#<br />
#..#<br />
#..#<br />
#NS#<br />
###-##..#<br />
#.N..#..#<br />
#.S..|..#<br />
#########<br />
<br />
###-##<br />
#.N..########<br />
#.S..|..S...#<br />
######..N...#<br />
######-#<br />
<br />
########<br />
|..S...#<br />
#..N...#<br />
######-##<br />
#.N..#<br />
#.S..|<br />
######<br />
<br />
####<br />
#..|<br />
#..#<br />
#..#<br />
#SN#<br />
#..#<br />
#..#<br />
###-##<br />
#.N..#<br />
#.S..|<br />
######<br />
</pre><br />
Note how the orientation of the rooms is not set in stone, demonstrated<br />
by room B's decidedly dizzying nature. This is something that I really<br />
like. When the rooms are generated from their random numbers, you<br />
get many more possibilities than if the orientation of the rooms was<br />
static. Do note that you could very well generate a string of rooms,<br />
and only have portals in certain areas, perhaps where gameplay demanded:<br />
<pre><br />
#####<br />
|...#####<br />
######.N.....#<br />
#......S.#...|<br />
#....#####...#<br />
##-### #####<br />
</pre><br />
I will stick to referencing single rooms, as I don't want to spend a<br />
hundred hours making room clusters by hand. I hope that is alright.<br />
<br />
As I said, when you randomly generate these rooms or clusters of rooms,<br />
you 'automatically' get many more possiblities than you had to generate. I<br />
consider this to be a side-benefit, though. The real reason I'd love to<br />
implement this mechanic is decidedly more on the fringe.<br />
<br />
I'm sure some of you have pondered the following by now:<br />
<pre><br />
:Room A<br />
#####<br />
#...#<br />
#.###<br />
#.|<br />
###<br />
<br />
:Room B<br />
#####<br />
#...#<br />
###.#<br />
|.#<br />
###<br />
</pre><br />
What would happen when these two rooms were combined? Surely not the<br />
following:<br />
<pre><br />
#####<br />
#...#<br />
#####<br />
#.|.#<br />
#####<br />
</pre><br />
That's simply silly.<br />
<br />
Well, it all depends on where the @ is standing, I suppose:<br />
<pre><br />
####<br />
..#<br />
#.#.#<br />
#.|@#<br />
#####<br />
<br />
#####<br />
#..@#<br />
###.#<br />
|.#<br />
####<br />
<br />
## ##<br />
#. .#<br />
#.#.#<br />
#.@.#<br />
#####<br />
<br />
#####<br />
#@..#<br />
#.###<br />
#.|<br />
####<br />
</pre><br />
Well, that seems slightly nonsensical. Less silly than the other<br />
possibility, though. Do you suppose that @ is confused? I sure would be,<br />
if I didn't know what was going on.<br />
<br />
So, you can overlap rooms. It is definitely interesting, but what about<br />
another possibility?<br />
<pre><br />
:Room A<br />
#####<br />
#...|<br />
#...#<br />
#...|<br />
#####<br />
<br />
:Room B<br />
###<br />
|.|<br />
###<br />
<br />
:Room C<br />
########<br />
|......|<br />
########<br />
<br />
:Room D<br />
#####<br />
|...#<br />
#...#<br />
|...#<br />
#####<br />
</pre><br />
If our @ is standing in room A, and the two portals lead to rooms B and C,<br />
which then link to room D's portals, like so:<br />
<pre><br />
###########<br />
#..@|.|...#<br />
#...### ..#<br />
#...|<br />
#####<br />
<br />
#####<br />
#...|<br />
#...########<br />
#..@|......|...#<br />
################<br />
</pre><br />
which way would be most efficient?<br />
<br />
One final case that I have given thought to:<br />
<pre><br />
:Room A<br />
##A##<br />
#...#<br />
B../C<br />
#...#<br />
##D##<br />
</pre><br />
Here I'm using the letters A, B, C and D to represent the portals,<br />
to try and see how a room linking to itself would work. The / is some<br />
random item (perhaps a nice wand of "Make Sense").<br />
<br />
If A links to C, and B to D:<br />
<pre><br />
#-#<br />
.<br />
.<br />
/<br />
##-##<br />
#.@.#<br />
|../|@ <--- This is you, unbelievably.<br />
#...#<br />
##-##<br />
.<br />
.<br />
./.<br />
#-#<br />
@ <--- This is you, again. You look nice.<br />
</pre><br />
I suppose that this scenario would actually want to draw an infinite map,<br />
so there would certainly have to be a cut-off point, before we really<br />
hit ad-absurdum.<br />
<br />
But still, it is a novel idea. Have I missed out on any more obscure<br />
uses for a system such as this?<br />
<br />
Another reason I was thinking of this idea, going off on a tangent,<br />
is the possibility of implementing a roguelike version of the<br />
probably over-mentioned blog posts made by a man named Squidi<br />
(http://www.squidi.net/three/entry.php?id=30) about a Communist Zombie<br />
MUD. So I wanted a system that would be capable of "bigness" while at<br />
the same time being easy on a server. One humongous, persistent world<br />
would be rather difficult to serve, even to a text-based client.<br />
<br />
Let's have a conversation.</div>Harblcathttp://roguebasin.com/index.php?title=User:Harblcat&diff=14755User:Harblcat2009-02-10T05:34:19Z<p>Harblcat: initial</p>
<hr />
<div>== About me ==<br />
I am a recent addition to rec.games.roguelike.development, and new to the whole idea of development, period (at least in languages like C++). I hope to get along with everyone.<br />
<br />
== Articles ==<br />
I have only written one article, as of 10 Feb 2009: [[Portals as a gameplay mechanism]]</div>Harblcathttp://roguebasin.com/index.php?title=Talk:Articles&diff=14754Talk:Articles2009-02-10T05:32:59Z<p>Harblcat: Categories</p>
<hr />
<div>==LoS, Fov==<br />
I am moving references to all FoV/LoS articles to those two pages (and ray casting/shadow casting/permissive fov pages). It is impossible to tell by looking at the titles of the articles what method is described and why you might want to use that method rather than another. This will be explained in the appropriate pages with links to the articles. [[User:Duerig|Duerig]] 04:47, 27 Apr 2007 (CEST)<br />
<br />
:They are now moved. I think this provides a cleaner and more useful interface for somebody trying to figure out how they want to deal with LoS/FoV. However, it not doesn't quite conform to the rest of the page. If the current state is objectionable, I can put the links back and perhaps use sub-headings to classify them here in addition to describing them on the respective pages. [[User:Duerig|Duerig]] 06:45, 27 Apr 2007 (CEST)<br />
<br />
== Categories ==<br />
<br />
If I cannot find a sufficiently good place to put an article, should I make a new category? --[[User:Harblcat|Harblcat]] 06:32, 10 February 2009 (CET)</div>Harblcathttp://roguebasin.com/index.php?title=Implicit_Facing&diff=14664Implicit Facing2009-01-27T22:43:06Z<p>Harblcat: fixed typo</p>
<hr />
<div>{{original|author=Jimmy Babcock|oldid=3824}}<br />
<br />
== Introduction ==<br />
<br />
Several games have used systems which represent the player's facing, and many<br />
more have rejected it. The standard way of handling facing gives the player an<br />
annoying extra element to manage, and so has been considered unworkable. This<br />
article proposes an alternate use for facing, which does not burden the player<br />
with additional details. It is best implemented as a replacement for the<br />
"defense penalty for multiple attackers" rule.<br />
<br />
== Rules ==<br />
<br />
The player's facing is determined by his previous move, and by the position of<br />
monsters around him, as follows (rules applied in order):<br />
<br />
* if the last move was to fire an arrow, zap a wand, throw a projectile, etc., then the player is facing in the direction he fired/zapped/threw in.<br />
* Else if there is exactly one visible monster next to the player, the player faces towards it. Justification: Regardless of the direction of movement, the player is aware of and defending against attacks.<br />
* Else if the last attack was to move or attack, facing is in the direction given by the move/attack.<br />
* Else facing is the same as it was last move<br />
<br />
Facing does NOT affect vision, movement speed, or any non-combat actions. The<br />
current facing should not be featured prominently on the HUD, or anywhere else<br />
that will make it obvious that a facing system is in use. <br />
<br />
== Melee ==<br />
<br />
On a given turn, the tiles around the player are divided into frontal, flank,<br />
and rear tiles (see Fig. 1). If an attacking melee monster is in a flank or<br />
rear tile, the player does not receive defensive benefits from a shield.<br />
(Variation: one flank receives shield benefits, depending on which hand holds<br />
the shield.) Furthermore, if the attacker is in a flank tile it receives a<br />
small (system-dependent) to-hit bonus, while if it is in a rear tile it<br />
receives a substantial bonus.<br />
<br />
Facing @ Facing NE<br />
321 1: Front 211<br />
3@1 2: Flank 3@1<br />
321 3: Rear 332<br />
<br />
Fig. 1 - Melee<br />
<br />
<br />
== Missile ==<br />
<br />
A ranged attacker receives the benefit of a flank or ranged attack depending on<br />
which quadrant (see Fig. 2) it is in.<br />
<br />
Facing E Facing NE<br />
\222/ 22|11<br />
3\2/1 22|11 1: Front<br />
33@11 --@-- 2: Flank<br />
3/2\1 33|22 3: Rear<br />
/222\ 33|22<br />
<br />
Fig. 2 - Missile<br />
<br />
Quadrant borders are never in region 2. Assuming a bresenham line draw from<br />
attacker to player represents the path of the projectile, this is approximately<br />
equivalent to representing the projectile as a melee attack when it is one step<br />
away from the player.<br />
<br />
<br />
== A More Formal Definition ==<br />
<br />
So long as we restrict ranged attacks to firing on straight or diagonal paths,<br />
we can represent facing as an integer in the range of 0 to 7, going clockwise<br />
at 45-degree increments; to determine what region an attacker is in, we find<br />
the facing which would be towards it, subtract the player's facing modulo 8,<br />
and take the absolute value; if the result is <= 1, it is a frontal attack;<br />
else if <=2, flank attack; else <=4, rear.<br />
<br />
If we do not make this restriction, then we must allow both for the player to<br />
face in arbitrary angles, and accurately represent the angle of origin for<br />
ranged attacks. The angle from the player to an attacker is atan2(monst.y-<br />
plr.y, monst.x-plr.x) radians. As before, we take attack abs(angle - player<br />
facing % (2*pi)). (There is some complication this time with using modulus,<br />
since C does not support use of the modulus operator on floats.) This is<br />
frontal if result <= pi/4, flank if <= 3*pi/4, else <= pi, rear. As a<br />
workaround for the lack of modulus on floats, you can use the C function below<br />
instead.<br />
<br />
float mod(float a, float b) {<br />
if(a&gt;0) return floor(a/b) * b;<br />
else return -floor(-a/b) * b;<br />
}<br />
<br />
== More on Missiles ==<br />
<br />
One of the goals of implicit facing is to not allow the player to control his<br />
facing directly, and to make it so that he doesn't need to. A problem case is<br />
when the player moves, with no monsters adjacent, but with missile attackers<br />
around. If the character is aware of their presence, it makes sense for him to<br />
consciously face towards them, but this is not what actually happens with the<br />
rules given. The situation is even worse when there are *multiple* missile<br />
attackers around. Certainly, it is tempting to ignore the case and expect that<br />
the player be aware of the facing rules, but this is not the best solution.<br />
<br />
One possibility is to divide up the angles around the player into regions,<br />
and face towards the region which contains the most known in-range missile<br />
attackers. The regions should be overlapping, and should not be too large (for<br />
accuracy) or small (for speed); 60 degree regions with 20 degree overlap should<br />
work nicely.<br />
<br />
Another possibility is to simply face towards the nearest monster. Or, facing<br />
could be left undefined until one of the monsters attacks, and set to be<br />
towards that monster. Unfortunately, this means that the specific order of<br />
missile attacks becomes relevant, which is not particularly desireable.<br />
<br />
[[Category:Articles]][[Category:Combat]]</div>Harblcat