Author Topic: Desert Roguelike  (Read 12920 times)

Feco

  • Posts: 1979
Desert Roguelike
« on: January 07, 2016, 08:25:59 PM »

Last year I started putting together a roguelike so that I could learn python for grad school, and I haven't really touched it in a while.  That said, I'd really like to continue developing it, albeit slowly.  I thought I'd post some screenshots, get some feedback on the aesthetic, and perhaps pow-wow on potential features.

The inspiration for this game draws heavily on Armageddon & Dark Sun.  I think the desert environment is woefully underutilized in rougelikes.  I think the setting fits nicely some of the themes common in roguelikes -- particularly procedural generation and "harshness."

In a fantasy desert, you can make the world so old, the winds so strong, and the sands so ever-shifting, such that you can almost never find the same place twice.  In light of that, the main goals are:

1) Procedurally generate a desert world to explore via a world map.
2) Procedurally generate individual permanent locations (cities, etc.) which reside on specific world map tiles.
3) Procedurally generate all other world tiles each time they are visited, to (a) give a feeling of vastness and fleetingness to each tile, and (b) give as close to umlimited variety as possible within a single character's story.  Places like dungeons, caves, etc. will not "regenerate" if you're able to visit them more than once, but what locations are available to you will change each time.


With this in mind, I'm interested in bringing together three gameplay elements:  Survival, Dungeon Crawling, and Something to Do with Your Loot other Than Buy Stuff to Get More Loot.

Survival is easy -- food, water, and sleep.  Consequently, there will need to be varied flora/fauna, a rudimentary crafting system (likely not recipe based), and a camping mechanic.

Dungeon crawling is also easy.  You need varied hostile flora/fauna, loot, and interesting dungeon mechanics (skill-based things, such as climbing or lockpicking).

More challenging is what to do afterwards.  Home-building is an obvious choice, but I don't think that fits the aesthetic I'm shooting for.  Camping, as I envision it, will already be a sort of "home building" each time you need to do it.  You'll have to set up your fire, shelter, defenses, etc., depending on your specific environment.  In fact, I think it will resemble home-building more than a traditional "surival" mechanic, as it'll be based on what sort of camping packs and supplies you have -- no need to go find 6 wood, a flint, and a stone to start a fire each time.  You'll, for a time, at least, have better equipment to buy, but that eventually gets boring.  I'm not sure where to go here.  This is an area I'd love some input on.

Anyway, below are some screenshots.  I'd love your input!  I've hobbled together the tileset from others online and a bit of MSpaint work.  The tileset can be changed by a simple file-swap, so mostly I'm concerned with the overall aesthetic -- colors, lighting, etc.  Click the images to make them bigger.

World Map

This first batch are from the world map, and show off just a little bit of the procedural world generation that goes on.  The world is largely desert, and is divided much the same way as Armageddon might be, into sandy desert, rocky deserts, salty deserts, scrub deserts, and mountains.

A sand desert between two distant cliffs:



Deep in the mountains:



A large dust bowl in the mountains:



A cliff overlooking a scrubby valley.




A day/night and basic weather system is implemented, and their biggest effect is on lighting.  The first screenshot is night-time on the world-map:



This second screenshot is day-time, during a sandstorm (night-time sandstorms are even worse):



Local Maps

The following are local-map screenshots.  Sand dunes are the most challenging to generate right now.  My biggest issue is differentiating the dune maps from the world map.  This may be true across other areas as well.



Here's a rocky desert near a cliff-face:



Night-time with a lantern, in a similar location:



Night-time, during a sandstorm, with a lantern:



Here's the inside of a ruin.  The red "u"s are braziers.  Ruins are generated sort-of-randomly.  They're made of building blocks, and each building block has several different individual bits that can be randomized.  The addition of dungeon "themes" further randomize each building block.  Not all dungeons are tunnel-room-tunnel-room, either, but may be other sorts of structures.



Here's after exploring a bit.  I decided to give a sort of "memory" to locations, but I'm not convinced it should stay that way.  I sort of like the idea of the player getting lost.



Here's one more example of a dungeon of similar design:



