Alpha 21 Discussion Overflow

[faatal]

On 4/15/2023 at 5:53 PM, Riamus said:

Yeah, I can't imagine they do it except between traders.  I wonder how they would manage vehicles... Do you have to pick it up to take it with you, or having it on the helipad is enough?  We shall see.  Since they did remove it, that means it is probably guaranteed to appear.  No reason to remove it otherwise.  Of course, maybe they just don't want to have false hope out there. 😁

It should be no surprise to anyone that we discuss fast travel as many games have it, hence the helipads. The vehicle teleport is one of my main issues. We think the vehicle should go with you without it being annoying. I'm thinking it teleports to an open parking like area and finding a free spot. I'd prefer it be a very limited system, but it could end up as whatever makes sense or not doing it at all. It could easily not be in A22, yet show up later.

[Pernicious]

4 minutes ago, faatal said:

It could easily not be in A22, yet show up later.

Well, you just leaked that A22 isn't going to be the gold edition! 

 

 

[Riamus]

1 hour ago, faatal said:

It should be no surprise to anyone that we discuss fast travel as many games have it, hence the helipads. The vehicle teleport is one of my main issues. We think the vehicle should go with you without it being annoying. I'm thinking it teleports to an open parking like area and finding a free spot. I'd prefer it be a very limited system, but it could end up as whatever makes sense or not doing it at all. It could easily not be in A22, yet show up later.

That makes sense.  You would need a good sized area where the vehicle can spawn because with a lot of players for servers allowing more than the normal max of 8, you could have a bunch of stuff in the way.

 

A few possibilities:

 

You could make a temporary holding spot for the vehicle that requires you to put it back down before leaving the trader's compound.  If you don't put it down, you're stuck in the compound.  And the temporary holding can hold a vehicle that has things in inventory, but can only be used automatically during fast travel so it doesn't allow filling a vehicle and then carrying it around with you.  You could tag a single vehicle to take with you that is within the helipad area.

 

Perhaps a better option is that when you arrive at the new location, you are automatically placed on your vehicle so you're taking about the same space (a little more) as if you don't have a vehicle.

 

Another option is to have the radio or some other device include an "inventory" that shows your vehicle that you chose to bring with you only to you and you would then click on it and click a place to put it on the ground.  It would never go into your inventory and would not need to find its own placement when arriving.

[Gamida]

8 hours ago, Pernicious said:

Well, you just leaked that A22 isn't going to be the gold edition! 

 

 

 

Well, IIRC, madmole had already mentioned in the dev stream that something could be pushed to A23 so fataal wouldn't be the one who leaked it

[meganoth]

9 hours ago, Riamus said:

That makes sense.  You would need a good sized area where the vehicle can spawn because with a lot of players for servers allowing more than the normal max of 8, you could have a bunch of stuff in the way.

 

A few possibilities:

 

You could make a temporary holding spot for the vehicle that requires you to put it back down before leaving the trader's compound.  If you don't put it down, you're stuck in the compound.  And the temporary holding can hold a vehicle that has things in inventory, but can only be used automatically during fast travel so it doesn't allow filling a vehicle and then carrying it around with you.  You could tag a single vehicle to take with you that is within the helipad area.

 

Perhaps a better option is that when you arrive at the new location, you are automatically placed on your vehicle so you're taking about the same space (a little more) as if you don't have a vehicle.

 

Another option is to have the radio or some other device include an "inventory" that shows your vehicle that you chose to bring with you only to you and you would then click on it and click a place to put it on the ground.  It would never go into your inventory and would not need to find its own placement when arriving.

 

I would guess those solutions are all too much special code for something only sometimes relevant in unsupported configurations. I think the teleport will just not work if all spots are filled. Or the car is teleported out of the compound just like players at night (because the code for that is already there, it just needs to be turned on for vehicles as well)

 

[Roland]

18 hours ago, faatal said:

It should be no surprise to anyone that we discuss fast travel as many games have it, hence the helipads. The vehicle teleport is one of my main issues. We think the vehicle should go with you without it being annoying. I'm thinking it teleports to an open parking like area and finding a free spot. I'd prefer it be a very limited system, but it could end up as whatever makes sense or not doing it at all. It could easily not be in A22, yet show up later.

 

