ok, I'll add it then.
It will not be unbreakable (like any protection), so no worries for lost passwords.
After all, the engine's source code will be available
But, it will make people think twice before start looking for cheats, instead of banging their heads to solve the puzzles...
nice idea, so it would work abit like a macro storing key presses & timings while playing the game to play back later. but i could see it opening up a whole can of worms, especially if someone edits the map or changes the scirpts in some way.
I think it is already doable from the script.
Use the update handler and consider three modes:
0 = normal playing
1 = normal playing + recordig
2 = playback
In the recording mode, on each frame, you store the incoming keys from G_KEYS (and G_KEYSHIT) in a file as integers, using GS9 file functions.
In playback mode, on each frame you read the stored keys from the file and write them back in the G_KEYS (and G_KEYSHIT), as if the player have pressed them on that frame.
Keep the file open during recording/playback.
Have all this functionality in a separate script file, for easy porting, and just call a RecorderUpdate like function in the update handler.
Optimizations can be made, to store keys in a buffer first and write it all at once in the file, when it's full. File operations per frame can be slow, so this kind of prebuffering is a good idea.
Consider a way to stop the recording/playback, like another special (non-game) key, or a combination, that players usually don't press while playing.
Also, before you start to playback a record, you must recreate the exact enviroment that was when the record was made. This can be done using a saved game. Like when you start a record, make a saved game and then record player's input. When you play one, load the saved game and emulate player's input.
This kind of gameplay recording is common to multiplayer games and sometimes it is quite tricky to implement. The good news is that DizzyAGE runs at a constant frame, so you can easy repeat a whole set of updates, given the same starting point and the player's input.
Depending how large?
DizzyAGE supports whatever your hardware supports.
Internally, this means restriction to power of two for texture sizes (width and height) and on some old hardware, restrictions to square textures.
The tiles of various sizes are handeled internally by the engine and expanded to the restricted sizes.
This means, if you have a tile of 129x129 pixels, it will take as much memory as a 256x256 tile, because 256 is the next power of two, after 128.
Considering that some old hardware have a limitation of 256x256 for textures size, it is best to stay within this limit.
Who knows on what platforms will DizzyAGE be running in the future!
You don't want to force an 2048x2048 texture into a mobile cellphone
its this i was referring to from my game thread :
As for the memory load, it can be helped by splitting the map in
rooms areas, where the tiles are loaded during the game, when
entered the first room in the area, to limit the amount of memory
used for tiles at any moment. Using TileLoad and TileUnload.
Now TileUnload unloads all the loaded tiles, but it can be made to
use some sort of package id, especially if there are a lot of common
tiles, that could be kept. Something like:
TileLoad("data/tiles/common",0); // package id=0
TileLoad("data/tiles/area4",1); // package id=1
TileUnload(1); // unload package 1
TileLoad("data/tiles/area5",1); // load other tiles as package 1
It would need an engine update, but if you're going to make
a game that needs it, I will add it at that time.
Oh, that feature...!
The "resource group" is already implemented in the upcoming v2.2
The group parameter is optional in the Load and Unload functions and by default it's assumed to be 0.
Available for tiles, sound, music and recently fonts.