These screenshots don't show everything.  Lots of creatures and plants are in (albeit unbalanced), and different sorts of creatures have different behaviors (thought they are pretty simple distinctions).  Combat works, but is based.  Food, water, and sleep systems are in, but don't really do anything but kill you at current.  I didn't show all environments, but barely most have local-map generation systems already made.  Essentially the bones for lots of systems are in -- but nothing is totally fleshed out.  You could actually play the game right now, if you're cool with ~40 enemies and something like 10 pieces of equipment.

Thoughts?  Don't be shy if you think it's ugly or stupid.  Points to anyone who recognizes the placeholder title-image.
« Last Edit: January 07, 2016, 08:34:39 PM by Feco »
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Mordiggian

  • Legend
  • Posts: 447
Re: Desert Roguelike
« Reply #1 on: January 07, 2016, 08:29:11 PM »
Is the title image a shot from Mars? It looks really familiar but I can't place it!

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #2 on: January 07, 2016, 08:31:26 PM »
Is the title image a shot from Mars? It looks really familiar but I can't place it!

Boom, points.  You can trade them in at your closest points retailer.
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Case

  • Helper
  • Posts: 3034
Re: Desert Roguelike
« Reply #3 on: January 07, 2016, 09:03:00 PM »
Very nice!

Ath

  • Legend
  • Posts: 1076
Re: Desert Roguelike
« Reply #4 on: January 08, 2016, 10:36:33 AM »
That is pretty damn cool.  Looks great so far.
Ourla:  You're like the oil paint on the canvas of evil.

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #5 on: January 08, 2016, 10:42:56 AM »
Thanks for the nice comments everyone!  

It's funny how walking away for a while can help you solve a problem.  The biggest "technical" hurdle I've had so far was save compression, but I was just overthinking it before.  I solved it this morning in less than an hour.

Also, I've been thinking about scrapping procedural generation of cities.  I've always liked the permanency of certain things, like some cities, in other roguelikes -- it gives some stark contrast to the randomness of the rest of the world.  That said, their locations and presence in any particular map would be randomized.

Anyone have thoughts on that?  Would a more or less completely new world each time be more interesting?  The biggest tradeoff wold be complexity and detail -- I could have a lot more of both with hand-made cities.  Procedurally generated dungeons can be made relatively complex without too much problem, but cities are another monster completely.
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Ath

  • Legend
  • Posts: 1076
Re: Desert Roguelike
« Reply #6 on: January 08, 2016, 11:12:26 AM »
You could do a quasi-procedural city generation.  Make a few static "templates" which could have a few static buildings, but the shops or other buildings could be pulled from a pool.  Or you could do pieced together cities, where you might have several pieces to a city that are then joined together by certain considerations.  Maybe you have 10 pieces, 5 are shop pieces, 2 are generic, etc.   Each "city" is required to have at least 2 shop pieces, one generic, and one plot piece.
Ourla:  You're like the oil paint on the canvas of evil.

LauraMars

  • Helper
  • Posts: 9393
Re: Desert Roguelike
« Reply #7 on: January 08, 2016, 11:14:24 AM »
I've always liked the permanency of certain things, like some cities, in other roguelikes -- it gives some stark contrast to the randomness of the rest of the world.  That said, their locations and presence in any particular map would be randomized.

Anyone have thoughts on that?  Would a more or less completely new world each time be more interesting?  The biggest tradeoff wold be complexity and detail -- I could have a lot more of both with hand-made cities.  Procedurally generated dungeons can be made relatively complex without too much problem, but cities are another monster completely.

I say just recreate Allanak in your roguelike!!

This looks amazing btw.
Child, child, if you come to this doomed house, what is to save you?

A voice whispers, "Read the tales upon the walls."

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #8 on: January 08, 2016, 11:33:11 AM »
Thanks Laura!

You could do a quasi-procedural city generation.  Make a few static "templates" which could have a few static buildings, but the shops or other buildings could be pulled from a pool.  Or you could do pieced together cities, where you might have several pieces to a city that are then joined together by certain considerations.  Maybe you have 10 pieces, 5 are shop pieces, 2 are generic, etc.   Each "city" is required to have at least 2 shop pieces, one generic, and one plot piece.

This is sort of how the traditional dungeons are made so far -- I have a set of building blocks which are "hand-built" enough to be interesting, but then have lots of qualities randomized to make them varied and fresh.  Themes (and sub-themes, but that's as deep as I'm going) to particular dungeons then further modify those blocks.

