RPG problem

Started by
1 comment, last by Cruel666 22 years, 10 months ago
Hello, i need some help plz. Here is the problem : i would like to code a RPG but i really have no idea how to put all the ''story'' in a file. Each monster will have a file, each item, each NPC ... but i dont know how to put in a file what is open and when .... cya all
Advertisement
You should really try to post more information on your circumstances. For example, what language are you programming in? How much programming knowledge do you have?

If you''re working with C, MSDN (Microsoft Developers Network) has some information on file load/save routines, just do a search on ''fopen'', ''fclose'', ''fread'', ''fwrite'', etc. Other important functions will be linked from each of those pages.

If you''re working with C++, it''s best to pick up a C++ book and read up on STDIO, the standard input/output library, using file streams ''ifstream'' and ''ofstream''

Anything else, and I can''t help ya.

===============================================
It''s either ether or the other,
I press my window to the glass,
the glass turns to gas...
I''m going upstairs now, to turn my mind off...
to turn my mind off...
This is my signature. There are many like it, but this one is mine. My signature is my best friend. It is my life. I must master it as I must master my life. My signature, without me, is useless. Without my signature, I am useless.
Well, I''ve never done this specifically (all the RPGs I''ve worked on have been multiplayer games without a real "story"), I can offer some advice, and a description of how I would do it off the top of my head. Bear in mind that this might be a really awkward way to do it once you get started, I''m not sure.

First off, I''d layout my story, breaking it down into various steps that you progress through from the start to the finish. For a linear story, this might just be a straight line from start to finish with no "options", or it might look more like a tree with branches that split off then rejoin the main branch later, or go off to their own totally separate endings. Then I''d give each of the "nodes" in the story a number, and keep track of that number with the other player data. If a certain creature will only talk to you after you''ve finished event #53, but not after you''ve done #67, you can just check the player status to see if its between 53 and 67, and do your thing. These would be for the main branch(es) only, if you have lots of optional subquests, I''d probably store them in a bitfield -- 0 means you haven''t done that particular quest, 1 means you have. That way you can easily check to see if the player has completed a given quest and act accordingly.

The main "guts" of the story would be a script of some sort. You might make your own scripting language to use in the game, or you might use an existing language that was built for that purpose, or allows you to embed it in the main code of the game. Guile (a dialect of scheme, which itself is a derivative of lisp) was designed specifically to be used as a scripting engine for programs written in other languages. Python can do this as well, as can several others I can''t think of right now. Its up to you which road you take, although bear in mind that you''ll need to link in and distribute the scripting engine with your game, because that''s not the player''s responsibility, so make sure that you can (legally) do that with the language you choose. This is one reason why it might be preferable to write your own.

As for the actual contents of the scripts, it''s up to you. You might use an interpreted scripting language, or write one that compiles down into bytecode with operations specific to your game. The script would have commands such as move to a new position, attack something, give an item to someone, or anything else that your creatures or items need to know how to do. There are several tutorials on the site here that detail how to write your own scripting language, so that would be a good starting point.

One thing I''d do, however, is keep the "story" and the "engine" as distinct as possible. Everything to do with your story (or, at least as much as possible) should be isolated from the main engine. This way, you can reuse your engine with a new story, maybe after improving it a bit. So, IMHO, everything that deals with what creatures, items, or whatever are, where they are, when they''re there, and how they act with the players belongs in the scripts, not in the main game code. You''d read the important bits of the script file(s) according to some "super-script" that is the overlord of the whole game [ie. player just completed event #30, now this previously blocked area is now open, so read the affected area''s scripts and get ready for the player to be
able to go there].

If you''re using interpreted scripts, you might want to run your script file(s) through some basic obfuscation routines so the players can''t peek at how the game acts to cheat that way, if you are actually concerned about cheating (if its just a single-player game, then they aren''t causing any harm). Just a simple XOR encryption will probably be enough. It''ll convince anyone who is just browsing that breaking it is "too hard" but will fall apart under any real cracking attempts, but you can''t do much to stop that, no matter how hard you try.

Whew, that was longer than I expected. Hope it helps.

This topic is closed to new replies.

Advertisement