In an RPG series if a record of the history was kept. ie. what happened when you played previous games in the series.
This way when you're chating to an npc about what happened in a previous game, they would know it was the character you used in that game, which saved the world.
Whether or not you completed certain quests in a previous game, may affect the current game.
This would increase the feel of them being part of a series, not just a number of seperate stories set in the same world.

Shining Force III for Sega Saturn kinda did that (I think).

Yeah Chris it does...

I had an idea similar to that... but on a different scale.

Like a group of us Allegro programs joined together to make an engine. Then we'd make our own projects using the engine. But have cross things. Like one Axis to link all the games together. Like a character or something. And certain things'd cross over.

Is that you ment Thanatos?

Sounds like CrossGen comics ...

Actually, I thought a good idea would be creating an RPG engine, then making it a serial game, so there was no sequel or Game Over; just continuous chapters. Being an X-Men comics fan, this naturally appeals to me greatly. And of course actions taken in earlier games have an effect on later chapters. Troy had a good idea too, but we'd have to have a strong central world, and maybe an overseer to make sure no one's stories conflict or anything ...

quote:..just continuous chapters.. Whoa, that's basically exactly what I was thinking when I just posted a message in this thread a minute ago.. http://www.allegro.cc/ubb-bin/ultimatebb.cgi?ubb=get_topic&f=5&t=000168 .
-Steve
"Your arms get shorter, your pockets get deeper."

Well my idea isn't something you can "finish"; the first chapter wouldn't even amount to a whole game. It would be just like a comic book; about 5 - 10 hours of gameplay each chapter, with a new one every month. This was based off of what I heard console game makers were going to do a year ago; hand out the free engine, first chapter is free too, every chapter after that is 5 bucks or so. That's my idea anyway; who knows if I'll ever do it.

Wow, that's not a bad idea at all, chris. Of course I'd go all free. My work ain't good enough to spend cash on! heh

Heh, I kinda had the same thing in mind.

But it'd be a series of unrelated stories(Seemingly?)

Hell I'd love to buddy up with anyone to create a RPG with Allegro.

I'm sitting here all week just writing out stories.

Nice idea! Teaming up with other RPG developers would be great too.

This sounds great! I would love to help out on something like this; it might be a better chance to get something finished for a change . Maybe we could discuss - peterhull90@hotmail.com

Pete

[ January 23, 2002: Message edited by: achil ]

How about letting the game evolve on itself ?
Instead of providing a story line, make the NPCs react according to a some 'purpose', so as that the story line evolves while the game is played.
For example, an RPG party want to conquer a piece of land. The current owners of this land, the NPCs, will react according to what the player does : if he tries to conquer the land, then the NPCs will react accordingly(organizing an army, assigning roles to them, fight, getting injured, die, etc).
A mechanism could also be built (ala COM) that gives access to a game's internals (characters and their attributes, locations, etc) so as that new characters can join in at a later time.

Thanatos: your idea is what I've been thinking about doing with my RPG WOG. Then I just decided to make sequels that start by showing the last battle in the previous game in an animation sequence and then letting you continue on with the story. I may do your idea in another RPG later down the road though .

hmm, I quite like this idea.

One cool way of linking them together might be to have a game map, and each module would add an area to the game. Each new area would have new things to explore do and see.

heh the player could download the areas they think look interesting and do them in any order.. or work on one area.. then get another area, and work on it.. then maybe go back and complete the first.. all with the same characters.

It would be neat if I could create my town of Hull and 'inject' it into the universe, and someone else could make the city of Troy (these 2 names chosen at random ) so both would appear on the map and be explorable. Furthermore items, NPCs, etc. originally from Hull could end up in Troy, and vice-versa
I am not suggesting a real-time online game but one where every computer has its own copy of the universe, but it could synchronise via something like e-mail (or download from a web-site) For example, you could chalk up messages on a board in a bar and others could read them later.
What do you think?
Pete

