gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Game Design > RPG design document - work with me here.

#157603 - AerosolSP - Tue May 27, 2008 1:33 am

Simply put, I want to make an RPG for the DS. See, I hate how RPGs like to rip you from the adventure field constantly and randomly to throw you into a battle screen. I hate how you have to sit there going through menus to do things. It's just slow. That's why I like the action RPG genre. So my RPG is action oriented. Here are some of the things that I'd like to have. I'll start off with my battle system.

The game will be from a behind-the-back perspective as opposed to an isometric one (like Quest 64). Movement is controlled with with the D-Pad, while the abxy buttons serve as simple commands like action, menu, etc. Run of the mill RPG fair as far as non-battle movement is concerned.

Battles are initiated with enemies teleporting into your immediate area to hassle you (unless they are important, story-related battles. In which case you'll see your enemy before hand, obviously). You can of course, keep going and ignore the enemy, in which case they'll either pursue you or disapp. ear again. But you can also engage the enemy. If you're in the vicinity of a recently spawned enemy, an icon will appear for you to tap on the bottom screen. This brings about the battle mode.

In battle, you use the D-Pad to move around, and you use the stylus to attack. Like I said in another thread, it's up to you to remember the commands for attacking. For example, with our sword guy (whom we'll call Knight), drawing vertically with the stylus results in a vertical slash, while drawing horizontally results in a horizontal slash. It's up to the player to experiment and see what kind of combos can be strung up. Specific special techniques can also be initiated by drawing a shape on the bottom screen with the L button held down (which doubles as a guard button if you aren't moving). Special Attack Points (Magic Points, whatever you want to call them) serve the same purpose as the do in most RPGs.

Other characters have other methods of attacking. While the Witch character has similar physical attacks to the Knight character, the gunman has something else altogether different. Instead of drawing lines on the bottom screen to attack enemies, you have to tap little targets arranged in two circles of six (like a six shot barrel), and the more accurate you tap the target, the more accurate his shot. The ninja character (for lack of a better word...she isn't really a ninja) who is more a support character, uses simple to learn gestures for moving about quickly so as to avoid damage. Side Note - I forgot to mention that one character cannot guard. The Gunman uses L for targetting (and thus, strafing around targets). I also want to take this time to mention that characters that don't have to manually target an enemy automatically target one. The player can switch targets by tapping them on a minimap, or hitting R.

You can have three (or four, I'm not entirely sure yet) partners in battle at a time, who the player must choose in the menu screen before travelling out to places where they know they'll get jumped! When in battle, their mugshots are arranged in a row on the bottom of the bottom screen (outside of the drawing area), and tapping a mugshot switches your control to that character. This can also be used outside of battles for solving puzzles.

Special attacks in this game aren't too expansive. For the Witch, she will learn offensive Fire, Ice, Electric, and Rock spells, 1 for each, that are simply upgraded the more it is used. The "Ninja" learns supportive Water, Wind, and Nature, and Earth spells (again, one for each) that are upgraded the more they are used. All other characters learn a few special attack techniques, some supportive, some offensive. This system is intended to simplify gameplay, much like Quest 64.

Levelling up is as it is in traditional RPGs. Killing enemies results in gaining EXP. The stats that characters have are as follows:

Strength: Brute strength for physical attacks.

Defense: Defense against purely physical attacks.

Magic Strength: Potency of all non-physical, magical attacks

Magic Defense: Defense against non-physical, magical attacks

Intelligence: Must be raised in order to learn new attacks

These stats can be raised with equipment and items, of course. But nothing complicated like that system from FFX. That was something crazy indeed.

The overworld is still undergoing development, but the basic structure will be like this. The world will be split up into countries, with each country having it's own capital, just like any other RPG. Nothing too crazy here, just keeping it simple. The architectural style of the first country (which I've been calling Blue Moon or Blaurmond for now) is based on medieval germany. Specifically, I've taken inspiration from a town called Rothenburg. Really pretty place.








So..I don't need a guru to tell me that this project will take alot of work. I've had this idea for a couple of years and I want to give it a shot now. I don't have art to show that I'm capable of low poly modelling (apart from an untextured Arwing model and an old, half finished model of Zero from the MMZ series), so I'm not asking for help right now. I cannot stress this enough. I am NOT asking for help, because I know I won't get it. I'm working on a village and the main city and when they are DONE, I'll ask for help specifically. Until then, all I want is information.

So talk to me folks. What kind of technical juice will a project like this need? Or do you need more information before you begin to tell me anything about the feasibility of this? I probably have it thought out somewhere in my head, just forgot to write it down here. So just ask me. Thanks for reading.
_________________
Uh oh, it's an oreo!

Last edited by AerosolSP on Tue May 27, 2008 5:54 pm; edited 1 time in total

#157606 - AerosolSP - Tue May 27, 2008 1:49 am

I just wanted to separate this from the colossus above, cause I just realized that I should think about left handed players and quickly scanned through my essay thing up there. You can switch the d-pad with the abxy for left-handed players (and swap L with R too) with no problems.
_________________
Uh oh, it's an oreo!

#157937 - sgeos - Mon Jun 02, 2008 6:07 am

Download a trial copy of RPG Maker for the PC if you do not have one already. Become familiar with the facilities in it. Any complete "RPG", whether it is an action RPG or menu driven will require these facilities. Professional shops use similar tools, but they are broken out so that a game can be made with a team of people.

When dealing with a large project, there are a couple kinds of documents that are useful- a short document that "sells" your project. This should list any key features that set this project apart from other. If you were to post this, it would be a long concise post that amounts to a description of what you want to do. Explanatory art is very useful here. (Pictures will have to be linked to.)

The other document is the spec. This is the complete specification of everything in the game, down to charge time, cost, usage flags, etc. These get very long, and are usually completed concurrently with development. Posting a sample of this information so that tech people can understand the project requirements would make sense, but detailed sections of the spec should be linked to.

I don't know how good the homebrew stylus drawing recognition is. It sound possible, although I would need to see some pictures to fully understand what you want to do.

It looks like you would need proprietary tools for the stylus attacks and a lot of art to pull this off. I think you would need a full size team and a lot of time for this project.

-Brendan

#169643 - Karatorian - Mon Jul 27, 2009 9:03 pm

Well, I'm not a DS coder, but have done a lot of coding for other platforms. So I'll offer what advice I can.

First off, on the design perspective, it sounds pretty good. As a hardcore RPG fan, it probably lacks the depth I'd crave (I liked FFX's sphere grid), but altogether it sounds like a solid idea.

