I'm actually an electrical engineer, but I have a bit more than a decades worth nonprofessional and academic game dev experience. I do coding and art (2D or 3D) but none of my nsfw projects have really gone off the ground so take what I say with a grain of salt.
~ avoid doing
Well a lot of the time there are two issues that I see.
Most nsfw dev's are hobbyist, not experienced devs. As a result, they tend to have the issue of thinking too big, trying to create games with two large a scope. When you only have 3 or so people, writer, programmer, artist, you'll be amazed at how slow things can go. As an artist, my best time to start with a description and with nothing (no previous drawings or assets), create a 2D character is about 10 to 24 hours, in one or more pose, with and without clothes, and possibly with more than one expression or ready for animation, and I consider that an amazingly short amount of time, but when you only have at best 6 hours a day to work, that means it can take as much as 4 days just to have one character in one pose drawn. Same with coding, 25% figuring out how to solve a problem 25% getting the code made 25% getting the code to work and 25% refining the code so it works will with the rest of your system. that's easily a week of work for me, for something like a dynamic dialog subsystem. They say it is best to make your first project a month long project, but when people think simple, they don't think simple enough. Something like making bejeweled could take half a month to 3 or even 4 months depending on your experience and skills.
The second issue is that nsfw dev intentionally design their games such that they can keep adding on to it, as a way of keeping the project alive and keeping the patreons coming in. I find that this is just dumb. I'm looking into the idea of making small one-shot games (such as some of those found on Newgrounds my favorite example is
You must be registered to see the links
, this is also
You must be registered to see the links
). Now the issues with these examples are that they focus on gameplay. That is not bad per say, in fact, I preferred this with final ass. In fact, in order to make a game as efficiently as possible, game makers have used all sorts of tricks, such as reusing a pose and just changing a character's expression, and many game mechanics are centered around the idea of reusing assets to minimize the amount of raw resources and work needed to complete a game. But that is besides the point. What I think leads to many project to go down is simply, we humans want to chase after the new shiny things, if I new idea comes to mind people want to break off and chase the new shiny idea. What I want to explore is making small games, not gameplay or story focused, but focused enough to embody one idea, such as a particular type of encounter (just like how many professional pornos are centered around a particular idea).
Now that is just the basic issue teams have from the start, but it looks like you may be asking for management types perhaps.
~ keep doing
I handle team management (especially in teams when people are just volunteering their time, I am typically non-profit) a lot like I teach students (or tutor? idk I am still a college student, getting my second degree).
You can bring a horse to water, but you can't make it drink.
Students can come to class, but being there doesn't mean they will learn.
You can get people interested in your game project, but that doesn't make the work any easier.
These three phrases are essentially identical, getting started is easy, but doing work is not. (actually not really, sometimes getting started is 90% of the work, but it is only a mental barrier, not a real one, once you get going it is easy to keep going, that is why a lot of students don't take breaks every 15 minutes like everyone says they should, they lose their momentum)
I like to do what I call a scaffolding approach. Think of it like this, when you lay the foundation for something, it makes it easier to work. That is kinda what I try to do. But just to be nit-picky, I think of the foundation more like the getting started part of each phrase (ie training a horse, having a school, or a game design document is a foundation). Scaffolding is the stuff that goes around a building to let workers work on building the building. Basically, it is like the skeleton of the building. Some of the work is already done. By having a skeleton of a completed game, course work, etc, it makes it easy to walk past the project, climb into it, and put something in place.
Basically, I think it would be ideal if a rando could notice your post, give it a quick look over, notice a request for a drawing of a particular character, the artist can look at what else has been done, they can draw it, share it, and then walk away. Two things that are important is that, there needs to be enough information and free room that the artist or other volunteers don't need to feel like if they can ask to join (they will do it anyways just to motivate themselves), so that makes it quick to get people, since you don't need to stop and explain. The second advantage is that people can walk away, that is very important. A lot of the time it is hard to get people because they are afraid of commitment, doing maybe one piece or so is all they have interest in, and I have learned to accept that (the issue is that sometimes the art will be inconsistent, so that is the compromise you have to make, unless you want to spend time redrawing things afterwards), and it allows more people to peek in and test the water.
~~ I guess I am moving onto the larger scale section ya mentioned.
Now the main issue here is actually making the scaffolding or the skeleton of a game. Making that is not easy, in fact, that is the primary goal for not only the nsfw hobbyists but also the professionals. A game skeleton is basically, everything is there, you just need to put in the pieces. For professionals, this mostly means developing tools and systems, so that new content can be added. Making systems is the most time-consuming part of any project (a system would be like, designing art and code for a dialog system, such that you can easily configure new conversations or swap out art on the fly). For hobbyist, most of the time they are just trying to get a demo out and build on top of that. This is... I don't want to say it is bad, it shouldn't be shameful, we all do this at one point or another, but it has some issues.
Say we make a game, a demo, and with each version we keep adding more. It is like building a foundation and then building on top of it. Sometimes our systems get kinda goofy and things get screwy. A new or bad dev would just simply patch any issues, an experienced or more willing dev (if the publishers allow the time, which they don't) would go back and rebuild parts of the system to fix these issues. That is like building a balcony that hangs past the foundation, so you come back and try to add more foundation to help better support the balcony.
Now the best situation and the wet dreams of many programmers and developers is to start out with building a system, a skeleton system that easily allows for fitting in new pieces and growing to new sizes as needed. I have met many who feel like they had a great idea on how to do this and spend lots of time working on it. In fact I have been doing the same thing.
~~~
I have pointed out a lot of issues, but no real solution. I should put my money where my mouth is, and I am trying. I have seen these issues and more over the decade or so, and I have seen others try to solve them, and tried my hand at it as well, I have explored game engines, different methods of art or programming (C# so far my fav), etc. I have done most of this before I found the NSFW community.
One thing of importance from all that is, I at one point started to work on a series of scripts and plug-ins for unity. The idea was that I wanted to have a lot of code done that could easily be dragged and drop into place, so that I as the programmer of most teams did not slow anyone down, in fact I could get a basic demo done in 1 to 4 days depending on how much placeholder art I could muster or find. So we could develop the game as fast as the artist could make assets. One of the things I was experimenting with, was actually developing a system which allowed artist with no programming experience to be able to add their work to the project and edit the project without having to email me and wait for me to do it, this way they could see how their art looked in game and then go back and edit it and upload it again. It started to become its own language as it allowed for people to narrate cutscenes. Or it was, I never actually finished the proof of concept.
The reason I point that out was that after a good break (had to focus on college stuff), this led me to my current project. Right now I am developing a type of programming language that uses natural language (or seems natural), and the language itself is actually the skeleton needed to solve just about every issue I have seen with either learning how to program or with game making. Instead of bottom-up development, the nature of this language is top down.
Now the language isn't the only thing (oddly enough it only seems to use 4 actual keywords). I mentioned my scaffolding system, the idea of building a skeleton of the work so that it guides people to fill in the blanks. My idea uses the same trick, the language is not alone. The programming environment is also a tool design to help you. One example is multiple inheritances and the conflicts that come from trying to implement such things, an issue avoided at all cost in most other programming languages. My system is able to work around this by reading what you have written, noticing possible issues, and then the programming environment works with you to figure out exactly what you mean. The neat thing about this is surprisingly the solution is a change in programming pragma, but with the nature of my language, it is not a concern for the person who writes, everything stays in its natural language format.
One key feature is that this programming environment has a todo list, it lets you know what need to be done before it has enough information to try and create your program, and because it is top down, adding things onto your project does not compromise the whole project because the program automatically restructures itself to accommodate so you never have to worry about going back and fixing your foundational code because you are not working from the bottom up, you are working from the top down and the programming language automates everything for ya.
But this summer I am focusing on art, as well as two part-time jobs, so I'll get to it later.
I could keep going on, such as describing how others try a similar approach of making a tool or system to make art quickly, and I have dabbled with it as well, but nothing noteworthy.
Best of luck