Hm.. I think I would get boered with downloading the newest version all the time... It would prove hard to upload it all the time to. I would rather go for a once a week update, where players could send in their completely new quests trough e-mail ,and have them implemented in the game. It would have been cool to have an world of maps, missions etc etc that the players made themself. The limitations could be almost unlimited, with size as the only limit. Of course, it would have been difficult to make all the maps and quests fit together, but the creator of the game could Do some work there. Like adding the NPC's, including the new maps etc. etc.

I like the idea of an on-going community RPG, with a modular map.
A moderator would have to add pieces into the main game. What style should the RPG be in?
My three thoughts (in favored for this project order):
Zelda Style
Shining-Force Stlye
Final Fantasy Style
...
...
...
Point Click Garbage Style (booo!)

Zelda or Final Fantasy. Probably Zelda.

I like the idea of the town creator being "mayor". Say there's a plot centered around the town of Troy, but of course some traveling is involved. If Troy needs an NPC of his in Hull, he can contact the mayor and ask if he can move in. Some requirements may be necessary ("No pets, no loud music, can't live in town square because it would interfere with a plot in progress ..."). If someone could write up a design doc to get this thing off the ground, I'd be interested. Some good possibilities here

Ultima roxor.

I like these ideas very much, I think white_door's idea with different areas linked together seems very good!!
I'd suggest everyone uses their own engine and tools etc. but use a common file for crossover (which in practice is your savefile)
let's say person_1 makes a game/area called "Looming desert - The battle for the black oil"
person_2 makes "Escape from Azhora dungeon"
There would be a main exe for all the projects called: "main.exe"
and let's say the savefile is called "JohnDoe.sav"
so in order for the prog main.exe to open a certain area it would simply call the program:
looming_desert/looming_desert.exe JohnDoe.sav
thus passing only the preset info in the savefile.
Let's say the person goes to another area then that program would in turn call
../Azhora/Azhora.exe Johndoe.sav
then terminate

Some grand h4xx0ring potential there.

I don't know what h4xx0ring means but the rest of the ideas sound good!

Having different EXEs would solve some problems but does that mean the look and feel would change between diffenrent areas?

Maybe a lib or DLL could be used for the common stuff.

Pete

