Correct me if I'm wrong, but it seems like game engines come in three distinct categories.

1. Graphics Engines: Renders really sweet graphics, but there's nothing for game play or for help with the virtual world (be that 2d or 3d).
2. Virtual World Engines: Manage "actors", Physics between objects, Terrain rendering, Handles player control
3. Game Style Engines: Most often hard coded to a particular style(predominantly First Person Shooter), Game companies release the engine they coded to apply "Mods" to it.

I was looking for a story engine. The closest I can find is Interactive Fiction, which does not work with anything else and is very old school.

Am I missing anything?

Thanks,

------------------
penny --Is. 64

------------------
penny --Is. 64

[This message has been edited by penny (edited September 22, 2006).]

Some games that have done this well are the Elder Scrolls series and the Dragon Warrior/Dragon Quest series (except for DQ 8, which is too linear.)

It is a fascinating idea to have an extensible "engine" that would handle these relationships and the state of the plot aspect of the game.

------------------
+---------+
|steveth45|
+---------+

------------------
penny --Is. 64

[This message has been edited by penny (edited September 22, 2006).]

------------------

How far that little candle throws its beams; So shines a good deed in a naughty world.

Portia The Merchant of Venice

------------------

How far that little candle throws its beams; So shines a good deed in a naughty world.

Portia The Merchant of Venice

This really needs to be fleshed out more, but here goes v0.0001 ...

Kinds of Data for this engine:
(Braces indicate a data field. The rest of the text is descriptions.)

Characters: {Name}(Wild Bill), {Inventory}(Polar Star, Rusty Bullet, Cowboy Hat), {Animation Set}(Cowboy), {Skin/Coloring} May reduce animation sets

Locations: {Name}(Tumbleweed, NV), {Map-Reference}(to the 3D/2D level and/or portion of an overall map for this location), {Type} (Sanctuary;no fight zone)

Story-Thread(this would be a particular story/quest[state machine] in the game): {Name}(Find Bill's horse), {Characters-Involved}(Wild Bill, Horse), {Chapters}

Chapter: {Character Locations}(Bill :outside tavern;Horse:at Dry Valley Oasis), {Character Action}(Bill:Stationary by tavern door;Horse: wander up to five units from oasis pool),{Dialog}(Initial dialog of Bill["say partner, can you help me find my horse?"] and the horse[this stubborn horse runs and hids from strangers]), {Events}(after Bill asks you to find his horse[in dialog], an event fires and he 'gives' you his hat, another event fires that changes the chapter of the story thread so that the horse doesn't run and hide from you anymore)

The chapter is expounded for each character in the story-thread, so that every character has a role, for each chapter.

Sorry about the formatting. Its a rough draft. With enough Story-Threads you could probably do what you are asking Ereon, but I gonna start smaller.

What do you all think? Is anyone interested in helping hash this out? ..or coding it?

I'm willing to organize the project and offer views from a storywriter's view point. Heck, I'll even host a site for it. We can make it open source. Any takers?

------------------
penny --Is. 64

[This message has been edited by penny (edited September 23, 2006).]

quote:

---

Originally posted by penny:
Umm.. actually no. That's cool and all, and it could evolve into that, but I was thinking more along the lines of a way of defining standard style games with play sequences, story sequences, etc. And the story engine would a) help the game designer by structuring that information into a common file format (instead of conditional statements scattered throughout the code of the game) and b) to act as the handler for this story data acting along side the game engine(s) to follow/render the "plot" of the game.

---

I think programs like RPGMaker gets quite close to that and this is how I'm trying to make VoHW editing. But complex quests need at least some locations and special objects defined in a map, like AI moving scripts and dialog scripts which have most of the condition and action code.

This is how the conversation nodes look like in VoHW's dialog editor.

------------------
1Jo 2:9-10 He that saith he is in the light, and hateth his brother, is in darkness even until now. 10 He that loveth his brother abideth in the light, and there is none occasion of stumbling in him.
Joh 17:26 And I have declared unto them thy name, and will declare it: that the love wherewith thou hast loved me may be in them, and I in them.

[VoHW] (Help needed) [Blog] - Truedisciple (mp3)

Perhaps (just a thought) if it was written as a library as a dll or .so object then it could be interfaced with a lot of existing code platforms and languages out there.

I really think this could be the ticket for connecting my stories and games. If everyone else is tied up in their own projects, I just might have to teach myself to program.

------------------
penny --Is. 64

Sounds like you should just pick up a simple language or scripting language and set this up as a dll if you can, or at least code it with usability in mind.

Cause from what I gather from it, your wanting to be able to setup some simple 'rules' and then the game will play out by those rules. A rule could be the rule for how a quest/chapter is completed and such.

So that a game could pretty much just be created using these rules. Pretty much its just a big scripting system from the sounds of it. If I wasn't busy with several projects (although I could see a real use for something like this (data driven game system) in one of my projects), I'd most likely volunteer.

Are you on MSN? Maybe I could help out however I can, even to help you learn programming (C/C++, or the like)... PM me if your interested.

------------------
Programmer - Team KAIZEN

I had a thought last night. It would be easier for us story writers if we could build the story first in an story editor in the same way one writes a script before making the movie. Then, using the objects created in the story editor (characters, items, enemies, etc.), a game "director" of sorts (person) could position NPCs and triggers, and locations, and whatever onto the game's map, like a movie director would position actors and props on a stage.

The advantage of approaching it from this viewpoint is that a) you could easily migrate from 2D to 3D; the game engine changes, the story stays the same (great for prototyping and/or mobile editions of your game) and b) you could easily/quickly create new games based off the same game engine i.e. MegaMan 1,2,3,4,etc. (all used the same engine different story)

