Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
Design / I need opinion on this map design
« Last post by SomeGuy on October 18, 2017, 10:32:14 AM »
Randomly generated using small chunks of map.
Maps end up looking like this:



It is for a sci-fi rl that takes place inside a spaceship.
The colours in the screenshot are NOT the ones in the real game. It only shows the map layout itself. It is missing (on purpose for topic) all the map features, fov, enemies, etc... Also walls ASCII character could be changed to "#" instead.

What do you think about the map layout? Does it look too much labyrinthic? Too many corridors? Too many rooms? Does it look "too random" or some defined structures can be clearly defined by the player? Does it look interesting to explore in general terms? Could it look like a spaceship or it looks too generalist? Would it look better with more wider corridors? Would it look better with more bigger rooms? Should it have more or less "walkable" space? Would it look better if it looked more symmetric? Would it look better if it had less variety of room styles?

Any constructive thought will be welcome.
Thanks beforehand : )
22
Design / Re: Skill category problem
« Last post by SomeGuy on October 18, 2017, 09:41:24 AM »
Sorry to revive this topic, but if you still need an opinion, I would ask you: what is exactly that "searching" used for? Is it A)"searching for hidden objects" or B)"general searching the room?"

If A) then, I would say make it a thievery skill. Usually it is thieves the ones who are more trained to search for hidden traps, treasures and the like.
If B) then it is a too general action to be considered a skill per-se. It is more like "describe me the room" or "search some something that is not too hidden". It is then a normal action like "walk", "eat", "quaff" and the like.

Then, if you want the player to actively search for traps/treasures/hidden chests/... then I think you could have, in the one hand, a skill that is "detect hidden" inside "thievery" skillset, and in the other hand, a skill general action called "search" to just look for general things around.

And in general, as for myself, I always consider a "skill" some action that only certain people can do successfully with training (like sorcery, 1st aid, fishing, playing an instrument, whatever), and a "normal action" something that most of the people do without training (even when if you train you can do it a bit better), like walking, selling/buying, observing (search?), and so on, and besides that, it is something that is done most of the time.

And even that, "normal actions" i think they depend more on your basic stats (STR, AGI, INT, ...) than on the skill itself. For example, a high AGI could improve how well your character can walk better, but there is nothing like "walking training". Or your PER(ception) can increase your character attention to detail when he is "general searching", but there is nothing like "the school of searchers" that trains your @ how to observe your environment.

And if you think about "searching" as an action/skill to look for resources (kind of like a bushcraft skill), maybe you can use it as a general action, but that its outcome is affected by PER(ception) stat, since rangers and bushcrafters are so good at perception, but they dont have a specifit training just to "search". Everyone can "search" in the forest, and many people will easily discover common resources like wood or rocks, but people with more PER will discover more things useful things.


Hope that was helpful.
Good luck with your project.
23
Design / Re: Approaching "enemy sees player"
« Last post by SomeGuy on October 18, 2017, 09:18:22 AM »
3) Enemies awake when player sees them. In this case, the enemies only awake when they are seen by the player. It is quite ok for a simple roguelike, but I need to implement enemies with different LOS size, so this wont work.

Could work if you also check the distance to the player and don't wake up the creature if it's too far away. I would also use "sound" based approach with simple distance check and possibly how much the player is making noise. Also, I would use pathfinding only if the creature has difficulties to approach the player directly when it knows where the player is. Even then it's often questionable, because how does some simple monster know how to pathfind the player? Maybe it could just stand there or leave.

Distance checking Line of Sight is the simplest I can come up with, but the downside appears when the monster can see from a farther distance than the player.
Lets say, the enemy is only "awaken" when the player seen him. In this case, all the enemies' LOS distance = player LOS discantance.

So then, distance checking should be performed from monsters' perspective, i.e. for each monster, check if player is within that monster's LOS distance.

