Use 1 base sprite, copy and paste. If you want different images, use either different frames or instance variables and different animations.

Set Sprite.Y to Sprite.Y + distance per second * dt

where dt is DeltaTime.

Working on an Action RPG myself. Different beasts in a some ways, but other ways they're similar. Might be easier to do a turnbased jRPG though.

1. Construct 2 can pull it off perfectly fine. Lots and lots of ways to do it, you just gotta find the implementation that works best for you. My tip would be get really familiar with arrays and object oriented approaches. That way you can minimize code but keep your engine flexible enough to add enemies, items, equipment, characters, etc... Everything can be accomplished in events for sure.

2. The product is geared towards anything you want, really. Action/platformers are just easier to pull off in a lot of ways. Most of the action games people make with it have very little if any RPG elements at all, because RPGs are a ton of work. That said, you'll find challenges either route you take. But it can pull off both just fine.

3. Using layouts for each map would be less system intensive. That said, depending upon how you optimize your game and how you setup your mechanics... the way you go about it doesn't really matter. What matters is the end result, what the player's experience will be.

Welcome to the community!

For my action RPG game I'm separating the event sheets as "GameSystems" for all the miscellaneous mechanics and functions, "PlayerControl" for spawning the party members and input, "UISystems" for controlling the message and HUD and menus, and "MOBSystems" to take care of mob animations and AI and combat formulas. I do an include on all of them in every layout's event sheet before anything else in the event sheet. Inside each of them are lots of different components to the game. Makes it all fairly easy to digest.

You have to tell the game to destroy the hitbox. Usually I make it auto destroy after about .5 seconds, or auto destroy on contact with the target. It literally is just another sprite... there are no real rules that say you have to do it one way or another. That's the beauty of Construct; any 2D game is possible, and even some "3D" ones. It's all just a bunch of simple tricks and nonsense.

It's definitely recommended to plan out a game with some sort of design document or at least some semblance of a blueprint. That way it can help keep you on track. Game development is pretty much 80% planning, 10% coding, and 672% debugging.

It's working fine for me.

I'm inclined to agree with R0J0hound on the ease of developing a turn based game... for someone who knows how to work with Construct. It can definitely be done, but I would agree with Arima in that you would be better off starting with something similar before tackling something big like that, at least to learn the ropes and get really familiar with Construct.

1) Old school retro games had 8x8 tiles or 16x16 tiles usually. In Super Mario Bros. 3 they were actually... 32x16? Maybe 24x16, can't remember now. Your best bet would be to follow that practice, so that you use less disk space. You can resize the sprites manually if you want, but I'd say just set the "Fullscreen in Browser" option to "scale" or maybe "letterbox scale". Also make sure to set the "Sampling" to "Point." These options can be found by clicking on the root project folder in the Projects tab.

2) Graphics. I believe Ashley actually went in depth explaining how you don't need to waste too much time trying to optimize your events, it's in one of the blog posts of yonder I think. The less space you can use with your graphics, the better.

3) I use only 1 or 2 event sheets for Happiness, and it runs fine. However, it might be better practice to utilize several event sheets more for organizational purposes. That said, events run from top to bottom in order so you'll want to be careful in that regard. Every event in the included Event Sheet 1 is going to run before every event in the included Event Sheet 2 which is going to run before every event in the layout's event sheet.

4) Multiplayer is tricky. There are a whole lot of ways you can go about this. It will definitely be easier to do a local multiplayer than online, but it's all relative. You'll want to keep in mind which player the camera follows, how the screen splits up, how you maintain 2 viewports or 1, etc... and those are just technical mechanics. Not even talking about gameplay stuff.

5) Array, JSON, Webstorage. Also the latest beta has Save/Load States. Probably some bugs with it, but that's why they call it beta. Not very difficult anymore no matter how you slice it though. You just need to understand how arrays work for the most part, and how to save arrays as JSON strings to web storage.

6) Create a separate sprite, a square one. You'll put it's visibility to invisible. You'll set up image points in your animations, and when you want a hit box just set up your events to spawn the hitbox sprite on that object's imagepoint.

7) Not entirely necessary anymore really, but still useful in some scenarios. You can actually easily set collision boxes in the sprite animations. However, for multiple player characters or for RPG games where you need multiple collisions per character, having separate bounding boxes can be very helpful.

I would highly suggest you don't do this as your first project. Start off small. Do some of the tutorials. I tried to do a full blown action RPG with a large world and I had this grand scope I was trying to accomplish... and I had no clue how to do it so nothing got done. After that, I decided to create Happiness as a small game to learn how to use Construct 2. I also made quick little tech demos, recreating some mechanics from Mario games and other things. I also got very familiar with a lot of array and database stuff and learned how to go with an Object Oriented and Class based approach for everything from music to characters to level design and inventories and so on and so forth...

The other reason to start small is so that you can actually finish a game. I'm not saying it has to be a quick arcade style game, but maybe a 10 stage platformer. Something simple.

There are a lot of good tutorials around here to help you learn as well. I highly advise taking advantage of them.

Anyway, hope at least some of that helped. Any other members feel free to correct me. Good luck in your endeavors! And welcome to the community!

This is really cool. Inspiring me to do something mode 7 style.

I couldn't play the sea one, but the ground one worked fine.

Awesome job.

Finally got around to making a trailer for "Happiness!"<img src="smileys/smiley4.gif" border="0" align="middle">

Why not global variables? Or better yet, an array! Dictionary object is not a bad choice either. A lot of good ways to do this.

Arrays

Dictionary

Point sampling is the one you want to use actually, if you're trying to get rid of the blur when scaling.

Then again, I know of plenty of adventure games that had action elements to it. To keep things from feeling too jarring though, you might want to consider making those points occur only when necessary, and maybe nix the "health bar" altogether. Make those sections either "instant death" or have a certain number of repeat tries where it is described how many shots you have left in that segment before meeting certain doom. What you should also do is make sure you either have checkpoints before each of those sections OR allow saving anywhere. That way it will decrease the frustration any players may have.

Also, make sure that the segments don't "sneak up" on the player: as Kyatric mentioned, adventure games are meant to be taken a bit slower with a bit more thought. Allow the player to take in the obstacle first before jumping into it, to think things through. If that's impossible for the scene, then make the solution to the action obstacle instantly recognizable.

Another way to make it feel less jarring in the "action" segments is to make sure the controls match with the controls from every other section of the game. If you swipe to move some curtains aside or swipe to wipe away cobwebs, maybe swipe to blow out a candle, then swiping to shoo attacking birds away would likely feel just as natural. If you're tapping the screen to throw a rock at a button earlier in the game, then later in the game if you're throwing a rock at a monster it's going to feel just as natural and feel like an extension rather than a completely different gameplay concept.

Just a few thoughts on the topic. Don't take my words as hard fast rules, they really are just suggestions.

Your images are broken.