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:

---

Personally a game where after you finish it you can download new stories would be pretty cool.

---

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.

Pete

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.

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.

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

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

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

Pete
[edit. corrected omissions]

[ February 05, 2002: Message edited by: Pete Hull ]

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:

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

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 ]

Namely what I said earlier:
commandlines and crossover files
each exe calls the next with arguments and then terminates.

code:

---

/* for example */
obj_set(man, "name", "Fred");
obj_set_int(man, "gold", 100);
if (obj_get_int(man, "health", 0) <=0) {
  die();
}

---

code:

---

obj_sync(man, SYNC_OUT);

---

Cheers
Pete

ps. jhuuskon good luck in the test!

Pete

Quote:

---

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?

---

Quote:

---

Well, as far as I know, ALL commercial games produced are not compiled, but scripted.

---

Quote:

---

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.

---

Quote:

---

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

---

Quote:

---

Don't let the Unreal's and so forth make you think that everybody is just writing scripting engines to games.

---

Quote:

---

How is it easier to debug a scripting engine?

---