Skip to main content ↑ ↓
Topic: Prototyping for an RPG Games (Read 91373 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Prototyping for an RPG Games

I read that the best way to make your first game(s) is to prototype, this means you strip everything down to the basic necessities that you need to make your game playable. For example for a platform game you would need to work on your physics script and have a few platforms and enemies to test it out then later you can add all that fancy double jumping, brick-smashing with your head stuff later. I realized that I am a serious victim of feature-creep-ism and the only cure is prototyping or spend a ridiculous amount of years working on an impossible game then ultimately committing social-cyber-suicide when people tell me how unplayable and ludicrous my game is. ::) Lets avoid all that drama.

So what are the most crucial and important mechanics of making a basic RPG or more specific Turn Based JRPG (Like Dragon Quest
and Final Fantasy)

I have one ( or at least I think so ):

The Battle System seems to be one of the main game-play mechanics that is crucial to every RPG becuase without a battle system there is no leveling up or stat improvements or quests or adventures or insanely annoying grind-marathons.

What else is in the general RPG rigmarole? Forget I  mentioned JRPG lets be more open and loose. What makes an RPG and RPG if you where to strip her down to her bare-essentials and get dirty  ;).

Re: Prototyping for an RPG Games

Reply #1 –
Let's see here:

1. Battle system.
2. Menu - Praty managenent.
2.1 Inventory
2.2 Equipment
2.3 Quests
3. Shops
4. Dialogue

And that's what I'd start with.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Prototyping for an RPG Games

Reply #2 –
I agree with Radnen, except I'd order it as such:

1. Party management
1.1 Stats
1.2 Equipment+Inventory
2. Menu systems
3. Battle system
4. Shops
5. Dialogue
6. Quests

Key differences between the two lists are splitting the menu development and party management development, doing inventory and equipment pretty much simultaneously, and doing party and menu long before the battle system.

Re: Prototyping for an RPG Games

Reply #3 –
Yeah I was thinking of doing the battle system first since that gives you an idea of all items/stats/abilities used by your game. Then the menus are just representations of those to screen, so they didn't come first for me.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Prototyping for an RPG Games

Reply #4 –
Yeah, everyone always says to do the battle system last, but if you're making a CRPG, that battle system is the centerpiece of the game--best to get it out if the way first so you have a foundation to build all the other mechanics around.  That's why I did the battle engine first in Specs, too.

Re: Prototyping for an RPG Games

Reply #5 –
I have a list of things you SHOULD NOT INCLUDE in your prototype:
>Custom Leveling Up System
>Day Night System
>Saving and Loading
>Random Dungeon generator
>Any visually rich graphics e.g cutscenes, facesets, battle backgrounds, gorgeous tiles and animations e.t.c
>Anything Pokemon (^_^)*joke*

I will work on the battle system first. I think It's better to start with the most used game mechanic then work your way outwards until you have something playable.
Like Radnen said the rest pretty much just displays whats already in code to the user via U-I menus and HUD's e.t.c. Also I have been eager to start making my battle system.
I actually worked on a UI before thinking about the code. At first I'm not including any graphics but here is what I want it to look like and flow.

Its very loosely based of the Mother battle system. I made two, one was too clustered but has more information for the player.
Anyway the last thing I should be thinking about is UI design but since I already made something might as well use it as a reference.

Explanation: For the Simple Ghost BS.png
>The top left box is for the party members graphic that has been hit or is issuing a command
>The other 4 boxes on the right are for the enemy sprites, the enemy attacking/hit will be in color/animated
>Below are two stat boxes with facesets to represent the characters/enemies
>The enemy stats are to the right and the player stats are to the left
>The stats belong to the enemy/player that is issuing a command or being attacked
>Below the stat boxes is the command box to issue a command to the player. I'm going to replace check with party
>Party will open up a party management UI where you can view detailed stats for your party members and select a member
>The selected member will be the one who issues the command, you then go back to the party members UI after the command
>Select a new member and then issue another command, this repeats until all ready members have been dealt with
>The turn will then commence
>The box in the bottom right is the text box and also the selection box (hence the scroll-buttons)
>Information about the battle goes here and information about selections such as items and spells go here as well

