It's interesting that you bring up tiny touch points in particular being an issue. That's part of the impetus behind my rethinking the entirety of how a player will interact with the game. My other experiences writing mobile apps revealed that touch points centering over small, movable objects *can* work well, but are not ideal, especially on 3.5-4.8 inch screens (it's been less of an issue on tablets, as far as I can tell). The focus for my CSCI studies in college was actually UX, which I always loved deconstructing and analyzing. When I approached the design I was going to use for this game, the first thing I looked at was how to make sure all the touch points were as big as possible while still letting the player see what was going on (or putting hidden menus in places that made sense).

I agree that Knights of Pen and Paper actually does a good job in a lot of ways, and it's probably the closest existing game to what I want, but I still have other ideas for how I want this to work, and how to make the experience (at least, at a basic level) easier for players to use.

As far as game mechanics go, the only question I still have left to answer is what gets "spent" to use "powers." In my original mockup, those things cost HP to do, which works fine on paper and in tabletop playtesting, and even adds an extra level of suspense for the players (I hashed out the battle system by writing it as a tabletop with physical dice rolls first, which will eventually be replaced with a math.Random() analogue), but may not make players feel good in a video game environment. I find HP costs more "hardcore" than having a separate mana pool or similar mechanic, and in my mind are more fun as a resource management mechanic, but only time will tell if that translates as a positive player experience to video games.

Keep in mind, I don't think this'll be easy...very few projects regarding game design are legitimately easy. The tabletop I want to publish as an actual tabletop has taken months longer than I thought it would, but it's also much more complex than the base system I've rigged up for this on multiple levels, more than one of which stem from the nature of the game as modular and extensible...if the most complex thing I'll have to deal with is the programming, I think I have a decent shot at making this work, though an additional programmer would be a welcome addition to the team...

Thanks, you too. By metaphor do you mean a gameplay mechanics for the mobile?

So your system is for post apocalyptic rpg?

Yes, I mean how one controls the character or party's actions in-game.

And no, not post-apocalyptic.

Arima

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! :)

SamBeastie

TO be completely frank with you, 90% of your game sounds like the game I'm developing now. Even for the same mobile related reasons. Shocker. I guess I will have to come up with more new ideas now that will differentiate it from yours!

Hey, the more people trying to develop something better than an on-screen D-pad as a way of interacting with an RPG, the better. I honestly wish you the best of luck on that front...coming up with a metaphor I thought would work wasn't the easiest part of my work so far.

As others have told you, yes C2 can make rpgs. The reason you haven't seen many is because RPGs are quite complex, and I'm afraid I must disagree with megatronx on this one, they are quite hard to make due to what Aphrodite said - they have a ton of interlocking systems that all need to work smoothly together. They look simple from the outside (I thought one would be simple to make too. Years later, it still boggles my mind how long my rpg has taken - but then again I had almost no game making experience at all when I started on it), but general opinion from those why try to actually make them is that they're one of the most difficult genres around (unless you're using a tool that has a lot of those rpg systems in place already, like rpg maker).

Here's a video of the old construct classic version of my rpg (don't even start to consider using construct classic over C2 for an rpg. Trust me. There are reasons why I started over in C2 even after years of work - it's vastly superior and more stable than CC). The C2 version looks very similar to this, but the ui and stuff isn't done yet:

I came across that video when I was searching around for information on using C2 for RPGs, and while I commend how polished it looks, it is quite different on a number of levels from what I'm planning.

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.

When 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)?

If 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.

If it's the former...well, there's simply work to be done there, though it seems like C2 handles events in an elegant enough fashion that it's less of an issue here than it could be.

It's not hard, just time consuming. So you're making an rpg. That's really cool. Could you say more about yourself?

There's not much to tell. I have half a degree in computer science (a minor, back in college), so I'm no stranger to programming. I spend a lot of time playing video games, but I've spent equal amounts of time playing pen and paper RPGs, so I know how those game systems work very intimately. I started out making homebrew material for D&D 3.5/OGL, and spent a little time making a ground-up conversion for the same rule set. Most recently, I've moved my own original tabletop system into its final phase of development, and I'm hoping to have that published by Q2 2014, likely with ePubs, since I don't have the budget for artists or layout designers, and have little expertise in either of those fields. Not that it matters, since I'm designing it as an extensible and modular generic system that others can build materials for or make conversions of. Kind of like FATE Core or Apocalypse World is built and licensed.

For the video game RPG I'd like to make, I've designed what I think is a better way of interacting via touch screens, built a combat/stat system complete with leveling, items and powers that maintains simplicity, but still allows for multiple character builds (in a way I find more interesting than a standard skill tree).

I'm not new to gaming, nor to software development, but the marriage of the two is uncharted territory for me.

What exactly is it that makes RPGs hard? Is it combat mechanics? Programming? Dialogues?

So far, I have leveling, stat and battle mechanics already worked out, albeit on paper. As far as programming goes, this isn't my first rodeo there. The story is worked out pretty much entirely, so that's at the bottom of my list of concerns for the moment. As I said, I've been working with tabletop RPGs fairly extensively, so I'm familiar with how to build individual game systems, conceptually.

If it's something else, please let me know so I can start practicing that immediately. I know it's ambitious for a first video game, but my mission is to build the game(s?) that I want to play, but don't already exist. In my mind, at least, the world doesn't need another side scrolling platformer unless it brings something radically new to the table. I can't provide that, so I'm providing this.

Hey, all.

I'm new to the video game development scene (been developing for tabletop before this), and as I look for tools to help me get started, I stumbled across Construct.

Without getting too in depth, the game I want to make is essentially a turn-based RPG, but without character sprites to interact with a town. Basically when you "walk into a town," you're presented with a map with all of the locations in town, and you'd click/tap one to go to it. Similarly, with combat, everything would move in a classic Final Fantasy sort of way. Fight, Use an Item or Run type deal. Dungeons would be selected from a bounty board menu of sorts, and travel between hub areas would be accomplished through an overworld map.

Is C2 capable of making something like this? It seems that the tools are more geared toward action-oriented games, and I haven't found much through scraping through the tutorials, but I'm not afraid of a little extra programming here and there (put that CSCI minor to use, I guess...).

Thanks in advance for any help you guys can offer.