However, one thing jumped out at me. You start by saying how you dislike being yanked into the battle engine by random encounters, but your solution doesn't sound a smooth as it could be. Two things stand out as wrong with your solution.

Firstly is the enemies teleporting in. Honestly, unless it's a naturally teleporting creature (like a blink dog in DnD), that's only slightly better than a traditional random encounter. The mosnters should be there, they shouldn't simply appear out of nowhere (unless that's their special power of course, in which case, they should use it in combat too...)

Secondly is tapping an icon to enter battle mode. I think this is a mistake. If I understand they direction you want to head with this, you shouldn't even really have a "battle mode." Battles and non battles should be nearly identical from a user perspective.

Think about Fallout 3, FFXII (to some extent), most of the modern MMOs (try Runescape, it's shallow, but free), or heck, even Zelda (perhaps one of the defining examples of the Action RPG genera, if a bit light on the RPG side). In these games, Zelda especially, there is no "battle mode" or it's all "battle mode", your choice.

From the sounds of what you've described so far, this sort of model would be perfect for your game. Of course, as you have some sort of targeting system in mind, one could basically say that if you have a target, you're in battle mode, but I don't think such a distinction needs to be made on a fundamental level.

What I suggest is that when a monster approches or is approched by the player (not suddenly just suddenly appears), nothing fundamental should change. The player then has to option to flee (using the same movement methods as "non-battle mode"), may target the enemy, or may do whatever else they could have done or been doing before it showed up. (Of course if they simply ignore it, things could go badly. On the other tentacle, that could be a strategy too. Perhaps some monsters only fight back.)

Some things might change in the background (such a switching the AI from wander around to fight, etc.), but the player shouldn't hardly notice.

I think "entering a battle" (which idealy wouldn't even exist), could be a lot smoother than you've designed it so far, which from your mini-manifesto at the top seems to be one of your priorities.

Now onto the technical stuff.

The way I see it, there's a lot going on here and so you should carefully focus your efforts to avoid getting yourself in over your head. It seems to me that the three big parts are going to be the engine, gesture recognition, and some sort of scripting system.

The engine is the most technically challenging part, but also where you're most likely to be able to use existing libraries to make your life easier. As engine means a lot of things, I guess I should be a little more specific. By engine, I mean rendering and physics, the sort of thing the pros buy from Id or Valve or somebody. I don't know what's availble, but if you can avoid writing your own, do so. (I'm assuming you're thinking 3d? If not, you'd be in a better position to write your own and some of this advice a little off.)

Once you've found or written a graphics engine, you'll need to setup an asset pipeline to load your levels, models, textures, etc. into the game. The less manual involovement the better. Idealy it'd be intergrated right into your build system, so you can just type "make" and everything happens automagically.

Speaking of level loading, you may want to look into open world concepts and continious loading (e.g. "no load screens"). While technically chanllenging (and I don't know how well the DS could do it), it seems to me that it would mesh well with what you've already proposed. Your opposition to random encounters and menu driven combat seems to me that the design is focused on making gameplay "smooth" (for lack of a better term), which it what makes me suggest it.

Unless the physics is already integrated with the rendering system, that will be one of the major tasks you have tackle. You've got to intergrate the basics like gravity and collision detection with your animation system (posibly involving kinematics) and, ultimately, with the game's logic code (but more about that later).

The next major subsytem you'll have to deal with is gesture recognition. While there are some docs on the web about it and even some code samples out there, it's still a bit of a dark art. The main thing with gestures is that it's all heuristics. A lot of programming is strictly defined algoritmically. Standard button code reading input code is strictly logical. Even basic stylus (or mouse) operations are pretty well defined. (Although not mistaking a sloppy double-click for a drag can be tricky.) But when you get into more complex motions things get fuzzy and ill defined.

For instance, you'll probably have to have code to answer fairly subjective questions, such as "Was that a curve, or an incomplete circle?", "Is this a sloppy circle or a sloppy back and forth?", or (I recently read about this in Game Developer), "What's the difference between a flick and a drag?" This is not the sort of thing you can look up in Knuth. It requires a lot of trial and error. You have to make it tight enough so that it doesn't just fire things off at random, but loose enough so that it's possible to use, even in the midst of a frantic battle.

What I suggest is developing your gesture recogntion software seperately at first. Ideally, write it as a well modularized library. Then you can write a very simple app to use for all the inevitable tweaking it's going to need. Something really basic that just reads the stylus input and displays what gesture it matches as.

Once that's working consistantly, then you should be able to hook your (hopefully) cleanly defined API into your game. Besides, if you make it a library, you can reuse it later without having to pry it out of the game code.

Finally is the subject of scripting. While of course it is possible to simply hardcode everything, and the core of the game mechanics will have to be, but scripting is really the way to go. RPGs can get very complex, and a scripting language of some sort can go a long way towards taming that complexity.

That said, you don't need to write the next Python or Perl. Of course, a full fledged language has it's advantages, but it's a lot of work and could eat up a lot of resources that are needed for other things. You could get by with simply a dialog system with a rich set of escape codes (such a support for variables and conditionals).

The above poster's suggestion to play around with RPG maker is a good one. While it's scripting language is really basic (all menu and dialog driven), it's rich enough to do some pretty amazing stuff (such as replacing the hardcoded battle engine with your own) and covers just about everything you need for a basic RPG. For something completly different, I suggest you check out QuakeC. It's (sorta) C like and a lot more powerful. Playing with it will also let you experiment with scripting a 3d enviroment.

On the technical end, I suggest you learn about bytecode (as used by Python et. al.) and threaded code (as used by Forth), as these are the two major methods of implementing scripting. I'd also suggest developing the first incarnation of your scripting system on the PC. While it may raise some issues with porting, being able to use printf and a full powered debuggers will be very useful.

While it may seem like overkill and the suggestion makes an already large project even larger, it could actually save you a lot of work in the long run. Basically, all scripting is is a way to call various bits of C code with proper arguments without having to write and compile more C code.

It can also help with stability. It's much better to have something like "Script Error in NPC 42" than a build that mysteriously crashes or, even worse, fails to build. Besides, do shouldn't really have to bust out the compiler to tweak random NPC A's dialog branching or the tiny details of subquest B. Especially once the project gets rolling and you start building a team. You can get a lot more done if your creative staff doesn't have to know C++ and the minutia of the game engine APIs.

That said, you don't necessarly have to roll your own. I don't know what's specifically availble, but I've heard Lua has been gaining a lot of traction in the game industry. It's small and easy to integrate and I would be very surprized if an ARM port didin't exist already. There could be others too.