Djgpp DXE system could be used! For separated quest modules. This could add new monsters behavior and new items. What a text cannot (if it's not a script). My advise is that a DXE is quicker than scripts! And nobody use them!

Daniel,
Could you confirm what those 3 look like. I'm thinking:
zelda: top-down 2d (like KQ on the allegro depot)
s-f: isometric 3d (like The Legend of Jou)
ff: perspective 3d (like ?? Mookies Quest??)
Is this right?
What's your opinion on platform, resolution, bpp, language (C/C++) and what could be a good name for it?
Pete
[edit. corrected omissions]
[ February 05, 2002: Message edited by: Pete Hull ]

godcells, DJGPP could NOT be used!
Djgpp should be painted dark green and thrown into the swamp.
IMO, the best way would be to create a common exe and fileformats, and use a scripting language like lua instead. dynamic linking isn't portable, so it's kinda against what allegro stands for.

quote:jhuuskon wrote:
IMO, the best way would be to create a common exe and fileformats, and use a scripting language like lua instead. dynamic linking isn't portable, so it's kinda against what allegro stands for.

What's wrong with static linking? Methinks writing shared code as a library and building it with a C compiler instead of a scripting language is better because all of the scripted stuff doesn't need to waste all of that processor time and memory with an interpreter. The only problems I see is that it:

Requires the code be written following all of the portable standards that Allegro itself is,
Requires the user to have a complete install of the compiler, Allegro, and the standard build,
Requires more programming ability to debug than an interpreter,
Requires more patience to get all the previous junk to work.

Isn't that how Allegro itself is built?
BTW: This post is only HALF serious. I just happen to think a compiler would be better suited to realtime game code than an interpreted scripting language. I just wish there was a better standard than C.
[ February 12, 2002: Message edited by: SamuraiCrow ]

why do we need to use a scripting language or dynamic linking?
When we could use the further above idea of having just one file for the player as a crossover file
then everyone can make contribute to the project as they see fit, with no version conflicts etc.
create a standard for the file and voila!

also, if everyone would share their sourcecode, the interface and graphics could be done consistant as well..
everyone would be looking at the other projects for guidelines

Funklord, You are forgetting the fact that if you want the project to have an audience larger than the RPG-fans of allegro.cc you'll need to supply precompiled win32-binaries.

Extrapolating this thought, one comes to the conclusion that with content written in some scripting language, the expansion code gets smaller, and user-expandability increases as the lower level code doesn't clog the user's view of the actual content.

Besides, the lua interpreter's few kilos of overhead, when compared to the bulky 900 kilobytes of alleg40.dll, feels like no burden at all.

If Lua was good enough for LucasArts (they used it in Grim Fandango), it'll damn sure be good enough for us, too.

SamuraiCrow, Expanding is easier when you already have a system that runs and you can build on that, (like you have the house built up but it lacks paint and interior) as opposed to your proposition where the construction material is assembled partially, but you still had to build the house yourself. I can tell you from experience, it's really frustrating.

Of course this limits your possibilities a bit, but only in a way that assures some level of continuity in the feel and appearance of the 'series'.

jhuuskon: That is exactly what I mean.. you can use/mix any platforms u want using my method
Namely what I said earlier:
commandlines and crossover files
each exe calls the next with arguments and then terminates.

I understand your point, but i'm too tired to make an argument. However, i will try.

The problem with your approach is that every game will be different. Not a bad thing necessarily, but more likely. Take the X-com series for example. If we disregard TFTD which was a blatant ripoff by 'Prose, all of the games in the series are completely different. Many people will agree with me that the sequels don't feel as good as the first one because it was so good and fresh in ideas.

There's not really a series similar to my idea. I'll have to use all the half-life mods as an example. Let's take counter-strike. Everyone knows what CS is like. Then, another mod, Team Fortress. More of deathmatch feel into it, but focuses on teamwork. The Opera is something completely different, but from the first second you notice that it's a half-life mod. By now you should have gotten my point.

It comes down to Xcom-like series vs. Half-life mod-like series.

It comes down to matters of taste.

Good night now, important enlish test tomorrow.

I have had some more thoughts on this, and put together some code to implement 'property sheets'. A property sheet is just a collection of named attributes of an object. You can store them in a file (Allegro packfile) and also just save the changes. So a collection of sheets could represent all the objects in a game, and saving the changes to them would save the total state of the game.
code:
/* for example */
obj_set(man, "name", "Fred");
obj_set_int(man, "gold", 100);
if (obj_get_int(man, "health", 0) <=0) {
die();
}

Because it would be inefficient to access properties by name (e.g. (x,y) coordinates of a moving object), there is a facility to copy properties out to a C structure, then copy them back for saving.
code:
obj_sync(man, SYNC_OUT);

The implementation does not put any special meaning on any of the properties, so different parts of a game are free to set properties of an object for whatever they see fit, in the same way that a web-site can set cookies in your browser.
So, a property sheet can be the common save format that Funklord proposes, or it could be used to add new objects to a single, monolithic game.
Furthermore, the property sheet turns out to be very close to what LUA calls a table, so adding LUA scripting should be fairly straightforward (imagine a property called 'script' that has the file-name of a script to run). You could even have a property 'dll' to link to a dll which etends the behaviour, though there are more complications to this.
I've put together a sample app, which would explain in more detail. It's a toy RPG with a world map, and a couple of sub-maps. The program scans the directory for property sheets, so adding a new sub-map to the world map, or adding an npc, or adding an item, is as easy as adding a file to the directory. The program then builds the map structure at run-time. Ultimately it should be able to look inside subdirectories and DATfiles, so all the resources for a particular object (e.g. a map and all the objects on it) could be kept together.
If this sounds interesting, please email me on peterhull90@hotmail.com and I will send you the code.
Cheers
Pete
ps. jhuuskon good luck in the test!

That sounds good. Very good indeed. It's got the best of both sides. Funklords approach, with user extendability. I like it a lot.
P.S. The test was blah, not a test actually. One could say more of a pre-test evaluation. The teacher presented us with a series of excercises, and then evaluated the results, commenting on what should be improved etc..
P.S. I got the results of the English listening comprehension test. 29 of 30 correct in multiple choice questions, and 5/5 in the 'open' questions (open means you have to write down your answer).
I'm just afraid what the Swedish listening comprehension test's results will be..

I've posted my stuff on the web http://www.geocities.com/peterhull90/Dynamic_RPG_Game.html

Pete

Hmm... I am not sure if you have realized, but the way you explained things to work is the basic of, in example, LPC, a C-like language to write MUDs (MultiUser D* -it has so many different meanings...-).

The scripting engine I am actually testing (MoSaM: Masters of Sword and Magic) uses that knowledge for objects, but it is written in C++ (until now, 2.3 MB shudder) and is divided into five main engines (combat, magic, item, quest and map).

However, the development (actually almost a year under DOS, plus another year under Linux) has been almost stopped since I am right now far from my studio grumble

If you want more help about what you are trying to get done, try looking for LPC, or in http://genesis.cs.chalmers.se you can download a snapshot of the library being used in Genesis (the Mud I play). You can also download docs about it, to get more ideas. You can also check for www.circlemud.org, which though it is not a language, it is an engine which comes with source and can help you too.

RB

Yes,I think it is something like a MUD but without the online bit.
It's still a neat idea to have these linked episodes that everyone can contribute to, but all the enthuasim seems to have gone! Is anyone still interesting in giving it a go?

Pete

The ultimate RPG would be one where the world you are in is like a real world - not just a platform to play out a story.

The world would have its own economy and politics etc. - the game play would come from modular downloadable quests that can be plugged in to the world - or they could just explore the incredibly detailed world they were in.

eg. - you download a quest where the king needs you to go and fight some nasty beast but a)you arent the only adventurer he calls on to do it and b)he will quite happily have you executed if you go around murdering civilians.

