ID:152056
 
I was thinking about making a function that will generate .dmm files to the hard drive of the server, then use a loader to place them in game. I'm pretty sure this method would be a lot faster than using straight DM.

That, and there are several roguelike map generation libraries out there written in C already. Anybody got a counterpoint to doing this using a .dll file in the first place?

I'm also thinking about using a much more complex pathfinding algorithm than my current DM approach allows, also using a .dll file.

If I return an array from C, I should theoretically be able to access that data in DM, right?
Ter13 wrote:
I'm also thinking about using a much more complex pathfinding algorithm than my current DM approach allows, also using a .dll file.


I really hope you plan on porting these DLL files to Linux .SO files as well, otherwise you totally cut off the ability to host from a Linux machine.


If I return an array from C, I should theoretically be able to access that data in DM, right?


No, call() can only return a string, any other return values (or even sending non-string arguments using call()) will result in the DLL crashing which will crash DS. So you'd have to do all of your array work in the DLL and return the final string.
In response to Nadrew
That's not terribly problematic, a string is pretty much an array anyhow, since I can use file i/o to create files on the server, the map creation isn't that much of an issue.

The only *real* problem is in players opening up the .dmm files in DM to cheat.

Yeah, I read your last post about .so files, and I've taken note of them, and will not neglect it.
Ter13 wrote:
I'm also thinking about using a much more complex pathfinding algorithm than my current DM approach allows, also using a .dll file.

That's a good idea. I think if you implement a dll that retains the map state, and update it everytime something moves, then you could do the whole pathfind inside that dll. Other stuff too, like line-of-sight and line-of-fire.
In response to Ter13
I'd like to hear more on this. I'm not planning on making actual .dmm files, but I do want to handle all of the complex tasks associated with map generation externally, since BYOND will slow to a crawl if you try it in game. I plan to just have the C program build a readable text file and have BYOND build up the map turf by turf, which is acceptable.


I don't know how useful it will be to do pathfinding outside of BYOND though. Might be more hassle than it's worth.
I'm not sure this is an ideal choice for a .dll file. If anything, Roguelikes are an area where BYOND can really shine. Most of the algorithms I've seen for map generation are easy to port to DM and they'd be pretty fast, I would think. Seems to me it'd be easier to do that.

Lummox JR
In response to Lummox JR
Lummox JR wrote:
I'm not sure this is an ideal choice for a .dll file. If anything, Roguelikes are an area where BYOND can really shine. Most of the algorithms I've seen for map generation are easy to port to DM and they'd be pretty fast, I would think. Seems to me it'd be easier to do that.

Lummox JR

Not perlin noise.
In response to Obs
Obs wrote:
Lummox JR wrote:
I'm not sure this is an ideal choice for a .dll file. If anything, Roguelikes are an area where BYOND can really shine. Most of the algorithms I've seen for map generation are easy to port to DM and they'd be pretty fast, I would think. Seems to me it'd be easier to do that.

Not perlin noise.

Perlin noise should be easily doable; the only issue is precision. For a map generator, I doubt more than basic floating point would ever be needed.

Lummox JR
In response to Lummox JR
Talking about good old fractals (but using integers)? :P
In response to Lummox JR
Perlin noise is very doable indeed.

/*
xo_Perlin : Perlin Noise Generator
copyright ©2007 Andrew "Xooxer" Arnold
~All Rights Reserved

////////////////////////////////////////////////////////////////////////////



xo_Perlin - The xo_Perlin datum. Use var/xo_Perlin/P = new(32, 32, 256)
to create a new xo_Perlin datum called P with the width
and height of 32, and seeded with the number 256.


InitNoise(w, h, seed)
You can also create a new null xo_Perlin datum, and set
its dimensions later with InitNoise(). The following
code produces the same effect as above.

var/xo_Perlin/P = new()
P.InitNoise(32, 32, 256)

Seeding your noise is optional, and defaults to 0 (no seeding).


GenNoise(seed)
You may wish to reuse your noise datum, but alter the seed.
Call this proceedure to re-generate your noise with the
new seed.


Perlin(turbulance)
Returns a two-dimensional list containing the final rendered
noise with the amount of turbulance stated (defaults to 64).


Turbulance(x, y, turbulance)
Use this procedure if you only need the final rendered noise for
a single x,y coordinate within your noise array. Turbulance is
optional, as above (defaults to 64).


SmoothNoise(x,y)
Used by this library to create the final noise rendering.



*/



