So my current ZZT project is coming along nicely. The only problem? The multiple engines involved in making the game 'what it is' are big enough that I'm not sure I can make the game fit - even if I restrict it to one ZZT file per mission (assuming 5 or 6 missions by the time I'm done, that's one game that takes 5 or 6 ZZT files).
I haven't worked out a title yet; I'm getting all the actual gameplay mechanics coded, and then I'll worry about the frills.
Gameplay is akin to Metal Gear Solid 3: Snake Eater.
It's a tactical stealth action game - done entirely in ZZT. Current plan is that it's set in a giant jungle, occupied by generic-bad-guy special military forces, perhaps with some sort of paranormal bent.
You sneak around, you kill people, you save the day. Good times.
What'll make this one interesting are the specific gameplay systems I've worked out.
-Varying levels of cover, for stealth action. Depending on the lighting of the area you're in, you'll be either hidden, normally visible, or highly visible. All enemies have lines of sight based on their patrol routes and which direction they're looking at the moment. When hidden in shadowy areas, enemies cannot see you. When normally visible, enemies will only spot you when they're in your line of sight. When highly visible, your movements will attract attention even if enemies aren't looking right at you.
-A "true shooting" engine. In other words, when you shoot the bullet immediately is #changed to forest->fake, and a player clone engine knows which direction you shot in, which along with some player-location-checking-ninjitsu is used to determine whether or not you hit. Your ammunition is limited, and shooting is good for the occasional stealth kill; it's not the primary means of combat. If you kill an enemy, either with a stealth shot or via the combat engine described below, you should to dispose of the body somehow; otherwise, if the guards come upon the body in their patrols, they'll sound the alarm and guards will be on the lookout for you.
(Optional thing I might try: realistic clip usage for your gun. You get five bullets per clip, and if you run out you have to be fully hidden in order to 'reload' - maybe using torches as an indicator of clips remaining or something?)
-A really fucking cool (IMHO) combat engine. Using a system of player-clone-teleporting, if you get into combat with an enemy, it pops you to another board where combat is resolved; if you win, you'll be popped back right where you left off in the previous board. The combat engine is not Yet Another RPG Engine; It's basically cinematic combat, with the player hitting key sequences as rapidly and accurately as possible to counter the enemy's attacks - a cross between DDR and Simon Says, almost. Being un-stealthy or fighting in combat while injured/bleeding/poisoned will give you disadvantages during the fight. While losing in combat will oftentimes mean your death, this is not necessarily the case; you could win the fight but end up bleeding/poisoned (see below), or knocked onto a different path through the level (i.e. failing to block a roundhouse kick if you're fighting on top of a waterfall could send you over the edge and into a different route) This leads into...
-A stamina system. How do you die in a game with non-traditional combat? Much like MGS3, your health is a measure of 'stamina', and is constantly draining itself at a steady (though not too fast) pace. Combat, as opposed to using stealth, will drain your stamina much quicker - as will being injured/bleeding/poisoned in combat. Stamina can be regained by capturing/eating wild animals scattered around the jungle. The basic idea here is to persuade the player to use stealth when possible, and keep the feeling going that "the clock is ticking".
-A poison/bleeding status healing system. When you are poisoned or bleeding, your stamina will depreciate more rapidly - you don't want to stay poisoned or bleeding for long if you can help it. How to cure these conditions? When fully hidden, you can enter a status screen (player-clone-teleported to a separate board, as with combat) where you will have to complete a bandaging or antidote-preparation minigame in order to cure your condition. (Not sure exactly what sort of minigame I'll do, but maybe something along the lines of Little Blue Squares for one of 'em?)
The goal is to replicate much of the feel and gameplay of games like Metal Gear Solid in ZZT.
Coding wise, this will be a long project to pull off, but not really an intellectual challenge; everything on the list above, I have a working beta of the coding going already.
The challenge will be making this work under ZZT's memory limits. Simply put, a lot of the systems above - especially the system with multiple levels of stealth, more-realistic shooting, and the guard's patrol systems - require a shitload of code and support objects to make everything actually work right (Ah, if only the ZZT gods had given us "#if alligned NS and #if alligned EW"...).
Not sure how many missions I'll finish, but each mission (each mission is its own self-contained 'jungle') is currently plotted out as 12 boards, usually a 3x4 setup. Plus 3 boards for combat, 3 boards for status check/minigames, one board for intro and finish, and that's 20 boards per mission.
Needless to say, I'd need to split it up 1 mission per world - but given the code-heavy nature of the systems I'm putting in, I'm not sure if that will fit. Thoughts? Also, has this sort of thing been done in ZZT before?
Sorry if this is long and rambling - this is just the first ZZT game I've made in 10 years (My last was the ZZT Encyclopedia 3C in 1996) and I'm really excited about making these again. :)
Trying to do something in ZZT that I think (hope) is new...
This sounds awesome. I'm really impressed you have a working beta of the stealth thing, I can't see how it can practically work. Presumably the different stealth areas are marked by different colour fakes, and if so then how do you check for the player being on top of it?
Or do you use something more restrictive for the areas of high/medium stealth, such as being in contact with a tree object causing high stealth?
Or do you use something more restrictive for the areas of high/medium stealth, such as being in contact with a tree object causing high stealth?
-
Ellypses
- Whaf yew vauhnt?
- Posts: 145
- Joined: Tue Aug 24, 2004 2:14 pm
- Location: In hell called earth
- Contact:
Sounds like a very sexy game, and very innovative and complex. Very looking forward to see it all working together and the awesomeness the gameplay will be.
Like you said, the engines involving in each board might be pretty thick so 20 boards per mission sound right to me if you want a non crashable file that uses a pretty desent amount of kilos say for instant all your boards are pushed toward 19k (350k "loadsafe" zztfile /18k boards = 19 boards total).
As far as all the juicy details on how you're doing all the engine, I'll like to wait til you release it.
Like you said, the engines involving in each board might be pretty thick so 20 boards per mission sound right to me if you want a non crashable file that uses a pretty desent amount of kilos say for instant all your boards are pushed toward 19k (350k "loadsafe" zztfile /18k boards = 19 boards total).
As far as all the juicy details on how you're doing all the engine, I'll like to wait til you release it.
Very few of the flags are persistent; most of it is objects talking to one another to check your state. A few of the flags that would be "persistent" can if necessary be converted to object-states while you're in a given board - and only turned into objects when you transit from one board to another temporarily to get them carried over. Also, things like the results of a minigame to stop your bleeding would be passed on between boards via flags.
Alternate possibility: I'm not going to be using gems, torches (unless I do the ammo clip thing, which come to think of it might be sort of useless - I really don't want the player to be having that much ammo in the first place), or score - those could be used on a temporary basis to transmit info between boards.
As to how you change levels of cover: It's pretty simple. The majority of the moving around in the game, you'll be in normal visibility area. (it is a jungle, after all). This makes sense for gameplay purposes, since being either impossible to spot or completely noticeable for *too much time* doesn't really fit the stealth-action premise.
Hiding is done via contact-checking objects; little crevasses, that sort of thing. you'll know pretty instinctively when playing where you can hide.
(That's also how you dispose of bodies in the jungle; drag them to a hidden spot, and you'll make the body 'disappear'.)
===
Which reminds me! Gameplay question. Tell me if this is a decent idea? I was thinking about ways for patrolling guards to not only be able to spot a body, but also to spot blood on the ground and become suspicious.
But how would one do that? How would one check for "if there's a red fake in front of me, that's blood!"?
My thought: There's an object somewhere on the map constantly changing red fakes to red normals and back and forth endlessly. The end result; if a player wants to walk over a bloodstain, he can - after all, blood is slippery.
But if an enemy finds himself #if blocked where he shouldn't be, he sends the object a command to make all red normals stay red fakes for a few seconds. He then checks if he's blocked again.
If that removes the blockage problem? It's blood, and he does whatever going apeshit a guard should do when he finds his friend is murdered.
What would be the gameplay point of adding this in? Further incentive to use your gun sparingly, and to really *SET UP YOUR SHOTS WELL*, as opposed to just "off anyone from the shadows whose body you can drag to a hidden spot before being seen" - if a little remainder from the body can't easily be cleaned up, that requires the player to think more.
===
(Another good part about doing it this way - that way, hitting the object when you're in the alcove can be the means of triggering the leap to the status page, rather than making players do ?+S or something like that - see my previous determination to make a game that has the player using no ? commands.)
As for the high visibility areas - well, as a spy, you won't want to be going in those too much, will you? The main idea with those is to be used as part of the gameplay.
For instance: There's an entrance to an underground bunker you have to infiltrate, but the entrance is well lit and guarded. Disabling the lights will allow you to sneak in.
As to how that's done: More objects than I'd like to use. A rectangle of high-visibility area takes 8 objects to do right (apologies for the crap drawing):
With the X's being the objects.
It'd be simpler if I were trying to pull some crap with "Step into the light and bam! You're instantly dead", but that would be cheating. If you step into the light, its rules apply, if you step out, you're instantly back in the shadows (Unless they're shooting at you at that point, of course).
Objects are used for a *lot* of alignment-checking - how to determine if you're in an enemy's line of sight, that sort of thing.
The end result of all this? Level design is absolutely key - everything has to be planned out in advance to play well and finesse ZZT's limits.
It's level design where I'm most worried about cocking this up - that, and graphics.
But right now, I'm most worried about getting the engine in place - getting my fully working test board (where rather than graphics the outline of the game world is just lines) up to snuff to prove the concept. General rule with a project like this: Unforeseen difficulties. Having a working board should get that out in the open.
Right now, It's the stealth engine and shooting engine in place - that's what I'm always tweaking and working on, that's the hard part. Things like minigames, etcetera, that are not technically challenging but more of a creative dificulty - that stuff I'll finish off later.
The shooting engine is an absolute bitch, but I'm very committed to making it work - I don't want usual ZZT-style bulletry in a stealth action game. For instance, making sure that if you're aligned with an enemy and standing to his left, and you shoot left, you don't hit. Or that if you're aligned with him and shoot in the right direction, but there's a wall between you, you don't hit. These sort of things become an exercise in a shitton of coding to do it right.
===========
Possible thought: if coding really becomes tight on space, one way to dial it back a little would be to tell the player "press space to shoot" rather than the usual shift+direction. That way, I'd still have to make sure the enemy isn't blocked by a wall or something like that, but at least I wouldn't have to account for all the ways you can shoot in the wrong direction; the game would basically just assume that the player's not a moron. ;)
Would this be sacrificing too much in the way of immersive gameplay, though?
This is a cost-benefit issue. Making it "Tomb Raider style", telling the player to tap the spacebar to shoot and just having the game then auto-aim in whichever direction the enemy is, might save me a GIGANTIC amount of coding.
=======
Now, as to the status stuff I mentioned earlier, and stealth, and how that's all reflected ingame. A word or two about the interface:
You know how some games expand the blue "ZZT Status Panel" outward, as a means of displaying additional data? Mine doesn't extend the whole panel outward; just a panel in the Northern corner, 4x4.
X is the player, A through D are indicators.
Why this approach? Simply put, because my engine absolutely needed a persistent player clone to know which direction the player is shooting.
I'm basically lifting the old ZZT Encyclopedia engine for detecting if/where a player has shot based on use of breakables.
However, rather than having a player clone sitting up there unseemly-like, I've decided to make the most of it, by using it as a status indicator.
The object at A indicates stealth; Appearing as one of these (·ºO§) based on your level of stealth. (The last one is if you're wearing a disguise). Hard to show since this message board isn't in ascii, but basically the little centralized-dot is the first one, the char used for locked doors is the second.
B indicates if you're bleeding.
C is a compass - I hope for the jungle to be at least somewhat nonlinear, and the compass makes a good, nonobtrusive way for me to guide the player toward an objective; it shouldn't be too hard to code and I think it'll improve gameplay.
D indicates if you're poisoned.
Why a 4X4 square rather than 3X3? the outer row/axis is a hopefully-inconspicuous way of doing the player-teleporting engine; I assume I'll find a blue-on-blue teleporter in some STK or another.
Even though yeah, this is ZZT and ASCII and all that, i want the game's systems to look *smooth* - my gold standard on that is Lebensraum, which I found very impressive.
So, yeah. Sorry if this is rambling. But I hope this clarifies my plans for the thing. I'm still frantically working on the test board.
Please to be having your thoughts! Especially on the two bracketed areas where I'm not sure which way I should develop the engine.
Alternate possibility: I'm not going to be using gems, torches (unless I do the ammo clip thing, which come to think of it might be sort of useless - I really don't want the player to be having that much ammo in the first place), or score - those could be used on a temporary basis to transmit info between boards.
As to how you change levels of cover: It's pretty simple. The majority of the moving around in the game, you'll be in normal visibility area. (it is a jungle, after all). This makes sense for gameplay purposes, since being either impossible to spot or completely noticeable for *too much time* doesn't really fit the stealth-action premise.
Hiding is done via contact-checking objects; little crevasses, that sort of thing. you'll know pretty instinctively when playing where you can hide.
(That's also how you dispose of bodies in the jungle; drag them to a hidden spot, and you'll make the body 'disappear'.)
===
Which reminds me! Gameplay question. Tell me if this is a decent idea? I was thinking about ways for patrolling guards to not only be able to spot a body, but also to spot blood on the ground and become suspicious.
But how would one do that? How would one check for "if there's a red fake in front of me, that's blood!"?
My thought: There's an object somewhere on the map constantly changing red fakes to red normals and back and forth endlessly. The end result; if a player wants to walk over a bloodstain, he can - after all, blood is slippery.
But if an enemy finds himself #if blocked where he shouldn't be, he sends the object a command to make all red normals stay red fakes for a few seconds. He then checks if he's blocked again.
If that removes the blockage problem? It's blood, and he does whatever going apeshit a guard should do when he finds his friend is murdered.
What would be the gameplay point of adding this in? Further incentive to use your gun sparingly, and to really *SET UP YOUR SHOTS WELL*, as opposed to just "off anyone from the shadows whose body you can drag to a hidden spot before being seen" - if a little remainder from the body can't easily be cleaned up, that requires the player to think more.
===
(Another good part about doing it this way - that way, hitting the object when you're in the alcove can be the means of triggering the leap to the status page, rather than making players do ?+S or something like that - see my previous determination to make a game that has the player using no ? commands.)
As for the high visibility areas - well, as a spy, you won't want to be going in those too much, will you? The main idea with those is to be used as part of the gameplay.
For instance: There's an entrance to an underground bunker you have to infiltrate, but the entrance is well lit and guarded. Disabling the lights will allow you to sneak in.
As to how that's done: More objects than I'd like to use. A rectangle of high-visibility area takes 8 objects to do right (apologies for the crap drawing):
Code: Select all
XX XX
X
X /--------\
| |
| |
X \--------/
X
It'd be simpler if I were trying to pull some crap with "Step into the light and bam! You're instantly dead", but that would be cheating. If you step into the light, its rules apply, if you step out, you're instantly back in the shadows (Unless they're shooting at you at that point, of course).
Objects are used for a *lot* of alignment-checking - how to determine if you're in an enemy's line of sight, that sort of thing.
The end result of all this? Level design is absolutely key - everything has to be planned out in advance to play well and finesse ZZT's limits.
It's level design where I'm most worried about cocking this up - that, and graphics.
But right now, I'm most worried about getting the engine in place - getting my fully working test board (where rather than graphics the outline of the game world is just lines) up to snuff to prove the concept. General rule with a project like this: Unforeseen difficulties. Having a working board should get that out in the open.
Right now, It's the stealth engine and shooting engine in place - that's what I'm always tweaking and working on, that's the hard part. Things like minigames, etcetera, that are not technically challenging but more of a creative dificulty - that stuff I'll finish off later.
The shooting engine is an absolute bitch, but I'm very committed to making it work - I don't want usual ZZT-style bulletry in a stealth action game. For instance, making sure that if you're aligned with an enemy and standing to his left, and you shoot left, you don't hit. Or that if you're aligned with him and shoot in the right direction, but there's a wall between you, you don't hit. These sort of things become an exercise in a shitton of coding to do it right.
===========
Possible thought: if coding really becomes tight on space, one way to dial it back a little would be to tell the player "press space to shoot" rather than the usual shift+direction. That way, I'd still have to make sure the enemy isn't blocked by a wall or something like that, but at least I wouldn't have to account for all the ways you can shoot in the wrong direction; the game would basically just assume that the player's not a moron. ;)
Would this be sacrificing too much in the way of immersive gameplay, though?
This is a cost-benefit issue. Making it "Tomb Raider style", telling the player to tap the spacebar to shoot and just having the game then auto-aim in whichever direction the enemy is, might save me a GIGANTIC amount of coding.
=======
Now, as to the status stuff I mentioned earlier, and stealth, and how that's all reflected ingame. A word or two about the interface:
You know how some games expand the blue "ZZT Status Panel" outward, as a means of displaying additional data? Mine doesn't extend the whole panel outward; just a panel in the Northern corner, 4x4.
Code: Select all
OA B
O X
OC D
OOOO
Why this approach? Simply put, because my engine absolutely needed a persistent player clone to know which direction the player is shooting.
I'm basically lifting the old ZZT Encyclopedia engine for detecting if/where a player has shot based on use of breakables.
However, rather than having a player clone sitting up there unseemly-like, I've decided to make the most of it, by using it as a status indicator.
The object at A indicates stealth; Appearing as one of these (·ºO§) based on your level of stealth. (The last one is if you're wearing a disguise). Hard to show since this message board isn't in ascii, but basically the little centralized-dot is the first one, the char used for locked doors is the second.
B indicates if you're bleeding.
C is a compass - I hope for the jungle to be at least somewhat nonlinear, and the compass makes a good, nonobtrusive way for me to guide the player toward an objective; it shouldn't be too hard to code and I think it'll improve gameplay.
D indicates if you're poisoned.
Why a 4X4 square rather than 3X3? the outer row/axis is a hopefully-inconspicuous way of doing the player-teleporting engine; I assume I'll find a blue-on-blue teleporter in some STK or another.
Even though yeah, this is ZZT and ASCII and all that, i want the game's systems to look *smooth* - my gold standard on that is Lebensraum, which I found very impressive.
So, yeah. Sorry if this is rambling. But I hope this clarifies my plans for the thing. I'm still frantically working on the test board.
Please to be having your thoughts! Especially on the two bracketed areas where I'm not sure which way I should develop the engine.
-
Quantum P.
- Level 17 Accordion Thief
- Posts: 1433
- Joined: Fri Sep 12, 2003 1:41 am
- Location: Edmonds, WA
- Contact:
On your idea for allowing blood to fall on the ground:
As far as I can see, the idea that you're using would work. A possible future project of mine uses this technique of changing fakes to normals extensively, so I've been doing quite a bit of work on engines like this. I have a couple of suggestions that may or may not help the engine run better...
* Don't bother checking if there is no red fake on the board (obvious).
* Have a central object changing fakes to normals and back again every cycle, but don't have a subroutine that pauses the changing. Instead, if one of the guards is blocked, have him check for red normal. If there is some red normal, wait a cycle and see if the blockage has disappeared. If so, the guard has come across blood.
* Each of your guards will have to have code similar to the following:
Since saving space will be important on this project, consider replacing the expression with a short flag...
The object that changes red normal to red fake and back would then be responsible for clearing and setting b.
You might also want to consider changing the method in which the guards see blood. For example, the current system that you described would require the guards to be on top of the blood in order to see it. If your guards follow regular paths and can keep track of their own locations, you might find it worthwhile to implement a line-of-sight system. When a guy dies in a visible region and leaves blood, that region is "tainted". When a guard walks into a tainted region, he panics. The effect is that the guards can see blood on the ground from a distance. You might be able to do this with a single object. When a region is tainted, the object has a label restored (for example, #restore blood:armory when someone dies in the armory). When a guard enters the armory, he runs #blood:armory. The object @blood would be rather simple:
This project sounds pretty neat. I hope something becomes of it, and I wish you good luck!
As far as I can see, the idea that you're using would work. A possible future project of mine uses this technique of changing fakes to normals extensively, so I've been doing quite a bit of work on engines like this. I have a couple of suggestions that may or may not help the engine run better...
* Don't bother checking if there is no red fake on the board (obvious).
* Have a central object changing fakes to normals and back again every cycle, but don't have a subroutine that pauses the changing. Instead, if one of the guards is blocked, have him check for red normal. If there is some red normal, wait a cycle and see if the blockage has disappeared. If so, the guard has come across blood.
* Each of your guards will have to have code similar to the following:
Code: Select all
#try <dir> #if any red normal isblood
'Continue with main loop...
:isblood
/i#if not blocked <dir> #if not any red normal panic
#loopCode: Select all
#try <dir> #if b isblood
'Continue with main loop...
:isblood
/i#if not blocked <dir> #if not b panic
#loopYou might also want to consider changing the method in which the guards see blood. For example, the current system that you described would require the guards to be on top of the blood in order to see it. If your guards follow regular paths and can keep track of their own locations, you might find it worthwhile to implement a line-of-sight system. When a guy dies in a visible region and leaves blood, that region is "tainted". When a guard walks into a tainted region, he panics. The effect is that the guards can see blood on the ground from a distance. You might be able to do this with a single object. When a region is tainted, the object has a label restored (for example, #restore blood:armory when someone dies in the armory). When a guard enters the armory, he runs #blood:armory. The object @blood would be rather simple:
Code: Select all
@blood
#end
'path1
'path2
'path3
'hallway
'armory
'room1
'room2
GUARD: Alert! I found blood! Sound the alarms! Etc...
#all:alarm
This project sounds pretty neat. I hope something becomes of it, and I wish you good luck!
-
Dr. Dos
- OH YES! USE VINE WHIP! <3
- Posts: 1772
- Joined: Tue Mar 11, 2003 12:00 am
- Location: Washington
You're totally topping my really simple ideas for stealth games that I never did anything with. Stop it :(
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter
Apologies for the old post you may have just read.
Follow Worlds of ZZT on Twitter
Apologies for the old post you may have just read.
Quantum, thanks for the great ideas re: bloodspilling.
Also, thanks for giving me the example of how to make the code neater.
I can code pretty much anything under the sun, but when it comes to making it neat and elegant and space-saving... I'm crap. :(
A thought regarding making areas 'tainted' - that makes perfect sense, since I do those areas already for having the game help with checking line-of-sight for the shooting engine.
For gameplay reasons, I might switch back and forth between the 'seeing blood in front of him' and 'tainted areas' method - the former makes more sense in dense jungle, the latter in enemy installations, etcetera.
Also, thanks for giving me the example of how to make the code neater.
I can code pretty much anything under the sun, but when it comes to making it neat and elegant and space-saving... I'm crap. :(
A thought regarding making areas 'tainted' - that makes perfect sense, since I do those areas already for having the game help with checking line-of-sight for the shooting engine.
For gameplay reasons, I might switch back and forth between the 'seeing blood in front of him' and 'tainted areas' method - the former makes more sense in dense jungle, the latter in enemy installations, etcetera.
It's projects like these and people like you that make me realize how much fun and engaging a 14-year-old DOS GCS can be. I can't wait to see some of this. It sounds really cool for a ZZT game. I love the thought of traditional Metal Gear Solid concepts integrated into ZZT.
I think it would be cool to have a custom font. Expressions for guards and such would be a nice thing to have. They could change depending on their alertness.
Good luck with all this!
I think it would be cool to have a custom font. Expressions for guards and such would be a nice thing to have. They could change depending on their alertness.
Good luck with all this!
I considered a custom font, and then decided against it. In fact, the noncustomizability of ZZT characters is why I picked ZZT for this project, when it'd probably be a ton easier to do in MegaZeux. The beauty of ZZT is in its limitations. :)
If possible, could I get some feedback on the 'space to shoot' vs directional shooting? The former makes life easier and saves coding resources, the latter might be 'cooler' when done with this engine?
If possible, could I get some feedback on the 'space to shoot' vs directional shooting? The former makes life easier and saves coding resources, the latter might be 'cooler' when done with this engine?
I think if at all possible the directional shooting would be best. Although tombraider has automatic aim turned on, this would be a very different automatic aim. Lara Croft will aim about 45 degrees from the way she's facing automatically, whereas this ZZT character would only be able to automatically aim N, S, E or W (which incidently includes the direction opposite to the way the player is facing). I think the ZZT automatic aim would make the player feel more like a machine than a person.