I'd be interested in participating, but I lack the knowhow to get it off the ground. If someone is willing to do all the work to make a setup where people can interact and contribute with a minimum of effort, then it could happen, but who's gonna do all the work?

Cool; quotes work 8)

Yes, I guess SourceForge seems a nice place to store the project. I would also help, just notify everyone when the setup has been done. If you want to be a leader, you must act as one wink

RB

Yep that definitely makes for a great game idea:D. Unfortunately I've been busy working my job now so I may not be able to ever get in on a game idea that involves multiple Allegro programmers:(.

Just noticed that I have to reset all my information. My sig and everything:(.

Also how do I change from vgdes2000 to another public nickname without using my real name(sorry to be off-topic with this question)? I've got more questions so I'll put them into the Allegro.cc forums.

Go to the top of the screen, click My Profile->General. Leave the "First Name" spot blank and put your nickname in the "Last Name" space.

If it's not just going to be me... I can try and set up a sourceforge page - but how is everyone on using CVS? I think you need this to use sourceforge.

Any ideas for a project name, though?

Pete

[edit: getting to grips with that mockup]

Hey! (warning, looooong and innecessary post)

I remember something about a project... Aeon I think, which started here as well, and tried to become a library independant full RPG engine, but it has not had important enhancements since that day (try looking Aeon in Sourceforge). If you don't start working right now, it will become just another dream.

So, until now we have...
1) It is a RPG engine that supports "chapters"
2) It is free

SCRIPTING

