GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Sander van Rossen🇺🇦🇪🇺 (logicalerror@mastodon.gamedev.place)'s status on Monday, 13-Jan-2025 03:54:14 JST Sander van Rossen🇺🇦🇪🇺 Sander van Rossen🇺🇦🇪🇺

    So a thing that's been in my mind for a while is that for a long time one of the reasons we'd put all our game resources in very large files was because mechanical harddrives had horrible seek times..
    but this isn't true anymore for ssd's
    now I'm not saying that there aren't other reasons for putting all your assets in a large file, there definitely are, but at least on the editor side of things maybe things could be a bit more .. loose

    In conversation Monday, 13-Jan-2025 03:54:14 JST from mastodon.gamedev.place permalink
    • Embed this notice
      The Seven Voyages Of Steve (sinbad@mastodon.gamedev.place)'s status on Monday, 13-Jan-2025 03:54:10 JST The Seven Voyages Of Steve The Seven Voyages Of Steve
      in reply to

      @logicalerror UE’s “one file per actor” system is basically this, the main problem with it being lots of generated file names that really needs custom version control integration with the editor to make sense of (which means it only works nicely with Perforce right now).

      In conversation Monday, 13-Jan-2025 03:54:10 JST permalink
    • Embed this notice
      Sander van Rossen🇺🇦🇪🇺 (logicalerror@mastodon.gamedev.place)'s status on Monday, 13-Jan-2025 03:54:11 JST Sander van Rossen🇺🇦🇪🇺 Sander van Rossen🇺🇦🇪🇺
      in reply to

      objects would have unique file ids, would be updated through import system. they'd basically be unity prefabs. instances of prefabs would be prefab variants.
      moving, renaming of objects would be file operations
      since you'd have folders you could have folders in your hierarchy
      transformation hierarchies would be more complicated to handle ux wise though, but maybe this should be a separate hierarchy anyway? maybe?

      In conversation Monday, 13-Jan-2025 03:54:11 JST permalink
    • Embed this notice
      Sander van Rossen🇺🇦🇪🇺 (logicalerror@mastodon.gamedev.place)'s status on Monday, 13-Jan-2025 03:54:12 JST Sander van Rossen🇺🇦🇪🇺 Sander van Rossen🇺🇦🇪🇺
      in reply to

      take unity's scene files for example, they contain game objects but can also contain resources like meshes etc
      what if instead of storing all that in a file, we simply have folders for our "scene files"?
      files/sub folders could be locked in version control individually, making collaboration simpler
      merge conflicts would be a lot simpler to deal with too

      In conversation Monday, 13-Jan-2025 03:54:12 JST permalink
    • Embed this notice
      Sander van Rossen🇺🇦🇪🇺 (logicalerror@mastodon.gamedev.place)'s status on Tuesday, 14-Jan-2025 02:09:29 JST Sander van Rossen🇺🇦🇪🇺 Sander van Rossen🇺🇦🇪🇺
      in reply to
      • The Seven Voyages Of Steve

      @sinbad why? are the generated file names not human readable?

      In conversation Tuesday, 14-Jan-2025 02:09:29 JST permalink
    • Embed this notice
      The Seven Voyages Of Steve (sinbad@mastodon.gamedev.place)'s status on Tuesday, 14-Jan-2025 02:15:55 JST The Seven Voyages Of Steve The Seven Voyages Of Steve
      in reply to

      @logicalerror nope, very much NOT human readable (they're like guids). In the editor they appear with their human readable names but it's almost impossible to link that with what you see on the disk (and therefore in other version control tools)

      In conversation Tuesday, 14-Jan-2025 02:15:55 JST permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.