SSR System Shock Remake Feedback Request - Night Dive Studios

[665b2210d9d8dRocketMan]

yeah... they're not going to just assimilate you into their discussions about game development.  That would be a major IP/commercial risk.

[665b2210d9f66Kolya]

It just wouldn't be internal feedback anymore.
Which reminds me: My internal feedback system just told me to get something to eat. No, you cannot become part of it. JUST NO!
Ah, peanuts! Food of champions.

[665b2210da2faJoin2]

My internal feedback system just told me to get something to eat. No, you cannot become part of it. JUST NO!

Your flesh...betrays you. The harmony is disturbed!

[665b2210da408Kolya]

Nah, my flesh never betrayed me. Well once it did. But that was because she had a weirdly formed head.

[665b2210da813Gawain]

yeah... they're not going to just assimilate you into their discussions about game development.  That would be a major IP/commercial risk.

but, I want to! And I can give them a discount to minimize commercial risk.

[665b2210daab1Join2]

Nah, my flesh never betrayed me. Well once it did. But that was because she had a weirdly formed head.

Heh. Her flesh welcomed you, but yours betrayed you both.

[665b2210daca6Matty]

Is there a more comprehensive breakdown of the item/weapon system in SS1 than the ICE Breaker handbook or this page https://www.systemshock.org/index.php?topic=1744.0 (which seems to have mostly the same information)?

These resources are nice, but I have some unanswered questions:

1.) How exactly does the offense and defense value interact with criticals?
2.) What about precise durations on patches?  (The ones in ICE Breaker are approximate).
3.) Fire rates on weapons would be helpful, and save me time.
4.) Does anything else affect the chi meter other than Genius patches?

Note: At the moment the combat system is implemented exactly the same except the critical chance, which is a fixed chance per ammo type.

Thanks!

[665b2210db226dertseha]

3.) Fire rates on weapons would be helpful, and save me time.

While I can't tell you the actual time values, I can tell you where to find the base information; The first byte of the generic weapon properties (in objprop.dat) specifies the time it takes for the next bullet/swing. I haven't determined what the unit of that byte is.

Here's the dump of that table (bytes in hex):

Code: [Select]

0/0/ 0 [                  ML-41 PISTOL] Generic : [ 08 03 ]
 0/0/ 1 [                 SV-23 DARTGUN] Generic : [ 05 13 ]
 0/0/ 2 [                   MAGNUM 2100] Generic : [ 0F 23 ]
 0/0/ 3 [           MARK3 ASSAULT RIFLE] Generic : [ 11 33 ]
 0/0/ 4 [                DC-05 RIOT GUN] Generic : [ 03 24 ]
 0/1/ 0 [               AM-27 FLECHETTE] Generic : [ 2D 43 ]
 0/1/ 1 [                RF-07 SKORPION] Generic : [ 3C 53 ]
 0/2/ 0 [                SB-20 MAGPULSE] Generic : [ 0F 61 ]
 0/2/ 1 [                MM-76 RAIL GUN] Generic : [ 05 62 ]
 0/3/ 0 [                     LEAD PIPE] Generic : [ 14 00 ]
 0/3/ 1 [            TS-04 LASER RAPIER] Generic : [ 14 00 ]
 0/4/ 0 [                    SPARQ BEAM] Generic : [ 0F 00 ]
 0/4/ 1 [                 ER-90 BLASTER] Generic : [ 0F 00 ]
 0/4/ 2 [               RW-45 ION RIFLE] Generic : [ 0F 00 ]
 0/5/ 0 [                 DH-07 STUNGUN] Generic : [ 0F 00 ]
 0/5/ 1 [            LG-XX PLASMA RIFLE] Generic : [ 07 00 ]
(second byte is clip description)

Setting the byte to 0 makes the weapon fire as fast as you can pull the trigger (or swing it - a 0 for the lead pipe feels comical ).
Looking at the values of automatic weapons (0/1/x) though, I'd guess for them the value is interpreted differently.