Well, as far as I know, ALL commercial games produced are not compiled, but scripted. And when a new release is done, they just modify some of the engine abilities. SeeR can be discarded, since it is not completely platform independant. RUBY might not be worth, since it is mostly used to write standalone scripts. LUA is an option.

The problem is actually building the engine. It is tedious, indeed. However, I think BISON can help us here if we don't want to lose too much time in writing it. Remember that this is a project to learn (and who knows? if it becomes a good one we can get some $$$

A scripting engine is slow? Yes, they are slower, but remember: it is much slower the input/output routine. A scripting engine can be debugged much easier, and will allow players just to download the compiled script rather than having to download the whole executable.

I go for the scripting engine. Take a sheet of paper, and write down functions and variables you think it might need to support.

LANGUAGE AND PLATFORM

Hmm... C or C++? I myself feel much more confortable using C++, but it can be discussed. And remember, C++ is a superset of C, so after learning C it is very easy to understand C++ (at least the basic to work with -- I myself started with C++, which made the learning a bit slower, but finally worked I would like, as Allegro, the engine to be independant. That means we must
write a good engine which reads scripts, and not load dinamically modules (which can be done under Linux, Windows and DOS-32, but who knows under Mac?). I much prefer working under DOS or Linux: I am really used to the black screen with white letters Call me a BBS boy

MODULARITY

We must divide the engine into several sections: sfx, gfx, maps, combat, user input, character handling, item, quest, etc. That will allow us to start with the easy sections (gfx: defining sprite sizes; input: those with joystick can start writing a wrapper for it; etc).

Well, those were some thoughts I had about this project. When I started mine, I first wrote everything I wanted the engine to do, and then wrote some scripts I wished it to understand. Here is the newest I compiled (except for the free() function, because I haven't finished the quest engine).

(EDITED: deleted the code, since it messed up the board shrug).

RB

On flipcode is a good tutorial on making scripting languages...

I've used the tutorial on flipcode to write a very simple scripting language for a game engine of mine (the engine is almost finished, but i've had no graphics to show it off with). I know my scripting engine is not the most efficient thing in the world, but it makes development INCREDIBLY easy. After writing that, i couldn't imagine hard-coding all of the objects. I would definitely use a scripting language of some sort in this project, as it gives the module developers greater flexibility with what they can create. Here's a good quote i found in my research:

“It seems he had created a puzzle script, where the user hits a switch on the wall causing the water level in the room to rise, carrying the player along to the top of the room. It seemed simple, except we had just recently decided not to support moving water levels in the game. no one, including those who had worked on the engine and the language, could figure out how he did it.”
-Robert Huebner, senior programmer at LucasArts Entertainment.

This sounds like an interesting project. My advice to those who undertake it: design it out at length. Figgure out how everything will work and work together before you code. I learned at my last job that design is crucial.

Just my $.02

Oh, yeah, it is rather easy to write a scripting engine, but if you want an optimized one, you must develop it with a lot of beta testing. That is why I prefer BISON or YACC.

And yes, design is important. But there must be a brainstorm and someone who actually merges all those ideas. And until now, we only have the storm done.

RB

I am still really interested in doing something on this. I have asked SourceForge for a new project. Once it's set up I hope you will join me and we can produce a plan, stories, etc. In the meantime I recommend you get an SF username if you haven't already.

Cheers,
Pete

======
Furthermore I think that c++ would be the best language to use (I can't face writing another load of linked-list code) but writing your own scripting language is difficult so I'd recommend using LUA; it's already stable and optimised. Writing parsers in flex/bison is a project all in itself!

That's not true at all. There are plenty of commercial games written purely in C/C++. Don't let the Unreal's and so forth make you think that everybody is just writing scripting engines to games. Some people are, but not everybody.

How is it easier to debug a scripting engine? In order to guarentee that some horrible convergance of scripts doesn't cause a crash or other unexpected events, you would literally have to test out every possible script. In fact, I think scripts make debugging harder. The first step in debugging is localization of the error. If you have scripts, then you have to wonder if the script code is causing the problem or if the bug is in the engine.

Also, players will have to download game data, not just new scripts.

You need to spend more time modularizing your engine. Sound effects, for instance, is in two parts: sound effects and music. Graphics can easily be broken into tilemaps, sprites, fonts, and your GUI.

I've been working on RPGs for about a year now (and soon need a break ) and I can add some experience:

First, a scripting language makes it easier to debug. Since there usually is nothing to debug! Scripts are usually dead simple and you either:
1. Make parse errors
2. Do completely logical errors
They will never crasch as a script in C would do since you won't mess with malloc and crap manually.

My current engine doesn't use it but my next will use a homemade language called SwampScript (will write a lib for it later). It uses queues and triggers to work on a frame-by-frame basis. This is needed if you want scripts that are as flexible as FF5+ and don't feel like coding to death. If you want specs for the lang, just tell me.

About DJGPP DXE: The format sucks. Don't use it. If you go with modules this way (which I don't recomend), use .so's and .dll's instead. Also avoid messing with multiple .exe's. All kinds of binary messing will make porting and usage harder.

About NPC-NPC interaction; only one game has been insane enough to do this, Outcast, and it's doing some pretty simple stuff. If you want something serious, bring in the AI professor from the local University it's NOT simple stuff.

If you're looking for a game serie that refers back, check out Phantasy Star 1-4. Really great stuff.

Edit: s/th/ll

Unreal? Hmm... I have never played it. The last game I bought was Heroes of Might and Magic III. So, I am not talking "from" Unreal, I am talking before it. Starcraft, Warcraft, Heroes... they all use scripting engine. Even ID has its own standard engine (that is why all ID games look so similar laugh). A game completely written in C++? Hmm... Maybe you disunderstood me... if you write starcraft without a scripting engine, the executable would be 12MB. And I am talking about: 1) AI, 2) Maps, 3) Dialogs, etc.

