Zero Target - Development Log

[Mystery]

Really fascinating stuff going on in here, thanks for taking the time to experiment, discuss and document your findings and ideas.

Sorry I can't contribute much. But I'm really happy to have started an interesting discussion
I'll try to catch up eventually.

Until then I'll fill this up with random thoughts and questions I'm having while working on Zero Target.

Is it possible to have a conditional level warp?
I have two scenarios in mind (not necessarily for this game, but we'll see):
1) the player goes to a specific spot in the level and depending on certain conditions (items carried or interactions in the current level) he moves to different levels. like an elevator that normally goes to the 5th floor but if the player hits a switch in the level, the same elevator takes him to a different floor.
2) have a level warp be inactive and only transport the player if certain conditions are met. so for example Jack Steel enters an elevator but it doesn't take him to the next level until he finds a keycard for it or talks to someone in the level who turns off the security in the elevator. I don't want a door blocking the elevator, the player should totally be able to walk inside, but unless conditions are met, nothing happens.

I really hope this forum and community will survive the next 5-10+ years, because that's probably how long it'll take for me to get anywhere
I absolutely agree with Greg about taking your time with something like this. Nobody pays me and I don't have any deadline so I can work on this as long as I want and make it whatever I want. Great attitude!

[chris]

Yeah some good questions being asked here. The projectile question basically started with "not really" and now it's "probably if you wanna get your hands dirty with Forth".

But yeah you can definitely do a conditional warp. You could have universe registers that keeps track of all mission objectives. 10=1 you planted the time bomb next to the gas tanks, 11=1 you grabbed the secret plans, etc. which you can set via platform, animated object, pickup object, etc.. Then in the elevator you could have an animated object run through the checklist like

0 skip if player close
1 branch 0
2 skip if reg 10=1
3 message "You forgot to sabotage the gas tanks"
4 skip if reg 11=1
5 message "You can't leave without talking to Dr. Doak"
6 skip if reg 10=1
7 branch 0
8 skip if reg 11=1
9 branch 0
10 skip if reg 12=1
11 message "without the keycard this elevator only goes to level 2"
12 skip if reg 12=1
13 warp to 2
14 warp to 3
15 skip if player close
16 branch 0
17 branch 15

I don't think the logic is exactly right, but something like that.

[Mystery]

That's exactly what I'm looking for, perfect. Thanks a lot!

Man, I've got so many ideas for later projects already...but first things first

[lgb3d]

Yes using an animation might be best for an elevator scenario so it gives player time to enter elevator and operate a animation such as a switch.

I have planned in my game to do something remotely similar but different.

Platform is warp to point.. enable only if register value equal..

So let's say player made it all the way to point B now he has to get back To The Choppa.. the warp to point that before gave him the ability to travel through multiple Maps like an open world no longer exist because it's only enabled if register value equal well since he made it to point B register value now equals a different number which enables a different platform that he exit that level. A duplicate of the map he believes he is warping to is now where the new work to point takes him but example perhaps there was an air strike and the level does not look like it did before there are bomb holes everywhere Flames everywhere some of the structure is damaged. Distracting him from the absence of the bodies of soldiers he killed that have been laying there throughout the entire gameplay. This gives the crater the opportunity to repopulate a map the player is familiar with or to give the illusion that there was more existing or that the map actually changed.

Example you build a level you get the memory and World limitation filled in where you can barely put anything else in the level well if there's an alternate version of it it gives the illusion that there was more to that level an opportunity to play through that map again as well to incorporate things that were not present before and there was not space in the memory or World limitation.

Example surprise boss fight, animations and Graphics can take up a large chunk of your available resources and map limitations so if you load that map again subtracting a lot of what is no longer necessary but add new animation of Boss you could make very complicated scenario with all that extra space he just created by subtracting the unnecessary aspects from the map that had prior existed..

Or let's say we have a situation where the game indicates time of day. Yeah you can do a lot of tricks with the lighting registers but you could create both day and night representations of a single map with all their own unique lighting registers Etc but separately which is determined based upon the existence or absence of warp to points...

