Author Topic: Desert Roguelike  (Read 11722 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: 9389
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: 1106
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: 1106
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: 1106
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: 2838
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

Asmoth

  • Posts: 1210
Re: Desert Roguelike
« Reply #25 on: January 16, 2016, 06:56:46 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!


It's impressive so far, keep up the good work and keep in mind that silly little games are sometimes huge successes on Steam Early Access.
<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

Marauder Moe

  • Posts: 13005
Re: Desert Roguelike
« Reply #26 on: January 16, 2016, 07:13:57 PM »
If you're doing body part/damage/wounds, a little color status ascii person would be a good use for that space.

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #27 on: January 17, 2016, 09:29:07 AM »
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!
It's impressive so far, keep up the good work and keep in mind that silly little games are sometimes huge successes on Steam Early Access.

Haha, thanks.  Entrepreneurship makes me uncomfortable, though, so it'll be free.

If you're doing body part/damage/wounds, a little color status ascii person would be a good use for that space.

Yeah, that's a good point.  I'm not sure if I have the artistic chops to get something not absolutely stupid looking together, so I may go with status bars.
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #28 on: January 19, 2016, 06:35:47 PM »
Big-deal game-play question to follow.  I'd love some feedback here.  For scale, remember that each tile takes about 5 minutes to walk across on the world map, and 1 second to walk across on local-maps.



You've been traveling for days through the sandy, dune-covered deserts to your west, and you've spent much of today over the more flat, sandy, rocky wastes leading east.

It's late in the afternoon.  To the east, you spot two very, very large outcroppings -- perhaps absolutely massive mesas of some sort.  You suspect it will be getting dark by the time you reach the pass between the two, so you decide that camping upon the larger raised area might be prudent.  You only hope there's a pathway up -- the climb would take some time.



Success -- the northern mesa is very large, and has plenty of space to explore.  On the south end, overlooking the pass, is a much, much, smaller raised area.  There may even be some ruins there -- seems like the sort of place someone might have built a fortress in some ancient time.

You wander over to that area, and explore.

To do this as a player, you walk over and press '>' on your keyboard.  This takes you down to a 'local map.'  They work in a particular way, and I've shared a few screenshots, but I'd like to know what you, as a player, would expect and/or would like to see when pressing the '>' button to explore an area.  This can mean any number of things, so please interpret the question however you like.

I know that's sort of a vague way to ask a question, and I was light on what details I'm looking for, but I think that's the best way to get an objective measure of what I'm interested in.
« Last Edit: January 19, 2016, 06:40:20 PM by Feco »
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Marauder Moe

  • Posts: 13005
Re: Desert Roguelike
« Reply #29 on: January 20, 2016, 02:33:02 AM »
So, as a general piece of advice, you should NOT by copying keys or UI design elements from Dwarf Fortress.

Is switching from overland map to local map a big deal for the game/engine?  If not, I might make it as simple as "enter".  Even if so... maybe "enter" and then a confirmation dialong.

Case

  • Helper
  • Posts: 3034
Re: Desert Roguelike
« Reply #30 on: January 20, 2016, 02:40:34 AM »
So, as a general piece of advice, you should NOT by copying keys or UI design elements from Dwarf Fortress.

Is switching from overland map to local map a big deal for the game/engine?  If not, I might make it as simple as "enter".  Even if so... maybe "enter" and then a confirmation dialong.
I had no idea that usage of '>' came from the totally definitely pre ToME/Angband/PernAngband game 'Dwarf Fortress'
« Last Edit: January 20, 2016, 02:42:28 AM by Case »

Asmoth

  • Posts: 1210
Re: Desert Roguelike
« Reply #31 on: January 20, 2016, 02:44:33 AM »
So, as a general piece of advice, you should NOT by copying keys or UI design elements from Dwarf Fortress.

Is switching from overland map to local map a big deal for the game/engine?  If not, I might make it as simple as "enter".  Even if so... maybe "enter" and then a confirmation dialong.
I had no idea that usage of '>' came from the totally definitely pre ToME/Angband/PernAngband game 'Dwarf Fortress'
Pretty sure what Case is saying here is you can't copywrite keybinds. So leave the man to make his game and shush.
<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

Case

  • Helper
  • Posts: 3034
Re: Desert Roguelike
« Reply #32 on: January 20, 2016, 02:47:57 AM »
So, as a general piece of advice, you should NOT by copying keys or UI design elements from Dwarf Fortress.

Is switching from overland map to local map a big deal for the game/engine?  If not, I might make it as simple as "enter".  Even if so... maybe "enter" and then a confirmation dialong.
I had no idea that usage of '>' came from the totally definitely pre ToME/Angband/PernAngband game 'Dwarf Fortress'
Pretty sure what Case is saying here is you can't copywrite keybinds. So leave the man to make his game and shush.
Well no I'm not saying that at all, because I can both spell and use the word 'copyright' appropriately in a legal context - but more or less that Dwarf Fortress stole tons of keybinding and UI by this standard of theft Moe is setting.

Marauder Moe

  • Posts: 13005
Re: Desert Roguelike
« Reply #33 on: January 20, 2016, 02:48:56 AM »
I'm don't mean to say Feco shouldn't copy keys/UI from Dwarf Fortress because of any copyright/originality issues.  I'm saying it because the UI is HORRENDOUS.


Case

  • Helper
  • Posts: 3034
Re: Desert Roguelike
« Reply #34 on: January 20, 2016, 02:52:44 AM »
I'm don't mean to say Feco shouldn't copy keys/UI from Dwarf Fortress because of any copyright/originality issues.  I'm saying it because the UI is HORRENDOUS.


Oh yeah it is, good point. Although '>' is reasonable notation for an uncommon action in a roguelike, and it looks like an arrow so entering is ok.

Marauder Moe

  • Posts: 13005
Re: Desert Roguelike
« Reply #35 on: January 20, 2016, 02:56:55 AM »
The enter button literally has the word "enter" on it.   :P

Case

  • Helper
  • Posts: 3034
Re: Desert Roguelike
« Reply #36 on: January 20, 2016, 04:51:31 AM »
The enter button literally has the word "enter" on it.   :P
Mine has an arrow ;P

Rathustra

  • Administrator
  • Posts: 1106
Re: Desert Roguelike
« Reply #37 on: January 20, 2016, 05:13:06 AM »
> is used because it is the symbol for a down set of stairs, < is used for leaving as it is the symbol in roguelikes for up stairs.

I'm not 100% sure what you're asking, Feco - but often when you use > to 'zoom in' like in UrW or Caves of Qud you end up in the center of the generated 'local map'. If you're asking if there are any ideas that could build on this - how about having a prompt for the player with enough sense/training that allows them to adjust where they appear on the local map when where they appear might be important.

For example - say the player does find a set of ruins and heads over to tap > - maybe they could be asked if they want to approach the ruins from afar, observe the ruins for a time (which would generate some information on what they might see), or stride directly up to the gates of the outpost. A less wise, or unexperienced adventurer might end up going straight to the gates of the outpost (for better or for worse). But the experienced scout would stop a while to watch and would see a pack of gith leaving and returning on patrol! This would give them a reason to approach from afar and plan their raid more carefully.

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #38 on: January 20, 2016, 08:29:55 AM »
Hahaha, maybe I was TOO vague.  Rathustra's answer was more what I was looking for.  Thanks for that!

The point of being vague was to not limit your answer.  I did have a specific mechanic in mind, but I'm also just curious what others would think would be fun or cool.

I appreciate the control talk too.  '>' is standard in almost every roguelike to "go down." Most controls are following roguelike standards.  Others will hopefully be intuitive, and/or will have in screen instructions.
« Last Edit: January 20, 2016, 12:51:40 PM by Feco »
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #39 on: January 23, 2016, 09:32:55 AM »
Here's my weekly update from the developer's forum.  Still looking for people to do blueprints.  I can provide more guidance if that would change anyone's mind.  I find content generation boring compared to system building, so that's what will ultimately slow development.

I might try to get a website set up this week.  If I do that, I'll post a link, keep a blog there, and quit spamming the boards.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Desert RL

Not much to show with screenshots this week, as I worked mostly on the back end. I did a lot of optimizing of current systems, and set up some new ones.

The largest optimization was probably one I should have been using since the beginning: seed-based map generation. Currently I save the world-map as a complete array, but all other maps (importantly, local outdoor maps) are now largely regenerated using a saved seed. The filesize for the outdoor spaces was roughly 3MB compressed. Each. This was a problem. Now, we've only got a 32 bit string, max, for each map, plus whatever space the list of objects/etc. from that map takes up. That's a MASSIVE improvement.

The game currently takes up ~170MB memory while on the world map. I'd still like to reduce this, and I suspect that'll involve recoding the worldmap to load from disk in chunks. Saves, from the start, are roughly ~3MB on disk, compressed. I'm pretty happy with that.

Initially I had planned to make local-maps non saving as a gameplay feature -- everything would be changing all the time. I've scrapped that in favor of the world-map changing ever so slightly. The more sandy and windy an area, and the worse the weather, the more likely it is to change a bit. These changes would drastically change the local areas affected, so you're still at risk at losing access to ruins/etc., or to finding new things to explore.

The other change I'd like to make is in world-map generation speed. The generator actually works pretty fast, but I don't load a map unless it has a certain number of features generated, so the time to generate a world is VERY variable. It could take 2 to upwards of 30 seconds. This is a low priority change, though, as it only happens once per game.

In the world, I'm up to 9 distinct biomes, with several variations (I think I've shown off mostly dune seas and rocky wastes). The biggest change is that these biomes change in appearance/weather/difficulty based on their elevation, remoteness, and neighboring biomes. This should add a good deal of variety. Since I mentioned elevation, it's worth mentioning that elevation is becoming increasingly important as development continues. Climbing a mesa could aid in helping you find ruins, or could be your last chance of spotting water when you've run out.