xo_Perlin
var
width
height
list
noise



New(w, h, seed)
..()
if(w || h)
InitNoise(w, h, seed)



proc
InitNoise(w, h, seed)
width = w
height = h
noise = noise[max(w,1)][max(h,1)]
GenNoise(seed)


GenNoise(seed)
if(seed) rand_seed(seed)
for(var/y = 1 to height)
for(var/x = 1 to width)
noise[x][y] = rand()


SmoothNoise(x, y)
var
fractX = x - round(x)
fractY = y - round(y)

x1 = max(round((round(x) + width) % width),1)
y1 = max(round((round(y) + height) % height),1)

x2 = max(round((x1 + width - 1) % width),1)
y2 = max(round((y1 + height - 1) % height),1)

value = 0
value += fractX * fractY * noise[x1][y1]
value += fractX * (1 - fractY) * noise[x1][y2]
value += (1 - fractX) * fractY * noise[x2][y1]
value += (1 - fractX) * (1 - fractY) * noise[x2][y2]

return value


Turbulance(x, y, turbulance=64)
var
value = 0
initSize = turbulance

while(turbulance>=1)
value += SmoothNoise(width/turbulance, height/turbulance) * turbulance
turbulance /= 2
return (128.0 * value / initSize)


Perlin(turbulance)
var/n[width][height]
for(var/y = 1 to height)
for(var/x = 1 to width)
var/c = Turbulance(x, y, turbulance)
n[x][y] = c
return n


~X
In response to Xooxer
I didn't say it wasn't doable, what I was saying was that it was slow.

My maps are 500x500. And I need to generate them randomly and on the fly.



Plus, if you make the map outside the game, it would be possible to create a new colored image file that you can then import on the fly to have a dynamic map of your newly created terrain. Which is exactly what I want to do at some point.
In response to Obs
Oh. I think someone (Theodis comes to mind but that might be wrong) made a demo to convert images into maps, making each pixel a turf. I'm not sure if it was released or just something they were toying with, though.

You could also try cellular automata. I think Hiead made a post on Dream Makers some time ago on the subject. I also have a cellular automata demo called LIFE3, with source code, if you want to explore that possibility.
In response to Xooxer
Xooxer wrote:
Oh. I think someone (Theodis comes to mind but that might be wrong) made a demo to convert images into maps, making each pixel a turf. I'm not sure if it was released or just something they were toying with, though.

Theodis made BMP2DMP, a program which converts BMPs into DMPs by allowing you to specify what kind of turf each tile will become. I don't think he has anything like it in library or demo format, but whether or not he COULD put it into such a format is another question.
In response to Xooxer
Xooxer wrote:
Oh. I think someone (Theodis comes to mind but that might be wrong) made a demo to convert images into maps, making each pixel a turf. I'm not sure if it was released or just something they were toying with, though.

You could also try cellular automata. I think Hiead made a post on Dream Makers some time ago on the subject. I also have a cellular automata demo called LIFE3, with source code, if you want to explore that possibility.


Cellular automata is not desirable because you need to be able to reproduce the exact same map every time. You also want maps to be tileable. So that if you move from one map to another, the next map correctly conforms to the edges of the previous one.


Also, the idea isn't to turn an image into a map, but to turn the map into an image.

I doubt you will be able to produce map images like this very efficiently in BYOND:
In response to Obs
Lummox JR has a seeded random number generator available on Dream Makers. If you use that to handle the automata, it will always produce the same results every time, given a single seed.
In response to Obs
Obs wrote:
Cellular automata is not desirable because you need to be able to reproduce the exact same map every time.

That's not true. Given the same initial conditions, you can reproduce exactly the pattern produced previously. It's just following a few simple rules to generate the pattern. The only randomness involved is provided by different starting conditions.

