XCOM-like thin walls in Curses, iteration 2
zai...@zaimoni.com
display. My prior idea (UNICODE, magnify the squares and use box-
drawing along the grid lines) only looked good; it isn't playable on a
24x80 console thanks to a pathetic on-screen view radius of 5. So
that won't get released. ["One main() To Rule Them All" is working
out very well emotionally. Aside from having to convert
destroy_renderer() into an atexit handler to make the game survive the
Close button, it looks like it is going to work as intended.]
My best guess now is to focus on visibility:
* use bolded colors for squares in direct view
* use faded colors for squares not in direct view
* don't bother showing thin-walls directly (they manifest by chopping
off visibility).
This doesn't handle windows inset into walls gracefully, unlike the
UNICODE approach.
dominik...@gmail.com
(apart from noticing that something blocks your LOS)? It may be a
traditional approach, but I believe walls NEED to be drawn...
Mingos.
zai...@zaimoni.com
If I knew that all of underline, leftline, and rightline worked in a
given Curses implementation, that would be reasonable. Unfortunately,
I am not motivated enough to patch PDCurses to support leftline and
rightline for the Win32 console port of PDCurses. And I find drawing
just the north and south walls confusing; they either should all be
drawn, or none be drawn.
The SDL port of PDCurses does support all of underline, leftline, and
rightline. However, I'd rather use SDL for a proper graphical
frontend that warrants the complexity.
Paul Murray
> My best guess now is to focus on visibility:
> * use bolded colors for squares in direct view
> * use faded colors for squares not in direct view
> * don't bother showing thin-walls directly (they manifest by chopping
> off visibility).
If your walls are only ever to divide inside from outside (not interior
partition walls), then you could use a different base square for interior
and exterior cells, which would indicate where the walls are.
Nik Coughlin
<zai...@zaimoni.com> wrote in message
news:faad6bc7-93e2-4bb9...@2g2000hsn.googlegroups.com...
Maybe it's not such a good idea but if you seperate off the right hand 24x24
squares you could have a 5x5 magnified preview centered around the player on
the right hand side showing thin walls. That still leaves you 56x24 squares
for the main view. Or you could have a key that toggles between magnified
and non-magnified view. Or maybe (given that most consoles support > 24
lines) you could show the magnified version for the majority that can have
more than 24 lines and use some of your other visibility ideas listed above
just for 24 line mode. Or a combination of all of the above?
zai...@zaimoni.com
That's an interesting idea on other grounds.
I'm confident this subgenre will have interior walls, however.
zai...@zaimoni.com
> Maybe it's not such a good idea but if you seperate off the right hand 24x24
> squares you could have a 5x5 magnified preview centered around the player on
> the right hand side showing thin walls. That still leaves you 56x24 squares
> for the main view. Or you could have a key that toggles between magnified
> and non-magnified view. Or maybe (given that most consoles support > 24
> lines) you could show the magnified version for the majority that can have
> more than 24 lines and use some of your other visibility ideas listed above
> just for 24 line mode. Or a combination of all of the above?
The box drawing characters (either UNICODE, or the VT100-type
typically supported by curses) give me a 7x7 preview in a 15x15
square. It'll fit in my current left sidebar.
zai...@zaimoni.com
>
> news:faad6bc7-93e2-4bb9...@2g2000hsn.googlegroups.com...
>
>
>
> > I'm back to visualzing how to display XCOM-like thin walls in a curses
> > display. My prior idea (UNICODE, magnify the squares and use box-
> > drawing along the grid lines) only looked good; it isn't playable on a
> > 24x80 console thanks to a pathetic on-screen view radius of 5. So
> > that won't get released. ["One main() To Rule Them All" is working
> > out very well emotionally. Aside from having to convert
> > destroy_renderer() into an atexit handler to make the game survive the
> > Close button, it looks like it is going to work as intended.]
>
> > My best guess now is to focus on visibility:
> > * use bolded colors for squares in direct view
> > * use faded colors for squares not in direct view
> > * don't bother showing thin-walls directly (they manifest by chopping
> > off visibility).
>
> > This doesn't handle windows inset into walls gracefully, unlike the
> > UNICODE approach.
>
> Maybe it's not such a good idea but if you seperate off the right hand 24x24
> squares you could have a 5x5 magnified preview centered around the player on
> the right hand side showing thin walls.
I'm not sure what I was thinking of when I mentioned view radius of 5,
obviously. Another thing I've been considering is multi-voxel
humanoids (to represent stand/crouch/prone)...that does make sense as
if the display scale is 3 yards/meters, with 1 cubic yard/meter
voxels, then I have a fairly reasonable representation. (5 square
radius takes 21x21, 7 square radius takes 29x29)
My prior comment was for a more traditional display scale.
David Damerell
>I'm back to visualzing how to display XCOM-like thin walls in a curses
>display.
How about showing the wall as present in whichever cell it is blocking
your view of? This would work badly with through-wall detection effects
like telepathy...
--
David Damerell <dame...@chiark.greenend.org.uk> Kill the tomato!
Today is Second Sunday, May - a weekend.
zircher
>
> * don't bother showing thin-walls directly (they manifest by chopping off visibility).
What about showing those squares as shadowed (perhaps using a shadow
casting system rather than a LOS system?)
--
TAZ
zai...@zaimoni.com
Recall that a fully implemented Curses only guarantees two intensity
levels for any hue.
Certainly it would be possible to use this to signal shadowed vs fully
lit instead of signalling in or out of LOS, but the LOS interpretation
plays well in both Angband and Crawl. Making it do both: I'd need a
game that actually makes it work to visualize how it would work.
zai...@zaimoni.com
wrote:
> Quoting <zaim...@zaimoni.com>:
>
> >I'm back to visualzing how to display XCOM-like thin walls in a curses
> >display.
>
> How about showing the wall as present in whichever cell it is blocking
> your view of? This would work badly with through-wall detection effects
> like telepathy...
Stepping left changes
|.
.@
to
.|
@.
That said, I'm not positive that the change in display intensity would
be much less confusing. (Between not being able to see an empty square
1 away diagonally and not being able to move diagonally into that
square, the initially proposed display situation is also going to be
weird without magnification.)
jot...@hotmail.com
The problem with that is that the closest walls would be very visible,
but then the shaded area would look completely plain; apparently it
would have no walls at all. A giant area that's completely plain. It
could get really confusing.
What about this extension to the idea: there's a first zone that's
completely lit, then after the first walls up until the second walls
it's just shaded, and anything after the second wall is pitch black.
It would take a modified LOS routine (one that counts the number of
walls it has passed through, up to 2) but the way I picture it it
could be pretty effective. And you could have thin walls in an ASCII-
based RL :)
Jotaf
dominik...@gmail.com
Either you write a new GUI that would support that (like having a 1
pixel space reserved for walls between each cell) or you use "normal",
thick walls like most RLs do. That, or you're doomed :D. But
seriously, I think you're trying to add a feature that in Curses will
make your game "uncomfortable to look at" (let's not use the word
"ugly", it's politically incorrect). It may make the map unradable and
difficult to get used to. Why don't you want thick walls, anyway?
Mingos.
zai...@zaimoni.com
> I still think drawing thin walls in Curses is a bad idea, sorry.
It's something I'd rather get out of, but it emerges from other design
constraints.
> Either you write a new GUI that would support that (like having a 1
> pixel space reserved for walls between each cell) or you use "normal",
> thick walls like most RLs do. That, or you're doomed :D. But
> seriously, I think you're trying to add a feature that in Curses will
> make your game "uncomfortable to look at" (let's not use the word
> "ugly", it's politically incorrect). It may make the map unradable and
> difficult to get used to.
Well, if I restricted myself to Curses ports that actually *had*
leftline and rightline it wouldn't be too bad; I'd just draw the
walls. [e.g.: SDL PDCurses]. But that loses most of the advantages
of a Curses front-end on Windows, and gets almost none of the
technical benefits of an SDL front-end.
(Yes, I'm aware of ncurses. It won't build under MingW32; that it
does build under CygWin is irrelevant, as my motives for not
installing CygWin/GCC are political.)
> Why don't you want thick walls, anyway?
Actually, the target subgenre has both thick and thin walls. So, it's
more "Why do I want a Curses frontend to a game that traditionally
would use isometric graphics"?
I don't want to wait on artwork to test the game mechanics. And it's
a one-off time cost to set up the parallel build process; the game
proper literally has no idea whether it's linked against Curses or not.
William McBrine
> Unfortunately, I am not motivated enough to patch PDCurses to support
> leftline and rightline for the Win32 console port of PDCurses.
And if you had the motivation, you'd find that it's not possible.
Although Microsoft defines symbols like COMMON_LVB_GRID_LVERTICAL for the
console attributes, they don't work... except, apparently, with CJK
versions of Windows. Or at least this was the case as of XP.
--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 -- pass it on
David Damerell
>On May 14, 10:26 am, David Damerell <damer...@chiark.greenend.org.uk>
>wrote:
>>your view of? This would work badly with through-wall detection effects
>>like telepathy...
>Stepping left changes
>
>.@ @.
Yes, that's intended. (Or perhaps:
]. to .[
.@ @.
although picking a fourth element to go with []_ which is reliably
top-centric is tricky - '"', maybe?
--
David Damerell <dame...@chiark.greenend.org.uk> flcl?
Today is Gloucesterday, May.
zai...@zaimoni.com
wrote:
> Quoting <zaim...@zaimoni.com>:
>
> >On May 14, 10:26 am, David Damerell <damer...@chiark.greenend.org.uk>
> >wrote:
> >>How about showing the wall as present in whichever cell it is blocking
> >>your view of? This would work badly with through-wall detection effects
> >>like telepathy...
Technically, rendering out of sight objects on the map would be a
through-wall detection effect.
> >Stepping left changes
>
> >|. to .|
> >.@ @.
>
> Yes, that's intended. (Or perhaps:
>
> ]. to .[
> .@ @.
>
> although picking a fourth element to go with []_ which is reliably
> top-centric is tricky - '"', maybe?
Yes, " is the most visually suggestive out of `'"^ .
David Damerell
>>>On May 14, 10:26 am, David Damerell <damer...@chiark.greenend.org.uk>
>>>wrote:
>>>>How about showing the wall as present in whichever cell it is blocking
>>>>your view of? This would work badly with through-wall detection effects
>>>>like telepathy...
>Technically, rendering out of sight objects on the map would be a
>through-wall detection effect.
Yes. That could get annoying quickly if objects are either hidden or
displaced by thin walls, although displacing objects next to the thin wall
one space further into the room might still make sense.
>>although picking a fourth element to go with []_ which is reliably
>>top-centric is tricky - '"', maybe?
>Yes, " is the most visually suggestive out of `'"^ .
I think walls changing characters as you pass them would also diminish the
illusion of them being moving objects.
I also think you're going to have serious problems at junctions of walls.
--
David Damerell <dame...@chiark.greenend.org.uk> Kill the tomato!
Today is Leicesterday, May.
zircher
Perhaps the way to go is to just give the thin walls their own cell
using dash, vertical pipe, and plus signs for junctions. That would
allow you to easily mix thick walls with thin. Perhaps using the
square brackets for double doors?
##---[]---+
# |
# +--[]-+
[ | |
] | |
# | |
##--+-----+
--
TAZ
zai...@zaimoni.com
I considered something like this for the magnified map approach.
UNICODE has some visual advantages (no gaps needed, more direct
visualization of T wall joints), and PDCurses does have UNICODE
support on Windows.
The catch, is that in-genre it is possible to enter a map cell with
thin walls (you just have to not use a face with a thin wall when
entering the cell). With the magnified map approach, this is easy
enough to display. I didn't carefully test out the tactical
possibilities of allowing partial steps of a multi-cell @, but the
visibility behavior for allowing half-steps at 2x magnification with a
single-cell @ was pleasing (if erring towards too much realism).
The limited on-screen view radius meant I was using the monster list
command continually even at 2x magnification, just to know what was
clearly in sight and immediately capable of attacking @. This was bad
in general, but on a non-maximized Windows console it was very hard to
maintain immersion.
jot...@hotmail.com
> I considered something like this for the magnified map approach.
> UNICODE has some visual advantages (no gaps needed, more direct
> visualization of T wall joints), and PDCurses does have UNICODE
> support on Windows.
>
> The catch, is that in-genre it is possible to enter a map cell with
> thin walls (you just have to not use a face with a thin wall when
> entering the cell). With the magnified map approach, this is easy
> enough to display. I didn't carefully test out the tactical
> possibilities of allowing partial steps of a multi-cell @, but the
> visibility behavior for allowing half-steps at 2x magnification with a
> single-cell @ was pleasing (if erring towards too much realism).
>
> The limited on-screen view radius meant I was using the monster list
> command continually even at 2x magnification, just to know what was
> clearly in sight and immediately capable of attacking @. This was bad
> in general, but on a non-maximized Windows console it was very hard to
> maintain immersion.
That would work ok, but using a magnified view. Did you read my
suggestion (extending zaim's) about shading the floor differently
depending on LOS and invisible thin walls?
Talking about that magnified view, there's some extra space between
the player and adjacent monsters. This space would be used for walls,
but in this case it's empty. Couldn't this be useful for GUI stuff
that is usually impossible? Like showing the facing direction of the
player (as an arrow in this empty space around the player), or other
information. Could enable a whole new level of gameplay mechanics.
Jotaf
zai...@zaimoni.com
> On 17 Maio, 00:22, zaim...@zaimoni.com wrote:
>
>
>
> > I considered something like this for the magnified map approach.
> > UNICODE has some visual advantages (no gaps needed, more direct
> > visualization of T wall joints), and PDCurses does have UNICODE
> > support on Windows.
>
> > The catch, is that in-genre it is possible to enter a map cell with
> > thin walls (you just have to not use a face with a thin wall when
> > entering the cell). With the magnified map approach, this is easy
> > enough to display. I didn't carefully test out the tactical
> > possibilities of allowing partial steps of a multi-cell @, but the
> > visibility behavior for allowing half-steps at 2x magnification with a
> > single-cell @ was pleasing (if erring towards too much realism).
>
> > The limited on-screen view radius meant I was using the monster list
> > command continually even at 2x magnification, just to know what was
> > clearly in sight and immediately capable of attacking @. This was bad
> > in general, but on a non-maximized Windows console it was very hard to
> > maintain immersion.
>
> That would work ok, but using a magnified view. Did you read my
> suggestion (extending zaim's) about shading the floor differently
> depending on LOS and invisible thin walls?
Yes. I think it would work, but that I wasn't up to immediately
psuedocoding how it would work.
> Talking about that magnified view, there's some extra space between
> the player and adjacent monsters. This space would be used for walls,
> but in this case it's empty. Couldn't this be useful for GUI stuff
> that is usually impossible? Like showing the facing direction of the
> player (as an arrow in this empty space around the player), or other
> information. Could enable a whole new level of gameplay mechanics.
Agreed there. Note that facing information is mostly useful when a
game turn corresponds to a small time scale (at most a second,
possibly less). I'm going to use this kind of time scale for combat,
and have already coded a reaction time system that correctly invokes
stub AI's and renderers. (Representing perceptual differences is
going to be a challenge. Ideally I'd have both "speed of noticing"
and "time to react to something seen", and use this to create
fundamental differences between playing a robot and playing a more
organic person.)
One possibility (fixing one of the issues I have with the original
genre) is representing looking to the side without doing a full body
turn. That's something that it isn't enough to have a sectored field
of view for.
That time scale is not at all workable for playability. From the
storyboarding I'm doing for the current game, it looks like I will
need to deal with pathfinding very early in the development process
(before monsters, even) just to make moving around feasible.