What the....

[Riamus]

7 hours ago, meganoth said:

 

I would guess those solutions are all too much special code for something only sometimes relevant in unsupported configurations. I think the teleport will just not work if all spots are filled. Or the car is teleported out of the compound just like players at night (because the code for that is already there, it just needs to be turned on for vehicles as well)

 

Turning that on for vehicles would be nice.  Especially if you have a larger trader.  Will be nicer to drive into it with it being larger, but it's a pain if you get kicked out at night with your vehicle still inside.

[Survager]

On 4/17/2023 at 5:32 AM, faatal said:

We think the vehicle should go with you without it being annoying. I'm thinking it teleports to an open parking like area and finding a free spot.

 

If you are talking about teleporting vehicles outside the merchant's base when night falls, then in this case the parking spaces should be located outside the merchant's base.

If you are talking about moving between merchants along with vehicles, then parking spaces should also be located outside the merchant's base, since the teleport can occur a minute before the merchant closes.

One way or another, the helipad is not suitable for these purposes, since it is located in the area of the trader's base.

And why then do we need a helipad, this is a big question )

[Roland]

Parking spaces? The entire world is your parking space. Park wherever you want inside or outside, on the street or in the ditch. I don't think there are any formal parking spaces anywhere.

[Riamus]

7 minutes ago, Roland said:

I don't think there are any formal parking spaces anywhere.

*Looks at his base with a driveway and garage and parking spaces*

 

Oh ... Am I doing it wrong? 😁

[Survager]

49 minutes ago, Roland said:

Parking spaces? The entire world is your parking space. Park wherever you want inside or outside, on the street or in the ditch. I don't think there are any formal parking spaces anywhere.

For the correct teleport of the player's vehicle so that he is not lost, this is probably necessary)

And no one will write a fine for wrong parking )

[Roland]

I will. I will be the meter maid of the apocalypse

 

[Obsessive Compulsive]

On 4/16/2023 at 10:21 PM, faatal said:

Zombie pathing is already cheap and runs off the main thread. I did fix a bug last week with only 1 path per frame being sent to the threading system and since it typically only takes 1 frame to make a path, it was a bottleneck for say 100 zeds making paths each second. A fairly simple change now has it requesting up to 8 paths per frame of which the threading system can provide about 6. This tested well with around 150 zeds on a server spread across 6 players.

Ohhh?  What I noticed was your animation rate versus physics updates and transforms are all done OOP. This can be spread out to help the runtime load. Making this multi thread is very difficult with the way it is coded however I was able to separate phases for players in specific so far. I took over the gmupdate from the unity update tick and separated some of the work. Specifically the entity update tick. Your thread pool is set too high. Way too high. If most of the game is single threaded, then having a thread pool do that will toss the threads into the pool waiting for work that almost never shows up. This can cause IO handling problems. This is my own opinion but the pool should be slightly larger than the work orientation within the code. If the game is only coded to use 2 cores in general, then 1200 threads in a pool will be an issue.

I also like to run work simultaneous along side the main, rather than isolated to only threads. This keeps a better work flow and the data has a better potential to be closer in the data stack when passed off to the other threads by the main which then runs part of the operation.

I am isolating the Entity.OnUpdate from the EnityAlive.OnUpdateLive which contains the heaviest calculations. Both can be multi threaded by dividing the work evenly with the players being split among them. If the Entity.OnUpdate runs at the same time as EnityAlive.OnUpdateLive, then the overlaps can cause issues. Isolating them into phases prevent this and I highly recommend it for all of the entity. I run the Entity.OnUpdate phase multi threaded, then the live section multi threaded. There are a few things you have to pull out of this process and run isolated to avoid overlaps with multiple players updated simultaneous. 
updateCurrentBlockPosAndValue and checkForTeleportOutOfTraderArea. Ideally these would be inside the position update phase. The buffs, inventory, bag, stealth and updateprefab sections need to be isolated, plus those must be done single thread. If some of these can be written for thread safety, it can all go multi thread while keeping your OOP process. This would avoid a total rewrite of the game while getting a giant advantage out of the multi thread.