I'm sure you guys have seen video of my red flashing light level. That could be toggled on or off but in reality that level always Fades to red so anything that has the ability to fade with distance at a great distance will fade to red so the level design is built around that. Well let's imagine a level like that where the color palette appears normal there is a special button that can engage a security system that creates that red strobing light. Okay cool you go to a different level and release the toxic gas flooding prior Maps with that toxic gas. With that warp 2-point trick you could deceive the player that they are returning to that map but now it is calibrated to fade to a green and not exactly the same but similar to the red strobing light the fade distance is pulsing a little bit giving the impression of a green Haze or fog fluctuating in density. Player turns on exhaust fan and the same as turning off the red strobing light the level is now clear as day appearance of the base normal color palette absence of red flashing light or green fog.


I'm saying too much but the heart of what I guess I should have really said, yes this can be achieved with animation but in my game the exit Point always appears as a hallway that the player is going to walk into so the warp two points are platforms located in that hallway. And they can be controlled by Universal register enable only if value equal. So I could have to work 2 point setting on top of each other ones off the others on or vice versa based upon campaign achievement. Both warp to different levels that resemble each other deceiving the player but allowing the Creator to cram either more content or different level attributes into Maps.

[chris]

Platform is warp to point.. enable only if register value equal..

Thanks for mentioning that. Dead simple way to make a conditional warp.

Update on the enemies dropping items. It is turning into pickup code 5 by default, which contains invalid data and that's why it crashes. You could replace these scancodes with working ones, or make your own pickup to set a universe register to set up clothing stealing. Whether the forth code to make you invisible to enemies with the clothes still works, not sure, but you could add it back in some way if not.

So that's part of the problem. The other problem seems to be with how the code for picking up weapons works. Set the extra line of code to "4 clt1 cl0[]!" and the enemy will drop a key. Picking up the key will leave a stripped dead guy (you might be able to remove this code, or just edit the solid text file to a normal dead body). Some other pickups have side effects.

Notably:
1,28,29 - grenades - same with guns, if you already have them enemies will disappear when you pick up, so avoid
5 - n/a - used to be clothes but has been removed from GCS. Must fix scancode or it will crash game
6 - bomb - if you press "B" without picking it up and placing it first, it will crash the game
7 - mine - if an enemy walks over the body it will crash the game
8,9,12 - note - works okay but make sure you add a line "1 clt2 cl0[]!" (where 1 is the PSTR string) otherwise you'll crash
10 - ? - crash just from walking over enemy
15,16,25,26 - guns - if you already have the weapon, it will make the enemy disappear. If you don't, it will leave a stripped enemy (drop ammo instead)
24 - timebomb - this one gets crashy if you don't set the ureg
32 - health - these make the enemy disappear, and also pick up automatically even if you're at 100% health. If you try to set the 2nd red box it crashes
36 - ? - crash trying to pick up, I think this item just doesn't have good scancodes

So there you go. The reason I was picking up the entire body when they dropped a shotgun was because I was testing killing them with a shotgun. Dropping guns seems to be problematic, but dropping ammo works fine, so I'd suggest doing that instead unless you know for sure the enemy is going to drop a weapon the player has never seen before.

[lgb3d]

In my game I replaced the shotgun inventory item with a pistol. So in my trial runs, at the start of My Level I pick up the machine gun and I kill them. I can pick up the pistol body still on ground. Put down the pistol walk over body again pick up second pistol, but the second time I pick up the body disappear.

But interesting with a normal kill the ammunition is always 12 when you pick up, but if I used a grenade to kill enemy and he is Gib the ammunition is 18. So something tells me the constant that is used to store death type is somehow incorporated into the ammunition value, second box? although with the initial example of using 16 inventory type for shotgun, we never placed any value in the second box.. so how dose it come to 12 or 16..

[lgb3d]

I see what you mean about invisibility. Assigned value to register if register value equal guard does not advance to identify Target. If guard shot alert, if guard distance is close trigger alert. But it might be more simplistic by guard assigning register value back to zero if attacked or what not which would invalidate the invisibility for all guards. Not that I would employ that in my game but I think your idea of how it worked is very accurate..

I think the important thing about stealing the uniform is the technique of the body remaining on the ground and no longer being a pickup object but the graphic changing. With that function yes picking up ammunition or a weapon would result in the graphic on the ground changing to demonstrate something left his possession.

[chris]

Yep, you'll have to avoid having enemies drop weapons unless it's like a miniboss and he's gonna drop something you've never gotten before.

As far as changing the ammunition I think you wanna do that by setting the second red box. Try "x clt2 cl0[]!" where x = number of bullets or however the manual says to do ammo. And yeah it's possible the enemies are already holding something in the 2nd red box so you may or may not run into issues trying to change it.

