Sign in to follow this  

RPG Woes

This topic is 4843 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

After a few (read: way too many) failed attempts, I have decided to seek the wisdom of the experts, you. I am writing an RPG and was wondering what the best way to handle NPC's in a world would be. I thought that I could store an identifier in the XML file along with the location of the NPC and read these when I load the level, placing a new instance of that class in an array of NPC's and other "interactive" objects found in the world. It justs seems like there could be a better way. Thats why i'm here. Another question I have is after getting said NPC's into the game, how do I control the storyline through these NPC's. Obciously a scripting language of some kind would be key here, but i'm not sure how to go about it. Any ideas would be great. Thanks in advance, Ion

Share this post


Link to post
Share on other sites
document everything...

document how every function works... and map your program... loops if and all... draw them up on paper with lines... as if you were drawing an electrical circut


your map save files dont need to be all one file... break it down into many files, one to store tile data... one to store scripting data, one to store npc data... then load a file that builds the map

ie:
1 Load Tiles
2 Load Npc Stats
3 build npcs
4 load all the scripting data
....

just break everything down into as many pieces as you can and document it all as you do it. if you can visualy see the function of the program you can easily determin errors... the less duplicate code the better
those are my thoughts...

Share this post


Link to post
Share on other sites
Quote:
Original post by IonDefender
(...)Another question I have is after getting said NPC's into the game, how do I control the storyline through these NPC's. Obciously a scripting language of some kind would be key here, but i'm not sure how to go about it. Any ideas would be great.

Are you going to make a Japanese-style RPG or a western-style RPG? A'la Final Fantasy? A'la Baldur's Gate? A'la Fallout? A'la Ultima?

In fact, with a script language you can control the storyline of almost every type of actual RPG. Imagine that you have one or more script programs attached with every NPC, and every script program has a certain purpose (activate when talking, activate every X minutes, activate following an schedule...). When your avatar interacts with the NPC, the script program runs, changing the context and content of the world.

As an example: The king wants you to rescue his daughter. This could be the script of the king that shows how he behaves everytime you talk with him:


if (is_dead(DAUGHTER_OF_KING))
{
if (killer(DAUGHTER_OF_KING, AVATAR))
{
speak(KING,"My daughter is dead... and you dare to come??? Guards! Kill him!");
hostile(ALL_MAP);
}
exit;
}
if (flag(QUEST_DAUGHTER,2))
exit; // The daughter is in her room, rescued
if (flag(QUEST_DAUGHTER,0))
{
// the king is in grief...
speak(KING,"Please save my daughter!!!");
exit;
}
// NOTE: set_flag(QUEST_DAUGHTER,1) when you rescue the daughter
if (flag(QUEST_DAUGHTER,1))
{
// happy!!
speak(KING,"Thanks for saving my daugther! Get anything you want from my treasure!");
set_flag(QUEST_DAUGHTER,2);
set_flag(OPEN_TREASURE_CHAMBER_KING,1);
exit;
}





... as you can see, some internal flags (and the behavior of the world) are changed, and those flags symbolizes an advance in the storyline.

You should check http://www.avernum.com and download the shareware version of "Blades of Avernum" along with the map editor - you can take a look at how scripts are managed in the final version of a game. You can also check the tutorials on my website (see my signature), maybe any of them are useful to you.

Share this post


Link to post
Share on other sites
This is why you have "failed attempts".

So, you're writing an RPG. RPGs make for some of the biggest gooball programs. You want to have a gazillion races to play, classes to play, skills to learn, quests to do, items to find, monsters to fight, areas to explore, spells to learn, doors to find or unlock or bash open, traps to spring or disarm, and on top of it all a compellingly unforgetable story with richly developed NPC in a totally immersive world with the latest graphics and sound technolgy.

I'd say you've set your sights a little bit high.

If you want to see what kind of work it takes to make a complex RPG, go and study the nethack/angband/rogue/moria source code (it is out there). Then think about all of the stuff that you want to do that goes above and beyond the functionality of nethack/angband/rogue/moria.

