The reason I'm hesitant to use something like RPG Maker is that all of the games it produces seem to have a very Pokemon-style approach to the genre. There's a town area where the player directs an avatar to move around, sprites for every NPC, etc. I'm effectively eliminating that entire element of the game, since, for mobile, I find that the avatar movement mechanic is clunkier than what the HID allows for, and better paradigms for travel and world-interaction can be explored.
Don't get me wrong, while it's more difficult, that's why I'm using C2 and not rpg maker myself - rm is just too limited and with C2 I can make my game exactly how I want it.
hen you say that they have a lot of "interlocking systems" that have to come together, do you mean that in a technical sense (getting objects to instantiate, interact, etc, properly from a programming perspective), or in a mechanical sense (make sure that a +1 to attack doesn't stack in a certain way to make characters be able to one hit everything)?
Well, both, but mainly the technical side from my experience (you still have to program the rules, after all).
f it's the latter, I've already developed the core system (Attributes, skills, to-hit stats, item balance, etc) to the point where I'm confident in the relative stability of the mathematics. You're not going to have a certain build that is superior to all others in every way. That's where my experience playing, modifying and more recently writing, tabletop (pen and paper) RPGs comes into play.
I'm not claiming your system isn't as good as you think it is, but you should probably be aware it's very common for people to code something and realize it doesn't play as well as they thought it would before they started - even people experienced in software and game development often encounter this problem, and is why some people like the idea of fluid game design rather than deciding everything about how the game is going to play before any code is written. Just something to be aware of that you might encounter.
Well is it difficult or not depends on your own take on it. I can tell you from my experience that if you don't approach it as difficult, but rather with attitude that it is simple but might be challenging, then the only thing that stands between you and the finished rpg are how you plan it in advance and how much time you are willing to put in to it. Also on the side note can't wait for your finished game! :)
Based upon the numerous reports I've read from other people attempting to develop RPGs and the very near unanimous opinions thereof that they simply are very close to the most difficult genre to make (only being beat out by stuff like mmorpgs and insanity like dwarf fortress) as well as my own experience already having tried to make loot pursuit with the attitude that it would be simple and having planned a ton of it in advance only to realize it didn't work how I thought it would once I tried to actually make it, I feel confident in objectively stating that attitude has nothing to do with it, RPGs are simply hard to make. Even with 5-6 years experience with construct (though I certainly don't claim to be the best C2 user, there are people who can easily code circles around me, I'm far better than I was when I started, having almost no idea what I was doing at all), there's just far too much involved in making an rpg to call it a simple task. I certainly understand how it would seem to be simple though, as I once thought that myself.
Here's one of many, many examples of how things turn out to be more difficult than they seem like they might be. Tapping on a unit to select them on a touchscreen in battle. Seems easy enough, right? On object touched. Except that tapping isn't very accurate compared to a mouse, and as such the user can miss a unit easily, especially if they're small enough, even more so on a small screen like a phone. Ok, so then instead I tried an 'on touch, pick closest unit' event - except there were times where I would try to tap the ui and a unit would be selected. Ok, so I put all clickable elements in to a 'clickable' family and pick the nearest clickable to the touch. Except unit hotspots are at their feet, resulting in inaccurate picking again since people try to aim for the center of the sprite. Ok, so I add invisible clickable objects at the center of each unit to pick the nearest from. Except some ui elements and units are large/small enough that even tapping what seems like close enough to them will still select something else sometimes because of the distance of the hotspots. Ok, so then I divided the screen up into regions and pick the nearest clickable object based upon what region of the screen was tapped on. Great! It worked flawlessly. Until I tried to use two touches at once.
Etc, etc... This is just one of a ton of examples.
Also, thanks for the interest in the game. :)