Messages

1

Design / Re: I need opinion on this map design

« on: October 29, 2017, 09:54:36 AM »

Would be nice to see whole level explored. If I have to judge by that example, new design seems better.

Maps also have a random generated name.
This one is called "Control Server" (the game is sci-fi)



Thnx for the feedback.

2

Design / Re: I need opinion on this map design

« on: October 28, 2017, 10:51:21 AM »

How about this new design?

3

Classic Roguelikes / Wondering how to play "Hack" on Linux?

« on: October 26, 2017, 06:30:46 PM »

Hi.

So far, I didnt have luck trying to do so.
I am under a debian-based distro. There is no "Hack" in the repo at all.
Also I found this:

https://homepages.cwi.nl/~aeb/games/hack/hack.html

But the sources there wont compile.
It says that BSD systems have builds for modern architectures, but I could find anything so far.

Anyone tried or knows how to do play it?

I could go with a DOS version, but I am lazy to install Dosbox just to play this game 

4

Player's Plaza / Re: Roguelike with persistent (or seed generated) world?

« on: October 21, 2017, 04:23:11 PM »

[...]  it only takes about a dozen years to get an actual roguelike.

[...]

Wait.... You are saying that creating a roguelike game could take 12 or more years, right?

In that case, are you implying that the original Rogue, a game designed for Unix (1970s) and firstly released in 1980, the developer started programming it 12 years before that, in 1968, at least, even before Unix existed? Basically, he was creating a game for a system yet to exist!!??

OMG! WHAT KIND OF CONSPIRATION IS THIS!!! I AM SURE YOU ARE SOME KIND OF COLLABORATIONIST, AT LEST, AND MOST LIKELY AN ALIEN FROM THE REPTILIAN RACE!!!! YOU, WICKED BEING CONFESS YOUR CRIMES TOWARDS HUMANITY!!! 

5

Design / Re: Approaching "enemy sees player"

« on: October 20, 2017, 08:00:57 AM »

I'm a fan of the pathfinding method.

You don't have to run pathfinding for every monster. You can just use Dijkstra's algorithm (http://forums.roguetemple.com/index.php?topic=3652.0) once with the player as the goal... then check the spot the monster is located at to see if they can reach the player... (you'll know this because when you instantiate dijkstra's, you give all cells a default very high value... any cell retaining the default value is unable to path to the goal) you only need to re-calculate whenever paths in the dungeon change (paths blocked, explosions open new paths) or the PC moves.

Dijkstra's maps can also be used for more complex AI interaction, as mentioned here: http://www.roguebasin.com/index.php?title=The_Incredible_Power_of_Dijkstra_Maps (Note: this article is the subject of the above roguetemple link I posted)

Good luck!

Good idea. I dont know why I didnt thought about Dijkstra maps!

But I think we can make this a bit more efficient: instead of calculating the whole Dijkstra, we can do simple distance check between the monster and the player.
If the player is within the monster's viewing distance, we do the pathfinding, otherwise, we dont.
So, instead of calculating the distance for lots of cells around the player (the Dijkstra map), we do the calculation only once.

What do you think?

6

Design / Re: I need opinion on this map design

« on: October 18, 2017, 09:12:13 PM »

It looks really nice, especially as *idea*, I'd like to know more about implementation of that map generation. Although, it would benefit of more chunks of map - it looks strangely repetitive at the borders of the map. The problem is, it doesn't look like spaceship interior at all. Too messy, too... unstructured. Would work great as as *mine-like* levels, thought.

I changed it a bit: made more wide corridors. Made more rooms. Reduced the "messy" feeling a bit.

Also, I should post before an image with the real fov and colours, because yes, that first image looks awful.
Anyway, this is how the player could see it already in-game:

Here with original wall style


Here with a different style:


Both images use the same algorythm, but different wall style.
Opinions?

7

Design / I need opinion on this map design

« 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 : )

8

Design / Re: Skill category problem

« 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.

9

Design / Re: Approaching "enemy sees player"

« 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.

10

Design / Approaching "enemy sees player"

« on: October 17, 2017, 11:26:39 AM »

Hi.

I am stuck with this problem
I need opinions on how would you implement the way enemies detect/see players.
Lets say, at first, enemies are inactive. They didnt see the player and they dont move.

How would you make enemies to detect the player, when he (the player) is seen/detected?

I thought about three different ways:

1) Enemies have their own LOS. When the player enters the LOS of the enemy, then the enemy awakes and starts chasing the player. This way uses a LOS algorithm for each monster, each turn. I think it is the most realistic and flexible, since the enemies can have their our "see distance", and enemies can awake from outside players LOS (i.e. the enemy has a bigger LOS than the player). But the downside is, we have to recalculate a LOS all the time.