Here is how I mapped the isolation phases

Positions > Chunks > Buffs-Inventory-Bag-Stealth-Prefab > Entity.OnUpdate > EntityAlive.OnUpdateLive > One offs that must avoid overlaps like CheckSleeperTriggers
4x               1x             1x                                                         4x                            4x                                         1x
1x = single thread
4x = four threads

Not sure if I measured this improper but your runtime with a single player in game on the dedicated servers was around 0.05-0.06 which is honestly atrocious. The unity update tick rate is 0.01. 5 runtimes missed from a single player. I hope I measured it wrong. After taking over the gmupdate and doing some tweaks for dedicated and taking over the entity update phase entirely, I have it down to below 0.01 with one player in game. Actually it was closer to 0.001.

I can go into a bunch of other things if you are interested.

Due to the runtime you are averaging and how much faster I can run the update, I can run multi runtime ticks in the same time frame, so I split the work across them. It actually was running so fast at first when I left it running every tick, everything was moving around like the flash. Chickens were red blurs. Breaking the chicken sound barrier. Beak neck speeds. Now I am updating across ten ticks. Zombies are in very nice animation flow while keeping their tracking more accurate. I also split them across four ticks. I update the players twice to keep them in better animation, network and update state with others around them.

You can reduce the updates across multiple ticks while keeping your OOP but splitting it to phases to allow multi threading too

You can also use flat buffers for the entity update phase which helps avoid some of the garbage collection.

I did some work on block collapse to make it rapid and look like it crumbles.

Chunk sync to unity has four ticks which dramatically helps in with loading large volumes and high player counts.

I run the entire gmupdate every tick like normal, it is just the entities update and chunk sync to unity that can be spread out across the ticks/frames
Tick 1 and 6 update players. Tick 2 3 4 5 is for non players and single thread for now(Yes it can be multi threaded but more difficult)
Tick 7 8 9 10 is for chunk sync to unity.

Keep in mind, I do that in 0.1 where the normal game right now is updating one player in 0.05-0.06. I do what I can to keep the runtimes under 0.01 to match the unity tick rate. The closer to that you can keep it, the better the overall fps. 

We were able to achieve 300 zombies and 70 fps on a high end server with multi threading. There are huge race conditions and overlaps that make non players extremely hard to multi thread.

You have a few sections using static lists inside of the class which is the only thing stopping multi thread. To avoid the garbage you need more lists allocated upfront or allocate them at runtime if not worried about the gc.

The AI is, well I will be honest its a bit ugly. It must be done single thread currently. I can achieve multi if I alter those static lists, however it hits a duplicate path id error and then spams the console. I suspect it is an issue in the library you guys are using for the pathing algo but I could be wrong. The good thing is its fast. Spreading the work load across more runtime ticks allows the ai to keep up despite being single thread and the changes you guys have made for a21 is a big deal. That single path check instead of eight will help a lot too. I am avoiding touching ai since you guys are updating it but I will let you know if I find anything

Edited April 18, 2023 by Obsessive Compulsive (see edit history)

[Pernicious]

Tell us what you really, think, don't hold back! 🤪

 

Wow, does seem like you've really done some really serious work reverse engineering this. I hope the devs can use some of this to improve game performance. 

[Obsessive Compulsive]

2 hours ago, Pernicious said:

Tell us what you really, think, don't hold back! 🤪

 

Wow, does seem like you've really done some really serious work reverse engineering this. I hope the devs can use some of this to improve game performance. 

I think they are doing a great job and have taken on a behemoth task. Probably not a huge consideration early on in the dev cycle but this late, I imagine not using multi thread is hampering the game potential. I would be stripping out things and 'streamlining' as a way to get the fps higher at this point just to fit in content. In reality, its a combination of things. They started this game when Unity was single thread and had no support for multi threading. Unity stopped supporting proper netcode for years and mid development of the game so the Pimps have done a really good job. Bravo Pimps.

