DizzyAGE Wish List

[Peter]

Another piece of advice I need:

I can add an option (in a game.inf file, inside the game's data folder) to allow users to protect
their game against players who want to unpack the dizzy.pak archive or to use the developer option in the dizzy.ini.
The packer would require the password code to unpack, and other developers would have to contact the author to get it, for learning purposes.

The advantage would be that players (who know DizzyAGE options) will not be able to trick the game and spoil their fun of playing, by navigating the map in developer mode or unpacking the data and open the map in editor or read the scripts to find the solutions for puzzles.
Though, no serious Dizzy player would do that ... cough, cough!

The disavantage would be that developers must contact the game's author to get the
password and look at the scripts for learning purposes. This might slow a little the process of DizzyAGE learning.
Though, no serious Dizzy developer would be lasy to send an email.

The option would be off by default and authors could choose to protect or not their games.

So, what do you say?
Should the game protection option be available in DizzyAGE 2 or not ?

I would say add it! Personally i don't have any worries about people looking though my games code and maps. but on the other hand it would stop people from 'cheating'

[xelanoimis]

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...

[SLIDER]

how about function "save/load video walkthough" on DizzyAGE (not avi, mpeg, e.t.c.) (like on "Spectaculator")

[Peter]

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.

[xelanoimis]

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.

Alex

[NigeC]

Did you ever get anywhere with large image support Alex?

[xelanoimis]

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

[NigeC]

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.

[xelanoimis]

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.

[NigeC]

cool!