My project's plausability

Hi guys,

First off, love the community in this place. I'm on the verge of buying the full version because I know I'll need it eventually.

My project in most vagueness, is to make a huge Castlevania-type exploration RPG. It will not be stage-based, closest thing to compare it to would be Symphony of the Night. So I have a few questions regarding my project's plausability.

My main goal would be for the game to be played it on PC. As my plan is currently "Go big or go home," I need to know how I should start. I have sprites so far for one enemy and a main hero. They're roughly 25x50 pixels big, since I want this to look retro.

Question 1) Since the game will be large, should I keep my sprites small (roughly 25x50 pixels per frame) and load it into a large layout and set the view small and stretch it? How much will it affect my game's performance if I blow up the images by 400% to be roughly 100x200 per frame?

2) What takes up more computing power? Event Sheet actions or graphics? Should I focus more on minimizing graphics or on minimizing code?

3) I'm currently only using one event sheet. Is this wise for a large-scale project or will this eventually choke out the game?

4) I would LIKE to make this game multiplayer (just 2 players). I saw the "How Do I?" on it but I haven't dug terribly deep into it yet. I'm not asking how to do it, but on a scale of 1-10, How much extra work would I be creating for myself? Is it easier to make the Multiplayer content local only w/ game pads?

5) Obviously being a huge SOTN-type game w/ 3 difficulty levels, saving will be necessary. Again, I'm not asking how to on this one, just asking how much trouble I'd be making for myself? Scale of 1-10. I'm going to dive into this later, after I start up a few levels and start actually testing out the early stages of the game.

6) I've made a punch animation for my character, and I don't see a How Do I on what the best way to create a collision box for the punch to do damage to an enemy w/o making EVERY frame of my "Player" sprite hurt an enemy (yes, I'm using a "PlayerBox" sprite as well. In the full version I know there are families. Would the best thing to do be to create a family and have the fist in as its own object on that frame?

7) I saw a post about having bounding boxes for EVERY enemy, and how to get it to pick the nearest sprite box. I'm cool w/ doing this but... how much does this help with enemies?

Thank you guys so much ahead of time.

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!

... Also make sure to set the "Sampling" to "Point."

THAT's why it was blurry... I love you already! =D My scale's currently pixel-for-pixel, so I think I'm alright =)

<img src="http://i1267.photobucket.com/albums/jj553/Dominius2010/Hero.png" border="0" />

2) "Graphics."

Perfect, very good to know and I'm glad I decided to fit this in now! I just recently got my bounding boxes to grab the nearest mob sprite and set values for attack, HP, etc based on what's overlapping... I'm VERY happy with my results and it'll save LOADS of code.

3) "I use only 1 or 2 event sheets for bluekeygames.com/happiness.html, and it runs fine. "

Awesome. I'm trying to use one Event Sheet and organize it by groups. Sounds like it won't kill me to not use Layout Events so I'm going to try without, then if I have to pull things out later if I see speed issues I think I can do that w/ the power I saved in graphics. =D I'm VERY glad to know ab the order of event code though, so thanks a load for that! I'll check out Happiness after I submit this reply =D

4) "Multiplayer is tricky. "

Cripes I NEED this thing to work multiplayer... It's going to lose so much flash without it imo and I feel like if I start coding with that in mind from the beginning things may be better... I'll see what I can do.

5) "Array, JSON, Webstorage. Also the latest beta has Save/Load States."

So far I'm clueless but it sounds like once I dig into it there shouldn't be any issues. Hopefully by the time I'm done with the portion I'm working on the beta will be live =)

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

Awesome! Will the hitbox go away when that frame of attack is past or will I need to write in a Destroy code for the hitbox?

7) "Not entirely necessary anymore really, but still useful in some scenarios."

Yeah like I said above I think I have this figured out FINALLY. =DD Thanks though!

"I would highly suggest you don't do this as your first project. Start off small. "

I am, in essence. All I'm hoping to do with my game is to create a prototype to get people in on the project. The grand scheme is a giant game and I have all kinds of great ideas to implement to make it a killer new twist on an old successful theme.

What I'm looking for to begin with is 3 zones of my giant game. If this game I have in my head had a demo, what I'm currently looking to create IS said demo.

"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!"

<font size="5">THANK YOU!!!!!!!!!!!!!!!! <333333!!!</font>

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.