Ecu

That would indeed work for a game where all assets are meant to be under my control. However, I'm not quite sure that would work quite well for a game where users can contribute content. My current plan was to have each part separately animated, and then assembling the character out of these parts when chosen, using a control game object to handle triggering animations and such.

Thanks for the additional information. It does sound like Unity (at least to begin with) would definitely better suit me as it would let me leverage existing systems without much work. Regarding direct loading vs. prefab loading, I will probably stick with the prefab method for now. I would like to ask, is there a good method for me to leverage one prefab for animations and apply said animations to others via this toolkit? Since it is likely I'll utilize multiple swappable parts (clothing, heads, etc.) that are shared between characters, it would be more efficient to have one main file that is animated and then using said animations for the others. Is this feasible, or will I have to just use the same rig for each new part and have the animations stored in each prefab separately?

Hrm. I might stick with Unity and go with the prefab method (at least for now). MonoGame sounds great, but I am not too keen on establishing my own physics engine, my own 3D rendering, etc. While I indeed plan on using Spriter for my project, the goal is to have an engine like this (Don't Starve Together). It actually uses Spriter for it's animations as well, only in a 3D world. The terrain is a flat quad that renders via tiles, all entities are 2D Spriter models, and there is a form of physics for items. In addition, it utilizes Lua for content scripting. I really feel an engine like this has a ton of promise, however, rather than modding it...I'd like to create my own rendition. On reason is because some things have been hardcoded into the core engine and not exposed to scripting. Another is purely the challenge of getting such an engine working. So Unity might work best for me. I know I could definitely achieve all of these goals via MonoGame, however, I'm a designer more than I am a developer. I enjoy the art and system design far more than I do implementing said engine. As such I feel like trying to learn how to get all these working in MonoGame may cause me to give up from frustration if I cannot achieve my aims at a reasonable pace. I'll look into MonoGame a bit though, maybe it is easier than I am expecting. If you happen to have some specifics I should look into, please share them.

That does help quite a bit. I'll consider checking out MonoGame and see if I might want to use that instead. Appreciate all the information.

@Dengarthanks for that information. It has been quite awhile since I've personally developed in Unity as well. I am quite curious if you know whether or not having a large amount of prefabs would also suffer from these two issues you bring up (if you know)? If there is a huge benefit regarding prefabs over direct loading (and keeping in memory), perhaps I should just go the route of using asset bundles for additional content. Since Unity is free, it wouldn't really force users to pay to mod for the engine and would just add an extra step.

No worries. If you don't mind me asking, what is your development environment of choice (assuming you're still using Spriter with it)? What I'm planning on trying to do is essentially implement my own clone of Don't Starve Together. So won't really use a ton of Unity's features anyways.

Heh. I would definitely feel a whole lot more comfortable with you pulling that out than doing it myself. If you were to do such a thing, would you be able to make editor generation a toggle as well? That way I can keep the Spriter folders with the project, instead of it automatically generating prefabs. Though I suppose I'm not sure if I want the Spriter folders in the assets directory if I want them to be copied into the runtime folder anyways. It's been a bit of time since I last tried developing anything in Unity.

So, not something the system does by default, eh? From the look of it, it would be quite a bit of work to re-engineer this to not generate assets and instead create correct game objects at runtime. As I'm quite unfamiliar with the this kit yet...perhaps to keep it easy, I'll just use asset bundles. I assume that it should be rather easy to just setup a simple project that people can load, dump Spriter folders into the assets and then export bundles.

So, I've been looking at Spriter as a tool for creating animated assets for a project I was thinking about and managed to run across this project. The main issue I'm curious about is the ability to load .scml files at runtime, rather than via the editor. The primary reason I'm curious about this is that I'd like the ability to users to customize or add content. I should be able to still allow for user created content via asset packages, however, that requires they use Unity to package such content, whereas loading directly would not. Appreciate any advice on this... Thanks!