I hope this can help out in some manner, maybe a small change in the approach of application from the strict OOP. They can keep the pattern but try to adjust it towards phases which would allow multi threading those particular phases as OOP processes. Each core gets a split of the entity list to update and handle on its own for each phase. Differ the work when possible. Utilize the runtime ticks to spread out updates. Not everything needs to be updated every single tick so simple pacers forcing it to only trigger every second or third tick is already 50% less work and retains their current pattern. If it keeps the game flow in tact, then they are really blowing their load a bit as they reprocess things over and over with no real purpose. That is the nature of OOP, so it is not their fault. What I am doing breaks the rules of OOP.

It is really hard to use the modern unity features of the engine like the job system since that really should be coded using ECS patterns, not OOP. They have also missed using pooling in some cases. Whenever they can be used, they really should be. What can you do at this stage though? You cant rewrite it all without breaking everything. I know optimization is not their focus but I feel they have missed the boat a little bit. Some of this is not really optimization so much as engineering and coding patterns. Although I am calling this an optimizer since that is what it achieves and does indeed have optimizations for ram reduction, in reality it is borderline an engineerizer lol and using harmony injections to achieve it makes it 10x more difficult.

It will be made public once I can sort out some interesting bugs that happen due to multi threading. This post is already too long. Maybe I will write up an entire process of how I did it and the complications along the way. A programmers journey to hell
 

[Obsessive Compulsive]

On 4/12/2023 at 7:57 AM, Gamida said:

Hypothetically speaking, if a mod like this did exist would it work on SP games also.

I have only seen it mentioned having to do with multiplayer servers.

While it is possible, it is another layer of headache. The local player aka local host when self hosting or client while only single player must be updated on the main thread. This is due to some rules in Unity such as mesh changes, chunk syncs, ui alterations and a few other things must be done strictly inside the Unity engine. The main thread is the only thread capable of passing data in and out of the Unity engine. However that means the other players can still be multi thread and get all of the advantages.  They should be able to handle a lot more than 8 players if the work load is spread and multi threaded using some phasing techniques.

Non players are another beast I am still working on. Some of it can be safely isolated and multi threaded. In particular the entities that are considered alive such as zombies, animals, vehicles, traders. These can all get isolated and multi thread for their physics sections among some other tricks. Non live entity, not so much. The way the game is coded would be very difficult to do that. I really want to avoid anything that alters their form and pattern too much while still getting significant multi thread boosts.

I would need to code a version for single player users in particular but I don't see why it could not work. That is something I can look at if people are interested. I am sure you want to see some results first with the dedicated optimizer. It is a little hard to believe it is possible or that the results are as good as stated. All I can say is they are real. You might not see the same level of improvements seen on a dedicated but you will definitely see a dramatic stability increase.

Here I am self hosting a dedicated and running a client on the same hardware. This impacts the total potential since the server starts to lose fps when the client is having trouble with hundreds of zombies all at once. Still managed over 200 zombies and a super high fps. This is before client side optimizations and just zombie and players using multi threading. I could not get the zombie stable enough on multi thread yet but this gives an idea of the potential. It is very much plausible to do. I can only get player multi thread stable so far. Once all the hiccups are sorted out I will push it further and see what is possible

On 4/3/2023 at 4:17 PM, Roland said:

 

I've been around and I have no idea of whom you're talking about. Why not name the mod author and post a link? Maybe @faatal would like to see what they did and whether it can be utilized? Why keep it a secret? That's not good news....that's just saying there is a secret.

psst, its a secret. You know me. It is not ready for public release yet. I want to squash some more bugs before making it public. It has run on a few of the biggest american and euro servers on and off the last few months. I had to do some work on ServerTools first but I am back to work on the Optimizer. If you don't remember me, you called me an arm chair developer a few years ago

[Pernicious]

2 hours ago, Obsessive Compulsive said:

I think they are doing a great job and have taken on a behemoth task. Probably not a huge consideration early on in the dev cycle but this late, I imagine not using multi thread is hampering the game potential. I would be stripping out things and 'streamlining' as a way to get the fps higher at this point just to fit in content. In reality, its a combination of things. They started this game when Unity was single thread and had no support for multi threading. Unity stopped supporting proper netcode for years and mid development of the game so the Pimps have done a really good job. Bravo Pimps.

<snip>

Kudos to you for the effort you put in, and the recognition of where the inefficiencies and legacy constraints come from. 

 