The problem is that you are actually thinking about writing your own scripting engine from scratch. And if it is your first engine, of course it would have hidden bugs. But if you use bison, and you actually know what to do (I, in example, had to write a scripting engine for a virus simulator essay, so I am not a novice there).

And about Johan NPC-NPC interaction: Yes, it is TERRIBLE to write that kind of stuff. Also, they would do much sense with a strategic game rather than a role playing one (when to attack a country, when to develop the walls, etc).

You all know my C++ devotion. At first, I wanted my engine to handle each tile as a different object. So, a 320x240 screen with 16x16 tiles does a 20x15 tile screen. So, my engine handled at least 20*15=300 objects at the same time (AT LEAST, since NPC, items, houses, etc were different objects as well). In example, suppose a field with only grass. I have on screen 300 grass tiles (which are in fact two or three different, but they are all repeated). However, I created 300 GRASS object, and set each of them into their own position. This way, I was able to handle multiple actions independantly of the grass tile. If the character lighted a torch, a fire broke up and so each object which was fired modified its own tile to burnt grass. Each object was able to hold a hidden treasure, which had to be scavenged in order to get it. A wall, in example, could be destroyed using magic, each magic ball hitting the wall deleting the target BRICK object.

oops Gone from the idea. Back: writing classes for a C++ engine allows you to design the different interfaces of all classes, make them "work in paper", and then start writing each class, knowing that, if you stick to the interface, you are sure it will work.

As a suggestion, I write here a simple CHARACTER class (stripped from my own version), from which both players and real NPC inherit.

(Edited: I give up, the board messes the code!)
RB

Warcraft, for one, does not use a scripting engine of any kind. You can't do anything close to programmed events or things of that nature. The Warcraft map editor was insufficient for reproducing some of the regular levels.

Starcraft was only slightly scriptable. I wouldn't even go far enough to call that a script as opposed to just map data. It's AI was certainly not scriptable (and believe me, I tried). The language isn't really powerful enough to do things truly different, so it isn't much of a script.

