Vapourware How to make indies like terraria, starbound, broforce...?

[Jools]

Well, I recently started musing about making a small game, a trifle if you wish, that would be similar in looks to games such as terraria/starbound/broforce. In other words, 2d and pixels would be mandatory. Landscaping (mining/farming etc) does not particularly interest me: I just like the visual style of those games. I would like it to have stats, NPCs, and dialogue choices (with possible branching conversahunz).

So, how does one go and make such a game "platform"/"engine"? Are there dedicated tools or editors? Or is there any editor to "mod" one such existing game? The fact that so many (like, a fuckzillion, all released sort of recently) similar games, or games using a similar "engine", would lead me to think they are not "too hard" to make, but I suspect there is a catch somewhere, or just that appearances can be deceiving.

Hoping someone can give me a couple of pointers. Thanks in advance.

 

[Mastermind]

Do you know how to program?

 

[Jools]

Do you know how to program?

Not really. But my associate (a friend who's in this with me) does.

 

[Destroid]

Follow one of the 9999 platformer tutorials. The basics are simple, making it feel good or have multiplayer, not so much.

 

[shihonage]

I would use Visual C++ with SDL 2.x.

SDL 2.x is a platform-independent 2D library (and also sound/network/input), AND, it uses hardware acceleration on all 2D stuff, unlike SDL 1.x, which was outdated crap.

You still need to know how to program games, though.

 

[Jools]

I would use Visual C++ with SDL 2.x.

SDL 2.x is a platform-independent 2D library (and also sound/network/input), AND, it uses hardware acceleration on all 2D stuff, unlike SDL 1.x, which was outdated crap.

You still need to know how to program games, though.

Thanks, I shall discuss this with my partner-in-crime. It's a start.

 

[Castanova]

The fact that so many (like, a fuckzillion, all released sort of recently) similar games, or games using a similar "engine", would lead me to think they are not "too hard" to make, but I suspect there is a catch somewhere, or just that appearances can be deceiving.

They're not hard in the sense that a small team with little to no budget can produce games like that in a reasonable amount of time. It still requires a large amount of skill in game programming, among other things.

 

[Jools]

The fact that so many (like, a fuckzillion, all released sort of recently) similar games, or games using a similar "engine", would lead me to think they are not "too hard" to make, but I suspect there is a catch somewhere, or just that appearances can be deceiving.

They're not hard in the sense that a small team with little to no budget can produce games like that in a reasonable amount of time. It still requires a large amount of skill in game programming, among other things.

Noted.

 

[curry]

Do you know how to program?

Not really. But my associate (a friend who's in this with me) does.

So you wanna be like VD, you know, the guy who takes all the credit but doesn't really contribute anything?

 

[Jools]

Do you know how to program?

Not really. But my associate (a friend who's in this with me) does.

So you wanna be like VD, you know, the guy who takes all the credit but doesn't really contribute anything?

I dunno. I'm gonna take care of the pixels, and of most of the writing. Also i'm for paying for due credit, so if my mate does more than I do, due honour will be paid to him. I really don't care much credit or fame.

 

[non]

Here's an excellent SDL tutorial:
http://lazyfoo.net/tutorials/SDL/index.php

 

[Mastermind]

Do you know how to program?

Not really. But my associate (a friend who's in this with me) does.

So you wanna be like VD, you know, the guy who takes all the credit but doesn't really contribute anything?

 

[set]

Do you know how to program?

Not really. But my associate (a friend who's in this with me) does.

Wake up and smell the coffee. It's 2014 and learning to program has never been easier.

You can never have too many (good) programmers on a game project. At the very least, learn how high level scripting languages work so you won't be totally useless in developing a game. Start out in WC3 (w/ JASS) or Gamemaker. For networked games, learning LUA (Garry's Mod) or PAWN (Source MP) is also useful.

Nothing bogs down a project like a bunch of know-nothings. At the very least, put together some competent spec docs for your programmer to follow. Nothing ruins projects more than poorly defined project requirements.

 

[Rhuantavan]

May I suggest you take a look at Unity as a complete multiplatform and free game development environment?

 

[Twiglard]

Fuck me, old post. Enslaving nations with necromancy.

I would use Visual C++ with SDL 2.x.

SDL 2.x is a platform-independent 2D library (and also sound/network/input), AND, it uses hardware acceleration on all 2D stuff, unlike SDL 1.x, which was outdated crap.

You still need to know how to program games, though.

I'd use something capable of decent C++11 conformance, like mingw-w64 with GNU toolchain.

Whether hardware-accelerated 2D or not, for lighting obviously shaders only. Unless totally static 2D lighting or heavy tricks like additive blending to mix static + rarely dynamic, blitting textures to screen NOT a solution.

As for the word "engine" abused and overused so much here and sometimes elsewhere.

When you say "engine":

- spatial (i.e. space, XY coordinates, areas) representation of game world
- types of assets, like floor, wall, roof, scenery tiles in FO/FIFE/moar, tile types like shoothrough etc
- SOME form of input handling
- streaming resources from storage
- management of data in memory, i.e. lifecycle, i.e. loading and unloading, not making game run outta RAM after 4 hours
- crapola UI with no layout management, just hacked up together in a weekend
- ragdoll physics
- immershun

After lurking codex on-and-off for years, this whole "engine" misconception of yours has become somewhat a pet peeve of mine. Not sure who started it but don't abuse words don't know the meaning of.

As if that ever happens.

> Unity Basic which might not be enough in more advanced stages of development (like having custom DLL's).

Elaborate some. Means exist on desktop to load DLLs dynamically. Typically that's GetProcAddress or dlsym.

There's also the dynamic linker, as in PE, COFF, or what you "omg engine" people call an ".exe file". So what the fuck do you mean "having custom DLLs".

 

[set]

SDL isn't an engine any more than XNA is - it's a framework for building an engine. It has some engine-like features built in, like handling sound for you, but a lot of the graphical stuff still needs to be implemented by hand (like the basic draw loop).

Unity is much, much closer to an engine, but even it I'd say fails to live up as an engine. You need to implement lots of basic mechanics, like movement and collision. It's a very "low level engine". I'd say a real "engine" is closer to UDK, or even WC3 map editor, or Hammer. Those are much closer to being "complete" engines that you can build games with.

Also, having used both SDL and Slick2D (Java), I'd say Slick2D is way nicer. Java runs on everything. The performance hit for using Java is negligible if all you're doing is 2D games. Slick is so nice because you can load animations with the framework real easy, and to animate you have a built in ".play" function, you don't need to build your own animation handler at the lower levels, just the basic logic for switching what animations to play. It's so fast to develop "low level" 2d games with, and you have full control, unlike Game Maker and other solutions to quick prototyping. In two days (about 8 hours) I already had collision, movement, sound, animation, map transitioning.

 

[Twiglard]

Unity already has the painful details of collision detection implemented, see https://www.google.pl/search?q=unity collision detection

Note that choosing implementations and writing glue for space representation + collision model isn't the same as implementing them from scratch. Do Unity programmers need to implement ray/triangle intersection, or stuff more involved than that?

Too bad XNA ended the way it did. There was even a community formed around it, not just XBLA shovelware pusher lot.

SDL audio doesn't support positional data well, or at all - there's an option for stereo sound, and mixing available only with a third-party available - see SDL_mixer.

That slick2d animation reminds me of using Fallout and Arcanum graphics to fuck around with prototyping and exploring traditional RPG programming. Animation "handling" isn't a thing really, with no special cases for each class of entities within the structure. Declare whether it loops, plays forward or backward, what's next on transition. That was with XNA, involved a desk, a hard drive, and a cat.

While using XNA, already had a fuckton of problems with garbage collection eating into frame rate and making it not deterministic. Trying out monogame made it even worse, as monogame itself needed patching to prevent just render code (or the update/render loop) from causing GC pressure. Imagine it's even worse with Java, given its lack of value types, reliance on boxing for manipulating the predefined few primitive types, not to mention GC having problems for so long and even now requiring tuning in deployments. That .NET has more heap profiling tools than JVM doesn't help.

All the languages forcing automatic memory management down users' throat aren't suitable for things like games. They aren't suitable for other usage scenarios, like numeric computation. Got no trouble with JVM/CLR for code that doesn't run on the CPU for most of the time. Games though loop without consideration for CPU slices allottance across a running system.

Lastly, one thing that python's slow, now that people use it for games, started whining that an implementation faster for most workloads, pypy, uses automatic memory management, and tricks that make frame rate less reliable. With all that, why not just use C++11 and not have anything to do with all the language advocates and "theoreticians" for heaven's sake.

 

[set]

For 2D games, does it really matter about garbage collection? I can only see that's the case if you're building Dwarf Fortress - a game so bloated in mechanics even with its non-graphics it still requires an i5 to really enjoy to its utmost.

Games in general aren't CPU heavy, they're GPU heavy. The only thing your CPU should be doing is the threads for sound and logic. The heaviest logic in most games is a frame-by-frame collision check, pathing calculations and maybe AI.

What you say about Python/XNA is pretty true. I've known someone who's building a game in python - I assure them they are dumb all the time for doing it, but they have some crazy reason for it.

 

[asfasdf]

Garbage collection always matter, don't build a bloated leak machine.

 

[jcd]

defbd58928d83ff02b1a935c63f3bb61a63fa56406a9459cba070b80440fd00b3a5159985cb3f63eb41d0152b91d8e951787e8f124d37888e40cc3deebf8e19515083179eadb21f45876e9d7963eaee5ef08dc2ad1a1b0fd7e47509e77e7770110ebe24a800beeb127cc6d41328ff195849c9fede6f5f1194776e518fa5fecb3bbfeab1b3d46c7d49a69fcf76ad0a85268592b3d8f12c6c7430bba2bcece8764b49e44acd70026e29219aaac74b6d4191329bd8bac1a6b89ec98997765a70117ec7792ea60673deebe45f2a4b7311a4fbc01643755f4c9d44b4c447e23b4e48d0bb840bd370e3739175ae64813410b6cc55a715c2f133f49b60bea308b0c9cf27d43780975f03a99afe492ce84a4f21430f7ca1dd1f41b9215a8c4bddf1e554f9348b4eff1711ed4bf591c7eadf179733c534e30f50359188eae94b2c401449cada8d05a65af0e6d629c2481fbccfcffe450a9202c603ad15d3a87387f8ca9eca74c3af3cd2b422742dfa5e55e68bf38525d455430568a8c4c8cb4c8f2e7ef680d506804926300e7669331ae1af3716b5f568e3f339ebb20d72df4c74e8637a21d73d231e60ce0def9c0624e70cb60f6c9d2aba503da080eac043500b25436770eb55e0ff4f8c0048e25a51de953e0b613eb4cc092fafaa513577040f09d1e2e35288152fbfb2526da2721cf1fa470ed43a2d8b060f934e2ce9e16411d084d2913fac3e84bd334673fe774098db84308f6f0ff76f3aab77ca9d6b4fc23aee85b65b7790e2aa924a93d871d5e1943f880dc09cd6d8c8dee1921eed679a383c6f60168eb77716a7b4e192102ae69e640f1fcb7c0e16df284bd8122b27d1bf9a1b04be72dd9794e0e110620a79249973194f4cc9b077f9415edabd2af12bd7f85db3be138d8fa7a9847d5aa0efaa247ebb1c732d2ead218cc60b78a9d599afb669617745eb7b10a4245080bccff5741d8bb56fb976abf8a56e232da6a46994c9942a7be96fdccb158ce9a8994bddc1f36782e56eb3fdc46fcb81b11d643a1e15773d78a35dc1a74a5a0ccc148b1642c2c9035805f6653cf4bcfba50b22e2ae6c673f9bb991cf7c18aba60c9de7b8c87ee0a15215521d3e1a9bfdc55485f929294a79c152d53c81e1d12caf066f5e8438c3f7985d74ca947e105a4b5b867401fee796fcd6766203c3107c59af7c5fe80ef94301fdb18694cbba3211bda39432b2f0527baddc62fe68dc0e758b83545cbfc0db5850442243639671834c07bf2a1577eaad700683db98a0f72e9f3982fdd1d069c98e31fbe77059c8871a7972a126eb963b3e71eb7dac29391e8645abf80a8a11332e3a374fe749141908115ac8238c7e7416188887bf72d3414d68dca6db021353409de37565e2dc875d0a6802cbd1dff05f1e509501f56f71f174618d090c135257a3fa8ec535bf581e0053f734eaa1ed1c0fe7d496719c7ebbb753f28c840599c670f5f6d750df4d238029d44bb33a01db4f1158367aee154cda283dc7ccf3e179b25646e7a738e52b9b00671904f1ce97b0296392cdd963724ff672e61aac3de80cd6c383b060dd3f9ab6e426c41bbf3c92ba50c27e7fdbf9fe39ce683ce2d90ce5b667862c6eafc6bdc0663ba4c3c40094eac4c6ff55f9606ae7a3d685f6116bd5dd0ffef67f1d2dcab263a0cc31f3d058a0096836cdc638dc9458010826235d57ac533fae55dc890d16f8ad38f8799b66cd6d013ad3424bf126eae0c5a1cb72146543d90fd5dffeea9dba2fe7e364880ee1e37d5ad9c92d8b1199aa51f6f6b90d736bf907834076561ab8ef85c9e3b6270b5423ccff54f3b2f31136e26b06653348bb699b03a4fc556201ac4c9fb4bfd95dfad37536c08cc6e5e2677af95887e7e1c6613e7666ea498b41e78944b9d2ba3c9006ac5dce1b634d66203660c24363534212a5bd773b0fee62fffb0388fb429e17015b5b32bc9e21e71d57ac22ef6cc986ff099da48a02594dfa48c9a3e48719ff12016ed41e549c680944223e257c290521cc327ebdcd7fa942e890a1ecdf8beb0f312b02acb7a6c5b6972b4bb1244b132fd12a571a3646253dcbe5aa21e7f5b9d91b50165ef6e242262fc25b13e383bc2af07b4abf1f62155322b8d3327d5e836ffb9ababb8424babed4c3b78f760126849d13fd0155661f75229e10601ab3acb27108b6787fcde11814dee77d7326be6087b1fbbfbc9d9adaa238ac1fcb235e802a79f315de60abe27c6e1fa9cbb3af2c065b75b6bc67823a443920ebd14040ad3d74ea5ec6b0f0976a83195715d2ff3592d44c50a3e6daf62f966dd3910e7a5e0d1f48d4dc4304f56034f60fd71495bdf99338d2752ef4ffd6de58d3d77c54f769c82ab8da5d27e635b0f5533c077db74ad9bcb9eebed0b6fb1a0365d365cda8321e57e3311ec6c44e49e1d3afebfb01ce883055aad86d8fb5293054574b86690bfb524fa7b710947848cd2fe11fbbe2b129b7cf9d1be6acf477a950b54a9cb695887e95be5bd3917b7d65111f5b360ff2a547f77d90414806cf17c45cab4a85022dec448d5e8934346cbe4c5ea479d38d125cd98c09e29c4429150608a065f5677aa8a64a67e5afe3142a8d8800608b1b51f86498a81eb7a4fe1a377c8ca8b12e9548ec6d53c4c0831b45464df6c0eeec9290fe979178aaa0572f94287252923520eb806d6b2ee6f49ec727102365ba4d0ea5ceab01574a218e721aa049a186bf5e260805f87e0607b2d9b5486657a873fdf5e2d26ac8f75a0ccc2664198f657206d52d50c5baf33747185a245a8eea956b4037bb28734f8e5539449f2bd988da71791e7422f1ced95857dcd924f16446ab95bd246e2b78ed217bd583c6a8f471f65b65ab278cc05997aadf61584f91ef03612218c342f16619870f54ac0b6f721152129cf98bf663434f73ce47e6cd3827931edfce4d38802702257e43526f5f7bcf711c6ab5ebe9820b6e9b61fe1332d8b0a9cbfa038aea5e29f4e03c6c9cf689f907efa716558c6b5d8ec08a28133c9f156dc1624060a28e794f9f3c1e1ece78e7f56e24bd4bec0b9183c3705a20996bb6b759a1acc9bf951229ddd59b589a60eb8bf065f859711920c7a17725f4b40842bbcc99e453d4234be972a2f1ebace5164639411ed8c39e4d3f9eb9347e0713cc3b37d46078c67a6e6bc0cc7a2a76ff0f81b39a59292ce7988191a7e7f1545fd2ae0b7391cb442e2fe56c92438b36ea744f9ed0f37db813fea695bb3166b452d2b147c6dd81c3b1e2b89fe7b0a1b5d4da92c694187f4ed01846459d1e097e43bc4ab967bf0883546c938a8bb3525e681c8b644d7b6093ffadb1aac18dae66fffe650ff22267da673da7a69604d7a0bb936884a832886e0346f06afc03e01aa988ce0035796629c491d0383b8b98baed5c827300a38696e26a5b99384df84b56dda93aa65d6cfb321ef1e517a9eb3508f573eb40c465d9b1a099bf40f6650285c4f0328cbc87d2dbef126fe77c728265165724c31e9c52bf215575c0f4b20f9d4bc900debe4146cd65287492d3c7860b857a54428a99a06fc51434010fe15d7bf7855466d8aac8dd91965fef957ead8332dc27b5a9fc206bbcdd21869b4b7592da58c8cbe367c5b457d8737809493224aac4d59a70a35489746c33d90229ee3bca19815981a6d4c764a78e442b1a060122a241bb7875f8cae602f33aa690d6dd038ec65beba3f4fcf15e2b3068da7f5db57d3b76a47c5f7fd6c391bc5e8d2a355a6ab10645a1e8c2c7cc53639a67ca1cef2b6c89c0969c5125d0bf942430b60a60ea94bf028267097b1443aeac217f3dc655e15b342a6e65dfb99e0cd955b8cddbf4d0c745ff658d68eebe9991171f59049323a31db45951fdd6d53c213ac050ba1efba5cacf7f489c4ecddbdd752ade1d20f73b92cdb3659193f314ed9d8eb67a2cf78cdd8b66e25a57e03ca656424a70cb6c9420d438310916deb071ecec5298f1a494c2284f049798800bdfe22b13b4acebbb83a6047b25f3ef3357f0abdde2fc90e6d4f5e008254cf6fb3dbafc4c9982627ba37bd4ab32c95b6db188cba1ceb403ee249467cbf4c78975bf50f2a1416956a36c12beeb8d672f29f3f31ced09c630db75a550b36a4a251f02629344c65cbcbcefe3ffbb9f0603cd6f93709fa44a85eea629caab79d8b90641753c21fb52193c84fc4728317dd4ecdabf71a1fd35ead050ec10d03d5c12162499b5c2b22cb5f860683e3ffae58e15c7c07404aaab7ac9893a987a6cba9a35364066f0543067d7a3d0f3cdbf2468b56a7bc1c2b8ef74f9838ce592c0912d18663a5d269d6df76a92f256dcd3e10a6c66d22cea22b635ca0d10cd64894b0fd9f03fbfe0f8fb78d8a04eb06de52a6a7b92b62ac6906c1b69d69506e5cd03203d87649a81eaca6f169cafdd4c74c8dac5defa8d6ce9f73eea891ccb0e902f7e74d2d54891bca11cc54226ba683608bdc371cc461f3fa302d1a5da88709211ea8733f9749cd03e604a7496859265b1d8ea259615849a7489f9b118a87ce2981704a247d1e91e01324cac3b2203371cb7c627923e6aa0a9c8b74098c3d143b1a5c0540ca64eacdd2091feacfb4a0a721c03f64c6ca8cfd0c5a5f61e1e255ca5e64aed9ddcec23621ca2751125b524100d665f0b59ff781600552677729a81d38d25c9788e6e174c86656451288efa910e62839fa1c5ccb4845f7b3cd258d7c031eb5e3e57bd3bfa71c55b76a5f7651589d34ac7a2825895e7865321501297a0d3af9c5b7ba2f6fccceb7521375cc440e6133bfd292c685d418b56a660f7cbd41b0726f3ec56225ed6e2a87faa8c23ae150dcbc9b7c2a8c5f559bbe3ef91218df26fa43fa178252188c5719a4b6d3fc2c6e4e134511b21f87fba76c6b56822b64d3e7c7c231910554ac63ea89f1be75b6af87e1070029a548d1385906209fd26071be609d882e831f939464ea551ab78f869f9a0ed58ae09d28a4abe70d535380e9588e0b93c9058136994ae354b81436f7e52f0ac6d7171323c29a525456e32d11cf069cb52b45ba039e30c242a65a990b568e37a25942e639fd7188465ad46d3e93683faa61ed0cdd0525f46981f67f1807d8fd5caeea49f17369e2f48775ab2523aad63a43a48df11bf6642267c1dfd5dd1732a0fa87eeb82ec05555c6de3579c74ed9edb43116d2e8c7906ab82ca76d8aefb517108f5cab006313aefa04e704907fbd8be577df1dde44840a0b55e2d72f7a7a80653d5d5c2e4617e622f89b4f8a9f7758544e706ed68485f69a9610e6bbf9e086740b67f91a43e308f643a0d26f7fe5afe0c9a838b60c5c270f1d88d3063cf5ad35386cd43e15c4c3369184670f906174706aa93f44e2eb4c0c6e1a7697098948ea32389af3abce2c3933fc6899d124221530a7deab688e8bd2b5241463f4993f4c053a221a05849e411a3fa104114c71fe500dacfc14acbe4ea54b05ab81f741a01580a2b14e833aef8e5bbcb6466889d87c772314e77ff54bcd02723fe804203fde5a9c03a12e03685ebbfdc677b1d581a22a777895b2bcea0bd2a0431f35f129ccb0b183ac9813946ddf5b761964f580017a9850fe22d435bd79e8bffa4159a26a7311e26a1eb0e315c5af2747bbab7812c51f3b9b0b4d69503d8060a55df892540bd60025a12cefc0d75120a45b7aaf296fdb7e9b04221ca1d1579a71b431302c999ef76cbd98ceb06b7fab31a97a2cab3f7e5893c9b5af255cea8880fa3f7397ec16c25494fa34f2f34837c0782dbd29a8b4d25ce4c02016d131d7c2262a171487269fb29070

 

[set]

Garbage collection always matter, don't build a bloated leak machine.

I mean, in languages that handle it for you.

Obviously, it's important in C++.

But, if you're using Java, and you set shit to NULL when you're done with them, it should all get cleaned up in a reasonable amount of time, just maybe a little slower than C++.

 

[Twiglard]

With that fallout-asset-based practice code that got lost in a cat accident, garbage collection made not only for lag spikes but general madness. And lag spikes were common, a second an order of magnitude, not like every minute even. Just imagine how much shit is allocated when running at 500 Hz in a 2d isokrapola.

Then imagine it's a generic function for, say, drawing, or drawing every visible of given asset type (roof, wall, scenery, floor). Just one shit consed, that's 500 * N where N is every floor, roof, so on on the screen.

Games aren't "in general" GPU-heavy. Unless you move the goalposts a bit and restrict to some subset of "games are".

Even if staggering amount of bloom, AAAA games written by those community college students tend to stall the GPU, don't do asset loading asynchronously, Pope knows what else.

> Obviously, it's important in C++.

What's important in C++ memory management is that there are no explicit cycles in shared pointers (just like Python, Perl), unless part of cycle's a weak pointer (in core language spec in C++11).

See also: std::make_shared, std::shared_ptr, std::weak_ptr.

Java yes, but just like XNA/C#, if heap-allocated shit needs to go out of scope more than once every eclipse a time, you have the lag spike and general slowness problem. Don't care about it and problem grows. Less you care, less FPS you get as more shit gets consed.

Note, my network server in C# consed more than few GIGS of data a second, used all CPU, throttled bandwidth. That's because used DateTime.Now which allocates on heap. After change to something sensible, Windows task manager showed barely any CPU usage. That's a network server, not a game.

 

[Destroid]

Twiglard it sounds like you wrote some really awful code (from a performance perspective). Just because you are in a memory management environment doesn't mean you can forget about it completely.

 

[pakoito]

Why recommend Slick2D when it's been completelly deprecated by LibGDX, even Google is using it for multiplatform games on iOS. While I respect SDL as a commercial and professional framework, it's just too much to handle for someone just starting. Even the build system has a higher learning curve than most other languages. Making an engine with it takes months if not years. In XNA/LibGDX you can throw a Entity-Component-System library taken from nuget/maven and you have one running on less than a couple of days.

Other stuff like Lua seems to be even easier.

But, if you're using Java, and you set shit to NULL when you're done with them, it should all get cleaned up in a reasonable amount of time, just maybe a little slower than C++.

Not exactly, most buffers need to be explicitly closed/recycled as soon as they're not in use. While this is mostly done by your framework it's good to know where and when. There's also pooling to avoid expensive item recreation. And memory tricks to reduce cache misses. And threading. Java gamemaking can be tricky too, not everyone has Notch's leeway.

 

[Twiglard]

Destroid no. It's just that any allocation at ALL has to be avoided in render code.

Not just self's (though not obvious always why there's GC pressure, ever) but also all third-party, including .NET runtime itself.

Entity/component model doesn't really deal with components depending on each other and having to synchronize. It's a really stupid idea/workflow to ever consider.