I am sure that the big shops have done this already. It would be nice to put this in the hands of indy shops, and of course to use it for Christian games (which is my focus).

I really think this could be a key element for creating good Christian games, since the point really is to teach via stories (Jesus did this really well).

I'm going to flesh this out into more of a project plan.

You all have been very helpful. Any other ideas? Do you see anything I am missing?

------------------
penny --Is. 64

[This message has been edited by penny (edited September 24, 2006).]

Good luck and God be with you in this. -Jeff

I have also noticed that in some games there are smaller threads of the story that are optional to play. You could skip them completely and still finish the game. Hence, the idea for story-threads that can be woven together into the complete game story.

I'm trying to pull together a plan for this. It would be nice to have a second non-programmer look at the interface and critique it.

In the end I would like to see a writer-friendly editor that a non-programmer story writer could use to build the non-linear story. Similar to the way one builds graphics programs and map editors which are usable by non-programming artists and game designers.

------------------
penny --Is. 64

[This message has been edited by penny (edited September 24, 2006).]

------------------
+---------+
|steveth45|
+---------+

[This message has been edited by steveth45 (edited September 25, 2006).]

http://en.wikipedia.org/wiki/Sequence_diagram

There are UML tools which will take a UML diagram and create a complete set of classes.

You may be able to define things like "if person has cat" then NPC reacts in some certain way. If person has a dog then NPC reacts differently. But not sure how it will work in the area of text interaction.

I have not played it yet, but Knights of the Old Republic II has, at some level, what you are describing. Your player's actions and behaviors will effect other characters in the game. Sometimes, the effect may happen much later in the game. Your party even reacts differently depending on who is in your party. This means you must choose wisely and keep everyone working together.

The thing is, a game must still be winnable, so in the end, there is still some linearity to the game forcing you in certain directions. You can't have a situation where losing a certain party member will end up costing you the game. In the end, the game will still be programmed in such a way where the character may end up leaving no matter what. Either he/she is fed up with your behavior and decides to leave, or he/she has been mysteriously called away or decides they have offered all the help they can and has decided to take off on some other excursion.