So yeah, I think this is a good idea.  I'm wondering if I should lean more on a hand-built design for cities though, to give the world more character.

Perhaps there are 20 hand-built cities, and 5 appear in game.  25% of each city might be generated from building blocks, say, a bazaar, and the housing (the bazaar yard might even change each time you visit it).  Certain details of the city are generated either randomly or based on world-map location, such as building materials.  The rest of the city is completely static.  This might allow me to write 20 really unique cities up, with really intricate details about who lives there, without having to generate some sort of dwarf-fortressesque history.  Perhaps a random tavern or castle here and there for inevitable procedural wackiness -- wackiness is part of the fun.

Thanks for your input!  Talking through this has been really helpful.

Since we're on the topic of generation, here's a shot of a spider-cave.  For some reason there aren't many webs in the particular cave.  The cave is generated via a cellular automaton, which is pretty neat (I did a lot of leaning heavily on other code to make it work).  I think they end up looking pretty cool.  You can't see much with the lantern, but that's sort of the point!



If you squint really hard, you should be able to see the faint memory of places already explored.  My thought in making it hard/almost impossible to see is to impart a vagueness to the map-memory.  The parts you've been look different, so you think you've been there, but it's so dark you can't always tell what's there.  If you try really hard to look (or cheat), you can figure it out, which I think adds a bit of immersion.  This might be eye-straining though -- I'll have to wait and see.
« Last Edit: January 08, 2016, 11:35:31 AM by Feco »
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #9 on: January 09, 2016, 04:43:16 PM »
I've had some people offer to do designs for building blocks, be it buildings, rooms, natural features, or what have you.

If anyone else is interested, don't hesitate to contribute!  Rexpaint is a neat little tool to use to make the blueprints.



Above is what the final blueprints look like.  The numbers and letters are modular entities -- they can be any of number things randomly (or may be weighted based on location theme).  Other things, like say, cobwebs from spiders, treasures, monsters, traps etc., are added later (but can be defined in blueprints as well.)  In this case, for example, the numbers can either be walls/pillars, or nothing.

The idea with these modular blueprints is to give a varied basis to give LOTS more variation to.

Cool natural features, buildings, go crazy and PM me!  Blueprints must be square -- what's in them don't have to be, and in fact I discourage you from making squares and rectangles -- they're easy to generate.  The above is 15x15.

In other news, I finally got a z-level system working that I like.



From this ravine, you can't see a whole lot -- there are lots of rocky and mountainous outcroppings all around.



Getting a higher vantage point by climbing one of the cliffs give you a better view -- now you can see the gith encampment atop the other structure, as well as some sparse scrub in the distance.

Multiple light sources are working as well:



The final intended system isn't in, but the framework is in place to have a dynamic lighting system.  This will be particularly helpful for exploring dark places and not getting lost.
« Last Edit: January 09, 2016, 04:45:15 PM by Feco »
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Rathustra

  • Administrator
  • Posts: 1113
Re: Desert Roguelike
« Reply #10 on: January 09, 2016, 08:14:28 PM »
Wow! This is so cool. Roguelikes were my first fascination before I got into RPI MUDs. I've tried to pick up programming before -just- to make a roguelike or a MUD. If I hadn't ended up on staff with Armageddon I'd probably have ended up tinkering myself to death trying to make one.

I wish I wasn't so busy with Armageddon to just build stuff for you full time.

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #11 on: January 09, 2016, 08:18:17 PM »
Thanks! If inspiration strikes, feel free to just make one or two things and send them to me!  I'm happy to include them!

I'll need some writing done too.  I really like writing so I'll hog a lot of it, but I can share!
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Rathustra

  • Administrator
  • Posts: 1113
Re: Desert Roguelike
« Reply #12 on: January 09, 2016, 08:20:05 PM »
Thanks! If inspiration strikes, feel free to just make one or two things and send them to me!  I'm happy to include them!

I'll need some writing done too.  I really like writing so I'll hog a lot of it, but I can share!

Argghh - stop, or I'll end up dropping the tablelands plot to spew endless pages of ideas here!

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #13 on: January 10, 2016, 12:08:59 PM »
With the addition of visibility and z-levels, climbing mountains has become more interesting than exploring the desert.  I think I need to start generating more things to climb in the desert!