Apart from the Party management UI nothing will pop up out of nowhere or change position. I don't like how in Mother the message box goes up and down, also I think using graphics instead of lists of names is more user friendly since its quicker to
recognize something that way also with color/animation to emphasize this. By everything being fixed in place it should be very easy for the user to get used to the layout.

I think the UI is simple enough to understand intuitively or at least I hope so.

For now I'm going to do some reading the Battle System tutorials on the Sphere Wiki.

EDIT:the graphics are NOT mine.




Re: Prototyping for an RPG Games

Reply #6 –
Lookin' good! :D
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Prototyping for an RPG Games

Reply #7 –
Agree with Radnen.
Looking Great!

However, if my input is up for any consideration,
have some advice on stripping games down to their basics.
Been documenting my plans and progress alongside my current project,
and while development has been slow (personal issues, medical mostly),
it's been an amazing experience overall.

Unlike past projects which were quickly tossed out,
either because of stuck-in-a-rut development issues or my own jaded feelings about them.
I'm beginning to realize that if a project isn't well planned, or well thought out ahead of time
then that can make game development a severe hassle for newbie programmers like myself.
Also, it isn't just about planning, but how you carry out your development process too.

Quote
that battle system is the centerpiece of the game

That's not always true. Adventure RPGs that are dependent on seek and collect quests for one example,
are more dependent on items and a quest system than a battle system. Not only that, but battle systems
require other parts of games to be developed. A functioning Menu for Turn-based RPGs and
movement controls for Action RPGs.

It's imperative to note that while this plan doesn't work for me, it isn't the same for everybody.
Human beings are individually different in comparison to one and another, which means
working on the Battle System first may have an excellent outcome for you. It's definitely
a good step in the right direction when dealing with programming. It's of the most complicated
parts of game development and easily prepares you for the rest of your programming feats
as a new comer to scripting. The chronological order of my work is a bit different though.

. . .

[Development Order for Projects:]

When beginning a project it's important to realize what is most important feature for your game.
Some projects focus more on their artistic endeavor while other focus more on their gameplay systems.
Here's the order of development hierarchy I currently use for all project types:

1.) Graphics - while optional to sustain level of satisfactory quality, they're most important
as a presentation of the player's choices, actions, and in-game persons. Graphics are
possibly the most frustrating part of game development, as it's the most varying
and diverse part of almost any project, and can be the most development heavy (time-consuming).

You're job is to get graphics out of the way so you can focus on the actual significant part
of every game project which is the programming (graphics aren't what make a game a game).
To start out, only begin with basic sprites within a small enough time frame (two weeks - a month, tops)
my personal list includes: *Main Sprite *Flooring *One House *Basic Obstructions (like trees, rocks) *Battle Sprite (single sword, no animation)

Then after you finished a significant amount of coding, add in animations and the other necessary
artwork as required by the code, or optionally you can use a temporary placeholder and do the rest of the artwork last.
The basics though are an important first!

2.) Dialogue - everyone's first venture into programming usually ends up being 'Hello World!' And scripting a monologue
or textbox can be just that. Functioning as a way to extend one's understanding about how to draw things on screen,
it's a small, but necessary feature for most games, and gets your toe in the water for what comes next
logically in the development order.

3.) Menu System - operates using your knowledge of the textbox implementation and extends further into
a programmer's practice of optional and conditional statements, to give the player a system of choice.

4.) Movement

5.) Player Statistics

6.) Item Management

7.) Battle System

8.) Quest System

9.) Save and Load

10.) Extra

Eh, got tired halfway through (6am, up all night). But if there's any questions about the above,
and/or curious as to why the development order is arranged like so
I'd be very glad to answer whatever it is you may have for me.
Again, this is my personal outline that has been genuinely working so far.

Development fatigue is another thing I'd like to hit on though, but
possibly when I get some sleep first. :p

One thing I'm most impressed by your comment is that you seem to have the
Battle System for your game, mostly logically already thought out. This is a great
step forward and can personally say makes development a whole lot faster.
Congrats on the progress so far, and am hoping to see more in the near time ahead.

