• Content count

  • Joined

  • Last visited

Community Reputation

103 Neutral

About Arina

  • Rank
  1. Design the game completely before you actually start making it. That way it's harder for the project to actually fall apart, because even if team members don't contribute and/or leave, you'll still have the end goal of the game written down. That means that, yes, you'll be doing more writing in documents and having meetings with people before you actually start drawing anything or coding anything, but less time will be wasted overall once you get to the actual creation stage. 
  2. What else will i need to learn before i can make a rpg

    Honestly, even though I'm a newbie at this too, I found instead of going with the "what do I need to learn," mentality, I think you should design the game first, that way you know exactly what you have in mind. Let's say all of your characters in your RPG learn everything through straight up leveling, you won't need to know much about programming to actually make the game. Heck, you could hard code everything about the characters into the game simply because it's so simple (not that this is a bad thing). Until people know more about your game-- or you, yourself, we can't really recommend much to you. Well outside of "you should probably have things like switches, arrays, classes, functions, inheritance etc..." No one will be able to give you particularly useful advice that you might already know. The thing is, it's your game, so you have to figure out what you want to design it like.I know you said you wanted it like breath of death VII, but I'll give you an example of what I mean... Do you want portraits in your game? Or are you just going to use a text box for their name? Those are all things that you/we need to know before we can be useful.    I just finished designing the RPG I was working on, from the battle algorithms, to what should be happening in every scene. Now, I'm not asking "where do I start," I'm asking myself "how would I do this?" Which I feel I can search for the answers a lot easier. Of course, I'm more than happy to get recommendations from more experienced people, but at the very least, I feel considerably less overwhelmed. 
  3. What makes a good beat'em up game?

    What makes a good beat 'em up? Well, let's see:    1) Good controls. So you need a good format for them. Personally I'd go with about 7 buttons needed for a good modern day beat 'em up. I'll give you an example of them:  a) Punch b) Kick c) Block d) Jump e) Special  f) Grab - Nothing is worse in a beat 'em up where you accidentally grab when you meant to punch or kick. Intentional grabs are always good if you don't have a good system where you grab. SoR for instance has a good one, but say the classic Double Dragon? Not so much. This can also be used to stop the general confusion games have with attacking versus picking up a weapon. Now there can never be a moment where the player can attack the enemy  g) Back Attack - Because it's annoying to have it mapped on dual buttons.    The biggest thing that kills beat 'em ups for me is when you have limited controls and those are half the reason the game is hard.    For varied enemies, I'd say the big thing is to have something in mind for the enemies. For instance, take Streets of Rage, every enemy pretty much has some "specialty." Galza's throw you and do sliding tackles to knock you on the ground, Donovans are anti-aerial so jump attacks are less useful, ninjas land on their feet when you throw them and also have projectiles, boxers can block so throwing them is the best option against them... The biggest challenge is trying to exploit these patterns in various environments and various enemy formations. That's what makes it fun. The problem with so many beat em' ups is that the enemies you fight have no real rhyme or reason to how you fight them (or how they fight for that matter), so when you encounter another enemy you just approach it as a new punching bag.