But the downside is, monsters would be able to see through walls, doors and any other LOS blocking map feature: (continue after Minotauro's quote):

My own design philosophy involves not to overthink whatever I can avoid. Since this mainly touches on events happening outside of the player's line of sight, I think it's okay to give one self some leeway here. I think the effect we are looking for, is two-fold: We want the player to get the feeling they are moving around in a living world, but we also don't want interesting events to play out outside of the player's line of sight. It's cool to come into a room where a knight and a bear are in the middle of a fight, for instance. It's less interesting to explore a dungeon full of already vanquished enemies.

That is a good point you have there. Afterall, with a simple "distance LOS" system we could justify it as if the enemy hears the player. And even we can implement a stealth check:

Code: [Select]
if enemy.viewDistance >= enemy.distanceToPlayer AND player.stealth < enemy.detectHidden then
     enemy.seesPlayer()
else
    enemy.doesNotSee()
end

We could even increase stealth based on distance.

Both my games that ever saw a release has a variant of "wake up monsters when player is at a certain distance". My first game had very strict division of the map into different rooms, and I'd simply let monsters wake up whenever a tile belonging to their home room came into the player's line of sight (including outer walls/doors, so most monsters would wake up when the player was somewhere in the room adjacent to them). My current project plays in an open landscape rather than a dungeon. Here I just divided the map into big chunks (approx. 16 x 16 points), and I make sure that all beings currently in the same map chunk as the player, or one adjacent to it, is active. As the player moves around, map chunks that are too far away are conversely put to sleep again.

As always,
Minotauros

Basically, your 1st game was based on Rogue wake system.
Whereas your 2nd game, since it is a openworld system, there are not meaningful obstacles that totally block monsters LOS.
But the problem I want to avoid as much as possible is this, directly related with dungeon-style Roguelikes:

Code: [Select]
   # # # # # # # # # #
   # . . . # . . . . #
 # # . . . # . . . . # #
   . . E . # . . @ . .
 # # . . . # . . . . # #
   # . . . # . . . . #
   # # # # # # # # # #


In that case, lets say enemy 'E' has a LOS distance of 10. Both, the player and E are in totally unconnected rooms, but the distance from E to @ in less than 10, so E can see @ even through walls.

So, in the end I might go all the way to simple distance checking, as you suggest, it is better to do things simple. But just wondering, for dungeon roguelikes how should be the best approach that balances realism with computational speed.

Btw, I tried pathfinding system, and it is terribly slow, even for a mere 10 enemies in the map.
Then I tried a LOS calculation (LOS from each monster towards the player position), and even when it is slightly faster, it is far from comfortable for the player.
And finally, simple squared distance check, the fastest, but could lead to "monsters can see through walls" effect.

I dont know if there are other methods to approach this, that is the question I really wanted to ask.


Thanks for your answer, both of you.
24
Design / Re: Approaching "enemy sees player"
« Last post by AgingMinotaur on October 18, 2017, 07:07:19 AM »
My own design philosophy involves not to overthink whatever I can avoid. Since this mainly touches on events happening outside of the player's line of sight, I think it's okay to give one self some leeway here. I think the effect we are looking for, is two-fold: We want the player to get the feeling they are moving around in a living world, but we also don't want interesting events to play out outside of the player's line of sight. It's cool to come into a room where a knight and a bear are in the middle of a fight, for instance. It's less interesting to explore a dungeon full of already vanquished enemies.

Both my games that ever saw a release has a variant of "wake up monsters when player is at a certain distance". My first game had very strict division of the map into different rooms, and I'd simply let monsters wake up whenever a tile belonging to their home room came into the player's line of sight (including outer walls/doors, so most monsters would wake up when the player was somewhere in the room adjacent to them). My current project plays in an open landscape rather than a dungeon. Here I just divided the map into big chunks (approx. 16 x 16 points), and I make sure that all beings currently in the same map chunk as the player, or one adjacent to it, is active. As the player moves around, map chunks that are too far away are conversely put to sleep again.

As always,
Minotauros
25
Design / Re: Approaching "enemy sees player"
« Last post by Krice on October 18, 2017, 05:48:26 AM »
3) Enemies awake when player sees them. In this case, the enemies only awake when they are seen by the player. It is quite ok for a simple roguelike, but I need to implement enemies with different LOS size, so this wont work.

Could work if you also check the distance to the player and don't wake up the creature if it's too far away. I would also use "sound" based approach with simple distance check and possibly how much the player is making noise. Also, I would use pathfinding only if the creature has difficulties to approach the player directly when it knows where the player is. Even then it's often questionable, because how does some simple monster know how to pathfind the player? Maybe it could just stand there or leave.
26
Announcements / Re: Cogmind (now at Beta 3)
« Last post by Kyzrati on October 17, 2017, 11:28:53 PM »
Thanks for the info, Tzan! Still doing okay I guess. Whew that was a long day for me yesterday--and now I just got up and inbox is way full xD
27
Early Dev / Re: Soulblight
« Last post by abraksil on October 17, 2017, 09:22:41 PM »
Soulblight Live on Kickstarter



And so it's finally October 17th. Just a moment ago I clicked the button to activate our Campaining :) Now Soulblight is Live on Kickstarter

Here's the link:
https://www.kickstarter.com/projects/1752350052/soulblight

Keep your fingers crossed everybody! :)

Cya Around,
Kuba
28
Temple of the Roguelike / Re: roguetemple.com moved to wordpress.com
« Last post by Avagart on October 17, 2017, 07:00:13 PM »
Everything works fine on latest Chrome.

Btw, It'd be good to update roguetemple-related links on roguebasin.
29
Temple of the Roguelike / Re: roguetemple.com moved to wordpress.com
« Last post by Tzan on October 17, 2017, 04:38:11 PM »
Looks fine on my old Firefox.
30
Announcements / Re: Cogmind (now at Beta 3)
« Last post by Tzan on October 17, 2017, 04:06:41 PM »
Oct 7th 12noon eastern US

Indie
New/Trending #2
Top Sellers #10
Specials #7


Early Access
New/Trending  #1
Top Sellers #1

Strategy
New/Trending #1
Pages: 1 2 [3] 4 5 ... 10