[665b2210db3a5ZylonBane]

I guess this answers the question whether the remake team has access to the SS1 source.

[665b2210db74ddertseha]

I guess this answers the question whether the remake team has access to the SS1 source.

Presumably - might also be still in a lockdown, pending legal clarifications - including the information whether this is the actual case. Room for conspiracy theories Or: "...and save me time" means: "I'd like to avoid wading through (huge number) of lines of code to find this."

At least, the patch duration must be hardcoded in the source as their property bytes are all zero - this counts for the generic and specific properties (objprop.dat), as well as the in-level properties (archive.dat).

[665b2210dbaf5Marvin]

I guess this answers the question whether the remake team has access to the SS1 source.

Not neceessarily, (some of) the information could also be very well hidden in the code. Wasn't part of it implemented in Assembler? Imagine you'd have to dig through that...

[665b2210dbbf9Gawain]

I bet all of the gameplay is in C. Finding that piece of code wont't be a problem or a long task either if they had the source.

[665b2210dbe3aMarvin]

I bet all of the gameplay is in C. Finding that piece of code wont't be a problem or a long task either if they had the source.

Well, maybe they think of the SS.org community as geniuses who would come up with the info on the spot, wich saves time? Always think positive.

[665b2210dbf91RocketMan]

You guys act like you've never encountered an employee before who asked a question he didn't know the answer to but for which the answer was available (maybe not readily available...).  Sometimes nobody knows the answer but that's because nobody looked before or their first attempt didn't return anything.  I'm sure many of these guys haven't touched anything system shock related in years but we live and breath it so I wouldn't say it's a definitive no just yet.  Maybe just a guy asking an off-the-cuff question before he gets the team to do a deep dive into the code.

[665b2210dc511JosiahJack]

Is there a more comprehensive breakdown of the item/weapon system in SS1 than the ICE Breaker handbook or this page https://www.systemshock.org/index.php?topic=1744.0 (which seems to have mostly the same information)?

These resources are nice, but I have some unanswered questions:

1.) How exactly does the offense and defense value interact with criticals?
2.) What about precise durations on patches?  (The ones in ICE Breaker are approximate).
3.) Fire rates on weapons would be helpful, and save me time.
4.) Does anything else affect the chi meter other than Genius patches?

Note: At the moment the combat system is implemented exactly the same except the critical chance, which is a fixed chance per ammo type.

Thanks!

1. I believe that the offense and defense are calculated first and that if the difference allows for damage, then a check against the critical hit random chance is made.  I believe I was taking the critical hit and multiplying the damage by 2.  I could be wrong, I haven't looked at my version of that code in a long time and can't see it now since I'm at work.  I tried to keep it as close to the ICE breaker order as I could.

2. I've just been timing the patch effects by hand from the original game and taking the average while noting min and max.  You can use the Biomonitor to see what patches are in effect. I'm taking both measurements of the patch normal time and the patch time under the influence of the reflex patch (slows time down).  I have most of the times written down, I can get them later tonight maybe.  There is also about a 10sec variance to the time length, 15 or 20 for the reflex effect.  This time may be framerate dependant though, which might be the source of the variation.

3. If you can cypher dertseha's comment please share.  As such I haven't been able to translate it into human readable form.  Otherwise, it's back to taking measurements by hand and averaging them.

4. I don't think so.  I haven't tested all the patches to see, berserk might make chi/brainwaves worse but the berserk effect only lasts about 30 seconds.  I've toyed around with the idea of having a pulsing/shifting overlay of the solution for the grid puzzle whenever the genius patch is active but still make it cloudy/partial.  For the wire puzzle, floating/shimmery voltage amounts to indicate sources of the most power along with resistances of the wires.

[665b2210dc6eaJoin2]

Picturing what the weapon visual designs could be like in the remake has me all giddy. There's a lot of freedom to iterate upon those old sprites.

[665b2210dc9a3dertseha]

