Jump to content

[Game Update] Summer Patch Available Now! - 419840


Recommended Posts

7 hours ago, Gurgel said:

These people really, really get on my nerve. I speak for myself. Nobody else does, unless I have explicitly authorized them to do so. I decide what I want and what changes I would welcome. And I decide what my moral values are, nobody else. (This being a game, I do not have any. Everything is fine because a game is not real. That is the very point of a game.) 

I'll add to that, it's a single player game. I understand there's a point in not cheating in multiplayer games, and the community decides what's fair, what's cheap, what's cheating. You're entering sport territory and sportmanship is a thing. Not in ONI, tho.

 

But there's something else that gets on my nerve. I'm a programmer. I know what it takes to write code, to implement behaviours. Yeah, sometimes there are unexpected things and side effects. But usually, if something happens, is because a programmer took time to implement it.

Calling established mechanics "exploits" is insulting to programmers (and game designers) at Klei. It implies them being incompent amateurs who write code w/o knowing what it would do. Labelling 75% of the game as "unintended behavior" means saying people at Klei don't even know how to make their programs work the way they intended to. It find this profoundly insulting.

Does this mean ONI is a totally bug free program? That designers did a perfect job and nothing can be improved? Does this mean they're not going to change their mind over something in the game, ever?

Hell no. What's intended today, may be changed tomorrow. Maybe one day they they'll decide to implement a different "pressure" mechanism, and liquid locks for high pressure deltas will fail. But that doesn't mean that pressure today doesn't work the way it works because people choose to have it work that way, and not because they're incompetent devs who don't know any better.

  • Like 6
  • Thanks 1
  • Sanity 1
  • Big Ups 1
Link to comment
Share on other sites

7 hours ago, TheMule said:

I'll add to that, it's a single player game. I understand there's a point in not cheating in multiplayer games, and the community decides what's fair, what's cheap, what's cheating. You're entering sport territory and sportmanship is a thing. Not in ONI, tho.

Very true. Forgot that one, thanks for stating it.

7 hours ago, TheMule said:

But there's something else that gets on my nerve. I'm a programmer. I know what it takes to write code, to implement behaviours. Yeah, sometimes there are unexpected things and side effects. But usually, if something happens, is because a programmer took time to implement it.

Calling established mechanics "exploits" is insulting to programmers (and game designers) at Klei. It implies them being incompent amateurs who write code w/o knowing what it would do. Labelling 75% of the game as "unintended behavior" means saying people at Klei don't even know how to make their programs work the way they intended to. It find this profoundly insulting.

I agree. In particular, the need for some form of working lock that keeps gas out reliably but lets dupes pass is something that the fine people at Klei will have run into basically as soon as they had a gas simulation and moving dupes. There is no way they did not know about or not expect liquid locks to be discovered. 

Edited by Gurgel
  • Like 1
Link to comment
Share on other sites

21 hours ago, TheMule said:

Calling established mechanics "exploits" is insulting to programmers (and game designers) at Klei. It implies them being incompent amateurs who write code w/o knowing what it would do. Labelling 75% of the game as "unintended behavior" means saying people at Klei don't even know how to make their programs work the way they intended to. It find this profoundly insulting.

I agree, basic mechanics should not be argued as unintended. But the developers have also commented when live-streaming new things that they haven’t thought of everything. And they are sometimes surprised by how players use buildings or mechanics.

The developers know how to design and code, but they cannot analyze the millions of combinations of how these different systems interact with each another. At some point the design shifts into being an art form, one in which they use the forum to help balance.

The developers have even encouraged players to exploit the systems. They want us to be creative and think of designs they may not have originally intended. Exploits are never black and white, meaning they are not all terrible and need to be fixed. They all fall into a gray area, hence why there is always so much debate.

  • Like 2
Link to comment
Share on other sites

4 hours ago, yoakenashi said:

I agree, basic mechanics should not be argued as unintended. But the developers have also commented when live-streaming new things that they haven’t thought of everything. And they are sometimes surprised by how players use buildings or mechanics.

The developers know how to design and code, but they cannot analyze the millions of combinations of how these different systems interact with each another. At some point the design shifts into being an art form, one in which they use the forum to help balance.

The developers have even encouraged players to exploit the systems. They want us to be creative and think of designs they may not have originally intended. Exploits are never black and white, meaning they are not all terrible and need to be fixed. They all fall into a gray area, hence why there is always so much debate.