Most major gameplay systems are in place, but many (like magic, psionics, and city generation) might as well just be called skeleton systems, because they simply don't have content generated yet.

In fact, content-generation truly is my bottleneck. Most things are procedurally generated, but in order to give the world more details, I've also been building blueprints that are fairly modular. These blueprints have many features which are different each time they're loaded, which are further modified by the generators (I think I've mentioned this before). Honestly it doesn't take that much time or thought to build one, and the reward is high (you can potentially get dozens of room designs from a single blueprint). I just think it's boring.

Initially I was aiming for next weekend to be the first alpha release. There are a few changes at work though, so that's probably going to change. I'm probably looking at a month for a stable and feature-rich release. It's tough to say, though, so I'm going to try to avoid making concrete predictions or setting deadlines for myself. Once all my current systems are fleshed out I will do an alpha release. I'll never be happy with the amount of content I add, and I'll keep coming up with new ideas for systems, but I can just save all that for future updates.

I should build a website and come up with a real name for the project.
« Last Edit: January 23, 2016, 09:34:32 AM by Feco »
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Rathustra

  • Administrator
  • Posts: 1106
Re: Desert Roguelike
« Reply #40 on: January 23, 2016, 06:51:54 PM »
I'd love to help with blueprints, but until I finish my current Arm workload I don't have the time on top of all my RL stuff!

Asmoth

  • Posts: 1210
Re: Desert Roguelike
« Reply #41 on: March 21, 2016, 12:16:30 AM »
Whatever happened to this, haven't heard much lately.  Tell me you didn't quit, it looked like it would be really fun to play.
<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

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #42 on: April 11, 2016, 05:26:22 PM »
Nope, haven't quit!

Progress is moving along at snails pace -- I'm starting work in my dissertation lab, have had several out-of-town stints, and my wife & I are in the process of buying a house.

I'll try and update at some point!
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #43 on: February 10, 2017, 07:08:31 PM »
Things have kept me away for a while, but I'm still working on this in my spare spare-time, and my largest bottleneck is still content generation.  I admittedly love building systems, but I find being creative pretty challenging.  I'd love some help, if people are interested!  I need help building things!

A lot of things are generated on the fly, and the hope is that the game generates interesting structures/items/etc. on its own... but, it's always great to have some hand-made items as well.  Even if you only want to make one item, please do!  A single item can have many variations once it goes through the item generation code, so it'd be helping add a lot to the game.

In terms of item quality, I need everything from totally shitty, to pretty nice.  Think Armageddon level technology.  Feel free to be creative.  Feel free to be boring, or really weird -- anything you want.  Nothing is too mundane or too strange!  Keep things non-magical, though.

There are a lot of variables that go into each item, but I actually only need a fraction of them from you!  The rest is automatic, or requires only a little extra effort from me.

If you're interested, please post here or PM me.  You'll have to copy and past the templates into notepad, or a similar program.  I'll PM you an email address to send the final text file to, when you're done.

Here's are the objects I currently need:

Traveling clothing and gear

No combat items (weapons/armor/etc.).  No tools (ropes, picks, etc.).  Only things one might wear when traveling/exploring (cloaks, packs, boots, belts, etc.).  Items with potentially specific uses (e.g, climbing harness) are acceptable, as long as they are worn -- not held.  Things don't always come in pairs (no pairs of boots, or gloves -- only a boot or a single glove).

Example/Template:

Code: [Select]
if spec_loot == 'sandcloth windcloak':

name = 'sandcloth windcloak'
char = 'W'
desc = 'A windcloak made of thin, scratchy sandcloth.'
color = libtcod.light_grey

material = 'plant'
slot = 'body'
type = 'cloak'

max_stamina_bonus = 1
capacity = 0

Item name goes on top line and after name.  Char is the icon that represents it -- use a letter or symbol.  Descriptions can be as long as you like, but I'd prefer things to be succinct.  Colors can be found here -- just replace the light_grey part with the color of your choosing.  Material, 'plant' or 'leather' only.

The following slots are available: head, neck, torso, body, back, belt, left hand, right hand, left foot, right foot, wrist, arm, leg.  Select one slot for each item.

Type doesn't matter (well, it does, but it doesn't matter what you put).  Put whatever general "type" of item you think it is.