It's also become pretty easy to get lost in the mountains, if you find yourself somewhere low without a real path to follow.  That's pretty neat.

The fact that I spend time exploring instead of programming is probably a good sign!
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Marauder Moe

  • Posts: 13005
Re: Desert Roguelike
« Reply #14 on: January 10, 2016, 12:10:37 PM »
This is all very cool.  I'd love to see some video.

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #15 on: January 10, 2016, 01:05:51 PM »
Thanks!  I'll put something together eventually.

Meanwhile, I just saw this picture on Reddit:



Mars is a nice inspiration.
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #16 on: January 11, 2016, 08:26:37 AM »
So I started a combat overhaul last night, and it's going nicely.

Fighters interact with their weapons/armor, and their physical attributes.  Physical attributes give one a greater or lesser ability to dodge or strike.

Weapons are defined by material properties (hardness, sharpness, and weight), and weapon properties (piercing damage, slashing damage, and bludgeoning damage).  The material properties are generally involved in how the weapon interacts with armor, and the weapon properties allow us to define how a weapon functions (clubs are blunt all over, but swords have edges, flats, hilts, and points).  These all interact in cool ways -- hammers are specialized can-openers, and swords have lots of versatility, while spears and axes have moderate versatility and specialization.  A weird consequence is that a really heavy stone sword *might* make a better bludgeoning weapon than, say, a light bone hammer -- I like that though, seeing as a stone sword is basically just a club.

Armors are defined by material properties (hardness, sharpness, and weight), and armor properties (just coverage, for now).  Coverage determines how much of one's body is covered by armor.

Attacks can miss the target, be dodged/parried, bypass armor, sunder armor, be totally blocked by armor, or damage through armor.  The rate and effects of these situations are all determined by the physical, material, and weapon/armor properties in play.

11 materials, 12 types of armor, 21 weapon designs, and some shields are already defined.  The framework is in place for basic attack/defend combat and equipment usage for the player (other creatures need work).  I have to totally redefine attributes for every creature I've already written.  Body-parts are not implemented yet - I'm still deciding how I want them to work.  Eventually, I'll have to write a better leveling system, which will lead to coding proficiency and skills, which will lead right back to the combat system.  Ranged combat will also need to be implemented, but that shouldn't be too difficult.

Once I have creatures redefined so that we can have basic attack/defense exchanges in game, I'll post logs!

Does anyone have thoughts on combat?  Any features you'd like to see, or are sick of seeing?
« Last Edit: January 11, 2016, 08:32:52 AM by Feco »
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #17 on: January 16, 2016, 10:44:59 AM »
I give an update on developers forums every Saturday.  Figured I'd just post that update here as well.  A lot of it I've posted as I was developing it, but here's a lot of the finished bits for this week.

I really want to try to get the first Alpha release done here in the next couple of weeks.  There are only a few systems that need to be implemented before the game is at a real playable state, and thankfully, ALL of them have some other complete system they are either dependent on, or can be based off.  They are:

* City/Village Generation
* Ranged Combat
* Magic & Psionics
* Treasure generation & placement (this is already in using a really sloppy method)
* Talking & Trading with NPCs
* Character generation GUI

Other than that, I just want to add shitloads of content, which is actually a lot harder than coding systems.  Anyway, on to the update:



Desert RL

This week has seen some core feature implementation, as well as a lot of cleaning up the back end.  Memory usage is still at ~200MB at its worst, which is probably way too high.

I've also made a number of aesthetic changes to better differentiate local and travel/world maps.



Here is a picture from the travel/world map.  Each tile on the travel map takes 5 minutes to walk across.  The character is standing in a rocky wasteland, with mountains to the East, and sandy waste to the West.  The addition of hills & plateaus to the landscape really give it the sense of scale it needed.



This is a local map in the same area, at the base of a sandstone cliff.  Faint ASCII marks have been added to give elevation changes a "sloped" look.  This is particularly important, because I've also introduced elevation dependent LOS.



The new "z-levels" are hard to appreciate in static images.  Above, the player has climbed a sloped path to the top of the sandstone cliff.



Here is a GIF from the travel map showing the system a bit better.  The player is approaching a massive plateau from the southeast, and spots it's at the beginning of some sort of scrub plain, with more cliffs off in either direction.  The player can find a path up, and get a better view.  This becomes really cool in the mountains;  LOS is generally very small there, until you get a high-spot with an unobstructed view.