Thanks!!

------------------
penny --Is. 64

@all: I could really see steve's idea of the graphical representation become a reality. It would suit it perfectly. If anyone has used a Shader creation program such as ShaderWorks (now knowned by Activision or the like) or RenderMonkey (I think). It has certain nodes which can be dragged and dropped, from inputs and outputs, and within those you can put variables, such as Vector3, float, etc. Even some particle effect systems use node based systems to create a particle effect.

Possibly the next CCN project haha... I'd volunteer some coding time for that :P

------------------
Programmer - Team KAIZEN

I suspect SourceForge has some UML projects as well.

Most of the freebies I've used are not that great. I tend to stick with simple class diagrams, as most of these apps can generally do this fairly well. Then again, seems like 90% of people who use UML just use it for class diagrams anyway. It starts getting rather complicated and involved after that.

------------------
penny --Is. 64

Yeah, at uni we messed around with UML, and for final project I made the programming team (as I was lead programmer) do class diagrams, sequence diagrams and activity diagrams (I'm pretty sure those are the right names) for their code sections/managers.

------------------
Programmer - Team KAIZEN

quote:

---

Originally posted by penny:
I don't know if any of you guys code in java, but here is a framework that looks like it is a pretty good start for this idea. http://www.jgraph.com/jgraph.html

---

It's actually perfect, or pretty close. It has a generous LGPL license, too. Java/Swing is a decent cross-platform GUI toolkit anyways.

------------------
+---------+
|steveth45|
+---------+

[This message has been edited by steveth45 (edited September 28, 2006).]

------------------
Jesus looked at them and said, "With man this is impossible, but with God all things are possible."
--Matt. 19:26

Your "Graphics Engine" is composed of the following:
Resource manager, Particle manager, Shading manager, Audio manager, Event manager, Scene manager, Font manager, Lighting manager, Materials manager, Texture manager, Scripting manager, Collision physics, and many entities not to mention the math libraies such as Vector and Matrix libraries that make up your (very basic) graphics engine or "rending engine".

Your "Virtual World Engines" and "Game Style Engines" are the same thing.
Managing "actors" is part of the "View", Physics collision is part of your "AI Sub-System", i.g. your physics system. Terrain rendering is part of your graphics systems, I guess depending on how you develop this, it could be part of your mesh materials. To handle player controls you need to have a "View" object, (the "View", for example, is YOU the player). A better term for "Game Style Engines" would be "Scenes". If your game incorporates scripting with in its engine API you will be able to release MODs. There's no such thing as a "Story Engine", however I think you mean "Scenes". (?)

The "Event Manager" or "Message Manager" breaks inner-dependency between objects. For example the AI system does not need to know about the inner workings of the Audio system, or Physics system. Also it does not need to know what "state" every system is in at every single moment. Also, imagine you have 101 systems in your game, then imagine adding later another system several months later. Can you imagine the amount of work that you would have to do to tie all 101 systems together with your new system you just added!? To break this inner-dependency, we need a way to let other sub systems (AI, Audio, physics, etc) know what's going on. Every system that wants to "listen" for event needs to register itself with the event manager. Once a system registers itself, it's ready to send and received events from other systems. For example, When the AI state changes, it can send, ("trigger") an event to the other objects that are listening for events/messages. Once an event has been received by an object, its state will then change. The event manager is not responsible for keeping track of "who's alive" and "who's dead", "players", "monsters", etc, that's the reasonability of the AI system. The only responsibly of the event manager is to send events/messages/triggers (whatever you want to call it) to the other entities or "Sub-Systems" in you engine. It doesn't care, nor should it care about who's alive, who's dead or who has the highest score. It just sends and receives events and does not handle the events. An event can say "Player_Moved" or "Player_Is_Dead" or "Spawn_Monster", but it does not "move the player", "Kill off the Player", or "Spawn Monster over yonder".
(Just FYI)

Linear dialog between the PC and NPC is very predictable as you might imagine. I think you will need more info in you script to handle dialoging between PC and NPC. I would consider careful planing here and eps. your data structures and how you plan to map them out. Since this is farly an old thread, have you decided on text, 2D, or 3D game?

Hope this helps.

Cheers

In my spare time (which recently I do not have any of) I am fashioning an idea of making a story engine that coordinates the story of a game with game events on a higher level: taking scenes and acts and translating them to triggers and state machines. I guess middleware is the buzzword they are using these days for this.

It would work similar to an AI system, but *not*. In the sense of story plot, AI, causes game characters to act in a random fashion. Characters act according to simulated stimuli like fear and desire. Sometimes they follow patterns and paths, but they are rarely coordinated with a story line. At best their dialog is.

I have never heard of someone breaking the story out as a generic engine into Plots, scenes, commands like "Once the player enters the 'Gum Swamp', move NPC 'Black Knight' to the town of Sharon and roam up to five paces from the door of the tavern 'Ye Old Ale'" Its normally a set of locations and points and triggers in an interpreted script tied to a state machine of sorts the tries to track the story with a slew of bit and enum variables. And that's fine.. for a programmer.

So, why do this?
1. To make it easier on game story authors that are not programmers.
2. To let the programmers do the whiz-bang graphics and ai routines that they love to do.
3. It abstracts the story from the game so that one could mock up a 'story' in an interactive fiction engine, then build a mobile version of the game in 2D and a full-blown 3D version, all with the same story data/engine!
4. To bring richer stories and interaction into games that go beyond running an instance, or barrelling to the end of a level killing everything in sight.
5. To make it open-source and in the hands of indy groups as a library piece to be integrated with their own or favorite game engine.

So, to answer your question about text, 2d, or 3d. I would like to build this story syetem as a library generically(dll,so) and hook it first into an Interactive Fiction system(Text), then a 2D system, then a 3D system.

As a writer, it seems silly to have to build a typewriter everytime you want to write a story. Or learn a different language to write a particular genre of story. Genius game designers can pull this metaphor off. They build complex story interactions between "actors" in an "instance" as a set of triggers and bit variables, and other data structure voodoo in various scripted languages that noone can seem to agree on (lua,python,basic).

And that is fine, but there are a lot of fiction authors out there that don't know anything about anty of that, but they are genius story writers.

Even if you use a commercial Game Maker system, you still have to be writer, director and producer, and these roles are all intertwined.

I guess what I want is to to abstract out the story writer role and standardize it, similar to how graphics modelling has been abstracted out of the game writing process so the genius 3d sculptors can shine eventhough they are don't know anything about matrix math and vector multiplication.

Does that make sense?

Sorry if I rambled on. Its sort of has become my passion for now.

------------------
penny --Is. 64

If so, you can make your code into anything, and then have "exporters" for various popular game engines, or create your own game engine. Such a "story to game" engine would be pretty powerful.

I have found that games are of course more than stories, so this will just be for the story part of the game. Some games really don't have stories, they are just games: board games, tetris-esque, sports. This would be primarily for story based games: rpgs, adventure-type, action-exploration genres.

------------------
penny --Is. 64

I guess I'm unclear as to what your asking or saying.

I think your question hinges on "How do I go about..." type of question, right? Well, let's think about this. First let me propose to you a sample scene from some game. Let's say we have a character named "Sethion" and he/she is a NPC that has a magical spell book that you (the player) needs in order to defeat some evil overlord. Your task is to go find Sethion and talk to him/her and get the book. Ok? So now we need a script that defines the scene and how communication is going to play out between you and the NPC (Sethion) ("C" style script up ahead!)

Character "Sethion"
{
"MagicalBook"
if ( GetStatus(possessBook) != true )
{
Say("You possess the book already my child. Please leave me now.)
}
Say("Yes, child I have the book you seek.");
// long winded discussion about the book....
Say("Here, take the book and leave me now.");
UpdateIventoryList("MagicalBook");
SetStatus(possessBook, true );
RemoveThingsToDo("Sethion");
AddThingsToDo("EvilOverLord", true);
}

The above script does several things in the AI; check to see if we have discussed the book before with Sethion, if not, we discuss the book with him/her. Once we have talked about the book we need to get the book from Sethion and add the book to our inventory list then set a flag to "TRUE" when we are done. (By setting a flag to TRUE indicates that we have talked with Sethion.) We then remove the "MagicalBook" from the "Things to do list" and add the "Go see Evil overload guy" to our "Things to do list". Clearly this is just one way of doing it, but it should give you a reference point on how to approach dialog scripting in your game.

quote:

---

I guess what I want is to to abstract out the story writer role and standardize it, similar to how graphics modelling has been abstracted out of the game writing process so the genius 3d sculptors can shine eventhough they are don't know anything about matrix math and vector multiplication.

---

Also, keep in mind that scripts are not embedded into .EXE or .DLL(s) files. They are essentially text files read in from the game.

Hope this helps!

Cheers.

[This message has been edited by seven7 (edited October 23, 2006).]

quote:

---

Originally posted by JeTSpice:
and then have "exporters" for various popular game engines, or create your own game engine.

---

I really like this idea of exporters.

quote:

---

Originally posted by seven7:
I guess I'm unclear as to what your asking or saying.

---

More like discussing and analyzing. In a nutshell, I would like to see a paradigm shift and some standardization in the area of game story design. Let me explain...

quote:

---

Character "Sethion"
{
"MagicalBook"
if ( GetStatus(possessBook) != true )
{
Say("You possess the book already my child. Please leave me now.)
}
Say("Yes, child I have the book you seek.");
// long winded discussion about the book....
Say("Here, take the book and leave me now.");
UpdateIventoryList("MagicalBook");
SetStatus(possessBook, true );
RemoveThingsToDo("Sethion");
AddThingsToDo("EvilOverLord", true);
}

---

This script is a fine example of how games story pieces are currently implemented. I'm sure you(and other programmers) look at this and say, "See how simple it is?" but a fiction writer is left scratching his/her head. A persistent novelist may struggle and learn a particular game maker engine or scripting syntax, and come up with what you have coded here.

Ok, now imagine an incredibly complex character that the player can interact with so much more than just retrieving an item. And perhaps the player would/could interact with this character 25 times during the game each with different responses depending upon different circumstances. All of a sudden that sixteen line script becomes hundreds of lines long; riddled with if conditionals, and switch-case statements and SetStatus commands.

I may be wrong, but I can see one of three things happening:
1) You have recruited a great level designer who can manage all this hairy code in his head, but really isn't creative when it comes to story writing and you get an intricately woven story that is cliche.
2) You have recruited a great fiction story writer who has incredible intriguing game story ideas, but ends up creating a fairly predictable game(fetching items and saving princesses) because he can't code the complexity.
3) You have recruited a genius level designer who can manage all this hairy code in his head and produces a fun, exciting, story masterpiece, but he's expensive to keep. Unless, you really land it, and he's your brother or something.

quote:

---

I think what your saying is that you want to be a "Level Designer". Level Designers, are the guys/gals that do the some/most of the scripting, "director/producer", create textures and mesh stuff. (Different companies have different titles and responsibilities.)

---

I'm saying three things.

I want a paradigm shift in game development that will break the role Story Writer away from the all-inclusive role of Level Designer.

I want to then equip the less-technical, more creative fiction story writers with standardized tools to create the story part of games.

I want to build an open-source library that can read the standardized files outputted from the tools and create the if/switch/set scripting logic that you have exampled, to be easily implemented into existing and future game engines.

That's what I'm trying to research, learn about, and hopefully accomplish.

Again, thanks for all your insights.

------------------
penny --Is. 64

[This message has been edited by penny (edited October 24, 2006).]