So I actually started with Unity - and was doing a diablo-like action game with action H and animations. I may go back to that system another time - but I ran into the same problem where I was either using a 3rd party extension like the ORK RPG system and having to learn that and then also extend that system for sex or coding an RPG from scratch. Also, art assets are still a problem. I had to go buy a bunch of UI pieces, learn Unity UI, create dialogue, combat etc all from scratch or using 3rd party stuff which I also had to learn the commands for.
I started implementing the stat system and then realized I didn't code the sex system and combat system on the same stat framework bc I was hardcoding for prototyping and would have to spend a month fixing that. I implemented dialogue and then spend 3 days trying to figure out how to scale the text to resolution bc the plugin didn't support that. I implemented an item system, then had to extend it to make penis, vagina etc items, then figured out the item system wouldn't work for that because I'd have to break my hierarchy to bring character stats into those items so I recoded that.
Art assets aside (can sympathize—I'm definitely not an artist!), it sounds like more of a process problem than a tool problem in this case. I get the impression that you did a lot of learning/prototyping
in situ, which is a very risky approach when you're putting a project together.
It sounds like you've gotten over a lot of those hurdles with your current game, but here's some unsolicited advice anyway:
I would strongly advise keeping your experimental prototypes far away from your production code. Sometimes you can evolve a prototype into the basis for a project, but generally that's only doable after a few iterations.
When you're scoping out a new project, you should develop a technical scope before you even open the IDE/engine tools. You're not going to be able to nail down every aspect, but if you go in knowing roughly what your project is going to look on a technical level it'll help significantly.
It's pretty easy to forget specifics when you have a lot of moving parts, so you need to come up with a way to organize them. Using a Kanban board is a pretty good way to organize everything. Two popular examples are
You must be registered to see the links
and
You must be registered to see the links
(I personally use
You must be registered to see the links
, since I can self-host it). Basically, you scope out your project in tasks and subtasks, then you can drag them around a grid to signify their status (for example: new, declined, in progress, on hold, in testing, complete…whatever best fits your workflow, really). It gives you a nice visual of where everything stands so that you don't suddenly realize that you're missing something at a crucial moment, and it's a huge boon if you ever bring on other team members.
This isn't really related to design, per se, but learn
You must be registered to see the links
(or another SCM) if you haven't already. If you make a fucky wucky at some point it gives you the option of rolling back to previous versions of the code, among other things. If you collaborate with another dev at some point, I'd consider an SCM to be mandatory.
Most importantly: don't be afraid to throw away work. Learning through failure is an important skill to develop. Just try to make sure that your failures happen outside of your main project (or, at the very least, occur in a separate code branch).
Obviously LT is pretty simple in concept but getting it to code and then adding content without breaking it is probably way harder than people here realize.
I've found that non-developers tend to be split down the middle with regards to their attitude on programming. Half think that even writing a "Hello World!" program is an insurmountable feat that can only be accomplished by the gods, while the other half consists of the "adding multiplayer is ez lol" category.
In truth, a lot of difficulty can be mitigated with proper design. The issue in this particular case is that LT never seemed to have a proper design: it mutated rather than evolved. It's not to say that Inno went in without a plan—she absolutely did have a plan, and a lot of thought went into various aspects of the game's design. The problem is that most of that plan consisted of world, lore, and things of that nature. High level design stuff, really. The code behind all of this is a bit of a mess. Very little attention was given to how computers would process data, and that's one of the things that leads to it wildly thrashing memory (among other things). Yeah, it works, but it's a house of cards waiting to fall (and the fact that I can easily and consistently get it to run very poorly on a modern high-end CPU is kind of silly).
And, of course, there's the financial aspect. Perspective changes drastically when money starts to change hands. An inconsistent schedule is excusable if you're already maintaining a full-time job (unless you have a very entitled fanbase), but when something
is your full-time job it naturally leads to more scrutiny.
What I figured was that RPG Maker was the best prototyping system to figure out all these problems and have a good framework for displaying content and dialogue that wouldn't break all the time.
It kind of feels to me like Unity forces you to build what you need more or less from scratch, whereas RPG Maker gives you a ton of functionality up front and asks you to mold it to your specifications should you need to escape its boundaries.