The other major thing I've implemented is a more friendly inventory management menu.  I'm not committed to the exact layout and proportions right now, but at least it functions.  The "place in a container" function is still a bit buggy, but I'm working it out.

What you'll also see is that, in the description for the bastard sword, there are a few specific properties it has.  Namely, hardness, sharpness, and weight.  You'll also notice that it gives a slashing damage die, and lists that it's capable of piercing and bludgeoning.  This is also a good time to point out the ATH, MEN, and INT on the status window (Athleticism, Mentality, and Intuition).   All of these are examples of the new materials, unit statistics, and combat systems.

All mobs have an Athleticism score (dexterity, strength, etc.), a Mentality score (intelligence, wisdom, etc.), and an Intuition score (a mix of luck and instincts).  These are already working in various ways to affect pretty much everything that happens.

All materials have a base hardness, sharpness, and weight to them that represent their possible uses.  Armors are then assigned a "coverage" score, a percentage, based on their design.  Weapons are given slashing, bludgeoning, and piercing properties, based on their design.

A sword slashes, but can pierce and bludgeon.  A spear pierces, and can be used to bludgeon.  An axe slashes, and can be used to bludgeon.  A hammer bludgeons, and that's it.  These aren't the strict classes of weapons -- these are just examples.  There are lots of ways to play with this system -- scimitars can't stab, but they may be better at slashing, for example.

Hardness, weight, and coverage are most important to armors.  All material and design properties go into defining weapons, and all are important for various tasks.

In combat, one has to hit someone, and then they either have to hit a gap in the armor, or sunder their armor in order to do full damage.  Slashes mostly rely on sharpness, bludgeoning on weight, and piercing equally on weight and sharpness to sunder armor.  All 3 material properties are important for sundering though, for any weapon type -- it's just weighted differently.

Armor doesn't always completely stop blows -- it often just weakens them substantially.  A percentage of blunt damage goes through armor.

What this makes for is a fairly complicated combat and equipment system, with a pretty simple execution that doesn't require too much thought from the player.  Things are designed to be intuitive.  Harder armors resist damage better, but are heavier -- strictly blunt weapons are better at attacking armored enemies, as they can still give lots of damage even when striking a strong part of armor -- swords are versatile, as they have points and heavy hilts -- etc., etc.



Here are just a couple exchanges between the player and a raider.  A few notable things happen:

 * Both successfully dodge some attacks.
 * The player fails to penetrate the raider's armor, but the heavy sword damages through it.
 * The raider stabs through the player's armor -- obsidian is very sharp.
 * The raider stabs the player through a gap in his armor.
 * The player makes use of the sharp-end of the sword after feinting.

The feint is the result of character customization.  Instead of implementing skills which just make you better with certain things, or just leveling you up and giving you extra stats, instead, "skills" will open up the opportunity to do advantageous things.

In this case, when the player straight misses the enemy, there's a chance based on the player's intuition that they'll instead feint, and make an attack with an alternative part of the weapon.  This is not a good skill to take for someone with low intuition -- it won't happen often.  It's also not good to take if the player plans to use strictly blunt weapons -- most won't have alternative attack types.

It's been a fun week!

In any case, going forward this week I hope to:

* Fix up the inventory screen and link it to other screens (just by listing keys, suck as (E)quipment, so the player knows what to press)
* Use the equipment screen as the basis of the character generation screen, and fully implement character generation.
* Generate content!  The game is completely playable now, but it just needs more content.  More types of dungeons, more monsters, more items, etc., etc.  I have a lot more in this regard than I've shown, just so as not to spoil anyone who might want to play.
* Figure out what to do with the empty spot on the HUD at the bottom-right.  I don't want to do a mini-map.  I'm considering putting context relevant controls (that might help to make the travel-map look even more different).
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Marauder Moe

  • Posts: 13005
Re: Desert Roguelike
« Reply #18 on: January 16, 2016, 02:22:57 PM »
Advertising space.   ;)

(Or just extend the right hand window all the way down and put more info in it.)

Rathustra

  • Administrator
  • Posts: 1113