[lgb3d]

256 * inventory number plus value

[chris]

You know what would be cool? Changing the number of bullets dropped depending on how many bullets the enemy has used. Maybe even making the enemy run out of ammo permanently, and then he has to fist-fight you.

[lgb3d]

Okay this is getting deep.

What you're talking about would be really easy to achieve with the Windows 95 ability to write custom fourth script for enemy type and for level which functions with the base AI for enemies throughout the game. That's where I started teaching myself this language a few years back. But that's a different topic. Very valuable good conversation, but it's Theory it's potential.

Looking at this code for a long time I've noticed numbers that relate to animation command, so recently you gave a little different perspective and it's opened my eyes a little bit more to what I'm reading.

Clt1 2 3 4.. attribute box 1 2 3 4.. okay

Clx y z.. already made sense and was obvious.

Ok...

Below the modified line of code for the inventory type placing 16 in the first box and writing it with the exclamation point..

There are some familiar numbers 1,024, X form new system object.. but where is that pointed to... align or two down, 512 unconditional Branch to frame number, but where is the frame number listed or generated..

I have tweaked with my guard script pointing to different frames, and giving different range of frames for different actions so mine's going to be off from the typical but the nap graphic is supposed to land on frame 28. So if I have an unconditional branch somewhere the number 28's either being calculated generated or input.

if we go in the editor and we select a enemy look at the attributes the fourth box would be the frame number or value associated with animation command. We find 2,300. That is the handle of nap.vgr..

so that's not the 512 command taking us to nap.vgr it's the 1024..

I want to believe the 512 is a animation command, but it's followed by the plus symbol meaning some other value that is being generated is being added to it which is probably somewhere in the code pointing to frame number 28. Where it will stay and not look back into the solid animation. Similar to once he's dead he stays dead but if he's knocked out there's an amount of time and he Loops back to the star of the animation

Ok... so we can modify that number in attributes in the editor for each guard, so each guard could land on a unique handle or value number we put in 4th box..

So it is pulling the handle number from within the editor forth red box.. that box is the storage place we can modify it in the editor to point to a value required by animation command animation command is placed in the fourth code script.

So instead of command 4 1024.. command 68! 68 = 17408 spawn new animation

Guessing.. So if similar code was written when enemy is hit by Bullet or whatnot.. we could tell the script to find the handle number for the animation of Gore in the fourth Red Box..

In our enemy folder we place a FLD and Define it in the guard def document giving it a handle number within the range of enemy handle numbers.. and potentially we have graphic of Gore appearing spawning into the world. Falling to the ground leaving puddle of blood wherever enemy was shot.

But then again, the guard handle numbers cannot overlap handle numbers used in other folders they have to be unique although they are not defined an object text, the engine reads them. Perhaps in the fourth box we could put the handle number for a different animation or object found within the universe.

What I am visualizing is not only that a guard can spawn an animation or object, but that each guard could be programmed through the fourth Red Box to show his own unique outcome. And as they wander around all you would see is diversity. One guy bleeds a little one guy bleeds a lot.

If I can get this to work my next step would be trying to altered the fourth Red Box not through the editor but through the fourth script itself, because then based upon different action it could modify the fourth red box and there could be different animation spawn if enemy is Gib or if in me is caught on fire if enemy is shot.. otherwise each enemy only has one thing that they can spawn that is permanently attached to them through the fourth Red Box..

Looking at what we already did with the first Red Box, modifying it to the number 16 when existing through the editor is 5 makes me think it is potential to alter all of the four boxes through the script itself but if this is true and functional then the boxes and the editor are no longer necessary and putting information in them would be pointless. But all guards regardless of what set or level are going to be calling on the exact same handle numbers, so if handle numbers are not being called from the guard definition but from object text similar to my weapons auxiliary animations all levels would have to have a uniform handle number for whatever is called by the fourth script.

This is just Theory it's a wild guess. What I think could be difficult is programming the height at which it appears so that would have to be programmed into the animation script for the blood itself. But the location would it remain at the location where it's generated even if enemy walked away or would it follow the enemy location as it's being spawned at enemy location and in my location is attached to enemy and travels animation is it attached to enemy or location enemy was currently existing..