As I wrote, nothing is set in stone. But I always draw a line between creative uses of game mechanics (which is what the game is all about) and bug using. And I was replying to a specific post:

  • Liquid locks that aren't viscogel, such as the T shape liquid lock, or the vertical multi liquid-liquid lock.
  • Diagonal building
  • Unpowered incubator lullabying
  • Infinite liquid storage - I'm sure you got plans for this one
  • Diagonally teleporting magma debris to power the steam turbine.

All this is working as intented. The only gray area here is the teleporting.

Liquid locks work thanks to the one element per tile rule. Explicitly coded, 100% working as intended.

Diagonal building confirmed as intended mechanics by the diagonal reach of sweepers, or shiftplates.

Lullaby status is a buff granted to the egg. Like any other buff/debuff, it lasts after the conditions that caused it ceased. Devs could have coded it differently.

Infinite storage, already discussed. High pressure pockets are a natural occurrence, we (the players) just found ways (that uses the one element per tile rule maybe) to recreate those (and push to the extreme). Devs have put in the game both pressure damage mechanisms and ways to overcome it (triple walls, airflow tiles). Again, there's a parameter somewhere in the code that is set for airflow tiles to infinite pressure resistance, otherwise they would be just tiles.

Teleporting, already discussed too: it's inconsistent with other mechanims (mass deletion by doors, building tiles). So it might be a bug, or something unintended. Why doesn't water teleport? Or oxygen? That's the only gray area.

 

image.gif

  • Like 3
Link to comment
Share on other sites

On 9/5/2020 at 1:32 AM, Fongie said:

It feels like duplicants get stuck and die more often.

it not feels but indeed there is a bug in game that they get stuck when they dig, if they dig  bottom tile they sometimes not drop down and stay in air, only way help him is build the ladder or tile that they can reach down

Link to comment
Share on other sites

On 7/7/2020 at 2:11 PM, Ipsquiggle said:

Hi friends!

The team has been mostly focused on DLC development (have you seen the new roadmap?), but we still want to make sure that the released version of the game keeps improving

 

Do you still working in the performance? is there any plan to make the game compatible with multiThread?

 

Link to comment
Share on other sites

On 10/15/2020 at 1:07 PM, gabberworld said:

UnityEngine by default don't support multiThread , there is still possible use that tho

Unity supports multi threading since a decade.

Please consult the manual for further information:

https://docs.unity3d.com/Manual/JobSystemMultithreading.html

This game may look simple, but it is very complex.

It combines simulation and game play in an astonish way. Developing in today`s time is very on the fly - A lot of things to consider and permanent changes, implementations, fails, budget restrictions, direction changes and optimizations. At the same time family, life and everything else has to be taken care of.

That`s why its good to always have a towel.

There is so many different layers of the term multi threading - The CPU level, the board level, people having anything from 1-40 cores, the OS level, the Engine Level, cpu cache, OS cache etc. On a hardware level its nuts if a buyer doesn`t even know what thermal cpu throttling is...Like a typical Apple notebook customer. The game has to run ok for everyone in the end and devs are used to forumistas and players demanding.

Gamers want everything and they want it yesterday :wink:

My complaints about threading here where a few years ago, at the time I was ONi noob and didnt know how complex this simulation game is. Its fun to play with 10 fold size map dimensions haha.

Wishing lots of ONi fun :p

Edited by babba
Link to comment
Share on other sites

9 hours ago, gabberworld said:

oops.thumb.png.39a12ee1252ff8bffac1f8f95d341d27.png

Creating game objects from any thread other than the main one would wreak havoc on a lot of systems with the way everything is setup. That's not the goal of multi threading.

If you want to queue object creation from a secondary thread, make a concurrent native array that pushes object info back, which is then read to create game objects on the main thread after the secondary thread finishes running. Multithreading should be used for computation, not object creation.

If you really want to go for full functionality multithreading, you should consider using DOTS.

Link to comment
Share on other sites

18 minutes ago, Beowulfe said:

Creating game objects from any thread other than the main one would wreak havoc on a lot of systems with the way everything is setup. That's not the goal of multi threading.

If you want to queue object creation from a secondary thread, make a concurrent native array that pushes object info back, which is then read to create game objects on the main thread after the secondary thread finishes running. Multithreading should be used for computation, not object creation.

If you really want to go for full functionality multithreading, you should consider using DOTS.

dots seems kind off new, when this game started develop then that thing not existed

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
  • Create New...