Adding new commands to ZZT-OOP without breaking older games

NOTE: I HATE A LOT OF YOUR ZZT GAMES, SO WATCH OUT!

Moderators: Commodore, Zenith Nadir

User avatar
Truncheon
MMMM baby
Posts: 32
Joined: Thu May 07, 2009 11:45 am

Adding new commands to ZZT-OOP without breaking older games

Post by Truncheon »

Hi there.

I'm thinking about writing a ZZT emulator (for windows and linux). It won't have an editor this time (you'll just use the old ZZT editor, or kevedit for editing). But it will hopefully play all legacy ZZT games without any problems. I'll try to emulate some of the bugs, as well, like the sticky player clone bug.

I'm just tring to work out a solution to adding some extra commands without breaking older code. One of the possible solutions I've come up with is as follows:

Code: Select all

#`if FLAG
#`{
#`    print("Display message")
#`}
This one is the favourable candidate. The compiler would treat a hash followed by a backtick as a single symbol.

Code: Select all

#_if FLAG
#_{
#_    print("Display message")
#_}
This one can be broken by weird label names, such as:

Code: Select all

#end
:_if FLAG
I'm uncertain how many games are using label names prefixed with an underscore. Could use two underscores for added protection.

Let me know what you think.
User avatar
Smilymzx
I hope she made lotsa spaghetti!
Posts: 182
Joined: Sat May 20, 2006 2:58 am
Location: LocacoLocacoL :LoL!

Re: Adding new commands to ZZT-OOP without breaking older ga

Post by Smilymzx »

If you want to enhance ZZT like that, Try to look at Naesten/Samuel Bronson's ZZT Enhancer page before using any enhancement base, as it can help you a lot for that since he is the current maintainer:

http://sites.google.com/site/naesten/ezzt

Also, If anyone wants authentic support, use Dosbox and/or a compatible PC, make a TSR version for DOS to use these enhanced codes,

Then make a windows 32-bit frontend, Add dosbox support as an option for 64-bit computers, and you created a new set of tools for a new ZZT!
User avatar
Commodore
fgsdfs
Posts: 2471
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post by Commodore »

You can detect when you're loading a regular zzt world or an enhanced one. Just don't even bother looking for the new commands in the older worlds. Look at ZZTAE for watermarking zzt worlds.
*POW* *CLANK* *PING*
User avatar
Smilymzx
I hope she made lotsa spaghetti!
Posts: 182
Joined: Sat May 20, 2006 2:58 am
Location: LocacoLocacoL :LoL!

Post by Smilymzx »

Commodore wrote:You can detect when you're loading a regular zzt world or an enhanced one. Just don't even bother looking for the new commands in the older worlds. Look at ZZTAE for watermarking zzt worlds.
I heard that Kevedit was in use for building the demos alongside EZZT.

But the upcoming should support any ZZT file!

Note that making a compatible TSR also requires Reverse-engeneering ENHANCER.EXE (I heard the IDA free/IDA PRO does OK with that) and the CER/DLM files.

Of coruse the DLMs are DOS DLLs built with DJGPP, and may come with a Mikmod variant (or other needs) that may or may not exist,

and I couldn't help with what tool can redo the DLM/CER file sources!
User avatar
Commodore
fgsdfs
Posts: 2471
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post by Commodore »

oh right, he's not making a editor. maybe a single command that signals to the program that the world will contain further extended codes.
*POW* *CLANK* *PING*
User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1433
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Post by Quantum P. »

I like Commodore's idea: use a single command to signal extended ZZT-OOP.

You could also scan through the object's code beforehand and guess whether or not the ZZT-OOP was extended. As soon as the compiler finds proof that the program uses extended ZZT-OOP (e.g., an #extendedcommand without a corresponding :extendedcommand), then it goes back and compiles it as extended. Everything would just work 99% of the time; as for that other 1%, all you'd need to do is put #use extended or whatever at the top of your program.

Using #` would work, but it would make it harder to learn extended ZZT-OOP. Some commands look like #command, others look like #`command, and if I don't know which commands were in the original ZZT-OOP, I'll forget which commands have a backtick and which ones don't.

What extensions are you planning?
User avatar
Dr. Dos
OH YES! USE VINE WHIP! <3
Posts: 1772
Joined: Tue Mar 11, 2003 12:00 am
Location: Washington

Post by Dr. Dos »

Tyger has a handful of commands in it that wouldn't be valid in ZZT.

When ZZT loads a world it checks that the first two bytes are FFFF. I just made Tyger also accept worlds that start with 3141.

Similarly there would be a few ways with an FFFF world to check that it is running in Tyger if it needed it. For example, setting 11 flags and checking that the 10th is still set. In ZZT this would be false, in Tyger it would be true.
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter

Apologies for the old post you may have just read.
User avatar
Truncheon
MMMM baby
Posts: 32
Joined: Thu May 07, 2009 11:45 am

Post by Truncheon »

Quantum P. wrote:What extensions are you planning?
Whatever the community needs/wants, plus a few commands of my own. Also introducing a new item element which can be created in the following way:

You create a scroll using the original editor. In the scroll you put the command:

Code: Select all

#become item [char] [colour] [id]
(Engine can detect and enable enhanced ZZT-OOP on an individual element basis.)

ID numbers 0-255 are reserved for keys, but otherwise you can use roughly 2^32 different IDs.

Flags can be set internally to an element, to prevent polluting the global namespace with lots of flags:

Code: Select all

#regset [flag name] ( [item or element] )
#regclr [flag name]
Create integer flags:

Code: Select all

#set [flag name] int 1
Check if player has item:

Code: Select all

#regset tempitem item 1 1 256
#if has tempitem #send etc


More commands:

Code: Select all

#port [x] [y]              teleport
#board [id]                switch board
#boardnp [id]              switch board with no pause
#if at [x] [y] [element]
User avatar
Smilymzx
I hope she made lotsa spaghetti!
Posts: 182
Joined: Sat May 20, 2006 2:58 am
Location: LocacoLocacoL :LoL!

Post by Smilymzx »

Hope to beat Megazeux with that, because it has more than ZZT and SZZT,

Will it support SZZT elements and features in the future? That would make a great package in one!

(Scrolling is one of the advantages MZX has that regular ZZT does not!)

Here is a title I may give it: UltraZZT (UZZT)
User avatar
Commodore
fgsdfs
Posts: 2471
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post by Commodore »

what are these items and why can't I just set a flag?
*POW* *CLANK* *PING*
User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Post by Saxxon »

New format entirely. There's no reason to try and play a newer format game in an older engine unless there is 100% backwards compatibility and support for the newer stuff.
T-Bone
Spitting Tiger Blood
Posts: 25
Joined: Mon Jul 05, 2010 6:11 pm
Location: Canada

Post by T-Bone »

Enhancing ZZT to me seems pointless. I like ZZT for the fact that it is limited and its challenging to produce something under these limitations. I feel its rewarding when something good does come out of ZZT because it shows how well you can work around limitations as a creative thinker.

But if you must! Thats fine. I just love it for its oldschool simplicity.
"That lion looks like a giant horseshoe to me"
User avatar
Zandor 12
What has science done???
Posts: 355
Joined: Wed Mar 12, 2003 5:19 am
Location: Neo Dakota
Contact:

Post by Zandor 12 »

It'd be tricky to add to ZZT without making it no longer feel like ZZT. Changes to existing commands might be able to increase its power without fundamentally changing its flavor, perhaps; objects being able to detect what they're blocked by, more sounds for the play command, I don't know. I vaguely remember someone releasing an edited version of ZZT, ZZT 4.0 or something like that, where one of the changes was boards that could handle 32k of data instead of 20000 bytes - that sort of minor but useful change would be cool. (bumping up flags to 16/32 or something to reduce the need to piggyback maybe?)
User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1433
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Post by Quantum P. »

I've thought for a long time now that you could make a really fun ZZT clone by simplifying it instead of adding to it. You can only add functionality if it makes ZZT's limits less arbitrary.

Remove most of the built-in enemies, but make up for it by allowing :shot messages at point-blank range. Replace #throwstar with #put <dir> star (or maybe a custom object). Allow all 16 colors to be used in ZZT-OOP commands.

You might have to keep some things just to make it easy to program (don't replace the player with a custom object with :n :s :e :w labels), but it seems like every ZZT clone tries to make ZZT more complicated. Maybe that's going in the wrong direction...
User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Post by Saxxon »

ZZT is not coded well and doesn't have a lot of features. Its limitations are at times really unusual. But that's why we love it. These kinds of limitations are what brings creativity out of people.

I like to relate it to the demoscene. People are still creating demos for the Commodore 64 and the Spectrum. Instead of thinking outside the box, they are making the best of the box they've been given. It's easier to throw more hardware at a problem than it is to make due with what's already there.

When you have a small canvas, you don't need to fill as much space to complete a project. It doesn't require several people or several years. What defines a good project is what's done between the corners. When you have less to fill, you are less concerned about filling up all that negative space. It's about being clever with the space you already have.

We love it because it's simple. You don't even need to know all of it. I'm glad they don't just toss you a clean slate and expect you to create everything from the ground up. Built-ins give it flavor. They make it easy for new players to identify what's a passage and what's ammo. I like the fact that you are limited to 256 characters (on most setups, the code page 437 ones). You don't have to be an artist and you don't have to be a musician and you don't have to be a coder to make something good.
Post Reply