If you ever do get around to documenting the journey, I'd be keen on reading it. There are a few topics that are off the edge of my area of expertise, but close enough to still be fascinating to me. I speak regularly with kernel programmers and hardware designers, and specialist algorithm designers. I understand little of what they do, but enough so they aren't speaking gibberish, and I generally find it fascinating. This would be one of those areas I'd be keen on reading up on.

[zztong]

13 hours ago, Obsessive Compulsive said:

Chickens were red blurs. Breaking the chicken sound barrier. Beak neck speeds.

 

My favorite part.

[LuckyStar]

9 hours ago, zztong said:

Chickens were red blurs. Breaking the chicken sound barrier. Beak neck speeds.

 

9 hours ago, zztong said:

My favorite part.

 

Yeah that's a funny comment! 😆

[Pernicious]

2 hours ago, LuckyStar said:

 

 

Yeah that's a funny comment! 😆

 

Alright, now I am looking forward to the mod. I started in A19, and I swear chickens used to be faster. I remember a Benny Hill-esque chase scene trying to get my first chicken, and laughing as my friends did the same.

[LuckyStar]

2 hours ago, Pernicious said:

 

Alright, now I am looking forward to the mod. I started in A19, and I swear chickens used to be faster. I remember a Benny Hill-esque chase scene trying to get my first chicken, and laughing as my friends did the same.

HAHA!! I can hear that music in my head right now.

So funny!

[faatal]

On 4/18/2023 at 6:26 PM, Obsessive Compulsive said:

Ohhh?  What I noticed was your animation rate versus physics updates and transforms are all done OOP...

The game tick rate is .05 ms, so that might be what your were seeing. Don't know where you got .01 from as most code runs at frame rate, physics fixed update rate .02 ms, or the previously mentioned tick rate.

 

We are trying to finish A21, so certainly not wanting to make large engine changes now.

I didn't get some of the other things you were saying, but thanks for info.

[Obsessive Compulsive]

7 hours ago, faatal said:

The game tick rate is .05 ms, so that might be what your were seeing. Don't know where you got .01 from as most code runs at frame rate, physics fixed update rate .02 ms, or the previously mentioned tick rate.

 

We are trying to finish A21, so certainly not wanting to make large engine changes now.

I didn't get some of the other things you were saying, but thanks for info.

Thanks for the details. That definitely makes more sense.

The 0.01 is the unity update tick rate? Unless I am mistaken. The tick rate of the update phase coming out of the engine is 0.01.

Oh you update physics at a different pace. Interesting. Maybe this changed for a21 or a later version? That is great to hear. Fixed update and update phase should definitely be utilized just as you mentioned. I must have misread the code. Currently I am updating it all at one time as that seemed to be how entities were handled. I do not run updates on entities every frame though, I do however run the gmUpdate method every frame and a faster rate.

I will have to take another look. It looked like the positions, physics, animations and stats were updating every tick for entities and triggered from the 0.01 unity update phase tick. This update tick triggers the gmUpdate method. Something else may have paced that down to 0.05 as you said. It was a little confusing how it was approached. Some sort of split list approach with entity in particular threw me off.

I took over gmUpdate using harmony and isolated the entity update section that triggers from it. I do not run the entity slice and split entity update the way you had it since I was able to utilize that 0.01 unity tick rate more efficiently and it looked like it was more or less to catch up on missed entities due to running too long during the update process. Since I am aiming to keep the tick runtime under 0.01, I can run multiple updates of the entire gmUpdate method within the same time frame of 0.05 that you are currently using. When I allowed the entity to update on every single tick at the 0.01 rate, things were moving around at super sonic speeds. The animations surprisingly keep up until it runs out of ai pathing, then gets stuck running in place. This might be one reason things are getting stuck in game at rare times. High lag and the server failing to keep the path up to date, might get them stuck in place as their animations out pace it. Something out paces the data available for sure, so they run in place at that point.

By using a combination of multi thread during certain phases for the player update, I can keep their runtime under 0.01 even with larger player counts.