Re: Prototyping for an RPG Games

Reply #8 –
Thanks, I like to work backwards with an end in mind then figure the rest out along the way. although this gets me into trouble later.

I agree with Vakinox about the Dialog and Menu system coming first for newbies.I have a working text box and I did learn on how to position windows on screen (although through some trial and error) it paid off big time. Same with the grid movement system. I think Battle System/Party Manegment System first is good for more experienced scripters who can just jump right in the pool and already know how to swim.

I have assessed myself and on how I want to tackle this.
>Basic Dialogue and 4-way Grid-Movement System ( finished )
>Menu Systems (Basic command interface like in Dragon Quest, only Talk,Search and Door)
>Battle System and Stats
>Party Management
>Shops
>Equipment + Inventory
>Advanced NPC's / Quests
>Save and Load
>Other simple features that I would like e.g Day-Night System

Learning Menus will help me use that knowledge for battle sytems
Making the battle system will help me plan out character classes and equipment e.t.c
Making the Shop first will help me create all the items first before worrying about managing them in menu driven database
The rest after are for a more complete RPG prototype

Saving and Loading is underestimated but its still important I think, RPG's need this unlike arcade/platform games
your rasing a character so its pointless if all your efforts are lost each time you play.


I took some time off before-hand to play a lot of old NES RPG's and observe their mechanics. I noticed how compared to more modern games a lot of the game-play is incredibly simple but impacting. I was too caught up with features that I had forgotten something as obvious as this  The fact is that I should stop comparing myself to other big-games like even NES/SNES ones like Chronos Trigger, FF-series e.t.c. All video-games are in-fact a chronological series of ideas that where built upon, the first version is always the simplest then you get sequels that just build around the initial game even more (at least good squeals).
I think its been about 4-5 years since I started trying to make games, up till now all of them had to be canceled or put on forced hiatus or maybe I just got distracted with a new game idea. Development fatigue is a serious issue, it takes drive and a lot of gusto to push yourself and work on those parts you hate e.g the art if your not a great artist or coding something new (might mean taking time off to learn first which is always a hard pill to swallow). Although I say you still learn from all those failed attempts. Nothing is a waste of time as long as you did it with purpose. Its so important to remember where video games came from. Its getting harder by the day with a lot of noise from established games and vanity (we all want to make our dream game). Without early prototypes like Pong, Mario or Final Fantasy we would have nothing. In-fact Prototyping is probably the most important part of making a game (besides finishing it) its about getting that spark first, I think with a good prototype you wont have to worry about game fatigue (you tell me).

Re: Prototyping for an RPG Games

Reply #9 –
Quote
Development fatigue is a serious issue,
it takes drive to push yourself and work on those parts you hate
(e.g) the art if your not a great artist or programming if coding something new.
Although I say you still learn from all those failed attempts.
Nothing is a waste of time.

Its so important to remember where video games came from.
Its getting harder by the day with a lot of noise from established games and vanity (we all want to make our dream game).
Prototyping is probably the most important part of making a game (besides finishing it) its about getting that spark first,
I think with a good prototype you wont have to worry about game fatigue (you tell me).



