Back with Umbrarum Regnum
dominik...@gmail.com
Nobody will code my ideas for me, so I got my hands on a compiler
personally.
Obviously, UR is not at an advanced stage. It's not playable yet, but
what the hell! Coding it is fun.
Thank you all for encouraging me to start coding. I enjoy it very
much.
If you're interested in how UR's faring, visit the site
http://dominikmarczuk.googlepages.com
Cheers!
Antoine
I like the screenshots. I feel like I would enjoy wandering round in
such a world.
A.
dominik...@gmail.com
on its looks ;). I'm planning to remove all foreground tiles save for
towns and the PC, the terrain will be represented using the background
colour only. I'll try to implement the new overworld looks this
evening, check the UR site this night for new screenshots.
Mingos.
dominik...@gmail.com
screenshot has already been uploaded.
Mingos.
jot...@hotmail.com
Sweet!! You went with a 24-bits look :) It looks distinctive; I
thought that most RL's based on libtcod would look like Jice's game
but now I see I was wrong. There's room for a lot of creativity and
yours is one fine example.
Jotaf
Jeff Lait
> > Sweet!! You went with a 24-bits look :) It looks distinctive; I
> > thought that most RL's based on libtcod would look like Jice's game
> > but now I see I was wrong. There's room for a lot of creativity and
> > yours is one fine example.
>
> using a similar technique.
Put down the pitchfork. You were being complemented.
> That's what TCODlib was made for, anyway: full use of
> True Colour.
After playing Chrysalis I'm seriously considering playing with libtcod
for my future 7drls.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
dominik...@gmail.com
That's COMPLIMENTED, not complemented, actually, but... Damn, I
understand perfectly what you wanted to say and you're right... I need
a rest, 8 hours of hard work bartending, another 8 hours coding, no
food, no beer, no sleep (and *lots* of ciggies)... I think it's
paranoia, I see sarcastic comments everywhere... God, I reread Jotaf's
comment now over and over again and... man, what was I thinking???
Jotaf, I apologize for that reply, I'm just really falling asleep (or
rather losing my conscience) here in front of the computer and don't
know what I'm reading. In fact, I already note my vision blurry :).
Back to you when I rest a bit.
G'night.
Mingos.
dominik...@gmail.com
reply.
Mingos.
Gamer_2k4
You can DO that? Man, I must be using the wrong newsreader. Anyway,
the town, cave, and wilderness all look great. Now if only a playable
version is released soon...
--
Gamer_2k4
oeb
You can't really.
You can send a cancel request, but most news servers (like mine) will
just ignore it and leave the article there. It used to be abused alot in
the early days of usenet.
Jeff Lait
> > Put down the pitchfork. You were being complemented.
>
> That's COMPLIMENTED, not complemented, actually, but...
dominikmarczuk = ~dominikmarczuk;
Or, if you're real:
dominikmarczuk = 1.0 - dominikmarczuk;
Perdurabo
> On May 15, 9:29 pm, dominikmarc...@gmail.com wrote:
>
> > > Put down the pitchfork. You were being complemented.
>
> > That's COMPLIMENTED, not complemented, actually, but...
>
> dominikmarczuk = ~dominikmarczuk;
>
> Or, if you're real:
>
> dominikmarczuk = 1.0 - dominikmarczuk;
> --
>
Or if he' s imaginary:
SQRT(-dominikmarczuk)
Best,
P.
dominik...@gmail.com
> > Or, if you're real:
> > dominikmarczuk = 1.0 - dominikmarczuk;
>
> SQRT(-dominikmarczuk)
Ha ha ha! OK guys, I assure you I'm real, let's stick with
"dominikmarczuk = 1.0 - dominikmarczuk" theorem :))).
I'll upload some new screenshots today, as well as a new article about
nonpersistent wilderness maps generation in UR (with sample
screenshots as well). Stay tuned.
Let's see how much it is until I finally code a bug free dungeon
generator and some monsters and inventories. Without these (at least
the latter two), UR just can't be playable... I just can't gather the
will to actually start...
Mingos.
datt...@gmail.com
noises did you use to generate it ?
BTW I would suggest a blog for your developer articles, Biscup
style :P.
Game looks great.
-Sid
dominik...@gmail.com
> noises did you use to generate it?
It's preprogrammed (a tiny joke I played on some of my friends who
know I'm rather crazy about the region I live in: the map has exactly
the region's shape). I'm not planning a randomly generated overworld
(at least at the moment), mainly because a) it makes things a little
more complicated to add a main plot of a political nature, requiring
certain geographical features to make sense, b) the current map's
artwork is 100% handmade and it would be difficult to make the
computer come up with similar results. In other words, "plains" tiles
range from light green to brownish-orange, while on a random map they
would probably use the same colour.
Sure, I can use tricks, like a heightmap (which is exactly what my
other project, Strike Force Barnard, does) to shade default colours,
one might adjust their hue easily as well, but it would look more
artificial. I might be eager to experiment at a certain point (I
already have some ideas on how to make things look more or less
natural, based on the heightmap, but right now I'm focused on
implementing key features in order to make UR playable).
> BTW I would suggest a blog for your developer articles, Biscup
> style :P.
I'm not fond of blogs.
Besides, there will be few developer articles, since most UR's
features are well known and widely used algorithms. I write dev
articles only when I manage to come up with an interesting algorithm
without consulting *any* external sources like other people's
articles, other games' source code, etc. For instance, I will not add
an article on cavern generation because it would repeat exactly Jim
Babcock's article about cellullar automata (Roguebasin). On the other
hand, I haven't found an algorithm that would generate forests based
on per cent population chances for each tile generated from fractional
brownian motion (or any other noise type) and thought it would be nice
to write about it. Sure, the idea is not necessarily new nor
revolutionary, but I haven't stumbled upon anything like that on the
net.
> Game looks great.
Thank you, I'm glad you like it. It will look even greater quite soon.
At the moment, I'm happy with the wilderness display, but all other
maps are rather ugly (don't tell me they're distinctive thanks to the
custom font, I'd rather use a background brown colour for a road than
the dot I use now... well, actually it's a double dot). As soon as I
come up with something new, the UR site will get updated.
Mingos
Risto Saarelma
> If you're interested in how UR's faring, visit the site
> http://dominikmarczuk.googlepages.com
Screenshots look nice. One thing that rubs me a bit wrong is the status
bar font. It seems to be going for some sort of calligraphical feel,
which might work thematically, but the type is just too small for that.
The letters just look smudgy when you don't look at them closely. You
might consider using a boring but clear standard font instead.
The horizontal road in the city screen looks a bit strange as it is
generated using a brush shaped like a vertical line. This makes it look
like a wall instead of a flat road whenever it weaves up or down. It
might look better if drawn with a 3x3 tile brush instead of a 1x3 tile
brush:
# ###
# ## ### # ## ### ### #### ##### ####
# : ############# ### : #####################
# ############ ### ####################
# ### # #### ### #####
With the concrete suggestions done, I'm off to a tangential rant about
content generation:
The maps are pretty big, so there's a design question of how to use all
that space. Having the player just explore large, empty dungeons by
walking around will be boring, and generating interesting content is
hard for bigger maps. The on-screen map size seems to be something
around 100x100, which isn't that far bigger than Crawl's 80x80, and
Crawl tends to be able to make reasonably interesting dungeons.
Something like the auto-explore functionality from Crawl would be really
nice on such bigger maps, although it might not be entirely trivial to
implement.
Still I wonder if it's an unnecessary extra design challenge to keep
things interesting in a 100x100 map compared to, say, a 40x40 map. The
thing with roguelike movement is that it doesn't scale from the user's
perspective like movement in a point-and-click game. In the latter,
clicking near the edge of the screen and next to the player avatar are
similar actions, so it's equally simple to make the character take one
step or walk to a specific point at the edge of the screen. With
roguelike controls, the default movement is always one step, and special
commands like the far move being somewhat tricky and different from the
basic move, not to mention suffering from a lack of precision on wide
open areas. This makes roguelike gameplay somewhat focused on the
immediate surroundings of the player avatar and tends to make large,
open maps overwhelming.
Of course a more radical solution would be to go for a mouse-based
point-and-click movement as the default way to control the character.
The problem with the large maps is again present with the city. What
does the player do there? There isn't any architecture in the layout of
the city which might point out more important or interesting houses.
Right now it looks like the player should explore every house or risk
missing an useful shop or a quest-provider (or some other type of
important house in your game). What will the player get from exploring
all those houses? If it's just empty houses with generic townsperson
creatures inside, exploring the city isn't going to be much fun.
Inhabited towns and cities are supposed to be centers of civilization
and concentrations of interesting stuff. That makes them much tougher
than wilderness, caves, mines or even abandoned dungeons for standard
roguelike map generation techniques. I don't think any roguelike that
has inhabited cities and allows the player to go inside the buildings
has gotten them anywhere near right. As done now, they just emphasize
the problems with generating meaningful content.
I can think of two approaches to this problem. One is to skirt the
problem for example by making cities ruined or making them into
Angband-style abstractions where the player can easily see what is
important. The other is to have a few hand-crafted cities with
meaningful architecture, interesting buildings and handmade npcs acting
as persistent hubs to the generated gameworld. This is the approach
taken by Diablo and most other commercial roguelikes. Of course it
requires making an interesting town by hand, but that should be way
easier than making a generator for making an infinite number of
interesting towns.
--
Risto Saarelma
dominik...@gmail.com
> Screenshots look nice. One thing that rubs me a bit wrong is the status
> bar font. It seems to be going for some sort of calligraphical feel,
> which might work thematically, but the type is just too small for that.
> The letters just look smudgy when you don't look at them closely. You
> might consider using a boring but clear standard font instead.
Yes, I too have thought about that. Eventually, I'll make the font
more readable, but at the moment this is a problem of little concern.
In the worst case, I'll just get back to the standard DOS font, as you
suggest. A custom font adds a bit of atmosphere, but it's difficult to
come up with something easily readable using 8x8 pixel characters
(7x7, actually, because they also need spaces left out in order not to
merge).
> The horizontal road in the city screen looks a bit strange as it is
> generated using a brush shaped like a vertical line. This makes it look
> like a wall instead of a flat road whenever it weaves up or down. It
> might look better if drawn with a 3x3 tile brush instead of a 1x3 tile
> brush:
The screen you have examined uses a 1x3 brush, but this particular
screenshot comes from UR ver. 0.0.2. In 0.0.3, road generation is far
better. Turns and junctions are supported and the brush is not a line,
but a circle (radius 1.5 for small settlements and a larger one for
bigger towns - I think it's 2.5 in this case, but can't recall exactly
right now, it might be 2.0 as well...).
> The maps are pretty big, so there's a design question of how to use all
> that space. Having the player just explore large, empty dungeons by
> walking around will be boring, and generating interesting content is
> hard for bigger maps. The on-screen map size seems to be something
> around 100x100, which isn't that far bigger than Crawl's 80x80, and
> Crawl tends to be able to make reasonably interesting dungeons.
> Something like the auto-explore functionality from Crawl would be really
> nice on such bigger maps, although it might not be entirely trivial to
> implement.
I see your point. map size is 112x90, and it was meant to be so. The
RL I used to play many hours every day (an addiction I haven't quite
shaken from yet) is ADoM. Its small maps seem insufficient to me. Even
with 80x50 display (which is the one I always use), I still am not
completely satisfied with the map size. And since I want more and TB
will not listen to my requests (I haven't made such a request, but...
you know what I mean), the only way to satisfy my thirst for large
dungeons is putting them in UR.
Now, making them interesting is a different matter. Monsters are a
must (a feature not yet implemented), of course. Special rooms, prison
cells, torture chambers, treasure caches, underground settlements or
whatever will make the maps more interesting, but I haven't really
thought of that yet. The dungeon generator isn't even working yet
(well, it does, but it's buggy and creates too many corridors). As
soon as it's implemented and it can be populated at least by dome
monsters, I'll try to come up with ideas on how to make the dungeons
more interesting.
And one more thing: the dungeons don't need to occupy the whole
screen. I might as well make simple, low level dungeons smaller and
generate large ones in special situations like the presence of some
unique feature.
> Still I wonder if it's an unnecessary extra design challenge to keep
> things interesting in a 100x100 map compared to, say, a 40x40 map. The
> thing with roguelike movement is that it doesn't scale from the user's
> perspective like movement in a point-and-click game. In the latter,
> clicking near the edge of the screen and next to the player avatar are
> similar actions, so it's equally simple to make the character take one
> step or walk to a specific point at the edge of the screen. With
> roguelike controls, the default movement is always one step, and special
> commands like the far move being somewhat tricky and different from the
> basic move, not to mention suffering from a lack of precision on wide
> open areas. This makes roguelike gameplay somewhat focused on the
> immediate surroundings of the player avatar and tends to make large,
> open maps overwhelming.
TCODlib includes mouse support and I'm planning to use it as well as
the traditional keyboard control, which will be handy for the
wilderness map and large dungeons. But before that happens, I need to
implement some pathfinding.
> The problem with the large maps is again present with the city. What
> does the player do there? There isn't any architecture in the layout of
> the city which might point out more important or interesting houses.
> Right now it looks like the player should explore every house or risk
> missing an useful shop or a quest-provider (or some other type of
> important house in your game). What will the player get from exploring
> all those houses? If it's just empty houses with generic townsperson
> creatures inside, exploring the city isn't going to be much fun.
The architecture is something I plan to work on later. First of all,
buildings will be made from different materials (rock, bricks or wood,
possibly a material or two more). Windows will be added as well to let
the player see the inside of a house without entering it. Special
constructions are planned as well (ports, castles, maybe mansions or
houses surrounded by a hedge). Halflings' housings will be circular
rather than rectangular. Varying architecture isn't that hard to
implement, it's the tedium that keeps me away from implementing all
that.
By the way, note that at the moment, each large town will sport around
100 houses. But when a castle is put in the middle, a mansion or two
in other areas and so on, the number of buildings will drop
drastically. Even if most will be plain houses with townsfolk inside,
exploring them will not be all that tedious.
> Inhabited towns and cities are supposed to be centers of civilization
> and concentrations of interesting stuff. That makes them much tougher
> than wilderness, caves, mines or even abandoned dungeons for standard
> roguelike map generation techniques. I don't think any roguelike that
> has inhabited cities and allows the player to go inside the buildings
> has gotten them anywhere near right. As done now, they just emphasize
> the problems with generating meaningful content.
Aye, I'll do my best to change that :).
> I can think of two approaches to this problem. One is to skirt the
> problem for example by making cities ruined or making them into
> Angband-style abstractions where the player can easily see what is
> important. The other is to have a few hand-crafted cities with
> meaningful architecture, interesting buildings and handmade npcs acting
> as persistent hubs to the generated gameworld. This is the approach
> taken by Diablo and most other commercial roguelikes. Of course it
> requires making an interesting town by hand, but that should be way
> easier than making a generator for making an infinite number of
> interesting towns.
Ruins will be implemented soon, but they will not count as towns, but
simply special locations on the wilderness maps. However, the
political background the game is supposed to have a political
background (in 5 years or so we'll discuss this subject in more
detail ;)). In other words, the human kingdoms of the north (there are
3 of them) are not supposed to simply be there for decoration. I
believe they should interact. Some interactions should be automatical,
independent from the PC's actions. Let's say that the Northern Kingdom
declares war on the Eastern one, sends an army and raids one of the
eastern towns. The town should be transformed into ruins (and will
remain on the overworld map). But hey, I'm commenting advanced stuff
and UR's just hatched! It won't fly until it starts to walk, it won't
walk until it has enought strength and motoric coordination to do so,
get my point? What I need now are the basic features like an
inventory. I'll bother with such issues later on.
In the worst case, I might decide to rewrite UR. Its engine is written
with possible future changes in mind. For example, most coordinates
(map sizes and so on) are not expressed as constant integers, but
rather by variables. For instance, maps are not exactly 112 by 90.
They're (max_x - 16) by (max_y - 6), where max_x and max_y are the
total console height and width (128 by 96 tiles). If I change these in
the constants definitions header, the game runs perfectly, but in a
different resolution. I used this to test possible resolutions and
pick the one that suits my needs best. 160x128 gives more
possibilities, but savegames are quite large and the font is barely
readable on my 17 inch monitor (besides, my eyesight isn't the best
one can wish for and I needed to force my vision in this resolution).
80x60 is siply too small: not everything can be displayed at the same
time. 100x75 is more or less OK, but the towns are awfully tiny... I
might consider compiling two game versions: 128x96 and 100x75, just in
case someone is happier with a smaller console, but I doubt I'll
decide to go down to 80x60 or 80x50. Greater resolutions are out of
question as well, not only due to readability issues, but also to the
screen resolutions supported by the players' monitors: mine would be
unable to display a 200x150 console (that's 1600x1200!), while a
128x96 (1024x768 screen res) is something all modern machines are
capable of displaying, even low cost notebooks.
Again, thanks for your comment.
Mingos.
Gerry Quinn
@d77g2000hsb.googlegroups.com>, dominik...@gmail.com says...
> In the worst case, I might decide to rewrite UR. Its engine is written
> with possible future changes in mind. For example, most coordinates
> (map sizes and so on) are not expressed as constant integers, but
> rather by variables. For instance, maps are not exactly 112 by 90.
> They're (max_x - 16) by (max_y - 6), where max_x and max_y are the
> total console height and width (128 by 96 tiles). If I change these in
> the constants definitions header, the game runs perfectly, but in a
> different resolution. I used this to test possible resolutions and
> pick the one that suits my needs best. 160x128 gives more
> possibilities, but savegames are quite large and the font is barely
> readable on my 17 inch monitor (besides, my eyesight isn't the best
> one can wish for and I needed to force my vision in this resolution).
> 80x60 is siply too small: not everything can be displayed at the same
> time. 100x75 is more or less OK, but the towns are awfully tiny... I
> might consider compiling two game versions: 128x96 and 100x75, just in
> case someone is happier with a smaller console, but I doubt I'll
> decide to go down to 80x60 or 80x50. Greater resolutions are out of
> question as well, not only due to readability issues, but also to the
> screen resolutions supported by the players' monitors: mine would be
> unable to display a 200x150 console (that's 1600x1200!), while a
> 128x96 (1024x768 screen res) is something all modern machines are
> capable of displaying, even low cost notebooks.
Why not just scroll the viewing area? Then map size is no longer tied
to screen resolution.
- Gerry Quinn
--
Lair of the Demon Ape (a coffee-break roguelike)
<http://indigo.ie/~gerryq/lair/lair.htm>
dominik...@gmail.com
> to screen resolution.
I thought about that, but I didn't find the idea appealing. It's
always better to see the whole map at every moment. And 128x96 is not
that big resolution. Making a scrolling view on that would make the
maps too large to explore without getting bored, I believe.
Mingos.
Gerry Quinn
26g2000hsk.googlegroups.com>, dominik...@gmail.com says...
> > Why not just scroll the viewing area? Then map size is no longer tied
> > to screen resolution.
>
> I thought about that, but I didn't find the idea appealing. It's
> always better to see the whole map at every moment. And 128x96 is not
> that big resolution.
It means you are stuck with ASCII or microscopic tiles, though.
A permanent mini-map is an alternative solution if you think it's
important to see the whole zone. (You can never see the whole map, as
there will be multiple zones.)
> Making a scrolling view on that would make the
> maps too large to explore without getting bored, I believe.
I don't follow... a scrolling view does not make maps larger. In fact
it means you can make them exactly the size that is best, even if that
is tiny or gigantic.
In my game Lair, the scrolling zone is 19 x 19 squares, and the maps
range from 20x60 to 80x80.
Mario Donick
> The problem with the large maps is again present with the city. What
> does the player do there? There isn't any architecture in the layout of
> the city which might point out more important or interesting houses.
> Right now it looks like the player should explore every house or risk
> missing an useful shop or a quest-provider (or some other type of
> important house in your game). What will the player get from exploring
> all those houses? If it's just empty houses with generic townsperson
> creatures inside, exploring the city isn't going to be much fun.
The thing you're describing here is very true for my roguelike,
LambdaRogue. Just before reading your posting, I wrote a blog entry
which talks about the problems of LambdaRogue town and wilderness, and
the approach I want to take to make LR town less boring is the one which
you call "hand-crafted cities":
> important. The other is to have a few hand-crafted cities with
> meaningful architecture, interesting buildings and handmade npcs acting
> as persistent hubs to the generated gameworld.
The LambdaRogue maps are made of puzzle tiles randomly chosen. Now for
towns these are mostly empty houses, and traders and NPCs are placed
randomly on a town tile after the generation of the time. For the next
major release of LambdaRogue, 0.3.1, I want to make towns consisting of
special puzzle tiles: say, I have a weaponshop, and I have four
puzzletiles which all mean weapon shop, and at the time of town
generation, I choose one of these four possibilities. All variants of
the weaponshop tile will be recognizable as the same building, but with
a little variance in design. For all other traders I do the same.
Finally, I put together all chosen puzzle tiles to a town, and this town
will be rather small in size (at the moment, the town sometimes is
really too big). So I combine predefined with randomness and hopefully
this will make town exploration less boring.
The "wilderness" around the town has to be made less boring, too, this
will be done by giving wilderness a meaning for winning the game. But
that's another topic.
Mario
dominik...@gmail.com
> > always better to see the whole map at every moment. And 128x96 is not
> > that big resolution.
>
> It means you are stuck with ASCII or microscopic tiles, though.
I don't find them all that small - and I don't own a 50 inch screen,
just a normal 17 inch one at one metre from my eyes. When I play on my
notebook (15 inches), I don't have small font problems either. The
only possible question is the font's readability (its design, not
size).
I don't use tiles nor plan to implement them, a custom "ASCII"
character set is fine by me.
> A permanent mini-map is an alternative solution if you think it's
> important to see the whole zone. (You can never see the whole map, as
> there will be multiple zones.)
I'd have to seriously modify TCODlib's source code to implement that,
I'm afraid. I don't feel up to the task right now, at least not until
my programming skills get better. I'm still a newbie programmer, you
know...
> > Making a scrolling view on that would make the
> > maps too large to explore without getting bored, I believe.
>
> I don't follow... a scrolling view does not make maps larger. In fact
> it means you can make them exactly the size that is best, even if that
> is tiny or gigantic.
Let me explain: since I *want* to stick with 128x96 display and with
my 112x90 maps (which, by the way, are large enough by themselves and
can contain practically whatever I want), I think making them
scrollable (even larger with UR's resolution) would make them too big
and thus, too boring.
> In my game Lair, the scrolling zone is 19 x 19 squares, and the maps
> range from 20x60 to 80x80.
See? You have a tiny scrolling zone, mine would be enormous! In your
case, scrolling is a necessity, in UR it would be merely a
programmer's caprice. Note your maps' size as well: if th largest ones
are 80x80 and you're able to stick everything you need within them,
112x90 would already result too large in Lair. There's no need to make
it even larger and scroll it.
Mingos.
stu
> > A permanent mini-map is an alternative solution if you think it's
> > important to see the whole zone. (You can never see the whole map, as
> > there will be multiple zones.)
>
> I'd have to seriously modify TCODlib's source code to implement that,
> I'm afraid. I don't feel up to the task right now, at least not until
> my programming skills get better. I'm still a newbie programmer, you
> know...
I don't understand why you think it would require serious
mods to libTCOD.
> > In my game Lair, the scrolling zone is 19 x 19 squares, and the maps
> > range from 20x60 to 80x80.
>
> See? You have a tiny scrolling zone, mine would be enormous! In your
> case, scrolling is a necessity, in UR it would be merely a
> programmer's caprice. Note your maps' size as well: if th largest ones
> are 80x80 and you're able to stick everything you need within them,
> 112x90 would already result too large in Lair. There's no need to make
> it even larger and scroll it.
What I know is that my vertical space on my laptop wont accomodate
your 112x90.
Here's a clue. make it scrollable, so for those who dont have massive
vertical monitors can scroll but on ones like yours it will fit all
nicely
on screen?
it sounds more like a cruch your refusal to think of anything but
112x90 because
it works for your computer. everyone elses computer is not your
computer.
dealing with that would be extra work, but hey, if it works for you no
need
to change it for anyone else.
-stu
dominik...@gmail.com
> mods to libTCOD.
You mean it wouldn't?
OK, I'll take a closer look at its source code...
> What I know is that my vertical space on my laptop wont accomodate
> your 112x90.
It sounds incredible your laptop won't be able to display 1024x768
resolution...
> Here's a clue. make it scrollable, so for those who dont have massive
> vertical monitors can scroll but on ones like yours it will fit all
> nicely
> on screen?
That's doable. And rather easy as well...
OK, I know It's always hard to convince me, but I guess you are right.
I will try to introduce switchable screen resolution. Is everyone fine
with 100x75 (800x600) as an alternative?
Mingos.
jice
> On May 21, 2:20 pm, dominikmarc...@gmail.com wrote:
>
> > > A permanent mini-map is an alternative solution if you think it's
> > > important to see the whole zone. (You can never see the whole map, as
> > > there will be multiple zones.)
>
> > I'd have to seriously modify TCODlib's source code to implement that,
> > I'm afraid. I don't feel up to the task right now, at least not until
> > my programming skills get better. I'm still a newbie programmer, you
> > know...
>
> I don't understand why you think it would require serious
> mods to libTCOD.
>
I think he means that the console resolution with cells of 8x8 pixels
would be too coarse for a decent looking minimap. He would need a
lower resolution, like 4x4 or 2x2 pixels. I'm currently thinking about
adding a module to libtcod that would allow to double the resolution
of the console by adding a few special characters in the default font.
With this, you would be able to draw a minimap with subcells of 4x4
pixels on a console using a 8x8 font, with a few limitations (you
cannot print text on the minimap and there will be a few color
reduction because you can only use 2 colors for each block of 2x2
subcells). The idea is cool but I'm not sure it will work...
--
Jice
jice
Personally, I still have an old Linux laptop with a max resolution of
800x600 so being able to switch to 100x75 would be cool :)
But making the whole user interface support both resolutions will
probably be a pain. I wouldn't be engaged in this in TCOD for nothing
in the world, but fortunately, I'm using a 80x50 console so TCOD
already works on a 600x400 display :)
--
Jice
Gerry Quinn
aad5e3...@a70g2000hsh.googlegroups.com>, dominik...@gmail.com
says...
> > A permanent mini-map is an alternative solution if you think it's
> > important to see the whole zone. (You can never see the whole map, as
> > there will be multiple zones.)
>
> I'd have to seriously modify TCODlib's source code to implement that,
> I'm afraid. I don't feel up to the task right now, at least not until
> my programming skills get better. I'm still a newbie programmer, you
> know...
Fair enough - if you are using a library and it delivers something
compatible with your design aims, best go with it rather than fight it.
> > I don't follow... a scrolling view does not make maps larger. In fact
> > it means you can make them exactly the size that is best, even if that
> > is tiny or gigantic.
>
> Let me explain: since I *want* to stick with 128x96 display and with
> my 112x90 maps (which, by the way, are large enough by themselves and
> can contain practically whatever I want), I think making them
> scrollable (even larger with UR's resolution) would make them too big
> and thus, too boring.
Well, yes, 112 x 90 is probably big enough not to provide any limitation
on the gameplay you design and the story you tell. In fact I think most
of your maps will probably be better off using only a small part of it.
> > In my game Lair, the scrolling zone is 19 x 19 squares, and the maps
> > range from 20x60 to 80x80.
>
> See? You have a tiny scrolling zone, mine would be enormous! In your
> case, scrolling is a necessity, in UR it would be merely a
> programmer's caprice. Note your maps' size as well: if th largest ones
> are 80x80 and you're able to stick everything you need within them,
> 112x90 would already result too large in Lair. There's no need to make
> it even larger and scroll it.
Indeed. And incidentally, Lair has a mouse-based interface where you
move several squares per turn. Small maps are *still* big enough!
(I found 60x60 appropriate for maps with rooms, corridors etc., and
80x80 for large open cave networks. Didn't really test other sizes,
though - these just seemed right when I drew them so I stuck with it.
The 20x60 is the boss level.)
Gerry Quinn
3f52a8...@l64g2000hse.googlegroups.com>, yakum...@gmail.com says...
> it sounds more like a cruch your refusal to think of anything but
> 112x90 because
> it works for your computer. everyone elses computer is not your
> computer.
> dealing with that would be extra work, but hey, if it works for you no
> need
> to change it for anyone else.
Well, there is a point at which you can't please everyone... but 90 rows
does seem like it would be a lot for most potential players.
Gerry Quinn
@f63g2000hsf.googlegroups.com>, dominik...@gmail.com says...
> > I don't understand why you think it would require serious
> > mods to libTCOD.
>
> You mean it wouldn't?
> OK, I'll take a closer look at its source code...
>
> > What I know is that my vertical space on my laptop wont accomodate
> > your 112x90.
>
> It sounds incredible your laptop won't be able to display 1024x768
> resolution...
For me it's more that my old eyes will struggle with letters 8 pixels
high! But then again, I rarely try ASCII games more than briefly
anyway.
- Gerry Quinn
Gerry Quinn
26g2000hsk.googlegroups.com>, jcwil...@gmail.com says...
> On 22 mai, 03:13, stu <yakumo9...@gmail.com> wrote:
> > On May 21, 2:20 pm, dominikmarc...@gmail.com wrote:
> >
> > > > A permanent mini-map is an alternative solution if you think it's
> > > > important to see the whole zone. (You can never see the whole map, as
> > > > there will be multiple zones.)
> >
> > > I'd have to seriously modify TCODlib's source code to implement that,
> > > I'm afraid. I don't feel up to the task right now, at least not until
> > > my programming skills get better. I'm still a newbie programmer, you
> > > know...
> >
> > I don't understand why you think it would require serious
> > mods to libTCOD.
> >
> I think he means that the console resolution with cells of 8x8 pixels
> would be too coarse for a decent looking minimap.
For most people I think his selected resolution would be the minimap!
And in fact I think he has no intention to have larger maps than 90x120,
so he doesn't need one. The minimap would be for if he had a smaller
visible area in normal play.
dominik...@gmail.com
> 800x600 so being able to switch to 100x75 would be cool :)
> But making the whole user interface support both resolutions will
> probably be a pain. I wouldn't be engaged in this in TCOD for nothing
> in the world, but fortunately, I'm using a 80x50 console so TCOD
> already works on a 600x400 display :)
Fortunately, I initially wrote UR with the intention of being able to
switch between resolutions, so there's not much problem adding such a
functionality now. Only a few recent functions will need a small
modification, that's all. I believe I can have it ready this night :).
Lower resolutions *WOULD* be a problem, though; not everything is
meant to be scrollable (character generation screens, for instance,
although I might be eager to redesign them). Main view will be
redesigned as well so it might fit on the screen in a smaller
resolution. But I'll leave that for later.
> Well, yes, 112 x 90 is probably big enough not to provide any limitation
> on the gameplay you design and the story you tell. In fact I think most
> of your maps will probably be better off using only a small part of it.
Yes, I believe that's the right way to go: maps that don't need to
occupy the whole 112x90 area should actually be smaller and only
occupy a part of the map. Others should be large, though (towns,
perhaps some caverns).
> Indeed. And incidentally, Lair has a mouse-based interface where you
> move several squares per turn.
I wrote the pathfinding algorithm in order to be able to implement
mouse-based movement as well. You click on the down staircase on the
other side of the labyrinth and the PC will go through it for you :).
> For most people I think his selected resolution would be the minimap!
> And in fact I think he has no intention to have larger maps than 90x120,
> so he doesn't need one. The minimap would be for if he had a smaller
> visible area in normal play.
No, apart from the wilderness, the maps won't be larger than that. The
idea is to be able to display the whole map with no need to use a
minimap. Still, if somebody's screen can't display 1024x768 or there's
a font size problem for those who don't have eagle's sight (hey, I'm
one of them and I have no problems on a 17 inch screen!), a lower
resolution might be the solution. But there will be no minimap, at
least until there's a way to display 1x1 pixel cells in TCODlib :).
Now, if you'll all excuse me, I'll get to implementing lower
resolutions in UR.
Mingos.
dominik...@gmail.com
ones, all maps are scrolled). Higher ones are not supported
(wilderness works OK, but other maps' display goes crazy). No point in
using them, anyway.
Now I only need to implement a config file (or a separate config
program) that will store the user's chosen resolution.
Mingos.
Jürgen Lerch
On Thu, 22 May 2008 00:33:20 -0700 (PDT), dominik...@gmail.com
wrote:
> > What I know is that my vertical space on my laptop wont accomodate
> > your 112x90.
> It sounds incredible your laptop won't be able to display 1024x768
> resolution...
The EeePC has only 800x480 or so.
Ad Astra!
JuL
--
jyn...@gmx.de / L'état, c'est toi. (Moi)
Jürgen ,,JuL'' Lerch /
dominik...@gmail.com
OK, now it won't be a problem, since you now may use 640x480 in UR :).
Mingos.
Jürgen Lerch
On Thu, 22 May 2008 15:52:05 -0700 (PDT), dominik...@gmail.com
wrote:
> > The EeePC has only 800x480 or so.
> OK, now it won't be a problem, since you now may use 640x480 in UR :).
Thanks.
I don't own one yet, but I'm seriously considering getting one.
(And the Sharp Zaurus, which could be a replacement for my
Psion 5mx, has indeed only VGA resolution.)
Ad Astra!
JuL
--
jyn...@gmx.de / Work like you don't need the money
Jürgen ,,JuL'' Lerch / Dance like no one was watching
/ Love like you've never been hurt
/ - ?
dominik...@gmail.com
> I don't own one yet, but I'm seriously considering getting one.
> (And the Sharp Zaurus, which could be a replacement for my
> Psion 5mx, has indeed only VGA resolution.)
Well, while UR can now be played at lower resulutions, the lack of a
minimap might make it less comfy than at full resolution. I'll see
what I can do about that in the future.
Mingos.