A little discouraging, isn't it?

Not at all. As I said earlier, you simply set your sights too high. To fix this, set them a little lower, a little more realistically.





Share this post


Link to post
Share on other sites
TANSTAFFL is dead on,

RPG games are increadibly hard to make, especially for one person.

Take for instance, our game, Morning's Wrath, It has been in development for three years and is almost done, and we have a team of seven people.

So, it is possible, but you need some hardcore motivation, a good idea, and the right skills in order to acomplish making a 'good' RPG.

Before starting the MW team, I had already completed 1 and 1/2 Adventure games (2D static background puzzle type games), which are large 'gooballs' aswell. But they were not quite as hard as my current project. So if you havent already made a few games, I would recomend you take your ideal game. and then come up with two or three more ideas in increasingly easy levels of difficulty to make, and then complete those, one by one, chances are you wont want to do these smaller 'lesser' games, but doing them will greatly increase your chances of succeeding in subsequent and more complex games.

If you still decide to take the hard road, and decide you are going to make a great RPG, then prepare for a very long road ahead, I will now list my experience from gamer to game developer below, it might give you an idea of a road to take.

1995 - Gamer, decided I wanted to make games
1996 - Started creating animated movies for my game ideas
1997 - Used hyperstudio to create lots of unfinished games
1998 - Began using visual basic to make games
1999 - Finished my first adventure game
2000 - Discontinued work on the second adventure game
2000 - Switched to Isometric game programming
2001 - Began work on the Flare 2.0 C++ game engine(isometric conversion)
2001 - Preliminary work on Morning's Wrath began
2002 - Flare reaches version 3.0 and is considered, feature complete
2003 - The MW game shell is half way done
2004 - 5 team members added, to bring us to a team of 7
2004 - Morning's Wrath phase1(feature complete demo) completed
2004 - Morning's Wrath phase2(pre-battle gameplay) completed
2004 - Morning's Wrath phase3(full map making) in progress

And that is where we are now =D

Hope that gives you some insight=)

[Edited by - EDI on September 13, 2004 1:42:17 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by EDI
RPG games are increadibly hard to make, especially for one person.(...)
I will now list my experience from gamer to game developer below, it might give you an idea of a road to take.


I'm going to describe also my experience (from gamer to "lame" game developer :-P), since i have been working (solo) on my RPG from the start. And both TANSTAFFL & EDI are right, if you are going to make an RPG, prepare to keep on working a looooot of time...

1995: Start working on an RPG. No design, just ideas in mind.
1996: Finished an engine in text mode.
1997: Discovered how to make graphics. First attempt into making a graphics engine.
1998: Start second "graphics" attempt. Scroll. Items. Menus.
1999: Fights. Script engine.
2000: Finally i'm able to make something "playable". However, I had "no" design behind, so cannot introduce some basic concepts. Trash everything.
2001=>2003: Design of the final game architecture. In mind: to make an 10hr RPG (less monsters, less mapmaking, less everything).
2003=>2004: Codify game architecture. Playable. Still a long way to do (two or three years more...).

Hope also that gives you some insight ^_-.

Share this post


Link to post
Share on other sites
I'm going to share the basic design of a game I now and again spend time working on:

First, a little background...

Over fifteen years ago, I got a computer for xmas. It was a TRS-80 Color Computer 2, and it booted to BASIC. I had a cassette deck for saving/loading programs that I wrote.

One of the first games I wrote was called "Doorways". Essentially, this was an "RPG", albeit a very simple one. You were in a room with ten doors. You picked a door, and would face whatever was on the other side. You were then in a new room, with different doors, and you went again.

In the earliest version, there weren't even hitpoints. You had a 50% chance of killing the monster, and it had a 50% chance of killing you. Later, hitpoints were added (called "health" and not hitpoints), and a number of items were added: gold pieces, spells(not a particular spell, just spells), potions, electroshields(don't even ask), weapons, and finally different types of monsters. In latter days, keys, traps, chests, etc were added. Typically goals were "kill 6 dragons" and such nonsense.