[Developer's Fatigue:]

Alot of what you said is true, but not necessarily all the time.
A good outline-plan (prototype) benefits the developer immensely so,
I agree but it isn't always the judging factor of development fatigue.

It can come from many places actually,
depending so much on the development process,
and how you go about working on your game/project.

. . .

Some of the things you went over, such as
no failed project is a failed product. It's always imperative to
pick up and learn from mistakes and errors, as it improves yourself for the next
project that comes along. Thus time is never wasted, like rollover minutes.

As for pre-established vanity from existing modern games and
creating your own dream game, I agree that it's important to recognize
your own abilities and the time frame in which you can accomplish something.
For example, it's important to note that Sphere is 2D Rpgs and you shouldn't
attempt to try and make the next Call of Duty out of it. Though neither should
you attempt to create the next Final Fantasy VI on your first go around either. 

Depending on the challenge level of the project being developed, you could
easily find yourself becoming anxious at the heavy amount of programming
that'll be needed, or cursing yourself at the skill level that would be required.

For those incidents, I like to look at this chart:

[Logic One:] The higher your skill level and the lower the challenge, the more ease of development and progress.
[Logic Two:] The lower your skill level the higher the challenge, the more difficult it is to accomplish.

. . .

For myself, these are the Top 5 issues that come
about with causing development fatigue:

1.) Familiarize the Language - reading comprehension is a must. You wouldn't try establishing independence from a ruling foreign country if you didn't know their language, neither should you attempt to break into the indie gaming industry scripting in a language that seems entirely foreign to you. The importance here is practice, as it's the only way to develop reading comprehension. Especially if programming is a new thing to you, even Javascript can seem as an overcomplicated language to most infant eyes. Once you're able to read Javascript, and logically deduct what is happening in a script written by another person, then you're ready to go out on your own and swim without your floaty's.

2.) Entertainment - it's always important you pick the right project that motivates you in interest. Something that will feel like an accomplishment every time a piece of it is finished, and will drive you to complete more of it. Goals are another important factor in this, but it's important to make sure the goals are in small increments from each other. Too much range from one goal to another will cause either boredom or frustration, and too small of a range in goals will feel like you're not accomplishing much of anything (due to the lack of challenge, refer to chart's "apathy"). It's a great deal of importance to recognize that most of what we're doing here is hobby, something to do in our free time. Once your spend too much time 'pushing' yourself and the project becomes a chore, then procrastination or frustration sets in. Remember to keep that enthusiasm rejuvenated!

3.) Feedback - pair programming or having someone to look over your shoulder and criticize your work is important factor also. If there's no audience but yourself, then the feel of accomplishment is short lived and is unpropelled by an outside source. This is why communities like Spherical shine through for me, because they're not only there to help and support, but eager to see your work as well. There's nothing better than another opinion to hurdle you over roadblocks and to apply teaching or discipline when needed.

4.) Productivity & Procrastination - again, this is where goals and having an outline helps. It also has to do with the size of the project. If it too much or takes too long to accomplish even the minor goals of the project, then becoming bored becomes perfectly natural for anyone. The way I personally deal with productivity is to complete atleast one function or one system everyday. If you've done that, no need to push yourself and be happy with what you have done for that day. Never overwork yourself, because again, once a hobby becomes a chore it's no longer a hobby. It's a bore.

5.) Brevity & Breaks - always keep the project fresh in your mind, like a girlfriend you take out on the weekends but never have to live with. It's important to keep a distance. Once you start living with her, you begin to hone in on each other's flaws and imperfections, then onsets a negative attitude towards it. How I deal with this personally is everytime I become a bit bored or don't feel like coding anymore, I go outside and exercise or skateboard. When I come back inside, my head is clear and I'm ready to code again. Sometimes I'll simply just pace around the house while I think about what is there next to do programming wise, or try to get some artistic visualization of an image or scene in my head. Take a breather, it's important.

I've noticed taking breaks are probably the most beneficial when programming, in my opinion,
because every time I've quit for awhile I've always came back with a better or more familar approach
to scripting and creating projects in general. It's as if your brain subtlety learns how to perform better
when it has a minute to think about what it has done and accomplished so far.

. . .

Also note, that with Battle Systems even the most simple of ones require graphics first,
such as a font for text and windowstyle for boxes. So Battle Systems need dialogue
and Menu Systems developed before anything else, especially for Turn Based systems.
The way my Development Order Hierarchy works is by completing the things first which
will be needed in the next functions and systems to come along in the programming.

Of all that was listed, only Text (dialogue), Graphics, and Statistics (objects, player, and items)
are independent in comparison to the other things in programming, and should normally come before them.
The hierarchy is organized so that when you finish one thing, you can move onto another without being
overcomplicated by the amount of things needed to do to accomplish/complete what it is that you're working on.
There's also lessons to be learned in programming the things that come before the other, so there's a sense
of progression in difficulty within the organization of the hierarchy as it was being created.
Such as: Learning how to implement choices and conditionals before working on things like Tile Movement.

