Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - sokol815

Pages: [1] 2 3 ... 6
Player's Plaza / Re: Looking for rougelike game from my childhood
« on: December 01, 2017, 10:08:07 PM »
Sounds like it might be Castle of the Winds.

Design / Re: Approaching "enemy sees player"
« on: November 09, 2017, 04:48:31 AM »
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?

Hey! Sorry about that... I forgot this forum does not auto-activate notify when you respond to a thread.

Yeah, you could totally do this... just decide upon a threshold at which Dijkstra's will stop spreading from the source... I've been playing around with a max Dijkstra distance of 24 (E.G. it stops pathing after more than 24 tiles away from the goal) for a PC with a sight range of 12 and it's still very interesting... you want monsters to be active if they are still close and out-of-sight of the player, otherwise the player might realize they can deactivate a monster just by getting them out-of-sight.

As far as optimization goes... My Dijkstra implementation (Breadth-first Priority Queue) can run through my entire 80x100 map in less than 1ms. You probably don't need to worry a lot about optimization until it becomes a problem.

What I refer to as "Dijkstra's algorithm":
1. Initialize all cells to default high value (I use 9999) & mark them all as not in the queue.
2. Create an array containing positions of our current goals(usually just 1 element with the PC's location).. this will be called the queue.
3. Mark all goals on the map as having a dijkstra value of 0 (or lower/higher if you want to make some goals more important than others, lower numbers being more important)
4. While the priority Queue is not empty, remove the first element from the queue and process it:
   a. Mark it as not in the queue
   b. Grab the list of it's path-able neighbors (e.g. open spots, not walls) and check if their dijkstra values are more than 1 + this cell's value... if so, set the neighbor's value to 1 + the current cell's value. If you changed the value, check to see if they are already in the queue, if not... add the neighbor to the queue and mark the cell as in the queue.

To use the above generated map, just employ an algorithm starting at the position of your monster and "roll down the hill" through it's neighbors to your goal.

When I first learned about Dijkstra's, I implemented the algorithm in a horrible fashion of using a while loop and inside of that, doing double for loops to iterate over every cell looking for neighbors that needed to be updated... if I updated anything in the for loops, I'd have to continue the while loop. That method could easily take 30ms to run in a 80x100 map.

I hope you've already made a choice as to how you're going to implement it, but if not... I hope this helped.

Design / Re: Approaching "enemy sees player"
« on: October 19, 2017, 07:20:52 PM »
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 ( 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: (Note: this article is the subject of the above roguetemple link I posted)

Good luck!

Off-topic (Locked) / Re: Images not appearing on my site!
« on: September 20, 2017, 09:39:02 PM »
Sounds like the urls you're referencing for your images are incorrect. The easiest way to get it correct is to create an images folder in the same folder as your index.html file. Then put all the images in there. Now, in your index.html, anytime you want to reference an image, just set the src to something like <img src="images/imageName.jpg" />. When the browser sees a "relative" source like this, it knows that the image you're looking for is in a folder inside your current location. The other option is to statically reference all of your images... you could put a folder called "images" in the web-root of your website and now anytime you want to reference an image on your website, just use <img src="/images/imageName.jpg" />.

Here's a helpful reference.

Off-topic (Locked) / Re: Prime numbers
« on: June 02, 2017, 09:10:04 PM »
If you're interested in learning more about prime numbers, is a great place to start. A lot of the problems on Project Euler deal with prime numbers.

Programming / Re: Sewer generation
« on: July 04, 2016, 11:36:56 PM »
Cool idea!

I might try using a 2d array initialized with zeroes, and then plotting your canals along the 2d array by increasing the values as each canal passes through the cell.

Then perhaps you could come up with a tile system that is able to pick from a set of 6x6(or whatever size) tiles that would correspond with the data in each cell + it's neighbors.

7x7 tiles might be even easier to use if you are looking to have large variances in amount of water flowing.

Code: [Select]
this tile has a small amount of water running east-west

this tile has a medium amount of water running east-west

this tile has a large amount of water running east-west, it's even overflowing onto the path

some water coming from all four directions

by composing these tiles into a map using the 2d canal-map array, you could build a realistic looking map. You would either require a decent amount of tiles (not ideal), or a method of generating all the types of tiles you might need...

Code: [Select]
Here is a multi-use East-West tile... the numbers here indicate the water level at which they turn from a . to a ~ or ≈

if you use this method, you will only need to make 16 tiles or so + variants (if you need them)

How to number tiles:
assume water can come from NESW directions... give each direction a worth 1,2,4,8.
for any individual cell on the map, determine which directions water is coming from.
If it comes from the north and south, it is a NS tile, which gives it a value of 5 (N:1, S:4)
You now know you need to grab a NS(5) tile and populate it into your world, switching out the water-depth-allocated cells as appropriate.

Code: [Select]
  |      |
  |      |
8 |      | 2
  |      |
  |      |

I'm interested to see how your project works out. Keep us posted!

Off-topic (Locked) / Re: Game research - 4x and card games
« on: May 10, 2016, 07:23:21 PM »
You could probably clean up your data a bit, too... it would be much more useful that way. For example the "Where are you from?" bar graph lists "USA", "US" and "United States" as 3 separate entities. California appears to have made it in as a country, too... Silly Californians. Cool results, though.

Temple of the Roguelike / Re: Please support Temple of The Roguelike!
« on: April 24, 2016, 04:41:57 PM »
Do it!

I like the puzzle this game presents to the player. it's difficult. Well done!

Programming / Re: Heterogeneous saving and loading objects in C++
« on: April 06, 2016, 10:46:10 PM »
3 stars to skullcoder! I'm sure your input will help future motivated devs who are working on difficult serialization problems in c++. The highly academic language of your responses can make it hard for non-native english speakers to clearly grasp what you are saying, unfortunately... nothing can be done about that. Don't mind Krice; he satisfies his need for human interaction by trolling on the internet. Welcome to the forums!

I find this topic fun. Perhaps if you ever end up building a custom chip for your new roguelike language, you could include the option to turn permadeath on, which would instantly fry the chip when you lose. Then you have to go solder another one in!

Off-topic (Locked) / Re: Nineties strike back
« on: April 01, 2016, 06:35:10 PM »

Definitely brings a longing for the geocities of old.

Pretty cool game. People who make games in javascript must be pretty cool.  ;D Something weird seems to be going on... I'm using Chrome on a windows 7 machine and Pressing '6' on the numpad does nothing, but all the other numpad keys seem to work.

Design / Re: Item randomization
« on: March 31, 2016, 12:58:46 AM »
I'm reimplementing item randomization mechanic in my game for the 3ed time now. How do you guys design your algorithms and what kind of parameters do you use to balance it. How do you describe the loot quality available in different places on different levels?

This is a great question. A previous discussion on the topic occurred here(

My personal favorite approach to drop-randomization is detailed in the thread above. I find it to be an extremely versatile system. You can easily add additional items, tweak drop rates, quality of drops, item ratios... etc. all in the same spot. Then I just assign a dropClass to my monsters and the system can choose what they drop. Alternatively, you could generate your monsters with their drops and have them use said items, which is a future goal of mine.

I'm not entirely sure if I want to match drops to the depth of the dungeon or the level of the monster... I think I'm leaning more towards the level of the monster, but if I were to implement the mechanic where monsters use whatever items they will drop, a dungeon-level-based drop rate might make sense. Additionally, it might make sense for a bat to drop a potion (they were carrying it?) but would they similarly be able to carry a chestplate? probably not... this is a future goal that I am working towards right now. The system I detailed in the thread above will make it rather easy to cobble together specific drop classes for enemies, which I think can help in making monsters not feel all 'samey'. other uses include the ability to specifically drop quest items on death of a specially spawned monster.

I just had another thought... if you met a weak monster on say level 2 (maybe a rat?) and were able to lure him down to level 5 and then kill him, it seems pretty arbitrary to say that because said rat died on level 5 he is attached to level 5's drop class... I guess that is just something additional to think about in the dungeon level vs monster dropClass.

Programming / Re: FOV algorithm demonstration
« on: March 28, 2016, 02:23:01 AM »
I got some errors.
Code: [Select]
ReferenceError: init2dArray is not defined
The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol. los
TypeError: jsRL.sighting is not a constructor
Cool idea. You may want to check out recursive shadowcasting, which is a similar idea, but instead of caching children you calculate them. Here's my implementation in js.

Hmm... looks like your browser didn't like the way I was checking if a variable was initialized... what browser are you using? I fixed the source to not worry about checking any of those things (as it is not needed...)

also, said code looks very nice and concise, I especially like the inclusion of custom callbacks for reveal and transparent. Definitely some good usage of javascript's... peculiarities. If ever I am not satisfied with my sight algorithm, this is totally where I will go.

Also, congrats on starting the journey to make a javascript roguelike. There are lots of interesting problems to work out for that. Here is the repository for my javascript roguelike... feel free to look around if you want. (github)strife repository

I used a similar kind of system in KleinRL. It's very well suited to maps with portals, glued boundaries, and other kinds of non-euclidean geometry.
Often games need to calculate point-to-point line of sight between non-player objects (for which the full field of vision isn't known or required). Is it possible to use this data structure to make that kind of calculation efficiently? I presume the result would differ from a check using a simple bresenham line from A to B.

I don't think you will be able to find a better solution than the Bresenham line algorithm, which it sounds like you are using already. That is guaranteed to give you the same line from pointA to pointB and pointB to pointA.

Pages: [1] 2 3 ... 6