My Adventure Game Engine - Making Way For Adventure Engine 2

[Jasoco]

In layman's terms. REAL memory is using the RAM sticks, it is stored on the physical sticks. VIRTUAL is RAM that was passed to the Hard Drive and is stored in a sort of "RAM swap" that is deleted at shutdown. It is slower to load from the HD, but allows you to run more without needing more RAM. Still, physical RAM will always win. The more the better.

Are you on Windows, OS X or Linux? Each should show you both Real and Virtual RAM amounts for each app.

No one should ever need a map that's 1000x1000 in size really. If your game is that huge, split it into areas. Like one map for the beach, one for the mountains, one for the cities each, one for the forest, some sections for other areas along the way. This is how it is done in professional games and lets you have smaller maximum map sizes.

My graphics may be placeholders, but I place a lot on appearance and the appeal it would have to onlookers, even if I'm the only one looking at it for hours on end, I still want it to look nice to myself. It helps me visualize it as a real game than simple stick figures and plain graphics would.

[zugamifk]

I don't plan on having a 1000x1000 map, I was just testing memory usage. I assume many small maps will be much more efficient, even if I'm spending more time loading new maps. The other issue that arises is that because my maps are almost totally dynamic, I can only update maps that are loaded into memory. That is, all of the natural parts of my maps are going to spread and grow and be affected by weather and such.

Anyway, this thread is about Jasoco's game. I am eagerly awaiting updates

[Jasoco]

Weather effects and time are two factors I plan on incorporating into whatever the game ends up being.

[Jasoco]

Well, testing done on a 500x500 map. Don't do it. Use smaller maps. One big map split into multiple smaller areas is much better.

Well, there is both good news and bad news.

I created a map, just a plain map of 500 tiles in both directions with no extra decorations. Just a green grass map. It takes about 10 seconds to load the map. Now, the array is already created, this is loading the actual map file into the array. About 10 seconds of pausing. Roughly 26,804 tiles per second.

It does load though. After a long delay the map works fine. Yes, fine. The map is in memory, and scrolls at 60FPS like normal. Once all 1,750,000 arrays are filled with their map data, the game plays fine.

Now this could be fine if I were to put all the maps into one big map, but that would be way too unwieldy. And if I decided to have one big map and a lot of small ones, I'd end up with a huuuuuge delay every time you exited a building. Not tolerable.

Not only that, but the map is also 7 megabytes of data.

A 250x250 tile map only takes a few seconds, but it's still a delay. And its map is about 1.8MB.

Bottom line, it just doesn't make much sense to have a huge map that big. The loading times would suck a lot. Maybe if you were to have all your house internals and the main map in one huge map file so it only has to load once, but as I said, good luck managing a map that huge.

Use a big map if it's the only one you will be loading. Use a bunch of small ones if you want to have many areas.

I'm glad to see my engine can handle a huge map without much RAM usage and no slowdown. But sad to see that it's not really useful.

I'll work on the loading and the formatting of my map files to see if I can cut down the load time.

Edit: By removing spaces and underscores from my map strings, I made them a nice percentage smaller. The underscores and spaces were used to make it easier to read and edit when I was doing it by hand. But now that I use a WYSIWYG map editor, I don't need the spaces and extraneous characters. In fact, I could create a completely unintelligible map format as long as the editor and game can read them.

[TechnoCat]

You should try having a matte tile. Like a certain tile that is the default. That way you can save by not copying over the matte tile numerous times because it will already be in the loaded array.

Another type of map file to speed up load time is to allow lines of tiles. Or even a large rectangle of tiles you can set in the map file. It is quicker to load.

You could represent

Code: Select all

1 1 1 1 2
1 1 1 1 2
1 1 1 1 2
1 1 1 1 2
1 1 1 1 2
1 1 1 1 2
1 1 1 1 2

with

Code: Select all

rect(1,(0,0),(3,6))
line(2,(4,0),(4,6))

Then with overwriting you can make bordered areas really easily. And other basic geometric shapes.

[zugamifk]

Well that's one problem solved for me then. Looks like I'm going to have quite a few map files.

Come to think of it, I do recall it taking along time to load the map. I was hoping that wouldn't be an issue since games like Grand Theft Auto and Oblivion seemed to have smooth transitions despite having very, very big map files. I wonder how they manage that.

[Jasoco]

GTA and Oblivion aren't built with Lua and have much more powerful backends.

I don't know whether the bottleneck is in the loading function or the part where it transfers the data into the arrays. I want to say loading though. The part where it actually opens the file and reads it that is.

After some testing with a 5.5MB map file it takes:

7 seconds to load the data into memory and 1 second to transfer it to the array grids. It also takes 1.3 seconds to dimension the arrays at the start to 1000x1000 in preparation. So that's the bottleneck. The filesystem functions.

That's using my more compressed map. I want to compress the map format even more. A map of 500x500 contains 5,500,500 characters. Each tile is 22. 4 for each of the 5 layers and two for collisions. Each tile has an X and Y. 00 through 99 in both directions. But I am thinking it is overkill and want to convert to a letter based system where A means 0, B means 1, etc. It would cut the amount of characters in half. I'd just write a conversion function to change the A to a 0 in the game and one that converts a 0 to an A in the map editor. Animations would be defined by another character like say a # or a $ followed by a letter corresponding to the animation to use.

I would assume a map of 1000x1000 would take four times that loading time.

A 1000,1000 map is large enough to hold the entire map for the entire game in memory to create seamless transitioning, but the question is do you want that? I mean, sure it'd save loading in game by only loading it at start. Personally, smaller easier to manage files that load in a split second are much more useful and easier to deal with. Games like Zelda used two maps. One for the overworld that loaded completely and just panned from one screen to another. And one for all the dungeons, which were all (All 9 of them) contained in one map fit together like a puzzle. In theory, you could hack the map to place a bombable wall on the outside of one dungeon and walk right over to a completely different one. This allowed them to store more in memory by utilizing all the empty space they could. There were extra open spaces in the dungeon grid that I assume were used for shops and wise old men and such.

More testing shows that in game, if I start at one map, and then load a large map, the delay is just too intolerable. Even on a 250x250 map. Though not as bad. I'll probably stick to small maps designed to represent one big one. No bigger than 125-250.

You know what the nice thing is? With a little bit of editing I could change this from a top-down engine into a sidescroller. Which is what I plan on doing next. A game like Cave Story or Knytt Stories or even I Wanna Be The Guy! can easily be done in Löve.

[bmelts]

Another option to consider is breaking up your maps into different areas, and doing preemptive loading - for example, when the player is walking through the Desert Zone and starts getting close to the entrance to the Fire Zone, load the Fire Zone's map into memory. That way, if the player does go into the Fire Zone, you'll have the map preloaded so the player won't have to wait - plus, loading time per zone will be shorter thanks to the smaller map files.

The fact that you're using a Zelda-esque engine simplifies matters greatly, since players go from one section of map to the next discretely, as opposed to constantly scrolling. So you could set it up so that when the player enters the section of one area that connects to another area, it triggers the load.

Of course, the point of preemptive loading is wasted if there's no way to load simultaneous with gameplay - if loading the map blocks the game loop from continuing to execute until it's loaded, that's no good. I don't know how well Love plays with coroutines, or if they'd even be necessary...

Just sort of thinking out loud here, this might be totally useless

[rude]

Interesting project!

[Jasoco]

It seems that when the FileSystem functions are running, the game freezes until it's done. There's no multi-tasking or way to show like a progress bar because it does it and doesn't stop until it's done during which point you end up with a blank screen, or the last frame shown before the load started.