Note again, recognize that Battle Systems and Movement are the two most problematic parts in most projects,
reason because you'll always be going back to rework something into them until the project is finished.
Most things like initiating functions during collision detection will have to be worked into the movement as
work is being developed on an action battle system, for example.

Apologies for the late reply also, slept in late and didn't wake till about midnight.
Have a feeling it's going to be a loooong Monday. And anyone feel free to use this information to be adapted into a tutorial if you wish.
I'm thinking about making some, but it's going to be awhile before I'm able to with most of my time focused on my project still and all.
 

Re: Prototyping for an RPG Games

Reply #10 –
Absolutely, I feel just focusing on small things day by day helps with more relaxing development than trying to make something huge at once which creates more anxiety and frustration when it doesn't go well (and even if it does you lose a lot of motivation).

I think this is a good thread/future tutorial for newbies especially that info on Development Fatigue ( thanks for the breakdown Vakinox ) a lot of the time you can get discouraged with the sharp learning curve sphere has not only that but game development in general is not as easy as most of us probably thought BUT with managing your fatigue level (making sure you're hobby is not a chore and pacing yourself) I think even the most intimidated newbie can find that its still possible to make the game of your dreams...although you do have to realize your skill level and take it step by step.

Whenever you reach a high challenge level and break it down into smaller challenges you begin to see how you never really have to force yourself or get anxious. Eventually everything will come into place.
Recently I've found programming to be really enjoyable, even though challenging at times. Before I was terrified to code anything in Sphere for a while, it all seemed very intimidating but I would mostly thank the community here that helps when you're having doubts. You guys are awesome!

Re: Prototyping for an RPG Games

Reply #11 –
Hmm, when I look back on the things that make me stop it's not the coding or the I don't know how parts, it's the legwork!

I'm at the point where I can code basically anything, but what I don't do easily is create maps and sprites, that stuff takes a lot of time. Attack animations for the player, each enemy, maps that look weathered, interesting. Tiles that animate, move, look coherent. It takes a lot of time. That's usually where I stop. Blockman is a project of mine that I've been working on for years now and not many maps have been made. However a lot of code has indeed been produced.

It's gotten to a point where not much more code later I can have a complete game - if only I mapped the rest out and made the stories/cutscenes.

Then I get sidetracked, with other games, an editor and now a new engine implementation. :P
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Prototyping for an RPG Games

Reply #12 –
What I do when it comes to graphics is just use some ripped ones from games with a graphics style that I like/ can learn from then later heavily tweak them or make my own. Not sure if that could help you but I think you're lucky. programming is probably the most challenging part for me, graphics are just tedious and take a lot of care and a good eye (pixel by pixel). I guess each has its ups and downs. I'm biased though.

Re: Prototyping for an RPG Games

Reply #13 –
Quote from: Xenso – on

Not sure if that could help you but I think you're lucky. programming is probably the most challenging part for me,


Well you'll learn with time. :) I used to suck really bad at programming, but once you start realizing the larger picture as you write code, smaller things get easier to visualize. A battle system is a daunting task, but if you break it up into smaller pieces and see where each piece fits in it gets a whole lot easier. It also helps to mimic your favorite battle system since it gives you a design without having to make a design. I think this is chiefly the reason why Lord English can write a battle system as complex so fast... But then again he might be using the pen and paper to write things out as well.

Pro tip: Sometimes to program something well, write it out what you are trying to do on paper.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Prototyping for an RPG Games

Reply #14 –
Quote from: Radnen – on

I think this is chiefly the reason why Lord English can write a battle system as complex so fast... But then again he might be using the pen and paper to write things out as well.


Using the FFX system as a basis definitely helped, but the biggest productivity gain for me came from the fact that I programmed about 75% of the battle engine using only console output and a menu strip before I even touched anything UI-related.  This allowed me to quickly prototype the various components (skills, statuses, etc.) and test them without needing to have a UI for them.  In fact I still have it set up so I can still enable the text console at any time to try out something new or diagnose bugs.