2) Simple squared, static LOS. Enemies have a simple square/circle of sight around them that covers both floor and walls. Whenever the player enters this squared LOS, the enemy awakes. The goodness about this is that you can justify it going over walls as "the enemy can hear someone around". Also it should be faster than the true and real LOS. In this case is just checking some map cells around the enemy. The downside is, it is less realistic, and could awake enemies that are in a room/corridor completely unconnected from the player's location

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. Anyway, the goodness about this is, only calculate LOS once per turn, and check if any enemy is within player's LOS. Downside, it wont work if you need to implement enemies with different LOS size.

4) The pathfinding way. I thought about running a pathfinding algorithm every turn for each monster, starting in moster x,y position, and finishing in player x,y position. Then, for each "step" in the path, we check whether the player is in such step or not. We repeat this "player check" for a certain amount of times, that are basically the enemy see distance. This is good and quite realistic since you can simulate not only a LOS, but also "enemy hears the player around the corner, even when there is not direct "eye contact" (because pathfinding will turn over corners and etc). The bad is, heavy on calculations, it is basically a pathfinding algorithm every turn for each monster.

Do you have any other idea or thought?

Please share with us.

Thanks

11

Traditional Roguelikes (Turn Based) / Re: Demons of Dex (now available)

« on: September 09, 2016, 08:16:18 AM »

Yes, I am Petri on the Grimrock forums and the 3585 bytes version is the vic20 game I wrote.

Please, check my edited message just there up.

12

Traditional Roguelikes (Turn Based) / Re: Demons of Dex (now available)

« on: September 09, 2016, 08:09:47 AM »

Hi! I am the creator of Demons of Dex, a game I released for the vic-20 last year. Please note that this version endorsed by CSDb is an unauthorized version that was made behind my back and without permission. A C64 group who call themselves Hokuto Force took the "Copyright Petri Häkkinen. All rights reserved" tagged source code from Github added a few bells and whistles like the titlescreen, options and custom charset. The gameplay is identical to the vic20 version because they used the stolen source code as is (C64 and vic20 can run the same machine code). As you probably know for roguelikes gameplay is king and everything else is superfluous. They are now representing the c64 version of the game as their own creation and give me no credits on the CSDb page and the marketing material they are posting on the web.

I have asked the game and its page to be removed from CSDb but the admins of the site apparently do not care about copyright infringements and support Hokuto Force's illegal and immoral actions.

Full story here:
http://sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?f=10&t=7648

Petri Häkkinen
The creator of Demons of Dex

Sad news if you ask me.
I have the version downloaded from the Legend of Grimrock forums, announced by Petri (I guess, you, unless you are falsely impersonating him here).
I suppose that the "Grimrock" version is the actual original version. Right? .prg file 3,585 bytes.

[EDIT]

BTW, I just visited that "Hokuto Force" page, and I noticed this:



They are giving credit to you as the original developer. They just made a version of the game.

13

Design / Re: What makes a roguelike easy or hard?

« on: September 08, 2016, 11:37:35 PM »

Hi, that is a very broad question

Try to get a prototype that you can play as soon as possible. It's near impossible to assess how difficult a given system will be in advance (especially if you're not an experienced game designer already). And when you get to the point where you're testing your own game, keep in mind that you're a lot better at it than most players. Ie. enemies that are windshield kills to you, will be a challenge to a newbie, and the stuff that you find difficult will be unbeatable to some.

Right.
The prototype is a roguelike-like, like the aforementioned Legerdemain.
Non-random maps, easy to die, and when this happens, the player can choose to "die" or to be resurrected with a penalty (losing gold, decreasing attributes, losing one random object from inventory, or whatever), so death is something to be avoided.
He cannot save whenever he pleases, only like "Save and quit".