As you stated, you are targeting a 0.05-0.06 time frame window. Since I am aiming for 0.01 as a max runtime per tick, I can split the work across that 0.05 time frame and update specific entities or do specific tasks within each tick, so long as I aim to keep them below that 0.01 runtime which, at least in testing seems to match the update tick from unity that triggers the gmUpdate.

In testing, I found I was able to run ten ticks at 0.01 and keep the animation flow to match your current game state, ai was more in tune to player movements and pathing around them, network is updated more frequent so you get less bottlenecking with packet dumps. You have multiple ticks to work with so you can focus on chunk sync to unity which is part of that gmUpdate method and gets a bit heavy with high player counts, but this keeps chunks loading really smooth around players.

When I say I run a tick, that means running the gmUpdate method fully, however I am isolating the entity update section of gmUpdate. I run ten ticks at 0.01, total equaling 0.1 time frame approx. Only players update on tick 1 and 6. They update completely, entire list both times. That utilizes multi threading as I phased certain sections like the physics which is mostly in the EntityAlive.OnUpdateLive sections of EntityAlive types. I do this with players to keep a better consistency of the movement that other players see. PvP is dramatically improved but so are the general hitbox responses due to keeping closer in sync. I hope the netcode improvements from a21 will really boost that for us. Exciting!

The physics for non alive types are mostly in the Entity.OnUpdate. I update non players single threaded but I divide the work across four ticks so tick 2 3 4 5 are for non players. If there were 100 entity to update, 25 are updated in each tick. Spreading the ai burden. This is why I am thrilled about your updates with AI since the combination with what I am trying out, equals a lot of zombies. I don't see why 400 zombies would not be possible with 100 updated across the four ticks. That should fit inside the runtimes. Tick 7 8 9 10 are for the chunk syncs to unity.

When I made it run 12 ticks, I was able to see a momentary stutter in the animation flow of the characters vs the network updates. This was very similar to when high lag and large entity counts will stutter the updates of entity normally. You also start to see a lag in the ai response while moving around the zombies. 10 ticks seems to be the limit which is 0.1 overall so long as I keep my runtimes below 0.01 for each tick. Currently the game runtime is often going well above 0.1 when large player counts or high entity numbers exist, which not only misses your 0.05 runtime rate but starts to bottleneck the netcode with multiple events getting updating at one time on the player side. It starts to look like warping.

One other trick I attempted was sector work. Splitting the map to five sectors. Update each sector with a different core handling all the entity of that sector single threaded but simultaneous to each other running their own sectors. Then run the last sector on the main which would be the middle grounds between the sectors. This would avoid physics collisions and overlaps while spreading the work. Only issue there is it does not address bottlenecking within a single sector. It would penalize all of them and so the advantages would be reduced, but typically one core was trying to update all of them, so it has to benefit in some manner.

There are two sections if isolated to avoid overlaps, they can be multi threaded. By that I mean running just the Entity.OnUpdate as its own phase and the OnUpdateLive sections as its own phase. It is tricky due to the overrides and how it is coded into the rest of the entity update process, but it can be done. It breaks the OOP pattern though so I know what you mean. You are not going to change the code now and I wouldn't dare suggest you need to. In general, this is not something I would expect you guys to ever do from the whims of some random forum post guy haha. This is your baby, I am just letting you know what I have found in testing so far.

If you multi thread these as phases you just need to be cautious of anything spawning, despawning, unloading chunks which in turn unload the entity. Of course double check for race conditions from static lists or anything you might modify while another thread is using the data. You do not want to be running your physics/collision checks and have something change position or despawn. It will crash the engine as I have experienced a lot of. To avoid this while I am updating multi threaded, I make sure the UnloadEntities method from the World class is run inside of the main thread task queue from your thread manager class. I am also running the main thread tasks twice inside of the gmUpdate method that I took over. Once in the original spot you have it placed but another right after the entity update section so that anything I toss at the main thread queue will stay inside the frame time.

You guys have a ton of awesome tools and systems that work really well together. A+. Would love to see the job system in action. I am still learning how it functions.

Sorry for the long post. I thought it would be best to give better explanations this time

Edited April 21, 2023 by Obsessive Compulsive (see edit history)

[KatsPurr]