You also want maps to be tileable. So that if you move from one map to another, the next map correctly conforms to the edges of the previous one.

Then merge the edges together after you generate them. :P

Also, the idea isn't to turn an image into a map, but to turn the map into an image.

Well, that is going to be slow. Also, you'll probably run into problems of unique object limits if you don't properly handle resources when building your image. It is possible, though. I've generated large images from the map in png format. It took forever.

I doubt you will be able to produce map images like this very efficiently in BYOND:

Efficiently? No. But you didn't ask for that in this thread. You wanted a way to generate a map using a .dll. I took that as using the dll to run your noise functions and randomly generate terrain based on the return. That is efficient in BYOND. Turning that into a png is not, but that's not what you asked for initially.
In response to Xooxer
Xooxer wrote:
Obs wrote:
Cellular automata is not desirable because you need to be able to reproduce the exact same map every time.

That's not true. Given the same initial conditions, you can reproduce exactly the pattern produced previously. It's just following a few simple rules to generate the pattern. The only randomness involved is provided by different starting conditions.

Perhaps.

You also want maps to be tileable. So that if you move from one map to another, the next map correctly conforms to the edges of the previous one.

Then merge the edges together after you generate them. :P

It's not that simple. You don't want an ocean to stop dead just because you transfer onto another map. You need oceans to gracefully flow into the next map, and in fact you should be able to put hundreds of maps together and never see a single seam. You should not be able to tell where one map starts and another begins. And you can't do that with cellular automata without it being a pain in the ass.


Also, the idea isn't to turn an image into a map, but to turn the map into an image.

Well, that is going to be slow. Also, you'll probably run into problems of unique object limits if you don't properly handle resources when building your image. It is possible, though. I've generated large images from the map in png format. It took forever.

I don't even see how you would run into a unqiue objects limit. Where are you using objects? But either way, this is why the map is best produced externally, where there are no such limits.

I doubt you will be able to produce map images like this very efficiently in BYOND:

Efficiently? No. But you didn't ask for that in this thread. You wanted a way to generate a map using a .dll. I took that as using the dll to run your noise functions and randomly generate terrain based on the return. That is efficient in BYOND. Turning that into a png is not, but that's not what you asked for initially.

I certainly didn't ask for anything. I was merely pointing something out.
In response to Obs
I doubt you will be able to produce map images like this very efficiently in BYOND:

http://i6.photobucket.com/albums/y230/notapoet/ds1.png
http://i6.photobucket.com/albums/y230/notapoet/ds2.png
Average generation time for those using a slow computer (1.25 Ghz processor, 256Mb RAM)? About 5-10 seconds.

I would say that is at least decently efficient :[
In response to The Magic Man
The Magic Man wrote:
I doubt you will be able to produce map images like this very efficiently in BYOND:

http://i6.photobucket.com/albums/y230/notapoet/ds1.png
http://i6.photobucket.com/albums/y230/notapoet/ds2.png
Average generation time for those using a slow computer (1.25 Ghz processor, 256Mb RAM)? About 5-10 seconds.

I would say that is at least decently efficient :[


:[




Lighting is inferior. Look very closely at the screen I posted, it's directional lighting.
In response to Obs
Obs wrote:
It's not that simple.

Actually, it is that simple. By merging, I don't mean just putting the two next to each other and calling it finished. You'd have to select the edges a certain number tiles deep for each map edge being merged and use them combined into one grid to generate another few generations, eliminating the hard edges with the same method you used to generate the maps. Then use that to make your edges.

I don't even see how you would run into a unqiue objects limit. Where are you using objects? But either way, this is why the map is best produced externally, where there are no such limits.

Then you don't know how to make a png image in BYOND pixel by pixel.

I certainly didn't ask for anything. I was merely pointing something out.

What you pointed out (BYOND can't do Perlin Noise) was wrong, then you went off and started talking about something else completely. If the png is built in a dll it can be very fast. The limitation is BYOND's icon manipulation and object limits. If you understand those, you can still generate png maps for your game, just not all at once in a flash.
Page: 1 2