Also, I forgot to mention that that dll up there was made with ILmerge. It works more than than the MSVC linker's output that I tried, and Sphere Studio gives a different error trying to open it (instead of badimageformat, it's some error with 'type' in the name, I don't exactly recall what).

But I made that dll using a getkeystring.dll that was compiled for clr, but not clr pure, which made ILmerge give an interesting message semi-complaining about it not being pure. It might actually work if it was clr pure.

I have been making (mostly?) any nontrivial function for TurboSphere have both a clean backend and a V8 frontend function. It just felt right to do it that way, but it certainly should make sharing functions between the editor and the engine easier.

I have to say, I'm not liking this whole fat plugin idea.  It's great from the point of the view of someone using the editor, as they can just install one DLL and have it automatically work in the engine, but the issue comes with distribution.  When I go to distribute my game, do I really want to add bloat by including design-time code with the engine?  Probably not.  Let's not forget that more code is usually needed for the IDE side than the engine side...

This is one of the reasons recent versions of Visual Studio actually seperated the design-time components from the runtime stuff, to reduce the size of the redistributables.

If that's a big issue (it might or might not being, I'm thinking no), it would barely be any more effort to also make a pure-TurboSphere plugin without any editor code. However, I'd rather just distribute the fat binaries: one of the nice things about Sphere games is that they are easily moddable, but if you get rid of editor functionality that was used to make the game mods suddenly become a lot harder. In other words: include the fat binaries for the curious people who like to mess with things.

I actually wouldn't mind if there was some way, for large binaries (at least) to have two versions. One version is intended for just the engine and another one for both. The one for both the developers use, and the one just for the engine is for release. I mean it's really the plugin writers choice to create a single fat binary, or two binaries (engine+editor, or just engine).

It's pointless to have a plugin for just the editor, unless all it does is modify something non-game related. I mean, it would be weird to have a battle system editor plugin, but not have the battle system it creates be used.

I have to say, I'm not liking this whole fat plugin idea.  It's great from the point of the view of someone using the editor, as they can just install one DLL and have it automatically work in the engine, but the issue comes with distribution.  When I go to distribute my game, do I really want to add bloat by including design-time code with the engine?  Probably not.  Let's not forget that more code is usually needed for the IDE side than the engine side...

This is one of the reasons recent versions of Visual Studio actually separated the design-time components from the runtime stuff, to reduce the size of the redistributables.

I for one would still distribute the engine-only plugins as well. It's quite simple to make them--that's all I have right now. That's also why making a core TS plugin that needs any .NET or Mono or anything other than V8, SDL and maybe OpenGL, and possibly a separate sound library to work rubs me the wrong way. I would be willing to have the fat binaries need .NET, since the editor would also need .NET. But if .NET or Mono was needed to make this idea work, I would make absolute certain that engine-only versions also existed of all the plugins I make.

As far as the editor plugins, it makes as much sense to have both the engine and editor function at once, since what good is editing something if you can't run it? And from my experiments, it seems much simpler to make something that qualifies as a TurboSphere plugin than an editor plugin, too. Every single failed attempt I had to make a fat plugin still worked as a TurboSphere plugin.

At the same time, I know that most engine plugins won't be more than 1 MB, and just about every one should be less than 100 kb. I don't know about the editor, but almost the entire bulk of what TurboSphere requires to work, including itself, is the graphics and audio libraries and V8--and V8 is a vast majority of that size anyway. And the biggest plugins, the graphics plugin (and although I do not know for certain, I believe the sound plugin as well), generally won't need many editor-side functions at all, since editing images should probably be a generic plugin (and be used for image files, fonts, windowstyles, etc.), and for most audio files I wouldn't expect the editor to do much of anything to the files anyway.

In fact, I can fit the entirety of TurboSphere (all the binaries, or alternatively all the source including the V8 source) on a single floppy disk with room to spare. It's not much bloat at all as we have it now. And we can always move away from this system later if we choose. We could always have some plugins that are fat and some that are only distributed as separate files if we wanted, too.

I think, for sounds, a fat plugin would be the best thing ever, it exemplifies everything about why it's needed: 1, we ensure the same filetypes are read by the editor and engine, and 2, that they sound exactly the same. If we can manage that, then it's really the best thing ever. This same logic applies everywhere else, images, maps, spritesets, etc.

Pretty much every other PC-based game engine I've seen, from RPGMaker and ika to Unity and XNA, only distributes engine runtimes with playable games. One would need to actively seek out the appropriate editor if they wanted to mod the game in question. Think about offering up the fat binaries only as optional downloads, while engine distribution has the engine-only libraries; that was probably your plan anyways, right?