As someone who loves - streams - creates POIs for and creates content about the game - I'd just like to chime in as a female player who is a HUGE fan of 7 days. Just like all you gents out there, I TOO feel the same emotions, the same excitement, the same hype, the same anticipation as you do about everything 7 days. I TOO have been looking forward to these dev streams! Just like you, when they started showing the lineup of character art during the art dev stream, I too was sitting on the edge of my seat, excited to see what was coming. 

 

So then they started going through one model after another, the artist fondly talking about all the cool little details and Easter eggs he'd added to the male characters. I thought to myself "Oh daaaammmnnn, if the MALE characters are THIS cool, I can-not WAIT to see the female characters!" Then when he finally got around to showing them, I mean it - out of all the variations, he decided to show the "boobies busting out her top" variation.

 

I wondered to myself: Was there a moment earlier in the day, where the devs discussed which variations to showcase on the stream? Were they saying things like: 

 

"Ok team, let's make sure to give some appreciation and love to our many female players out there and choose a really nice female player character to show them! They're gonna be so thrilled!"

 

or... did they say: 

 

"Duuuuude! Let's show our boys some eye candy, why don't we!? They're gonna looove the rack on this desert character! *giggity*!"

 

If they would have shown additional normal female characters, there wouldn't have been a problem! But that was it. Just the big boobies and then they moved on. Where were the female characters that had as much personality and attention to detail as say the packrat dude for instance? Where was a female character that "told a backstory". All we saw were just big solid implanted boobs. And then that was it. Nuttin' else. I have to admit: it was a deflating moment to say the least.

 

Listen: Let me make something absolutely clear 'kay? I absolutely DO NOT mind a game having hottie outfits for female characters in games. God knows how many hours I invested hunting for the skanky outfits in Anarchy Online and WoW back in the day. I also don't mind the only female trader in the game being a cutie called Jen who flirts with me from time to time. I don't even mind the fact that there are SEVERAL strip joints in the game catering to the gents out there. Heck, 7 days wouldn't be the same without the rough humor. I luvs it! (although, I wouldn't mind seeing a "The Stud Farm", "The Muscle Mansion", "The Beefcake Bungalow" or a "Hunk Haven" POI appear for us ladies one of these days. POI designers: Make it happen! You know you wanna!

 

What I do mind however is the at-times deaf tone and clueless attitudes in regards to making female players feel appreciated, included and welcomed. I remember when I started playing 7 days, one of the first things I noticed was that the traders addressed my female character as if she were a man. Then I remember the first time I saw Joel on stream... Honest question: What's the ONE THING your eyes zap to when he's on screen? The naked lady painting on his wall. I mean my god, it's a frickin' gorgeous painting, it really is! But that's beside the point. What makes this problematic is that a) It's highly unprofessional and has no place on a dev stream b) It creates a horn-dog-buzz amongst the male chatters and this can feel disturbing for female players just trying to focus on the information.

 

In the very least, it would be considerate if devs could at least avoid reacting to comments about the painting and just choose to focus on one of the other hundreds of comments that are actually about the dev stuff instead. When devs react to comments about the painting, it's like validating the horn dogs in chat and saying "Hey dudes, it's absolutely fine that you continue chatting about naked ladies. We don't need to care about how our female audience will feel or whether they will be creeped out or unwelcome!" Devs should be better than that, and lead by example. Instead of encouraging that sort of behavior.

 

There will be those of you who say: "Female players don't matter since the target audience is and always has been male" - Choosing a target audience is fine. But it can still be done in such way that doesn't make literally half of the population feel excluded and unwelcome at the same time. Besides, look at how many female streamers there are that stream this game. Isn't it time that females became a valued and respected part of the target audience?

 

At the end of the day, none of the things I mentioned are very serious or disturbing on their own, the problem is how it all starts to add up. A real shame as this game has so much potential to be enjoyed by everyone equally.

 

[Old Crow]

14 minutes ago, KatsPurr said:

As someone who loves - streams - creates POIs for and creates content about the game - I'd just like to chime in as a female player who is a HUGE fan of 7 days. Just like all you gents out there, I TOO feel the same emotions, the same excitement, the same hype, the same anticipation as you do about everything 7 days. I TOO have been looking forward to these dev streams! Just like you, when they started showing the lineup of character art during the art dev stream, I too was sitting on the edge of my seat, excited to see what was coming. 

 

