z2

A while back, I came across an old ZZT game called Planets. It's a turn-based strategy game, but there isn't that much strategy involved -- all units are identical, and each attack is just a 50/50 chance your ship will destroy your opponent's, instead of vice-versa. Over Thanksgiving break, I thought I'd take a stab at making an improved engine. I didn't think it through, didn't implement it properly, and lost interest in it before I did any significant work. Screenshot posted here because the idea is still going through my mind, I thought you guys might find it interesting, and what I had thrown together (though woefully incomplete) is a nice illustration of what I had in mind:



Note: These are only ideas for how such an engine would work. I have no implementation, aside from the Pollyanna version inside my head.

Original idea from Thanksgiving: Pressing the arrow keys move a selector across a grid (in an actual game, colored fakes would be used to make a map). Moving the selector over a unit gives you info about that unit in the area to the right of the map (would be a second sidebar of some kind). Selecting a unit (by shooting) switches to movement mode, in which the arrow keys cause the unit to move around. If you run into another unit, it tells you about that unit, and if you shoot in its direction, you initiate an attack. The results of the attack are randomly decided, but the odds would be skewed depending on a comparison of your attack strength and the other guy's defense strength. Once all your units have had a chance to move, it's the other side's turn.

This naturally lends itself to being a two player game. Either two players would have to sit at the same computer, or two people would have to do a play-by-mail thing via email or IRC (if you use a pseudorandom number generator, the only data you have to send back and forth is who moved where). The alternative is an AI opponent (thing I didn't think through #1). It's easy to give the computer twice as many units, let them play with loaded dice, and have them sweep the board in a pattern, but ideally they'd at least try to look intelligent.

On to technical details. A lot of code could be avoided using #bind a lot. Units could keep track of damage using Dos's binders keepers engine. You could actually keep track of more than just damage using a similar technique. Say you have 4 unit types, 3 damage levels, and 2 sides. Each object on the map would bind to one of 4*3*2 = 24 objects in order to keep track of type, strength, and side. These objects only do two things -- report who they are bound to, and change that binding when told to. If a unit is commanded to actually do something, it binds to one object with the proper code, then binds back to what it used to be when it's done (it sets a flag so it can remember what it was bound to). This way, what I'm guessing is nontrivial code won't be duplicated across 24 objects, or however many you have.

When the cursor moves over a unit, one of the cursor objects puts a normal wall above the unit -- a message is sent to all the units to check #if blocked n, and if so, to report what type of unit it is. Selecting the unit (similar if blocked check used) causes the object to bind to the "active unit" object, which contains all the code for moving and stuff (see previous paragraph). Depending on the type of unit (declared when the cursor moves over the unit), the player is given a certain number of torches (movement points). Movement is a bit complicated because to stay on the grid, you have to move forward one step, then move back if you're blocked, else move again -- this keeps you on the grid. Also, somewhere in there the unit #puts dir line and checks #if any color line -- this restricts what colors you can use for the map, but it also allows for a movement point system where certain colors cost more points.

When an object runs into something, it backs up and shoots at it -- this is not to destroy it, but to send it the :shot message to indicate that it should report what kind of unit it is. If the user finds the odds favorable, he signals the computer to attack. Attack strength would be compared to defense strength (perhaps by #give ammo attack and #take ammo defense). The easiest thing would be to just give a random number of ammo, and if it goes over a certain number, the attack is a success. But if you wanted to get fancy, you could do a whole combat results table thing instead, where each category of confrontation has different probabilities for no effect, damage to defender, damage to attacker, defender eliminated, etc). Once the outcome of the attack has been decided, the objects rebind to reflect the results, possibly becoming fake if they were eliminated.



That was Thanksgiving. Since then I've been brainstorming a lot, although distracted by other things. Would it work without a cursor (force user to move units in a certain order)? Is a reasonably good AI possible (one idea among many -- have invisible objects run around until they pass an enemy then a friendly, then tell the enemy to run in their direction)? Would it work without objects (use different types/colors of terrain to symbolize different unit types/strengths, have a cursor go around and updating them)? Would a more compact grid work (might be possible with previous idea)? Would different turn orderings work better (all at once, or separate movement from attacking)? This whole thing is just me thinking out loud.

I realize a lot of this is tl;dr and possibly incoherent, and I apologize. Thoughts, suggestions, questions, and feasibility estimates are welcome.

I tried to do something similar to come up with a fight engine for Zultima. It used 3 objects to represent the player characters and 4 that were enemies that could turn off and run out of the arena when fewer monsters were supposed to fight. The map looked similar to yours in the spacing but was smaller. I found that (in trying to emulate ultima's engine) making each move one at a time took quite a lot of code especially because objects that were not activated still needed to pass information.

I think with a cursor you save a lot of trouble and perhaps a you would eliminate the need for the cursor to be above if you made it too shoot and then zap all shot commands for objects so a second one can mean a contact. Then again having all objects try and zap a label could be a little shoddy.

You run into problems also because the cursor is solid and objects need to move around it or the whole thing can be broken easily. Navigating dead units off the playing field was something I struggled with and having something like the cursor there would not help.

I think the idea of not using objects and having fakes is a feasible one, but severely limits the amount of info you can use and makes distinguishing players difficult.

With AI I had a small enough grid that random movement worked and engaging the enemy was dangerous enough considering the low amount of hitpoints I used.

i like the fact that dos' engine is called "Binder's Keepers"

funny story about planets

i remembered it from years and years ago on the aol archives because it was really cool and unique, but after aol kicked everyone off it was lost forever and i could never ever find it again until kingbat (super old-school zzter, used to complain about the lack of avatar size limit here a lot) came along for a while, and had a bunch of old zzt games and i told him to upload planets if he had it, and he did

well, i guess it wasn't funny at all, but you should be glad it's there at all... and not lost to the sands of time...

STEPHANO!!!

Also, huzzah for attemtped refinements of innovative ideas! I didn't follow all of what you said, Quantum, but what I understood sounded pretty cool; hopefully you or somebody else will pick up these ideas and run with them.