Re: Desert Roguelike
« Reply #19 on: January 16, 2016, 04:15:43 PM »
Will you be adding systems to track exhaustion and weather? In Dark Sun heavier armour (and rare bits of metal armour) would be counterbalanced by the fact that they increased the heat experienced by a player character. This, plus the day/night and yearly cycles might make choosing armour take into account the part of the world/environment being fought in.

Perhaps information about weather, the 'state' of the land (drained/defiled/disquieted), the direction and intensity of the wind, output of any passive psionics that give you a sixth-sense or 'attunement to the land' could be put in the bottom right hand corner? In settlements this could also display passively noticed things about the attitude of those around, the state of the buildings or one's 'standing' in the settlement.

The intuition thing is neat - maybe it could be tied to a set of 'feats' (In the 3rd edition D&D sense) or 'traits' that give you a bonus to intuition in certain situations. E.g. - 'soldier' - bonus to intuition in humanoid/humanoid combat; 'diplomat' - bonus to intuition in social situations. Perhaps you could even make each stat work in the same way - having them trigger at certain points to offer choices, or take beneficial action. Then you could design traits around that too.

Another classic system from Dark Sun was the way that armour was cobbled together from different sources to make a patchwork, with one's AC being determined piecemeal. Is this possible in DesertRL?

While I'm spamming you, I spent a lot of time last week thinking about Sorcerer Kings and how they fit into Armageddon and Dark Sun before it. It was spawned out of thinking about how you were randomly selecting a set of present cities from a list. Perhaps there could be a pool of possible 'Mage Lords' with different attitudes (desires, motivations, biases, etc.) which are picked from and assigned to the cities (plus a bonus 'overthrown' option for a city without a Mage Lord). The assigned Mage Lord could subtly adjust features about the city as it is generated - the sort of races that appear there, the presence or absence of slaves and the jobs the slaves do, The prevalence of magick, the amount of organised resistance against them, the appearance of guards and their equipment, etc.

Then I thought beyond this and considered - what if these different Mage Lords were also set up to have alliances and rivalries with each other either overt or in secret. Perhaps this procedurally generated web of 'big bosses' could be what adds a dynamism to the game world. But then I realized this was a little beyond what you were probably planning!

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #20 on: January 16, 2016, 05:30:52 PM »
Advertising space.   ;)

(Or just extend the right hand window all the way down and put more info in it.)

That's a pretty simple solution, I guess!  What sort of info would you like to see on a HUD?  I know that's probably a tough question without knowing what all possible info exists.

Will you be adding systems to track exhaustion and weather? In Dark Sun heavier armour (and rare bits of metal armour) would be counterbalanced by the fact that they increased the heat experienced by a player character. This, plus the day/night and yearly cycles might make choosing armour take into account the part of the world/environment being fought in.

The green bar on the HUD is stamina -- you lose stamina by moving and fighting.  You regain stamina (normally) by sleeping.  Currently temperature and weather don't affect your stamina, but do affect your thirst.  My thought was that thirst gives you a single "survival stat" which varies based on your environment.  Stamina and hunger are also very important, but you don't have to keep track of a ton of variables all at once.  I'm open to changing this, though.

Since materials have stats, and equipment have stats, that means that armors have stats specific to their material and design.  Currently weight affects combat performance, but it wouldn't be hard it all to make it affect stamina, or heat (and thereby thirst).  The question is, does this make the game more interesting, or just more complex?  I'm totally open on this issue.

Yearly cycles aren't something I'd considered.  There's a date and whatnot  (I should add that to the HUD...), but it doesn't matter for weather.  I'll consider this!

Perhaps information about weather, the 'state' of the land (drained/defiled/disquieted), the direction and intensity of the wind, output of any passive psionics that give you a sixth-sense or 'attunement to the land' could be put in the bottom right hand corner? In settlements this could also display passively noticed things about the attitude of those around, the state of the buildings or one's 'standing' in the settlement.

I think this is a good idea.  I had considered turning it into an "description space," to give short descriptions of areas.  There's room to add more info to the right-panel, so maybe I can add weather info and stuff there, and location specific stuff in the corner.