Doorways has been written for TRS80, Atari800, IBM PCjr, Tandy 1000 EX. Over the years it has advanced, and has been inspired by a number of different other games.

One game was dungeon of daggorath, a game for the TRS80. Mostly, the inspiration came for the text input. I suppose another bit of inspiration came from the zork like games of the time. Another inspiration came from nethack and similar games, and the use of ASCII screens to represent rooms visually.

One sort of "spin off" of doorways was a dungeon editing tool. You could name rooms, doors, traps, items, monsters, etc, and put them all together into different little mini adventures. This was still a text based game, but it was a lot of fun to make, a lot of fun to make adventures with, and a lot of fun to play.

And this is the sort of game I like to work on, but it does have its gooballishness. Of late, I have been looking at two different versions I want to make of this game. One is a version for Cybiko, which perhaps a total of 10 people on the planet earth would play. The other is a web based version using ASP and talking to an MS Access database. Naturally, these would still be text/dialog/menu based games.

Personally, I'm now leaning more towards the web based version. The hard part of the game is deciding where to put the limits. For example, I allow various types of portals/doors to be named. Pretty much any sort of transition from one area (room) to another is a portal. But now, what directions are portals allowed to go in? Sure, north south east west, but what about up/down? And how about a portal named "hut entrance" and a direction called "in". Whoops, now I need a way to specify direction names. Now do I want to make the doors difficult to open(i.e. stuck)? If so, how does the player check to see if he can open them? Oh, I guess I'll need a skill system/attribute system.

And then, of course, the act of playing an adventure changes it, as monsters are killed off and items are picked up. How does one handle that?

Blah. It gets incredibly complex, rather quickly. Better to keep it simple.

Share this post


Link to post
Share on other sites
Heh heh.

Pretty much every game I've ever made or attempted to make has been a gooball. A very large, very sticky, very gloppy gooball. With stuff sticking out of it, and all sorts of nasty dripping things oozing around.

Good article there, TANSTAAFL.

Share this post


Link to post
Share on other sites
Wow. Thanks a ton for all that insight guys. I have have convinced myself that this project will take along time, but I'm hoping that with enough motivation from friends and some awesome help from you guys I will be able to get close to realizing my dream.

I guess the theme to this thread has been "KISS" ("Keep It Simple Stupid"). I know that "gooballs" are my worst enemy. I started a development notebook today and I plan on keeping all of my ideas, plans, and designs in that ONE notebook, not spread out over 5 that I randomly lose and stumble upon later.

I started a scripting system today. It is fairly simple but its not done yet, so I thought I would run it by you guys to see what you think. I know there are some gaps, but hang in there. Here goes.

My scripting system will consist of several blocks of scripting that are run at the apppropriate time. I.E. the <On_Activate> block is run upon the activation of the quest. Simple enough. In these blocks you will be able to display text, give players items or money, warp them, unlock portals (used to move players between "regions", which are just loaded from an XML file), and anything else that I find necessary later (as I PLAN, not CODE :D). There are 4 blocks right now, as follows:

