z2

SZZT would have gotten a bit more attention if you didn't have to use command line options to open worlds.

As an all in one it will blur the line a bit between the two separate programs.

Anyone for making hybrid worlds?

_________________
*POW* *CLANK* *PING*

I am going with what Commodore says, Vote +1 for Hybrid mode!,

Funny you guys should mention hybrid modes - by design, it is possible to have whatever size board and element list you want. Board sizes are only fixed when worlds are saved and loaded. The engine does not see ID#04 = Player, only the load/save code needs to know that. It's more like "hey this is a player and this is a ruffian and this is what happens when they snuggle". So theoretically, you could have an element list that contains every single ZZT and Super ZZT element all in one. You could even create your own - they still need to associate to a prefab element in order for the code to recognize it. But you could assign Ruffian to whatever char, default cycle, default color, even name, you want.

If you leave out Bullet but include Tigers, that'll cause a fun crash.

Even with this flexibility, I don't currently allow these changes to be made by the user. It wasn't really coded for these kinds of modifications. It was coded this way to simplify debugging, one change fixes both games :)

For fun, though... maybe after the editor is implemented fully.

Big image incoming!

It exports full board screenshots.

I can understand why creating SZZT boards would be difficult. It's hard to fill up such a large space, especially when only a small fraction of it can be seen at a time.

This shuts everything down.

...

not really :)

I'm not terribly worried about Lyon-related lawsuits, but for those who like to understand the law (like myself), here's a couple of links from reputable sources.

Summary: it's complicated.

Edit: changed image size settings.

Wow, that is some excellent information on the subject. It's good to know where the lines are drawn and some precedents.

However, there is this: http://www.classicdosgames.com/files/li ... icense.txt - the license states to remove all previous versions of the game, but they are still all offered there at CDG. Adding another twist, this license is not included at every place that has it available for download. Also, it was written and distributed after the initial distribution of the game.

ZZT 2.0 was used for the disassembly (because I was too lazy to get an executable unarchiver for 3.2). None of the documentation that came with ZZT 2.0 mentions reverse engineering. I downloaded it from a site that did not provide the license mentioned earlier.

Gray area indeed.

Nobody's sued Kev Vance yet, so I think you're safe.

Discovering more about the strange events that happen when you delete a stat object using #PUT. Sometimes objects unrelated to the action are affected - I had one object put an empty over another, and it caused a completely different object to become empty with stats!

More on this later.

This is basically caused by what you guys call the Koopo Bug, and the rabbit hole is deeper than I originally thought.

ZZT deals with indexes in arrays instead of references. When OOP is executed or behavior is processed, the index is sent, and is not adjusted when the number of stat elements changes (for example, #PUT kills an enemy whose index is less than that of the code being run). This index is also not changed when an action switches boards. Anything that changes boards and subsequently changes stat element data can trigger this bug as well - duplicators are probably the only thing that would cause a noticeable effect.

The order of objects is important. Objects that must run consistently, will not be deleted, and can't risk unforeseen modifications should have a low index. Any time an action is taken on a stat element that deletes a stat element of a lower index can cause strange results.

#DIE and #BECOME are safe because of how they are implemented.

Throwing in sound and packing it up for release.

I've got two OEM fonts to choose from. One is called CP437 and the other is called VGAROM. The notable differences are in the vertical placement of the smileys, the shape of 0, and the shape of O.

I've attached an example of each.

Which looks better? DosBox uses VGAROM for ZZT.

I'd like the one named VGAROM, It actually is the the real default ASCII Font!

Yeah, I like that one better too.

_________________
*POW* *CLANK* *PING*