The last two lines, feel free to fill out if you like.  Don't worry about game balance too much -- I can adjust things later (and you actually taking a stab at it helps me a lot)... and seriously, don't think too hard about it.

max_stamina_bonus refers to how much easier it makes travel.  A 10 would mean that you can travel roughly an hour longer than you otherwise might be able to naked.  Badass pieces of traveling gear should get a 10.  A badass cloak/duster/etc. can get up to 50.

Capacity refers to how much it holds.  (A spacious leather pack holds 20.  A cloak with a single pocket holds 1.)

Useless treasures/artifacts

General treasures -- things like urns, small statues, ancient religious items, old currency, books bound in fancy bindings.  These items can have variable materials (a statue may be made of carved wood, gold, or anything else), so you may or may not specify material qualities in descriptions as you see fit.  Nothing useful for fighting, exploring, or camping (or anything but selling/collecting, for that matter).  These things will have other uses, but no sense spoiling everything.

Example/Template:

Code: [Select]
if spec_loot == 'small urn':

name = 'small urn'
char = 'u'
desc = 'A small, cylindrical urn.  Its carvings are long since worn away.'
color = libtcod.light_grey

capacity = 1

Same as above.  These items may hold something via capacity, if it seems right (like in the case of an urn).

                                                             

That's what I need!  Let me know if you're interested (and no promises I ever finish, or that it'll be any fun)!

I'll be putting out calls for other items, maps/rooms, and characters at some point -- so hang tight if none of the above interests you.
« Last Edit: February 10, 2017, 11:57:59 PM by Feco »
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Bahliker

  • Posts: 210
Re: Desert Roguelike
« Reply #44 on: February 10, 2017, 10:54:38 PM »
I would love to help with this.

Earlier you talked about things to do with loot and mentioned home building in a way that gave the impression that you weren't into it. Is that the case?  If so, what do you not like about it? Why not tie the classic elements of home building to the villages that the game generates instead of to the player's "home"? I'm drawing a little from KDM here. bring enough of a resource type to the right npc and they develop an upgrade. Combine the right upgrades and the village developes new 'technology'. Tie these technologies to a simple special ability tree that your character can access as long as he's friendly with the village, or lives there, or visits frequently, or maybe it's permanent but you can only pick up a few. Each village, depending on its beginning state, has only limited potential for how it can grow. Idea seeds here, nothing more.

Have you considered storyline quests? Suppose there's one main story, a basic one, but it can be approached from multiple starting points, each with a different goal and perspective.

I hope you will also want oodles of randomly appearing side adventures and unique, legendary, magickal artifacts that do badass things.

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #45 on: February 10, 2017, 11:49:08 PM »
I would love to help with this.

Awesome!

Earlier you talked about things to do with loot and mentioned home building in a way that gave the impression that you weren't into it. Is that the case?  If so, what do you not like about it? Why not tie the classic elements of home building to the villages that the game generates instead of to the player's "home"? I'm drawing a little from KDM here. bring enough of a resource type to the right npc and they develop an upgrade. Combine the right upgrades and the village developes new 'technology'. Tie these technologies to a simple special ability tree that your character can access as long as he's friendly with the village, or lives there, or visits frequently, or maybe it's permanent but you can only pick up a few. Each village, depending on its beginning state, has only limited potential for how it can grow. Idea seeds here, nothing more.

Have you considered storyline quests? Suppose there's one main story, a basic one, but it can be approached from multiple starting points, each with a different goal and perspective.

So, I'd like the primary driver of this game to be exploration.  The maps get really interesting, and certain features can only appear when certain bits come together in the right ways -- this means the player has to do a lot of exploring.  Plus, I don't think I'm creative enough to put together a compelling story, and I'm not savvy enough to build a procedurally generated story that wouldn't seem hobbled together.

I don't want to talk too much design philosophy, because I think it can ruin the fun... but I will say that I've considered having the "starting village" be on a bit of a "starvation-clock" (take your village resources, and it will prosper, elsewise it'll die).  The player is totally free to ignore this, and let the village die, setting off on their own to explore, make a reputation, and get phat lootz.  But, making sure your village stays alive might give you better long-term access to resources (at the expense of losing short term access, having to share what you reap on your adventures).  This would probably be the extent of there being "home building" or a "story."

I'm hesitant to get too detailed with long-term village/town/homebuilding, because your PC is going to die, ending the game.  Probably frequently, in the beginning.  I could certainly put together some sort of succession, whereby you keep making PCs from the same village, but I'm building a roguelike, not a city-builder.  We'll see where it goes, though!  It's important I keep features in check, otherwise I'll definitely never get folks playing it.

I will say, though, that with the system they way it is, nothing is stopping a PC from setting up base pretty much wherever they want.  NPCs with special abilities, that quest with you, will certainly make it in, so I guess "base building" would be as simple as claiming a spot, and having the ability to leave NPCs there.

I hope you will also want oodles of randomly appearing side adventures and unique, legendary, magickal artifacts that do badass things.

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

Shoka Windrunner

  • Posts: 835
    • YouTube Channel
Re: Desert Roguelike
« Reply #46 on: February 11, 2017, 12:42:17 AM »
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!

I am a big fan of the older version of ADOM and I'd love to try this.  Maybe even do some videos on it.  (on my little channel)
At your table, the badass dun-clad female says in tribal-accented sirihish, putting on a piping voice, incongruous not the least because it doesn't get rid of her rasp:
     "'Oh, I killed me a forest cat!' That's nice; I wiped me bum after taking a shit.

TheGoose

  • Posts: 127
Re: Desert Roguelike
« Reply #47 on: February 11, 2017, 01:05:20 AM »
Saw the title and immediately thought 'What, Armageddon?'

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #48 on: February 11, 2017, 05:12:54 PM »
Thought this would be a fun gif to share.  This is a PC gathering energy and shooting a projectile fire spell:



Explosions/other effects are built to be modular, like everything else.  I haven't done much with them yet, though.  This particular example is about as simple as it gets.  Looks a little better in game -- should have recorded the gif at a higher framerate.
« Last Edit: February 11, 2017, 09:36:47 PM by Feco »
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #49 on: February 16, 2017, 05:57:17 PM »
Been working on the elevation and line of sight system a bit.  I'd love some feedback.

I've implemented triangular "ramps"  between quantized set of elevations.  They aren't necessary for moving between elevations, but they help to differentiate them.  They're more frequent in more confusing areas.  Still a few bugs to work out.

I've also decided to slowly fade lower levels to black, to make it easier to tell where you're at.

Here's climbing a massive sand-dune (and ignoring an Anakore about to eat me):



Here's climbing a rocky outcropping in more mountainous regions:



It works particularly well in areas with darker terrain, I think.  I want to be careful not to spoil locations, but here's a pretty barren, black-sand dune:

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

Feco

  • Posts: 1979
Re: Desert Roguelike
« Reply #50 on: January 29, 2020, 09:58:35 AM »
So it's been years, but I've had people ask here and there.  Figured this is one of the few communities which might think an update is cool! :)

I haven't abandoned this, I just barely work on it!  And I'm closer to a release than I was in 2016 or 2017!  Hah!



Gameplay has finally been fleshed out.  Most of the game is played as a traditional roguelike, exploring the world, dunging diving, and murder hoboing.  But there are two additional parts.

Firstly is the "travel game."  While you can just walk around the world map, it's really hard.  The desert sucks to walk in.  Instead, you can operate wagons and other vehicles, which you stock with supplies, spare parts, trade goods, and other people.  Then you select routes to travel, rather than navigating with the arrow keys. This exposes you to some Oregon Trail type gameplay -- where you'll have encounters and what not on the way.

The other is the "settlement game."  You live in a really basic settlement to start, but can develop it.  This started as a way to procedureally generate city-states, sorcerer-kings, and the like.  But I realized it might be fun to let a player just take advantage of it all as a sort of extra mechanic

As you can see above, I'm also fleshing out the art assets and important things (like tutorials).  So you, know.  SoonTM!
Quote
Sunshine all the time makes a desert.
Vote at TMS
Vote at TMC

Hauwke

  • Posts: 2047
Re: Desert Roguelike
« Reply #51 on: January 31, 2020, 09:11:01 PM »
Keep at it!

RogueGunslinger

  • Posts: 19158
Re: Desert Roguelike
« Reply #52 on: January 31, 2020, 09:16:54 PM »
This looks fun!

Dreadlock

  • Posts: 4
Re: Desert Roguelike
« Reply #53 on: February 02, 2020, 06:53:57 PM »
This looks like it would be awesome to give a run.