I don't know anything about Heroes of Might and Magic.

QuakeC wouldn't be considered a scripting language by some people. That is because it is compiled into something. If I understand correctly, QuakeC is compiled into machine assembly that is then loaded dll-style by Quake and executed as regular code. QuakeC is more like a framework library for making Quake mods than an actual scripting language.

The reason that the Quakes look the same is because of their artists, not the underlying code. Just look at the games based on the Quake 3 engine. Most of them look very different from Quake 3.

Maps are not scripts. Here's an example. Suppose you have a basic RPG engine that, when in a map, you can walk to a town icon, and the RPG will load and display the correct tilemap for that town. That isn't scripting unless you purposely have your gamecode call a script whenever you try to enter towns, buildings, etc to load the new map. That's data-driven code, which is somewhat different (and usually more restrictive) from a script. I think of Starcraft map scripts as falling under data-driven code rather than scripts.

That's not going to solve the problem. I presume that this "Bison" is some kind of pre-designed scripting language and system. However, it is up to you to design objects and funtion interfaces to any Bison script that someone writes. That requires your writing interface code into your engine. This interface code can be prone to bugs, but you won't know that until you start using scripts. So the question will still arise, "Is the bug in the script interface or the script itself?".

fyi Bison
Writing a parser in Bison is hard (IMO), as I mentioned before. I think, for us amateurs, it's a question of compromising a bit of flexibility and using a pre-built scripting language like LUA. i.e it's not ideal but good enough to get a project off the ground.

Pete
========
8):o

I said earlier I would set up a sourceforge project for this; well I have now, the page is here and the home page is here
I called it the MERE project because it could be an acronym for some combination of extendable, engine, modular, RPG, massive, ... , it doesn't sound too pompous and it's short to type.

It would be great if you could pop along and maybe just say 'hello' on the forums. If you'd like to work together on this, let me know (peterhull90@hotmail.com) and I will add you to the developers list. If someone would like to join in, I would be very pleased because I think it will be exciting to experiment with these Open Source tools (allegro itself is developed on sourceforge!) and work to gether with other people from allegro.cc (It's a lonely business, otherwise)

Ramble over,
Pete

Not Allegro-related, but http://exult.sf.net/ Exult is looking promising for the future regarding an RPG engine. As to allowing info from previous RPGs to be used in others, well (after a fashion) it exists - Bard's Tale III can import Wizardry characters, for example, even keeping some kinds of weapon and armour. As for retaining quest info, this could be useful, and would have been fun, for example, for Black Gate and Serpent Isle.

Id be interested in helping out on this project.

I can also host the website, I have perl, php, mysql, ssi installed on the server, so let me know.

This sounds somewhat like neverwinter nights from BioWare corp...

http://www.neverwinternights.com

EDIT: Some craxxor guy messed my desktop shortcuts while I was writing this I should always have my firewall on...

Hey this is good very good Some mates and I have always wanted to do someting like this. If their is still anything going down wed like to be in it so you can mail us at bladenick@hotmail.com .

Ohh and yeah if we wan't this to work we need to first get the main engin going and then distribute it to all of the people that want in. We will have to keep the maps and items in a similar structure through out the game if we all are going to make maps and extra missions and stuff like that. EG the map is based on hexagonal tiles with npc's and stuff like that which can all be scripted by a document or file that you use. If anyone has ever played UO it is similar to our idea it is just that the npc's don't really react to the player's speech. If this game is going to be a single player game you will have to get the ai going reallly reallllly reallllly well I mean better than most ai systems implimented in pro games of today. That could take years for a single person but for a group of people only weeks.

As I said... most projects become dead before the first month... shrug

I feel stupid, but can u explain your sig???

It's because he was member (n where n<1210) before, I guess.

Now I feel REALLY stupid: what did that mean?