Hey all you Text-Based RPG fans! Guess what?? I have created our very own message board for us to help, share and discuss Text-Based RPG related topics! The URL for the board is:

http://pluto.beseen.com/boardroom/v/59486/


Be sure to bookmark it!


Master Conjurer

I haven''t played text RPGs for awhile, but some of the ones I had the most fun were fairly simple. I refer to them as "Arena combat" games. Basically, you are a gladiator of sorts, and "train" in town. The town serves as a hub to all game functions -- training, resting, purchasing, etc... You can also venture out of towns for simple quests, which provide the story of the game. For example, once you venture out at a certain level, you may find a destroyed town or something. A few levels later, maybe you find the cyclops that destroyed it and have to slay him.

But yeah, consider that for a simple idea. Town hub, with focus on arena combat.

Hey, Mythril, you''re right, makeing towns and stuff is hard.

I''m new to C++, but here''s how I plan on doing it:




That''s my idea for actual input.

I''m just wondering if I should switch many of my int functions to voids, especially my Cls, which is now inline. Doesn''t it make sense, even if it is bad form? I think inlines should be void, shouldn''t they?

thx for the town code. i hear what you guys are saying, but my game, i think, is not gonna be town-based, its more like a journey, it has a definite ending, but wont be too terribly long at first. my main question is the structure. do you have like, a fight function, travel function, and so on, and if so, how do you tie it all together based on a plot? is it like: if this victory condition is met, go on to this quest, until you have finished the game? that is the only thing i can think of, but there might bet a more efficient way or something.
thx for feedback


Mythril

In my game, you walk around (different locations are described). You randomly encounter enemies, but you are told where bosses are, so you only fight when you''re ready. You will have the chance to run from battle. Battle will be turn-based. Everything is quest-based, you get quests from townsfolk. There will be many towns, which are like checkpoints. I''m thinking of incorporating something like Diablo 2''s waypoint system.

That''s basically how it''s gonna work.

In my game, you walk around (different locations are described). You randomly encounter enemies, but you are told where bosses are, so you only fight when you''re ready. You will have the chance to run from battle. Battle will be turn-based, but you don''t take equal turns fighting. The "battle interval" your character has determines how often you attack, and is affected by your agility rating. Everything is quest-based, you get quests from townsfolk. There will be many towns, which are like checkpoints. I''m thinking of incorporating something like Diablo 2''s waypoint system.

That''s basically how it''s gonna work.

on sabre''s proposal ya we could say that. oh wait it will compile. hmmm prolly should stick with just having his head =)


as for constructing the code. your avoiding the objected oriented features of C++. bad as in "haha flame you" no. continue with a procedural view as long as your comfortable. eventually though youll prolly eye some objected oriented style.

someone in another thread said "Text RPGs are incredibly hard have you read the zork code" zork was not the state of the art of programming a text rpg. i read the zork code. its quidescentual horrid program by todays standards the story itself is programed into the code. the constraints that zork had to deal with dont exist for the young text rpg''r anymore. Objets were an intellectual fad back then. its a shame there isnt a better commericial text rpg to base yourself on =/ also in the same thread someone said that text rpg''s were inherintly less extensible. crazy. if anything they are more extendable. so much of it could be put into data files and scripted. provided you dont code like darn zork.


at its heart the text rpg can still be modeled as a collection of objects. its just that the presentation layer has been changed considerably. key there is the scene waits for a trigger to paint its text on the screen. the trigger comes in the form of a key word prolly represented by token. some scenes have common triggers. this is nicely represented by a virtual hierarchry. where every scene is either a data filled instances of a common class or in special cases inherits from that class.

i mean lets say i have
class Scene such that it has a function that checks to see if it understands "what do i see" that could work. it would invoke See which could output the data of the scene. cept i dont like it. for one it has to know where to output.

i like class Player acting as an agent for the players input prior to class Scene getting it. Most things would resolve in player. Player would take the pointer to current scene and do outstream << current_scene->See(this /* so they can change what is presented based on player stats */);

current_scene could get a shot a any input that the Player agent couldnt figure out. current_scene->Parse_Input( unknown_input);
which in turn could give it to objects in the scene.

which is another way to view the scene and get reuse. a scene could have a description but also reusuable objects in that scene that paint their description in text form at the end of the "See". Dressers. Doors. Doors could be ornate or heavy or flimsy. they could be enumerated with ID#s.

so if player said "what do i see" then function in Player class would invoke outstream << current_scene->See(this);
and current_scene->see(this)
would move through its vector which would attach to the string its own object->see(this) outputing: #id: i am a closed large ornate chest.

so then the player could say "Open #id" which would invoke common code in that Player class such that it checked to see if there was an object in the scene with that #id and if it did it would pass it object->player_action(this, "Open"); ) so "you open the large chest but see nothing in side" doesnt have to be written 500 times in your code. Also note now that the resultant See function when called would be changed when this object writes out its message for the scene.

im not saying take all this in. or that this is best. what i am saying is that text rpgs are a good choice because there is more to how you can do them then zork did. sophistications that are even over what you have in a graphics game. potentially atleast.