Steam telepítése
belépés
|
nyelv
简体中文 (egyszerűsített kínai)
繁體中文 (hagyományos kínai)
日本語 (japán)
한국어 (koreai)
ไทย (thai)
Български (bolgár)
Čeština (cseh)
Dansk (dán)
Deutsch (német)
English (angol)
Español - España (spanyolországi spanyol)
Español - Latinoamérica (latin-amerikai spanyol)
Ελληνικά (görög)
Français (francia)
Italiano (olasz)
Bahasa Indonesia (indonéz)
Nederlands (holland)
Norsk (norvég)
Polski (lengyel)
Português (portugáliai portugál)
Português - Brasil (brazíliai portugál)
Română (román)
Русский (orosz)
Suomi (finn)
Svenska (svéd)
Türkçe (török)
Tiếng Việt (vietnámi)
Українська (ukrán)
Fordítási probléma jelentése
Hozzászólási szabályok és irányelvek
Hozzászólás jelentése
Developers don't know what we want they know what some the RPG Maker fans on their site want. That is no new features and to stay in the stone age :P
Sorry for the rant but it's slightly true. I find Anime communities really hard to work with from personal experience for running fansites.
They don't like too much change and are quite a custom to something they want to keep it that way.
Sadly this has ended up being the excuse for everything so far that was removed or nerfed in a sense.
Do realize that no game actually has this.
Every game, from Ultima to Minecraft uses a kind of macro-sector system. The entire world isn't in memory at once, only the part of the world that is within scope. For most games this is basically the visible area of the screen * 9.
So if you have a 256x256 map of 48x48 tiles That is 150,994,944 pixels, taking up 603,979,776 bytes of memory. If you restrict the visible area to 1024x720 (x9) that is 6,635,520 pixels or 26,542,080 bytes of memory. As you walk in one of 9 directions, the next macro-sector is loaded from that direction. That's how seamless maps work. In tile-based systems, you get to save some memory and only load 50% of the tiles in either direction, drawn in strips. You can even check this out by playing any NES/SNES RPG title in an emulator and then inspecting the video buffer. You'll notice that the area not on screen only extends by about half the screen resolution, and that's what enables "shakey" effects (by shifting the display buffer up or down a few few rows.)
Games that use individual maps, often only have one tileset per map, and the maps are pretty small.
For example, FF6's SNES/GBA world map is 4096x4096 pixels made up of 8x8 tiles with 16x16 macroblocks, so the world map is 256x256. (256 tiles x 16 pixels = 4096)
A city like South Figaro in FF6 is 1024x1024 pixels (64 tiles x 16 pixels = 1024)
Since a RPG Maker MV game dynamically loads maps as they are requested, the way to get something pseudo-seamless is to provide cache hints and remove any transition buffers. So as an example, once the player reaches the eastern-most part of a map where they would cause another map to load, you instead already have this map loaded and quick transistion to the new map where the western-most tiles look the same. So if you walk back and forth between the two maps, no apparent loading time exists.
There's probably better solutions, but I'm telling you right now, if you want seamless maps, what you are looking for are smaller maps limited to the draw distance. It may ultimately require creating one large map in a separate program (eg TileED) and having something slice it up into RPG Maker MV sized tiles, and then working from there.
So because you want it, you assume everyone does. uh huh, riiiight... Seems to me, to export games to smaller devices, they have in fact delivered what RPG Maker fans wanted... so....
Feature creep is a thing, try to avoid it.
/endrant
People just love to complain. First it was the pre-order thing where people thinking they were getting 2 versions when they really aren't. So now there's this. The complainers aren't real devs anyway. Real devs understand how hard it is to make an engine. No engine does everything for the user. That's why there are scrips and plugins, to push the editor further then what its capable of by default. If the engine literally did everything for the user it would sell for $100,000 and then people would complain that its too expensive. And really, the only time to use the biggest sized map is for the over world if the game has one. And even then you don't really need the biggest map. Maybe with a plugin these people will be happy. But till then they will just complain and I will sit back and laugh at them. They could just make their own engine
You can download up to 4GB on the mobile devices, but it's extremely frowned upon. The largest game I have on my iPad is The Simpsons Tapped Out, and what they do for every event is delete the previous two-event's ago content when they add new stuff. It's about 600MB installed.
The point is that people making unreasonable demands, are doing so without consideration of why those limitations exist. You aren't limited to a 256x256 map, you are limited by the editing tool to 256x256. Which is more reasonable? 100 256x256 maps or 10 2560x2560 maps? The latter take more memory, while the former require more disk or network i/o. If it takes 1 second to load a 256x256 map but 100 seconds to load a 2560x2560 map, you're going to make 256x256 maps entirely because the loading time isn't reasonable unless the entire game is one map.
I imagine you could just do the same in MV.
Ace had a limit of 250k tiles however (it would crash on anything higher), but this might not be an issue in MV.
I was once asked if a webhosting customer would be allowed to scan every single IPv4 IP and collect some information about it. Putting private IP spaces aside, I said sure! How much information do you plan on saving? If you only want 256 bytes of information, you'll need to dedicate 1TB of diskspace...
I'm pretty sure it wouldn't take a gig of memory to draw 250000 tiles.
Different story for disk space, but you should be compressing your data files anyways.
When I load a 500x500 tile map in Ace (flood fill with the same grass tile), task manager reports 28M of usage.
Why are you complaining about map sizes again?
You're not reading what I'm saying. You do not compress and decompress stuff as you use it, it's decompressed in memory. There's a thing called page swapping. The "active" memory might only be 28MB, but that's only the visible map and current tileset, and since it's the same tile, only that one tile is in memory, not 250,000.
If you had a map of 250,000 unique tiles that needed to be rendered seamlessly, it certainly would be 1GB. And the reasons for crashing the game client likely had to do with the Ruby interpreter being unable to do garbage collection (Ruby is notoriously bad at it.) Javascript has similar issues (The Sphere RPG Maker has a similar problem) is that the Javascript interpreter will decide to just delete objects it thinks aren't in use, because they run out of scope, when in fact they need to remain in scope because it's not a web browser. That's a huge pitfall in OOP programming. You create a tonne of objects and aren't manually deleteing them when you should. Instead leaving the automatic garbage collection system delete stuff that "hasn't been touched in a while"
That's why games often build their own memory managers to implicitly bypass GC. But at the same time they tend to make a lot of errors in not initializing memory or worse, reusing memory that has just been released.
I remember playing the original version of Ultima 7, and whenever you "went to sleep" all the keys in your inventory would disappear. You had to store them in a bag and leave them outside your inventory. This was a bug due to the game needing to delete the Inn keys, but it deleted all of them (making the game unwinnable without using the dynamite to blow doors up.) Another related bug is when you try to make a crate staircase to find the debug room, some of the crates will disappear if you leave the town. This is again the "garbage collection" in action. The crates don't go back to their original spot, they just disappear. A third game-killing bug is if you fly the magic carpet over the Isle of the Avatar, it triggers the doors in the dungeon, thus making the game unwinnable, even in the patched game.
For reference Ultima 7's maps[exult.sourceforge.net] are 9,437,184 (3072x3072) tiles of 8x8 pixel tiles. That is 16x16 tile Chunks x 144 (12x12) Superchunks for a total size of 24576*24576, or a total of 603,979,776 bytes. Each chunk is reused about 10 times (36,864.) Without that reuse it would have been 2.25GB and computers back then only had 4 or 8MB of RAM. The game shipped on 7 floppy disks (about 18MB installed including the add-ons.) Ultima 7 was "seamless", but it was actually swapping out these chunks as you walk around, and you definitely saw the reuse.
It's this kind of thing where letting the game engine be "too helpful" is often detrimental.
Anyhow, RPG Maker MV could in theory do this, but as I mentioned earlier, it probably would require an external tool to create the supermap first and then everything else has to be worked on at RPG Maker MV's editor scale.