As for the fire rates, I now found some time to do some testing (for science!).
Test setup:
* vanilla CD shock running in dosbox, running in a VM.
* Spamming the fire-button of the mouse as quickly as I could with one hand
* measuring lap-times with the other hand on the smartphone, which gives only 1 fraction of a second.

So, yes, a very crude and errorneous test setup. To compensate I hit several times to see some common values show up. Then I changed the mentioned byte to another value and re-measured.
0x80: timings of around 4.6 - 4.7 seconds
0x40: timings of around 2.3 seconds
0x14 (the original value): ~0.7 seconds

So, 4600 / 128 = ~35.9; 2300 / 64 = ~35.9; 700 / 20 = 35

Based on that I'd guess that the unit of that byte is somewhere around 36 milliseconds (for the non-automatic guns). Take that number with a huge chunk of salt as it doesn't feel like a "round" number. As a hunch, I'd have a look if the game's timing is somehow linked with the timer interrupt, which DOS games liked to capture; You could reprogram its timing, so perhaps that one is a common factor here.

I'll continue my investigation - is a nice change from the performance rewrite of the map editor (that one is coming along nicely by the way)

[665b2210dcabcZylonBane]

It seems like capturing video of the experiments would be a superior approach.

[665b2210dcc87Hikari]

How do you account for potential input lag verses innate delay between fire button and actual firing?

I would agree that having video of each weapon firing would be a good idea, but believe that would only be useful if you have a seperate video recording mouse use/capturing and showing when the fire button is pressed.

Easy way to do that?

[665b2210dd09adertseha]

It seems like capturing video of the experiments would be a superior approach.

I did that to figure out the values of the palette looping. The test setup isn't much better in my opinion - especially since, in this case, it's still bound to manual input, like Hikari notes - and my intention was to figure out in which ballpark the number was. Matty (et al) could have a look at prominent code and watch out for a number close to (or related to) 36.

For a faithful remastered implementation I suppose the exact values are required, which none of these "outside" tests would provide.
Of course, if the code proves to be too cryptic, then we'd have to do a proper test setup to approximate the value as best as possible.

[665b2210dd336ZylonBane]

Easy way to do that?

A microphone and a clicky mouse.

[665b2210dd91fMatty]

As for the fire rates, I now found some time to do some testing (for science!).
Test setup:
* vanilla CD shock running in dosbox, running in a VM.
* Spamming the fire-button of the mouse as quickly as I could with one hand
* measuring lap-times with the other hand on the smartphone, which gives only 1 fraction of a second.

So, yes, a very crude and errorneous test setup. To compensate I hit several times to see some common values show up. Then I changed the mentioned byte to another value and re-measured.
0x80: timings of around 4.6 - 4.7 seconds
0x40: timings of around 2.3 seconds
0x14 (the original value): ~0.7 seconds

So, 4600 / 128 = ~35.9; 2300 / 64 = ~35.9; 700 / 20 = 35

Based on that I'd guess that the unit of that byte is somewhere around 36 milliseconds (for the non-automatic guns). Take that number with a huge chunk of salt as it doesn't feel like a "round" number. As a hunch, I'd have a look if the game's timing is somehow linked with the timer interrupt, which DOS games liked to capture; You could reprogram its timing, so perhaps that one is a common factor here.

I'll continue my investigation - is a nice change from the performance rewrite of the map editor (that one is coming along nicely by the way)

I asked the above questions to not only save time but also generate conversation.

For example, is the offense/defense system preferable to just a flat critical chance? With a flat critical chance it can be easily displayed in an item tooltip. With the critical varying per enemy it will always be a bit too complicated for UI display.

I was able to acquire the source code about a week ago, but haven't had much time to look at it. It is in C, which back then would be ANSI C89, and it can be a bit tricky to read since they do some odd things to compress values.

For example, the logic for determining an automatic weapon fire speed is the following:

#define AUTOFIRE_SPEED 1500
Delta = Elapsed_Time_Milliseconds * Weapon_Fire_Rate + Weapon_Fire_Remainder
Shots_Fired_This_Frame = Delta / AUTOFIRE_SPEED
Weapon_Fire_Remainder = Delta % AUTOFIRE_SPEED

I've renamed the variables and condensed the code to be more readable. AUTOFIRE_SPEED warps the fire_rate by dividing by an additional 1.5, since dividing by 1000 would properly convert from milliseconds to seconds.

It looks like automatic weapons fire at about 66.666...% (slowed down) of the specified fire_rate in data. This looks like it is ONLY applied to automatic weapons.

[665b2210dddc7Join2]

I asked the above questions to not only save time but also generate conversation.

For example, is the offense/defense system preferable to just a flat critical chance? With a flat critical chance it can be easily displayed in an item tooltip. With the critical varying per enemy it will always be a bit too complicated for UI display.

Suggestion #1:

Perhaps you can have have nested tooltips where you can give a description for the individual stats themselves, and therefor you can explain how criticals work within the description of the critical chance stat.

Click on the weapon in the inventory -> window appears giving weapon stats, description and buttons -> hover on the specific weapon stat (e.g damage/rate of fire/critical chance) for a tooltip description of the stat itself. Here you can explain how criticals work.

Suggestion #2:

How about weapons have an individual base critical chance,  and enemy armor reduces the weapon's chances based on how strong their armor is rather than negating crits outright? This probably removes the demand for a thorough explanation of criticals and you can just display the weapons crit chance in the tooltip and leave it at that. Additionally with this system the weaker/less "lucky" guns can still remain somewhat relevant vs the more powerful late game enemies. They'd still be able to score critical hits only the chances would be reduced.

Of course, these suggestions lack insight behind them as I haven't seen the code and I don't know the full extent of what Night Dive are doing with the remake and its GUI, but maybe the ideas have some value.

Click on the weapon in the inventory -> window appears giving weapon stats, description and buttons

Better yet, to save screen space:

Click on the weapon in the inventory -> window appears as so:

-------------------------------------
             [Equip Button]     
              [info Button]

[Ammo Icon] [Ammo 2 Icon]
--------------------------------------

Clicking the info button clears the window & displays stats and weapon description instead.
In other words, similar to how it is in shock 1 but with added info. 

Just throwing ideas around while having no idea what you are actually doing, which is probably something more streamlined. Meh.

[665b2210de6c3dertseha]

For example, the logic for determining an automatic weapon fire speed is the following:

#define AUTOFIRE_SPEED 1500
Delta = Elapsed_Time_Milliseconds * Weapon_Fire_Rate + Weapon_Fire_Remainder
Shots_Fired_This_Frame = Delta / AUTOFIRE_SPEED
Weapon_Fire_Remainder = Delta % AUTOFIRE_SPEED

I've renamed the variables and condensed the code to be more readable. AUTOFIRE_SPEED warps the fire_rate by dividing by an additional 1.5, since dividing by 1000 would properly convert from milliseconds to seconds.

It looks like automatic weapons fire at about 66.666...% (slowed down) of the specified fire_rate in data. This looks like it is ONLY applied to automatic weapons.

There seems to be more at play here. I now made another test sequence using the automatic weapons (flechette and skorpion), ripping through a clip of 255 bullets and measuring the time after changing the suspected byte.
For any tested value in objprop.dat (of the generic weapon properties), it takes around 33 seconds to go through 255 bullets of continuous firing. Tested values are the defaults, 0x00, 0x01, 0x7F and 0xFF. So at least for the extremes I'd have expected some differences, yet none to be found.


Also:

...and it can be a bit tricky to read since they do some odd things to compress values.

Heh, I know - I've got the experience from reading just the hex dumps of the data files; You get used to it.

My offer still stands: I'm willing to sign an NDA (or suitable license) for the code to extract such information and make it public in the ss-specs documentation. Though still as a private project, I'd prioritize by your requests.


I also mistakenly mixed up the names "Marvin" and "Matty" in my previous post - fixed & I'm sorry.