We are about to switch to a new forum software. Until then we have removed the registration on this forum.
I'm wondering how a roguelike can store HUGE maps (think Dwarf Fortress) without the speed of the program being affected much? Generating a world of, say, 1000x1000 tiles is incredibly tolling on my programs.
Answers
Only draw what you can see.
1k square is only a million, nothing for a modern computer.
I should try this, see how hard it is. I am sure these are mostly solved problems.
Please post anything you do!
I understand the concept of drawing what you see, but how would I pre-create a gigantic world that you can explore? Obviously, you can't generate a world according to the travels of the player, or else the world will be mangled and disjointed...
I once made a map where you move a player (a red dot)
the map is much bigger than the screen and it scrolls
http://www.openprocessing.org/sketch/149191
see discussion here
http://forum.processing.org/two/discussion/comment/18546#Comment_18546
Well, that is slightly closer to what I'm getting at...
I guess it's more a question of procedural generation, and how to store large maps that have been generated in a way that won't bog down the program.
yes, when you use byte or short as data type for the 2D array it can be a huge map
number 1 could mean grass, 2 forest, 3 path etc.
doesn't take much memory for computer
for the number 1/2/3 you just show another image in that cell (tile)
so you only need 3 images that are repeated
;-)
I made an example of navigating a large unit map. At any given point you can only see a 12x12 section of the map, but the rest of the map exists.
More importantly, only the 12x12 section is drawn, the rest is ignored. Likewise I would imagine that you will have other entities / other characters / bad guys later, you should make similar code where only other entities close enough to where you are on the map are given actions. Say you are at location (10, 30), what some other entity might be doing at location (600, 800) really doesn't matter. This will be what makes it run at a reasonable speed despite being large.
Thank you for the help!
Note: @asimes The window size shows up as about 100x100, and that seems to happen whenever a large array is made in Processing. I fixed it using frame.setResizable(true);. Also, I would love to use what I know to polish up your code for you!
Here is a combination of what both of you suggested, based off of the example:
Glad it made sense and I am kind of surprised noise() makes reasonable looking terrain
I think my version is a little better since the scrolling of the map stops on the borders but the player moves on and walks to the end of the map (on the screen border)
when he walks back to the center, the map scrolling only starts again when he reaches the center of the map again
do you have that?
Couldn't resist and made a online remix version too: =:)
http://studio.processingtogether.com/sp/pad/export/ro.9Ql2E8JBC54LJ/latest
P.S.: Hit SPACE or ENTER in order to switch turbo mode on/off! ;)
@Chrisir My program does allow for not being able to magically walk off the map, but it won't allow walking to the edge.
I see.
I now made it more roguelike:
I've updated my remix version to be more rogue-like too: :bz
http://studio.ProcessingTogether.com/sp/pad/export/ro.9Ql2E8JBC54LJ
awesome! Now we need to do city generation... :P
I'm kinda lost when it comes to that
I was rather thinking about enemies & treasures! O:-)
lol, that would be easier...
1st I recommend to check if there is are lib
2nd you need an graphical editor to be able to edit the map, save it (So longt text pieces with entries like 786576 to decode your city / map content) load it. This map will later be used in the game. Maybe the lib has it. Should have it. Because when you have different levels, for each Level / town you need it.
3rd You need a graphical editor (windows paint or so) to paint the single tiles (cells of the map) such as street, small house with grass in front, big house...
when it comes to city generation, I don't think you can work with random, because next to a street leading right, on the right side must come a tile that starts with a street on the left (and can go straight or go left or right or be a dead end)
When you don't have random generation, you need some kind of editor, see above. You could type it in in a text editor (45451546) but that'd be quite a pain...
;-)
You should be familiar with # 1 to 6 of the tutorials at last
http://www.processing.org/tutorials/
Look into
www.openprocessing.org please
e.g. in the collections you'll find games of course.
http://www.openprocessing.org/collection/25
You'll see a lot of games with code there.
Also for games please see
Link
KevinWorkman wrote some basic tutorials on game development in Processing that might help you out: http://www.staticvoidgames.com/tutorials/
i went a different route with this, more SNES zelda than rogue, using graphic tiles but allowing sub-tile movement - tiles are 32 pixels wide but the player can move a pixel at a time.
i've also used a png to define the map so i could just draw it using a graphics package, but which is terribly inefficient as it'll use 24 bits per pixel for the image which it then doesn't directly use. it moves all the non-empty pixels into a hashmap using position as key. this is probably slower than an array, but might be smaller if map is mostly empty - i was experimenting.
it's more processor intensive than i'd like, but using opengl helps. i turned off the grass tiles because they looked too busy and took too much cpu.
you'll need to supply the tiles yourself - grass.png, tree.png, lava.png, water.png, wall.png. they need to be 32x32 pixels. but i've uploaded the (crappy) map so the program will pick it up when it runs.
< and > to rotate (actually , and .) collision detection isn't great, is probably half a tile out. it works ok for something i cobbled together in an hour.
Hey @koogs! So you're using a String as some kinda tuple for coordinates, is it?
I've had an idea here to make it faster: Rather than <String, Integer> pair, how about <Integer, Byte>?
Graphics coordinates generally don't go any further than 16-bit value range.
Therefore we can store x & y together as a 32-bit value! *-:)
Check it out my experiment. Perhaps its implementation can help your game be less CPU intensive. =:)
Now, what if we wanted to make a large world (500x500) with every tile conaining a map (200x200). That way, you can travel on the large map, and explore inside of the tile's map.
HashMap<Integer, Byte> would help, i think, but i think that's still going to be negligible compared with shifting the image data - something borne out by how much less cpu it uses when i switch to opengl.
and an array will always be more efficient, speed and space-wise, except for the very sparsest of maps. and looking at zelda (below), it's pretty much all non-grass.
maytze, i don't think that'll work. a tile is the smallest indivisible object. it holds all the attributes for that possible player position. having a 500x500 tile would be very limited. but there's nothing to stop you having multiple maps, each 500x500 tiles. that said, playing around with 1000x1000 tiles it was obviously TOO big.
http://mikesrpgcenter.com/zelda3/maps.html ^ probably 128x128 x 16x16 tiles (maybe 256x256 x 8x8 tiles) 2048x2048px total
but rogue-likes are different. there is no sub-tile positioning (i'm not convinced there is any in zelda either, except when the player is moving from one tile to the next - he can't stop halfway between tiles)
Sub-tiles are possible, except a 4D array would be needed.
please see this free tile editor
http://www.mapeditor.org
see also
http://forum.processing.org/two/discussion/comment/21445#Comment_21445
which features a jump and run map (from the side)
and not a look from above map
I actually have tiled :D
I need help with exporting and using the maps I make.
Update:
I am making a roguelike that features a 80x60 map with 40x30 subtiles.
Hello, I've been working on similat project and I can't make zoom working with your example. Do you have any idea how to handle that?
look at scale in the reference
;-)
there is also a new forum now
@TheJeff This might help https://forum.processing.org/two/discussion/20853/scale-translate-ab-comparission#latest
Please let's continue in the new forum. Don't forget to cross your future post with this one.
Kf