The intuition thing is neat - maybe it could be tied to a set of 'feats' (In the 3rd edition D&D sense) or 'traits' that give you a bonus to intuition in certain situations. E.g. - 'soldier' - bonus to intuition in humanoid/humanoid combat; 'diplomat' - bonus to intuition in social situations. Perhaps you could even make each stat work in the same way - having them trigger at certain points to offer choices, or take beneficial action. Then you could design traits around that too.

Thanks!  And yeah, I think these are great ideas.  I should explain that the "Skills" in the game are analogous to feats.  Leveling up will give you a few stats upgrades (HP, attack bonus, etc.), and then you can buy Skills.  They are all generally tied to a character attribute, and all do things like you mention!

The only other big "character customization" things are mutations, which will be tied to magic and psionics, among other things.

Another classic system from Dark Sun was the way that armour was cobbled together from different sources to make a patchwork, with one's AC being determined piecemeal. Is this possible in DesertRL?

I started programming body parts, but scrapped it pretty early on.  Currently, armor just fits in an armor slot, and represents a full set.  Different body parts is something I really wanted to do (and still want to do sometimes).  Honestly, I just found it tedious to code from the ground up, so jumped ahead to the fun part by making a simple base.

That said, the base and programming language are pretty modular.  A "body parts" list is a single line of code.  The only tedious part would be going through and defining body parts for each creature (thankfully creature types would cut down the load here).  The combat system would only need a few lines extra to grab the list of body parts and pick one.  The system already checks for armor, and for what the creature is made of (usually for natural armor), so it's pretty much all set to go.  I guess I hadn't thought about how much easier it would be to implement, now.

The question is like above, though -- would it be more interesting, or just more complex?  I don't know the answer, so I appreciate your thoughts.

While I'm spamming you, I spent a lot of time last week thinking about Sorcerer Kings and how they fit into Armageddon and Dark Sun before it. It was spawned out of thinking about how you were randomly selecting a set of present cities from a list. Perhaps there could be a pool of possible 'Mage Lords' with different attitudes (desires, motivations, biases, etc.) which are picked from and assigned to the cities (plus a bonus 'overthrown' option for a city without a Mage Lord). The assigned Mage Lord could subtly adjust features about the city as it is generated - the sort of races that appear there, the presence or absence of slaves and the jobs the slaves do, The prevalence of magick, the amount of organised resistance against them, the appearance of guards and their equipment, etc.

Then I thought beyond this and considered - what if these different Mage Lords were also set up to have alliances and rivalries with each other either overt or in secret. Perhaps this procedurally generated web of 'big bosses' could be what adds a dynamism to the game world. But then I realized this was a little beyond what you were probably planning!

You're absolutely NOT spamming me!  I want input!  Seriously, this is awesome.

I think separating rulers from cities and assigning them in a semi-random way is a great idea.  Programming this is straight-forward -- the challenge is generating the specific content (the modular ruler and city blueprints, if you will).

Like you're saying, each ruler will have a set of preferences and attitudes.  These preferences are attitudes will be shaped by the sort of city they rule, and then, the city they rule will be shaped by their preferences and attitudes.  I hadn't thought to make them interact, but the more I think about it, the less challenging it seems to implement.

The creative bits are what I really need help with!  Blueprints (both map blueprints, and descriptive ones!) are time consuming to make, and the more the better.

Oh, and I added basic mouse support to the inventory today.  That's pretty neat.
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #21 on: January 16, 2016, 06:26:17 PM »
For shits and giggles I tried to implement body parts in as few lines as possible.  I only needed 2 new lines to make it all work on the back-end.  I'll have to add more to make it visible to the player, but... yeah.  That was a lot easier than I thought.
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Asmoth

  • Posts: 1210
Re: Desert Roguelike
« Reply #22 on: January 16, 2016, 06:30:40 PM »
So is this going to be a dwarf fortress type game?  But Armageddonish?
<19:14:06> "Bushranger": Why is it always about sex with animals with you Jihelu?
<19:14:13> "Jihelu": IT's not always /with/ animals

Harmless

  • Posts: 2863
Re: Desert Roguelike
« Reply #23 on: January 16, 2016, 06:31:19 PM »
i'd play it foooor sure :)
Useful tips: Commands |  |Storytelling:  1  2

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #24 on: January 16, 2016, 06:55:15 PM »
It'll resemble dwarf fortress adventure mode in some ways, I guess, but I won't ever begin to be able to approach that level of simulation!

Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC