Some considerations for the single player engine
One of the most important decisions were whether or not the engine, and scripting, implicitly, should support multiple maps or just one map.
Now, each method has some advantages and dissadvantages that had to be properly considered.
The pros of multiple maps:
1. Smaller loading times.
2. Slightly less memory footprint (not a big deal with the caching algorithms we are using).
3. More versatility.
4. The overall maps (like a paper with the landscape) would be more easy to manage, since your location can be better pinpointed in the local context (more accuracy).
The cons:
1. Players usually don't like loading times (an initial loading time is OK, but additional loading times while changing maps are not so great).
2. Much harder to implement. For example, say we have some actors (NPCs) which go
to work in the morning then come home in the evening.
Now, what happens if you leave a map during the afternoon, and come back at night?
How would that NPC move to go home? It would need that old map in the meory as well, to calculate the path. Some cheating can be done, to teleport it home if you return during the night, but what if, say, you place some traps on their way home, to kill them? If they teleport home, they would not trigger those traps.
3. Similarly, the monsters would be in the same position where you left them, during map switches, because having them switch maps and walk in new maps would be pretty difficult.
4. Saving and loading the game would be much more complicated, as all the maps should be saved as well, since they can be modified.
In the end, I have decided to go with one map per game. The map would be pretty big, perhaps 4 square kilometers. Yes, it will take a lot of memory, but then again, modern computers have at the very least 512 RAM, and I estimate the game would be pretty playable with 256 MB of system RAM, possibly less than that.
Which is not that bad, considering that during some Battlenet custom games, the Warcraft 3 client run out of memory on me (no swap, about 1GB of free memory).
Now, each method has some advantages and dissadvantages that had to be properly considered.
The pros of multiple maps:
1. Smaller loading times.
2. Slightly less memory footprint (not a big deal with the caching algorithms we are using).
3. More versatility.
4. The overall maps (like a paper with the landscape) would be more easy to manage, since your location can be better pinpointed in the local context (more accuracy).
The cons:
1. Players usually don't like loading times (an initial loading time is OK, but additional loading times while changing maps are not so great).
2. Much harder to implement. For example, say we have some actors (NPCs) which go
to work in the morning then come home in the evening.
Now, what happens if you leave a map during the afternoon, and come back at night?
How would that NPC move to go home? It would need that old map in the meory as well, to calculate the path. Some cheating can be done, to teleport it home if you return during the night, but what if, say, you place some traps on their way home, to kill them? If they teleport home, they would not trigger those traps.
3. Similarly, the monsters would be in the same position where you left them, during map switches, because having them switch maps and walk in new maps would be pretty difficult.
4. Saving and loading the game would be much more complicated, as all the maps should be saved as well, since they can be modified.
In the end, I have decided to go with one map per game. The map would be pretty big, perhaps 4 square kilometers. Yes, it will take a lot of memory, but then again, modern computers have at the very least 512 RAM, and I estimate the game would be pretty playable with 256 MB of system RAM, possibly less than that.
Which is not that bad, considering that during some Battlenet custom games, the Warcraft 3 client run out of memory on me (no swap, about 1GB of free memory).
posted by Radu at 6:18 PM
5 Comments:
Sounds like a good plan, I personally like the 1 map idea I've been thinking about that for my game but I want to make something that works on slower systems as well as faster ones just not sure what would be best for that situation. Personally it sounds easier to just load a map all at once instead of having to swap maps or load them while the game is running once you get close enough to an area in the background.
I know thats not what you were talking about but I think small maps with lots of loading also get annoying especially when you have to move back and forth between them a lot. Good luck :) I was thinking about posting that info I found out on the forums for the 200m just in case if someone is still having problems with it or someone in the future has problems with it. Not sure why it won't handle particles, they seem to work fine in other games...
Yes, it is easier, and it doesn't really take much effort to preload the nearby areas, the caching has already been done.
As for your particle problems, the ATI cards have problems displaying point sprite particles.. No idea why. Mine displays them, but bad, with flickers and stuff.
Yes I do actually remember hearing that. ATi should fix that. But as I said before I've always liked NVidia better anyhow. I did post up my findings on the forum because I have noticed other posts having problems similar to mine and the same card as well, maybe it will help them someone out in the future.
It feels good to contribute in little ways.
Sounds very good, are you planning on using code from this for the online version as well? Adding moveable NPCs seems like it would add to the effect of the game.
No, this is exclusively for a single player game, no multiplayer support whatsoever.
Post a Comment
<< Home