To simplify things let's say animation does not leave puddle on the ground and is just a brief flash of red, this should be very feasible but it would be cool if puddles of blood appeared all over the level wherever enemy was shot. I shoot him he moves a few feet I shoot him he moves a few feet leaving trail of blood that would be super duper cool.

So I'm going to set out trying to figure out how to implement something along those lines.

I don't know if it would feasibly work, as it's looking for a graphic or animation but command 68 creates a new object, that could be a gun falling. Similar to Doom the shotgunners drop a shotgun.

[chris]

I think in this case the 1024 is referring to the 1024 attribute bit (robobit) "bit that makes it a robo object", which I'm guessing robo means guard or enemy? So I think it's checking to see if it's still an enemy or not, and then interestingly checks the 4th red box to see if it's not zero. The 4th red box defaults to 2300 for enemies. No idea what that does but interesting things start happening when you change the number. Some numbers seem to prevent the naked guy from appearing, but also have the side effect of creating 2 items, and the corpse becomes a pickup again. Maybe there's a magic number in the 4th red box that will leave a normal corpse, drop an item, and won't pick up with the item.

But yeah instead of us explicitly telling Forth which item to drop, we can simply put the pickup code in the 1st red box Maybe some code could be added to ignore the pickup code if it's a 5 to avoid errors, but otherwise most of the code could stay

As far as the other red boxes, the second red box is used with some inventory items so that should be left alone. 3rd red box controls lighting so playing with this might have the accidental side effect of making enemies flicker or pulsate. Then there's the 4th red box, which is doing... something, not sure what or if it matters, maybe like you said it's the handle for nap.vgr. But there probably is potential to squeeze some data in one or two of these boxes one way or another.

As far as bleeding when shot... maybe when the enemy is shot you could turn the enemy into a fluid for a split second which spawns blood splatter, then turn back into solid? I'm still not actually sure if you can morph an enemy into a fluid but I have had some success turning enemies into walls and windowed walls when killed so I believe it's possible. I think that code with the 512 in it, I think I was goofing off yesterday and changed it to 256 or something and it turned into a wall. Maybe giving it a fluid handle would do something interesting?

[chris]

So good call on the 2300 in the 4th red box. If you change it to 2256, you can pick up an item and it'll leave the dead guy instead of change to nap.vgr. It changes the Z elevation but that's an easy fix in Forth ("170 clz0 cl0[]!" instead of 200).

I tried giving it a handle of an animation though and it won't cooperate. Sadly I'm not sure there's a way to morph a solid into a fluid.

[lgb3d]

Yeah I should have known. The 2300 was obvious for the handle number. But a lot of my other Theory fell apart I kept crashing or getting bizarre results like I shoot the enemy and when dead disappear showing no image but became bumpable so I was bumping into these invisible dead bodies. All sorts of bizarre outcomes messing around with some of this.

After you just reminded me, I remembered discovering this before in the past when I thought that the animation commands would translate to the 4th enemy. Those numbers 1024 512 are listed at the very top of the document they are constants that relate to Flags example 512 signifies that the guard is in little lost lamb mode 1024 means to recycle the guard.

What you're saying about the relevance of the four boxes makes sense. I swear I've read or picked some of that up somewhere before,

Turning solid enemy into wall. Okay that makes sense. It's the number that references object type. What is a solid wall what is a window wall what is a symmetrical object.

O solid wall
1 windowed wall
2 symmetrical ...
6 = fluid!

I still want to believe these theories are thoughts are achievable but the reality is the attribute box is apply different to a fourth guard than any other object type or animation. The operation command numbers are used but serve unique purpose as well.

So the thought of potentially converting it to a fluid to be able to use the fluid command numbers separately from the fourth script through the fluid seems more feasible.

But heck away from the guessing. We are discovering some pretty interesting things about the 4th script and achieving things that were not happening before. And it's bringing forth all sorts of new ideas.

[Mystery]

Alright, small update:

I'm working kind of backwards from the second to last to the first level and then I'll do the final level.

I have to admit, it is REALLY REALLY hard to resist and not make my own assets for textures etc. as the default stuff is, well, not that great. But I wanted to make the most stereotypical gcs game out there and so I'll stick to my plan. I will perhaps dip into some material from the mega art pack and might steal some iconic midi tracks, not sure yet. But who loves HOD2.MID on loop through the entire game? This guy!

Two very early work in progress shots of a later level:




But really, I cannot overstate how basic this game is going to be.