<On_Activate> - Runs when the quest is activated and the appropriate NPC is activated (talked to).
<On_Return> - Runs when the player has returned to the NPC AFTER getting the quest but BEFORE completing it.
<On_Completed> - Obviously this block is run when the player has all the requirements for the quest and has returned to the NPC.
<Requirements> - Run right after the <On_Activate> block is run, this block will describe the requirements for the quest (I.E. Bring back 5 dragons's fangs to prove you have defeated 5 dragons)

This system has lots of flaws but I hope to iron them out soon.

Of course I thought of this before reading rrc2soft's idea, which I like much better. It seems much more dynamic. Dynamic, in most cases, is good. Unless it turns into a gooball, then it's just nasty. :P


Anyways, thanks alot for all your advice and I'm looking forward to your replies.

Ion

Share this post


Link to post
Share on other sites
Glad we have helped so far :-D

Since you bring up scripting, and I am very proud of the scripting engine I wrote for Flare, I'll just take a few seconds to let you know how I implemented a scripting.

So, the scripting language used for flare is called 'Magic C' it is a mix of PHP and C.


Each script is a text file, which contains one or more 'Entry Points' these are like functions that are called when a script is run.


Main()
{

}

OnMouseClick()
{

}



etc.

When you want to run a script you simply do,

game.RunScript("scriptfile.script","EntryPointName");


A MagicC script might look somthing like this...


Main()
{
$globalvar="Magic C, woo!";
c=100;
i=0;
str="";
while(i<c)
{
str=str+"wow!\n";
i=i+1;
}
Trace(str);
}




The three main things to know about my scripting language is that is that...

- $ indicates a variable is global and can be referenced between multiple scripts (all other variables die after the entry point returns
- variables are implicit, you dont need to predefine them
- variables are dynamicly typed, and can be either numbers or strings, the variables change type automaticly through implicit casts or assignments.

Magic C supports the major flow control functions:
if,else,switch,case,break,continue,while,return

and it supports compound conditions with boolean operators:
==,&&,||,!=,>=,<=,>,<

and it also supports arithmatic operators(no compounds =/)
+,-,*,/,%

The Flare implementation of Magic C, runs it with the ability to use 'latent functions', in a virtual multi-proccess enviorment, basicly this means that there can be 500 scripts running at once, most of which waiting in limbo for a latent function (function that happens in more than one frame, like walking) to be freed up by an event.

Obviously the hardest part about the scripting language was actualy implementing it.

Magic C scripts are interpreted and complied down to an instruction object model, and are cached (important for speed in scripts that are used over and over), this data is saved in a Script object. When the engine is required to run a script, it spawns a ScriptProccess object, attaches the script to it, sets the execution 'cursor' to the specified entrypoint, and then begins to execute. The script executor examines the compiled instructions and runs them through thier respective proccesor states to make the code do what it was meant to do.

All function calls like...

woot=KillEvilGuy("whatever");

get pased to the custom script handler of the game object, the game programmer subclasses this function to make extensions to the script's function set.

The script function handler gives you the ability to read all of the passed arguments, query if they are present, and query thier type, It also gives you the ability to push back a return value which is set inside of the variable 'woot' in this case. Also all passed arguments are assumed to be passed by refrence, this means that if i passed the variable '$str' instead of "whatever", it would allow the function handler to not only read, but change the value of $str, making it possible for functions to have multiple outputs, not just the single return variable.

Some functions are intrinsic, for instance...

Trace("text"); throws a messagebox
Wait(nms); makes this script yeild to the game and wait until n milliseconds have elapsed.
Beep(); a message beep
RunScript("scriptfile","entrypoint"); spawn another proccess with a new script (the calling script waits for the other script to continue, or yeild).


Once a script is done executing, it's proccess object is destroyed.


Hopefully this will give you some ideas as to what kind of functionality is helpful in an RPG. Magic C is _very_ general in that it could be used in almost any kind of game, you might opt for a more specialized aproach, in which it would be easier to build the system.

If you need any more information let me know :-D


P.S. Below is a script from Morning's Wrath,
A fine example of basic NPC interaction using Magic C

OnLoad()
{
$gnumtalk1=0;
}

OnMouseClick()
{
switch($gnumtalk1)
{
case 0:
SpriteLookAtSprite($lpmorning,$lpgsoldier1);
Talk("Hail, Princess Morning.","",true);
$gnumtalk1=$gnumtalk+1;
break;
case 1:
SpriteLookAtSprite($lpmorning,$lpgsoldier1);
Talk("My family has served Castle Iridine for many generations.","",true);
$gnumtalk1=$gnumtalk+1;
break;
case 2:
SpriteLookAtSprite($lpmorning,$lpgsoldier1);
Talk("We trace our service as far back as the Ashidian war.","",true);
break;
}
}


Share this post


Link to post
Share on other sites
Wow, some great advice is in here. Just out of curiousity, how long do your "failed RPG attempts" stay in development for? I'm on my first RPG, first ever game right now (see sig) but I'm just doing it for fun. I can't say whether its a crystal or a goo ball right now (can it be both?), but the project is 3 months old and stronger than ever before. I've got about 4 years of programming experience in multiple languages and creating a wide range of applications, but I quickly came to realize that game programming is in a category of its own.

To anyone that has completed or almost completed a successful RPG, do you have any tips regarding the actual design process itself? I think my game has been mediocre with its design so far, but that was mostly my fault due to a lack of experience with programming games. Thanks for any advice you can give. :)

Share this post


Link to post
Share on other sites
Thanks for the speedy response!

I really like Magic C and grats on creating it, it seems like a very solid and well thought out system.

While I would love to use it, I think that porting it over into VB .Net may prove to be difficult. I would also like the satisfaction (and experience) of writing my own system. I will definitely keep Magic C in mind as I plan out my system. My biggest obstacle, as you said, will be implementing it. Any thoughts or pointers on that topic would be greatly appreciated.

I feel selfish asking all these questions but with all these excellent responses, how could you not?

Looking forward to anything else you feel inclined to bless me with.

Ion

EDIT: Roots, my attempts only stayed in development for about a month. Not all of them where RPG's, but its the same for all my games. I dream too big and don't plan enough. I have to learn to live with that fact that i'm not going to make a commercial quality game after my first go. I have plenty of time in my life to get things right and make a game i'm proud of. You seem to have been blessed with an a talented team, and from my experience those are pretty rare to come across. I learn alot after each attempt (I guess their not failures after all, are they?) and I feel strong enough about this game that I am retrying it, in hopes that I can make it a little farther this time. Anyways, enough rambling. I think i answered your questions a few chaptes ago so i'm off now!

Share this post


Link to post
Share on other sites
For tutorials on script-engine making, you can take a look at PxdScript, made by peroxide. You can also check the tutorials here in gamedev.
Quote:
Original post by IonDefender
(...)I would also like the satisfaction (and experience) of writing my own system.

Keep in mind this tradeoff: learning Vs finishing your game. If you try to learn while making your game, then be prepared to push the deadlines a "few" times.

Share this post


Link to post
Share on other sites
I am victim of the dream too big plan too little disease as well. Also victim of the play too much code too little disease. Heh.

Anyway, I finally decided to focus my goal on producing a workable RPG with the complexity of Ultima I. I'm actually "cloning" it in a general sort of way, so I can have side by side comparisons of the actual real working (and still fun!) game versus my own look alike. I'm incorporating a few minor differences of course, but nothing drastic until I get everything functioning like the original.

After a few weeks I've almost finished character creation. Full time job, wife, two kids with one on the way doesn't help in the finding time to code department. Consequently I get a couple of hours a day, or every other day, if that.

But the concept of Keep It Simple Stupid will go a long way for us hobby programmers, I believe. I think it cannot be overemphasized that there is a great need to constrain yourself to a limited subset of your "Dream Game" so you'll actually be able to finish. And getting something simple working is so much more important, I think, than planning on getting something complex.

Take care, and awesome thread!

Share this post


Link to post
Share on other sites
Speaking as someone who has completed my own engine, I would advise you to use an an engine that has already been written. Check out Spiderweb Software's games. They have their own map editors. If you can write a good game using his engine that people are prepared to buy, then you're on your way. I'm sure he would work something out with you if you made an awesome game.

Its one thing to write a good engine. However it is another thing entirely to make fun and addictive games that people will fork out money for.

I'm still learning the latter. :)

Share this post


Link to post
Share on other sites

This topic is 4843 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this