View Single Post
EvilMike

JCF Member

Joined: Jun 2001

Posts: 3,478

EvilMike is OFF DA CHARTEvilMike is OFF DA CHARTEvilMike is OFF DA CHARTEvilMike is OFF DA CHART

Sep 1, 2009, 06:06 PM
EvilMike is offline
Reply With Quote
Quote:
Originally Posted by Penalty View Post
You're overcomplicating it, Mike. Remember that this is a scripting language meaning there should be much simpler solutions than trying to stick your variables in some unused jj2 memory. I am thinking about implementing two separate script contexts, the first one being game-wide and the second being system-wide. Each time a new level loads, the game context would load up an appropriate script that persists throughout the game until the level cycles while the system context is automatically created whenever the library starts up and persists throughout the entire game (level cycles, main menu, high score, credits, everything) until the game unloads. So if you were to put a custom object inside the system-wide context it would persist through level cycles. Then all you need to do is write down the desired variables to this object and have them retrieved again as soon as a new level loads - OnGameBegin().
But overcomplicating things is so fun

In all seriousness, that sounds good, but my problem isn't so much going from level to level (not too worried about that; while I COULD use some insane solution like I described, I won't... that's why I referred to it as a "bad" way of doing that). The problem, rather, is going from game to game.

Let's say I want the map to reveal itself a bit each time you visit a room. Ok, nothing complicated there: just have an array for that where a flag gets set each time you enter a new room. Then, when you visit the area with the main map, fiddle around with animations or the tile cache to get the map to show up as it's been explored. So far so good... but what happens when the player unloads jj2?

In other words, the game is saved, JJ2 is closed, JJ2 is run, and the save file is loaded. None of that "map" information will get saved, because it's not meant to be part of the save file. That's the real reason for looking around for unused bits of memory to mess with.

Of course even that is unnecessary, if the scripting language is able to save things on its own... but I'm not sure if that's a planned feature or even a good idea.