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!

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'.

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.

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..

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

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.

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

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.

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

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

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!

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