So then they started going through one model after another, the artist fondly talking about all the cool little details and Easter eggs he'd added to the male characters. I thought to myself "Oh daaaammmnnn, if the MALE characters are THIS cool, I can-not WAIT to see the female characters!" Then when he finally got around to showing them, I mean it - out of all the variations, he decided to show the "boobies busting out her top" variation.

 

I wondered to myself: Was there a moment earlier in the day, where the devs discussed which variations to showcase on the stream? Were they saying things like: 

 

"Ok team, let's make sure to give some appreciation and love to our many female players out there and choose a really nice female player character to show them! They're gonna be so thrilled!"

 

or... did they say: 

 

"Duuuuude! Let's show our boys some eye candy, why don't we!? They're gonna looove the rack on this desert character! *giggity*!"

 

If they would have shown additional normal female characters, there wouldn't have been a problem! But that was it. Just the big boobies and then they moved on. Where were the female characters that had as much personality and attention to detail as say the packrat dude for instance? Where was a female character that "told a backstory". All we saw were just big solid implanted boobs. And then that was it. Nuttin' else. I have to admit: it was a deflating moment to say the least.

 

Listen: Let me make something absolutely clear 'kay? I absolutely DO NOT mind a game having hottie outfits for female characters in games. God knows how many hours I invested hunting for the skanky outfits in Anarchy Online and WoW back in the day. I also don't mind the only female trader in the game being a cutie called Jen who flirts with me from time to time. I don't even mind the fact that there are SEVERAL strip joints in the game catering to the gents out there. Heck, 7 days wouldn't be the same without the rough humor. I luvs it! (although, I wouldn't mind seeing a "The Stud Farm", "The Muscle Mansion", "The Beefcake Bungalow" or a "Hunk Haven" POI appear for us ladies one of these days. POI designers: Make it happen! You know you wanna!

 

What I do mind however is the at-times deaf tone and clueless attitudes in regards to making female players feel appreciated, included and welcomed. I remember when I started playing 7 days, one of the first things I noticed was that the traders addressed my female character as if she were a man. Then I remember the first time I saw Joel on stream... Honest question: What's the ONE THING your eyes zap to when he's on screen? The naked lady painting on his wall. I mean my god, it's a frickin' gorgeous painting, it really is! But that's beside the point. What makes this problematic is that a) It's highly unprofessional and has no place on a dev stream b) It creates a horn-dog-buzz amongst the male chatters and this can feel disturbing for female players just trying to focus on the information.

 

In the very least, it would be considerate if devs could at least avoid reacting to comments about the painting and just choose to focus on one of the other hundreds of comments that are actually about the dev stuff instead. When devs react to comments about the painting, it's like validating the horn dogs in chat and saying "Hey dudes, it's absolutely fine that you continue chatting about naked ladies. We don't need to care about how our female audience will feel or whether they will be creeped out or unwelcome!" Devs should be better than that, and lead by example. Instead of encouraging that sort of behavior.

 

There will be those of you who say: "Female players don't matter since the target audience is and always has been male" - Choosing a target audience is fine. But it can still be done in such way that doesn't make literally half of the population feel excluded and unwelcome at the same time. Besides, look at how many female streamers there are that stream this game. Isn't it time that females became a valued and respected part of the target audience?

 

At the end of the day, none of the things I mentioned are very serious or disturbing on their own, the problem is how it all starts to add up. A real shame as this game has so much potential to be enjoyed by everyone equally.

 

 

I 100% get what you're saying. It would have been nice to show some other female armor variations, assuming they had them ready yet. Maybe that's why they only showed that one (of course the boob one would be the one finished first if that were the case).

 

That said, there were a few ladies in the audience who commented on the male character models, particularly the one in his skivvies. Something to the effect of "Finally, some eye candy for the ladies!" This unfortunately creates a double standard. It's okay for the ladies to comment like that (as well they should be okay to comment thusly), but the boys can't say anything? On your side here, just something interesting to think about.