Difficult features in games should of course always be interesting. As you note, putting in overpowered enemies (or just scaling enemies' HP as you get deeper in the dungeon) isn't very fun at all. Enemies with special abilities, on the other hand, can be fun. Most RLs feature one or more basic enemies (aka "giant rats", "zombies") which will usually just charge the player and attack in melee. A step up from this is any enemy with a single special trait: One that is fast, or uses ranged attacks, or is slow but super strong, etc. It doesn't always have to be "special attacks" either. Mixing in enemies with different behaviour patterns can give rise to a lot of challenging game positions. It goes without saying that any enemy you normally encounter should be beatable (or avoidable/manageable if you play well). Strictly speaking, a game can be said to be broken if it ever generates unwinnable positions (given perfect play from turn 1), but you'll have to at least partially rely on your gut instincts.

But monsters' special attacks or abilities are something limited, and once you know how to deal with a monster with such ability, the game difficulty will difficulty and so the challenge it represents to the player.
Also, due to the nature of the game I'm developing, magic is a very limited and scarce resource or skill, but powerful.

If your game depends on limited resources (potions, mana points, power cooldowns, whatever), the right balance is usually that the player will find/have just enough to get by.

In the end, it all depends on what you want. Some games use procedural lock+key puzzles (Brogue and Ultima Ratio Regum spring to mind), some require intelligent usage of spells/abilities (like Caves of Qud or Legerdemain), others go for a more pure tactical tension (check out PrincessRL and Hoplite, and a plethora of other 7DRLs). Rogue itself is a notoriously difficult game, and yet supremely well designed. It more or less invented typical RL systems like hunger and identification, and stands still as a shining example of what these systems are really all about.

I kinda like this more. It looks like the player must manage the difficulty at all times. Using consumables early on could lead to problems later, while reserving these resources from the beginning could make hard to reach deeper dungeon levels since you are making the game harder in the begining.

But in this case, both low level mobs and high level mobs should represent a rather similar challenge for the player, otherwise there is no reason why the player should use potions or spells at the beginning. I mean, if a rat is not a challenge at all, then the player will just save these potions since he doesn't need them at all, so the logical decision is not to use them.

Nothing bad about this, but the problem could come if the player saves a huge amount of resources for later levels, then these later levels would be too easy.

You can also have strategic decisions which are "hard" in a sense, such as whether to invest skill points in weapon mastery or magic, or which wand to leave behind if you have a limited inventory space.

Limited inventory space is something that I have been working on already. I am more inclined to think about a weight-managed inventory.
In this case, the player again must manage how easy he wants the game to be now and in the future:
saving potions in the inventory for later will not allow him to carry one extra weapon for low level monsters (a problem if your current sword breaks). But if you have a pair of sword and do not pick up potions, these swords might become to weak when fighting dragons instead of rats.

So either drop the sword or drop the potions... Or find the best balance.

If you like to play RLs as well, take note of how your favourite games implement systems to be difficult/interesting/whatever-it-is-that-like-about-them. Also, read up on which games are out there and check out the ones that seem interesting. Steal and adjust the ideas that you like.

Hope some of these stray thoughts can serve to inspire in one way or the other.

As always,
Minotauros

Actually I have several favourite RLs, and their approach to difficulty is different, such as Nethack or DCSS.

Yes, your thoughts are really useful. Thank you.
I think I will experiment with the limited resources and volume-managed inventory by now.

14

Design / What makes a roguelike easy or hard?

« on: September 08, 2016, 02:52:17 PM »

Trying to develop a roguelike-like game.

But I came up with a serious problem: what makes a roguelike game hard or easy?
I mean with that, which *fair* factor should increase or decrease a roguelike game difficulty.

For example, having overpowered enemies is not a fair feature. That is something that the player cannot control or even participate in any decision.
But if we think about limited number of spells casts, or weapons durability or similar factors, they can make the roguelike easy or hard if the player doesn't make the correct decision.

Or anything similar to that, which is a feature of the game that the player has to take into consideration, since it is a necessary but limited resource/mechanics/<whatever>.

So then, which features do you think are worth considering when trying to establish a difficulty for a roguelike?

15

Design / Re: Simple AI/Logic for chosing enemy skills?

« on: June 13, 2015, 08:49:00 AM »

For AI behavior a lot of people give monster type a set of parameters, a subroutine of actions it will take.

Like I'll start all my monsters in WANDER mode. Then, when they see the player (or smell him or hear him, though I've never implemented that) they activate.

Their active mode will be preset. Some flee straight away, some attack straight towards the player, some will get to a certain distance and try to maintain that distance as a priority, else shoot the player. Some will hit the player once a flee (thieves do this). Some will flee towards their closest ally and only go into attack mode when they are with allies. Some stand and start shooting without moving.

There are many ways to do this, but usually you see each enemy having a certain behavior type (flee, hit and flee, charge, find friends and charge, or ignore and wander forever, etc...). You can reuse these behavior profiles on each different monster type. You can even change their behavior type based on their range from the player. Like less than 5 spaces away then flee, greater than 5 then shoot. Or less than 3 then charge (or use short range weapon) or greater than 3 then use long ranged.

Also, sometimes when wandering the creature will go to sleep, they stop moving and can get hit for huge damage.

A stealth specialist creature might go invisible when they see the player.

I'm probably not answering your question directly, but I hope I've given some ideas. Good luck!

That was of great help indeed.
It doesn't any hard to implement.

But anyway, once the monster has chosen to attack instead of flee/wander/stealth, how can he decide to choose attack1 instead attack2, or viceversa?
Should he try to get closer to the player to use the short range attack? Or should use it only if the player approaches? When does the enemy need to heal? when health is critical? when health is non critical, when health <= 50%? etc...
That kind of questions are the ones I don't know the optimal answer.

BTW, I don't want a cheating AI that may know the player health value, attacks and equipment or other info that only the player is supposed to know.