Wyrmkeep Entertainment Board

Game Devlopment Forums => General Game Development Forum => Topic started by: Kay on September 02, 2004, 06:38:43 PM



Title: Game Concept: Technical
Post by: Kay on September 02, 2004, 06:38:43 PM
Re: a dialogue/scripting system: I suggest looking at Morrowind's editor. From that and from my own work, what's needed are data structures that look like this:

class Line: ## A line of dialogue
    text="What gets said, with code insertions like 'I have {value:self,HP} hit points.'"
    requirement_1_variable = None ## A variable that gets checked to determine whether this line can be used.
    requirement_1_value = None ## What must its value be?
    requirement_2_variable = None ## etc.
    requirement_2_value = None ## etc.
    code_to_execute = None ## Special code that gets executed if this line is chosen, eg. "Give Player 100 coins" or "Run script #42."

class Topic: ## A dialogue topic the player can ask about
    lines = [] ## Attach Lines to this.
    name = "The name of this topic."
    special = None ## Requirement for being able to ask about this?


Then when the player wants to ask about a topic, you use a function that basically says,

For each Line in Topic (starting with the first):
    check each requirement for this Line.
    if all requirements met:
        select this line and display; run its code. Quit.
    else:
        do nothing
If we get here, no line was selected.
Display default line.


That gives you the equivalent of Morrowind's dialogue system. Coding individual topics and lines by hand is a royal pain, so an editor program is necessary. If you want a more advanced dialogue system, you start getting into neural networks... possible, but tricky. I would assume Morrowind-like AI first.

Re: AI, we'd need to decide what the NPCs are capable of. Random walking within a restricted area, the above dialogue system, and basic "attitude" towards the player (based on group membership, species, etc.) are all fairly easy to program. Would they need to do more? For party members or potential friends of the hero, I'd want more AI, but we could get away with the dialogue system plus Final Fantasy-style scripted conversations to bring them to life.

Re: Graphics Engine, this is the hard part. Displaying square graphic tiles is fairly easy. Adding multiple graphics layers (for transparency, clouds, etc.) isn't terrible. Scrolling smoothly and animating sprites is tough. Using isometric (diagonal) tiles adds another level of complexity, since you're basically drawing rectangular graphics but only displaying a diamond-shaped chunk of them, and deciding how multiple faces of a 3D block should be painted. Especially if you can rotate.

Re: Developer Tools, what's needed are:
-World Editor (draws the areas where the player can walk around; places scripted events, items, etc.)
-Tile Editor/Converter: Creates graphics or (if necessary) converts them to the right format
-Dialogue Editor: Creates conversation topics and lines.
-Script Editor: Creates planned events.
-Game Engine, Debugger Version: Lets the player walk around in the game world as if playing the game, with the ability to cheat, turn code features on/off, etc.

Other things:
-Is it possible that Bethesda/ZeniMax (Morrowind's creators) have patented some part of their AI, ie. the concept of a topic-based conversation system?
-I will mention this discussion on TSA-Talk, a relevant mailing list.


Title: Game Concept: Technical
Post by: Threed on September 03, 2004, 12:26:59 PM
Quote
Re: Graphics Engine, this is the hard part. Displaying square graphic tiles is fairly easy. Adding multiple graphics layers (for transparency, clouds, etc.) isn't terrible. Scrolling smoothly and animating sprites is tough. Using isometric (diagonal) tiles adds another level of complexity, since you're basically drawing rectangular graphics but only displaying a diamond-shaped chunk of them, and deciding how multiple faces of a 3D block should be painted. Especially if you can rotate.

For this, I beg to differ - using a 3d Scene Graph almost immediately eliminates all of these problems. Its entirely possibly to make a 2d game using a 3d engine, and is often desirable, since you can use many neat 3d special effects on the 2-d elements that you get "for free" when you would normally have to code these by hand... Gish - http://www.chroniclogic.com/gish/ (http://www.chroniclogic.com/gish/) - is a perfect example of this. You wouldn't know it was a 3d game unless you were fishing around in the advanced settings. They get advanced per-pixel lighting, beautiful special effects, the whole she-bang, for free.
The effect is stunning; a beautiful mix of 2d elements and wonderful "3d"-esque effects. Also, the lper-pixel ighting effect is really neat for night-time scenes. ;)

This is not to say it would be a cakewalk, but using a 3d Scene Graph eliminates most of the mundane work and lets you work with the actual logic of the implementation.

Quote
Re: AI, we'd need to decide what the NPCs are capable of. Random walking within a restricted area, the above dialogue system, and basic "attitude" towards the player (based on group membership, species, etc.) are all fairly easy to program. Would they need to do more?

What kind of world would you want them to be in? The type of gameplay dictates what the player would expect from the AI - a hack 'n' slash would not have the AI depth of a dynamic RPG, for instance.

Morrowind-style AI is ridiculiously easy to copy, though, given that they only do a few things, if any at all (have you ever asked Ahansi the thief about "her profession?" Her tone of voice changes completely and assumes the pre-defined gender-neutral tone that the scripters wrote up for all thief classes, ackward at the very least).

On a completely unrelated note:
I love Ultima 7's model of AI. You could literally stand still in one place and watch the AI wander around by itself. Guards patrolled the streets. At dawn, shopkeepers would wake up, leave, and LOCK THE DOORS behind them - it is truly a great experience, sneaking into someone's house at night through the window, waiting until morning (when they lock-up and leave) then ransacking them blind, opening the door and hauling ass when you're done. ;) Its a pretty simple model of AI, but compared to Morrowind's... I'm really not sure why Morrowind's AI wasn't more indepth: they had an attitude towards the player (good or bad), and walked random patterns at all times of the day and night. The only "special" actions were scripted ones, which I thought was kind of odd, but whatever.

Quote
-Is it possible that Bethesda/ZeniMax (Morrowind's creators) have patented some part of their AI, ie. the concept of a topic-based conversation system?

If you write over a 1,000 lines of code for anything its been estimated that there is at least an 80% chance you're breaking someone's patent - sometimes its just best not to think about it.

Of course, if that's true, then I must be some kind of legendary underground hacker-hero of the wild west. ^.^

More realistically, a patent for conversation-driven AI c(SH)ould never be granted to Bethesda Softworks - if anyone has the patent, its gotta be Origin, as the first few Ultima games contained all of the stuff Morrowind's conversation scripting does.


Title: Game Concept: Technical
Post by: Kay on September 10, 2004, 06:48:07 PM
Quote
This is not to say it would be a cakewalk, but using a 3d Scene Graph eliminates most of the mundane work and lets you work with the actual logic of the implementation.

So where would we get a graphics/animation coder?

Quote
What kind of world would you want them to be in? The type of gameplay dictates what the player would expect from the AI - a hack 'n' slash would not have the AI depth of a dynamic RPG, for instance.

My "favorite" Morrowind moment: being chased by a dozen or so wolves, bears, berzerkers, and ice witches, all of whom attack on sight, fight to the death, always follow my path even if I'm running in circles; none of whom cooperate or get demoralized by seeing me slaughter their friends with a sword crackling with icy doom.

The moral: make the battle system stylized, more like Final Fantasy's, and have the AI focus on when to fight and when to surrender.

Re: dialogue, the problem of characters switching speech styles is partially treatable. Create a "Speech Filter" so that before a character speaks, all instances of words in [list 1] are replaced by the same entries in [list 2]. For instance:

Bostonian: "r" --> "ah", "R" --> "Ah"
Result: "Park your car at Harvard" --> "Paahk youah caah at Haahvaahd."

Kid: "want to" --> "wanna", "going to" --> "gonna", "got to" --> "gotta"
Result: "I want to fly high; I've got to fly higher" --> "I wanna fly high; I've gotta fly higher."

Then tag each NPC as to what filters they use. These have flaws, eg.:
Filter: "very" --> "really"
Result: "Every" --> "ereally"

...but they can help keep characters from switching accents suddenly. For cat-people you can just change "r" to "rr"; for a Japanese person you could do a few substitutions like "hai" for "yes" just to add flavor.

Re: AI, like I said, I would put Morrowind-level AI on the "must have" list, with a few characters (like potential friends) having better AI, and put advanced stuff on the "do once there's a working demo" list. The "shopkeeper schedules" thing you mentioned exists for Morrowind, but I lack the "Tribunal" expansion it requires.

If I had a good basic graphics engine in a language I knew (like Python), I could show off decent AI. I could also, with a little work, show off what I mean in Python based on what I've already done, but the graphics "engine" there is unusuable for a real game.

Where could we find people willing to experiment with these ideas?


Title: Game Concept: Technical
Post by: Threed on September 12, 2004, 08:25:58 AM
Quote
So where would we get a graphics/animation coder?

Why reinvent the wheel? There are tons of open source 3d scenegraphs that do the job admirably; there's probably at least one very advanced engine for each major language. Its just a matter of implementation after that.

Quote
My "favorite" Morrowind moment: being chased by a dozen or so wolves, bears, berzerkers, and ice witches, all of whom attack on sight, fight to the death, always follow my path even if I'm running in circles; none of whom cooperate or get demoralized by seeing me slaughter their friends with a sword crackling with icy doom.

The wolves should be killing the bears, the bears should be killing the wolves, the ice witch should be casting buff spells on the berzerkers, and the berzerkers should be killing everyone - including the witch!

Quote
The moral: make the battle system stylized, more like Final Fantasy's, and have the AI focus on when to fight and when to surrender.

Turn-based, real-time, quasi-real-time (those whacky power-up bars!)?

Quote
I could also, with a little work, show off what I mean in Python based on what I've already done, but the graphics "engine" there is unusuable for a real game.


Also, google for "Python Scene Graph" and you'll find a ton of 3d engines to use. Its pretty easy to use them 2d styles: programmatically draw a polygon for each sprite, then use the bitmap image as a texture on the polygon.... bam. Instant 2d love-making, you know? You'd move them around on the same Z-axis and it'd be just like a 2d engine.

Quote
Where could we find people willing to experiment with these ideas?


! You seem pretty willing to experiment on the issue yourself.

There's a difference between experiencing and trying to deliever a polished product, though - they take two seperate, distinct development arcs, and very little intersects. What you use in one you  probably won't be able to use in another. So you'll have to decide no what direction you want to go with this kind of prospect.

Don't look at me unless you fancy getting comfortable with the .NET library and a Python-clone for the platform like Boo or IronPython: I've sworn off all other development platforms but Java and .NET - I gain way too much and I slow too far down when I start using low-level langauges. I used to be technologically agonistic... but ****** that. I get too much stuff using .NET or Java.


Title: Game Concept: Technical
Post by: Kay on September 12, 2004, 07:30:53 PM
How does one get Java and .NET? I've worked with JavaScript a bit; is there a free (and usable, and legal) version of these available?

The biggest problem I encountered while fooling with AI (I haven't touched it in a while) is the "world," which isn't even part of the AI itself. It's the virtual environment containing rooms, items, and things that an AI can sense. The "world" is a pain because it takes up more than its share of programming time and limits what an AI can do. Right now I got away from my ugly-graphics version by switching to a MUCK-like text interface, but that means it's not possible to move around within a "room." It's like something Douglas Adams said about the Hitchhikers' Guide Mk. II: ideally an AI would have no filters limiting how it can perceive the world.

Bleh, but most of what the new version does is move around and look at new objects. All the graphical version did was move, find food, converse Morrowind-style, and learn a bit.

What kind of actions would you expect from a major character -- with a good AI -- in an ItE sequel sort of game? What could it do to make you like it, and make you think of it as more than a scripted character?

Come to think of it, I wonder whether VERGE would be usable for a project like this. It's C-based, contains basic graphics functions and a scrolling tiled graphics engine (2d), and is ugly.


Title: Game Concept: Technical
Post by: Threed on September 13, 2004, 08:01:16 AM
Quote
How does one get Java and .NET? I've worked with JavaScript a bit; is there a free (and usable, and legal) version of these available?

Both are free and crossplatform.

Java
Java SDK - Java JDK 1.5 - http://java.sun.com/j2se/1.5.0/download.jsp (http://java.sun.com/j2se/1.5.0/download.jsp) A release canditate for version 1.5, the final version due out at the end of this month. Contains too many improvements over Java Development Kit (JDK) 1.4.2 to even bother with 1.4.x now. :)

Best free Java IDE available: Eclipse. www.eclipse.org

.NET

You can go here: http://lab.msdn.microsoft.com/express/ (http://lab.msdn.microsoft.com/express/) to grab the .NET SDK and a free IDE for the language of your choice. If you're interested in notepad-style development, you can search around www.msdn.com for the .NET 2.0 SDK, download, and install...

...both are free.

Quote
The biggest problem I encountered while fooling with AI (I haven't touched it in a while) is the "world," which isn't even part of the AI itself. It's the virtual environment containing rooms, items, and things that an AI can sense. The "world" is a pain because it takes up more than its share of programming time and limits what an AI can do.

It could act more like an "agent." To get around AI interaction with the world, things would have to be described in units that the AI could understand. It must be able to look at a "node" (let's say a sword in this case), know that this node is used for "damage," know that this node can be "wielded," know that this node can be "stored," know that this node could... etc, for every action. The agent, then, stumbling across this node, will decide (using weighted values) wheither the weapon is better than anything it has, wheither it can carry this weapon around, and if it can carry this weapon around, does it have enough weapons that it should discard the lowest power weapon?

You could apply similar logic to interaction with other world components - agent wants to go to point C from point A, but at point B there is a locked door. The agent cannot pathfind its way to point C from point A. However, upon inspecting the node at point B, it passes it through a function that determines a few essential values: is there something it wants behind the door, will opening the door allow it to continue with its path finding, can it open the door...?

To keep the code simple, you can break node logic up into an abstract basis of "verbs" and "nouns" and shit, so you won't have to keep programming new logic for each kind of node you add to the game. All nodes would pass through the same function, and the appropraite action would be called at the very end (agent might decide to invoke the "wield" verb, the game takes it from there).

This requires weighted values and for verbs to be defined - the Agent must know what the "wield" weights its "attack" or "defense" values much heavier than the "eat" verb, which weights its "health" value down to, like, 0. Or maybe -1 (application crash!). The better part of this is that agents that do not have a particular definition for how a "wield" verb will affect them would probably ignore the item and keep moving; great for feral agents.

There need to be a handful of basic hardcoded values, though, such as traversing distances would be done the same in all agent models, for instance.

Quote
What kind of actions would you expect from a major character -- with a good AI -- in an ItE sequel sort of game?

I'd expect it to have its own "agenda" - something it wants to accomplish, something that makes it real and different from the unwashed masses that simply wander around mindlessly all through the day and night. If it knows that I've found out about its treacherous plans, I want it to try and hide somewhere - not just stand in the middle of the town square and wait until I initiate conversation. I want it to flag me down if it has something important to say... or just follow me around creepily. >:)

I want it to do things without waiting for me to walk up and mash the 'A' button on the controller.


Title: Game Concept: Technical
Post by: Kay on September 22, 2004, 11:50:44 AM
.NET doesn't look like what I had in mind at all; it seems to be more for making online databases and E-commerce sites. Will investigate Java next. What I'd like is to build a program with a clean Windows interface and Net access. As it is, I either have to build my own window-and-button system or learn Java!


Title: Game Concept: Technical
Post by: Threed on September 23, 2004, 09:46:00 AM
Quote
.NET doesn't look like what I had in mind at all; it seems to be more for making online databases and E-commerce sites. Will investigate Java next. What I'd like is to build a program with a clean Windows interface and Net access. As it is, I either have to build my own window-and-button system or learn Java!
Not really.

People are making Realtime 3d engines (http://axiomengine.sf.net) and high quality commercial games (http://arenawars.krawall.de/eng/index.html) with it. Grab the demo of Arena Wars, by the way, if you dig strategy games - its one of the craziest RTS' I've ever played. Capture the flag... with tanks. Man, Germans are ******ing insane.

The .NET framework is the next generation in windows development, after all, so it encompasses everything from client-side programming to server side programming.

Is this simple enough for you?

Code:
using System; //base libraries.
using System.Windows.Forms; //Windowing library.

namespace MySampleProject
{

class MyWindow : System.Windows.Forms.Form //Inherit a generic Windows, uh, window.
{

  public MyWindow() //Constructor; called when class is created.
  {
   Button MyButton = new Button(); //Create new button.
   this.Controls.Add(MyButton); //Add new button to this form.
   /* Anything else.
    ....
   */
  }
}
}

Launching:

Code:
using System;
using System.Windows.Forms;

namespace MySampleProject
{
class Launcher
{
  public static void main(string[] args)
  {
   Application.Run(new MyWindow());
  }
}
}

Those are two seperate flies, by the way, for consistency's sake.


Title: Game Concept: Technical
Post by: Threed on September 23, 2004, 09:49:36 AM
Oh. Uh, not to sound like a cheap shill for .NET, though - the only reason I know so much is because of a hobby project (a game) I'm working on every once in awhile.

Edit: Freaking forum broke my bracket spacing. Bah.


Title: Game Concept: Technical
Post by: Kay on September 24, 2004, 09:35:16 PM
I'm installing the Visual C# IDE for .NET now. It looked like the best option of the ones MS offered, and possibly easier to use than IronPython. Why can't I get anyone to give me a legal, high-powered, easy-to-use development tool for free? =) Python is powerful and not too hard to use, but you really have to build a lot of stuff from scratch even using Pygame.

I'm concerned about MS's license agreement though -- automatic expiration in 2005 March? "Recipient may not... distribute" anything "created using the Software"?

Will edit this after I give Visual C# a try...

OK. I'm now fooling with basic applications, closer to "Hello World" than AI or ItE. Will keep at it.


Title: Game Concept: Technical
Post by: Threed on September 25, 2004, 09:11:09 AM
What you are downloading is Visual Studio 2005, C# Express Beta 1, an Integrated Development Enviroment for the .NET Framework.

Beta 1, AKA, "We're not sure its ready for production use yet, so until we say you're not allowed to distribute stuff you make with it, don't, O-K?"

Beta 1 is time-bombed to explode a year after its release, but Beta 2 should come long before that... and, with Beta 2, you'll be able to freely distribute applications created with it.

The "do not distribute thing" is mostly hope on Microsoft's part, though, since there's really no way to tell if you wrote the program using the command line or you wrote it using another IDE like SharpDevelop.

Microsoft has gotten into the habit of public betas before polished final releases.

It usually goes, 'Beta 1, Beta 2, RC1, RC2, Final Software Release.'

Quote
Why can't I get anyone to give me a legal, high-powered, easy-to-use development tool for free? =)

~.~ hehe. Yeah.

The development framework - ".NET Framework SDK" - and the runtime are available for free, to everyone. What you're downloading is an IDE - an advanced editor that invokes the SDK whenever it wants to create a new application. You could just as easily use Notepad to develop .NET/C# applications, but that's not as much fun as looking at the IDE's pretty graphics.

The IDE could die on you a month from now - radioactive cancer or something - and you could keep programming using another .NET IDE or just NotePad or jEdit.


Title: Game Concept: Technical
Post by: Kay on October 04, 2004, 08:53:57 PM
Thought I'd give a progress report. I was hoping to create a simple C#/.NET demo of the dialogue system by now, but with other things going on (fiction writing and law school!) I've been busy. So far, C# is great for creating buttons and Windows controls, but a pain for even an experienced amateur trying to figure out how to make basic things like arrays and objects work. Can't do anything without making the line/topic structures compile and managing to access and manipulate instances of them.

This (http://www.xepher.net/~kschnee/aboutniss.htm) has screenshots of past versions.

I was thinking that instead of the ugly graphics I was doing, and instead of the MUCK-like text interface, it'd be nice to make a Windows tree-view of game locations (like City A\Wharf District\Alley) and organize the AI along those lines without worrying about the exact placement of obstacles within a location. That would make pathfinding simpler, and if it were ever built into a real game, AI for walking around a room could be handled separately from AI for deciding what city to go to. (This is based on Threed's "agent" comment, but without the assumption that any AI picking up a sword automatically knows how it's used.)

Will keep at it.


Title: Game Concept: Technical
Post by: Threed on October 05, 2004, 11:40:39 AM
Quote
I was thinking that instead of the ugly graphics I was doing, and instead of the MUCK-like text interface, it'd be nice to make a Windows tree-view of game locations (like City A\Wharf District\Alley) and organize the AI along those lines without worrying about the exact placement of obstacles within a location. That would make pathfinding simpler, and if it were ever built into a real game, AI for walking around a room could be handled separately from AI for deciding what city to go to. (This is based on Threed's "agent" comment, but without the assumption that any AI picking up a sword automatically knows how it's used.)

Will keep at it.

What happens, using this model of pathfinding, when there is a location that is in the "root" node (A City), but can only be accessed by two distinctly seperate children nodes that aren't in the same tree?

AKA,

"Gulliver" can only be accessed via "A City\TownPlaza\BackAlley" and "A City\Hidden Attic\Roof\FireEscape\Backalley"? It should not be able to pathfind its way to Back Alley by going directly through "A City."

For a MUCK-like style, have you considered a matrix layout? A 3 dimensional L x W x H layout of the city (!) where the blocks are interconnected and thus that determines where the AI can and can't GO?

[3, 2, 1] might not be linked to [3, 2, 2], and so to go upstairs, the AI might have to go to [3, 3, 1] ... etc, etc, etc.

This can be a 2d matrix, I'll admit, but then the layout's going to look pretty funny from a visual perspective and you'll have to do weird things to link one node in the matrix to another.

And of course, each matrix node can hold information about the room (other nodes inside of it that might be of interest ... ..)!


Quote
This is based on Threed's "agent" comment, but without the assumption that any AI picking up a sword automatically knows how it's used.

I think - as a matter of preference, of course - that all Agents should explicity know what actions are available for any given object they encounter, then make a reference check against a matrix of information about that object, AKA, 'What do I know about the functions of this object?' and 'I tried to use this particular node's function before and I failed miserably - should I try again?' The crux of the issue, in my eyes, is that most functions will be used regardless - a pipe wrench is used for unclogging drains, which an AI might not have discovered, but it does know that a pipe wrench is a very blunt object and that there is a six foot ogre coming at it, and so, off it goes - pipe wrench meets ogre's forehead with a responding thud!

That implies that there are basic things an AI already knows, though: how to defend itself, how to forage, how to...




(Something something something, arrays, something, objects, something)
Incoming code block! Its C#, but I'm sure you can figure out how to translate it to Python easily - its very legiable:

First: topic node structure thing. ;)
Code:
struct Topic
{
public string Subject;
/The following are two arrays: one contains possible questions, and another contains possible answers.
The first array is one dimensional; that is, there is only one style of question to ask.
The other arary is two dimensional; that is, for each kind of response, there are really several different kinds of responses!
Thus,  Questions[0] (first element in the Questions array) corresponds to Answers[0][N] the first element in the answers array, with N being one of the 2nd dimension elements - typically, "depth."
 */
public string[] Questions; //Things user can ask.
public string[][] Answers; //Two dimensoinal array.

}

Second: random code snippet, initalizing the array and them picking a random response:
Code:

Topic topic; //new topic.
//Initalize new questions array with preformatted responses - in a real scenario, this should be done dynamically, and frankly, using an ArrayList, or else you'll have to be dynamically resizing Questions[] until the cows come home.
topic.Questions = { "What is your name?", "Why should I make sweet love to you?", "Yo!" };
//Initalize Answers - see above comment.
topic.Answers = { { "My name is Sir Frederick the Great", "My name is... your daddy, that's what!" }, { "Because I am hung like a horse - literally", "Because... uh... shoot. I love the color of your eyes, you know?", "What?! WHAT!! YOU PERVERT! GET OUT! GET OUT!" }, { "Sup?", "Diggity!", "Er, goddamn thug wannabes..." } };

//Code that reads user response here and stores it in an integer named bob, bob being the, uh, integer that determines what the query was.
//In a real scenario, you'd iterate through a list of keywords and try to make a 75% match between what the user asked and what the AI knows.
//But this isn't real, is it?

int bob = 1; //He's trying to make love to me!
Random rand = new Random(); //A new random number generator.
Answers[Question Asked][Responses available]
Console.WriteLine(topic.Answers[bob][rand.Next(0, 2)]);

Its really quite trivial to manipulate arrays in a basic way - they're the equivilent of  a mathematical matrix, except that they can be strings, characters, integers, or custom datatypes (you can make an array of Topics[] if you wanted!).

I'm pretty sure Python has the concept of arrays - they're very powerful constructs for some things, and I don't think that Guido von Russam would've left'em outta the langauge for too long.


Title: Game Concept: Technical
Post by: Kay on October 06, 2004, 10:05:25 PM
For the sake of my blood pressure, I'll bug you about code again. I've got the basic dialogue system working in Python already, but I can't translate it into C#. For instance:

Code:
  class DlgLine
    {
        public string text;
        public LineReq req1;

        public DlgLine()
        {
            this.text = "Test text";
            this.req1 = new LineReq();
        }
    }
...defines a simple version of the dialogue line, where a LineReq is another class. Then:
Code:
          ArrayList squirrel = new ArrayList();
            squirrel.Add("A");
            squirrel.Add("B");
            squirrel.Add("C");
            return squirrel[0].ToString();
...returns "A", with no problem. But:

Code:
          ArrayList squirrel2 = new ArrayList();
            squirrel2.Add(new DlgLine());
            squirrel2.Add(new DlgLine());
            return squirrel2[0].text;
...gives an error: 'object' does not contain a definition for 'text'. Changing that last line to "return squirrel2[0].GetType().ToString();" returns "DialogueDemo.DlgLine", so the program acknowledges that entry 0 of squirrel2 is a dialogue line, but vigorously denies that it has a property called 'text'. (I also note that the 'Item' property of ArrayList, while mentioned in the docs, doesn't seem to exist.) What's going on?!

The topic structure DlgTopic has a variable called "lines" which is an ArrayList into which I put DlgLines. I make an instance of DlgTopic called "topic". All I'm trying to do is call "topic.DisplayLine(0);" for an existing instance of the topic structure and have that function return this.lines[0].text; I haven't even gotten to line-selecting code here.

And if I distribute a working demo, do I distribute the 'solution' file that the IDE builds? I see no information here on making an actual EXE.

Thanks a lot for any help here.


Title: Game Concept: Technical
Post by: Threed on October 07, 2004, 08:23:42 AM
Alright, if you're using .NET 2.0, there are two types of lists:

ArrayList returns an object that must be cast to the proper format - it is slow, but not terribly slow, and mostly used for heterogenuous arrays, where you might have a string, then an integer, than an... you get the jist.

The other list, List<>, is in System.Collections.Generic; it works just like the ArrayList, except that it is a homogenuous data-type - there can be only one!

Using a List<> works like this:

List<int> bill = new List<int>(); //This list only holds integers, and there's no reason to cast them to integers, because they are!
int ted = bill[index];

You'd use, List<DialogType> dialog = new List<DialogType>();
and then, DialogType diggy = List<DialogType>[Index[;

If you want to keep using ArrayLists, you'd use this:

ArrayList ted = new ArrayList(); //HOmogenous array - add whatever.

And then, to retrieve,

return (ted[INDEXOFMYLEWT] as string).text;

Or,

string text = (ted[INDEXOFMYLEWT] as string);

Or,

string text = (string)ted[INDEXOFMYLEWT];

Yo.

On the Item property

The 'Item' property means that you can access a data structure like you would an array.

Its the []s in ArrayList[INDEX];

It means that you can grab a particular ITEM from the array doing this: [].
ArrayList[INDEX] returns an ITEM, usually an object that needs to be cast to the proper datatype (int, string, MyFavoriteDataType), etc.

On distribution

Nope, compile the application, and surf to ProjectDirectory/bin/(Release or Debug, depends on how youbuilt the application)/ProjectName.exe

Distribute, but know that, like Python, peeps will need the runtime installed.

Most peeps already have the runtime (thanks microsoft!), but inevitably, there will be someone who does not. They can go here:

http://www.microsoft.com/downloads/details...&displaylang=en (http://www.microsoft.com/downloads/details.aspx?FamilyID=916ec067-8bdc-4737-9430-6cec9667655c&displaylang=en)

Its all point 'n' click, just like everything else microsoft.
Errata

You can AIM NuklearToast if you need more help in a hurry and I'm online. ;)


Title: Game Concept: Technical
Post by: Threed on October 07, 2004, 08:26:39 AM
To be more poignent,

Code:
    ArrayList squirrel2 = new ArrayList();
           squirrel2.Add(new DlgLine());
           squirrel2.Add(new DlgLine());
           return squirrel2[0].text;
should be,

Quote
ArrayList squirrel2 = new Arraylist();
squirrel2.Add(new DlgLine());
squirrel2.Add(new DlgLine());
return (squirrel2[0] as DlgLine).text;


Title: Game Concept: Technical
Post by: Kay on October 07, 2004, 04:13:13 PM
Thanks! Success so far using List<>s. Will update when I have something worthwhile in C#.


Title: Game Concept: Technical
Post by: dronon on October 13, 2004, 10:43:47 AM
I may have missed the opening messages in this thread or may be misinterpreting the nature of the discussion, but if you're looking for a PC graphical adventure game engine, there's Adventure Game Studio (http://www.adventuregamestudio.co.uk/).  I'm personally biased towards games having a good story and well-integrated puzzles - not so much 3D or AI elements.  Although the latter are easier to market.  :)
 


Title: Game Concept: Technical
Post by: Threed on October 13, 2004, 02:59:10 PM
Quote
I may have missed the opening messages in this thread or may be misinterpreting the nature of the discussion, but if you're looking for a PC graphical adventure game engine, there's Adventure Game Studio (http://www.adventuregamestudio.co.uk/).  I'm personally biased towards games having a good story and well-integrated puzzles - not so much 3D or AI elements.  Although the latter are easier to market.  :)
I can see what you mean. I'm more of an immersion fan myself. I like getting "lost" in the world. ;)


Title: Game Concept: Technical
Post by: Kay on October 13, 2004, 06:18:31 PM
Quote
I'm personally biased towards games having a good story and well-integrated puzzles - not so much 3D or AI elements.
Quote
I'm more of an immersion fan myself.

Take a look at the messages more than 30 days old to find the origin of the AI talk -- in "What was/is ItE for you?", I think. The reason I brought it up is because I think AI can be part of a new level of immersion in games. In "Ultima VII," shopkeepers held regular hours and went home at night; in "Morrowind," NPCs had access to a wide range of dialogue about their race, job, homeland, etc.. What I expect will happen is that someday there'll be a living world inside the game, and you'll be able to go around chatting with NPCs and making your own plots independent from anything the game designers explicitly put in.

PC: "So, Bob, how are things in town?"
NPC: "Well, we've had a hard winter, so the wolves are coming down from the mountains and eating our livestock."
PC: "I'll take care of it."
NPC: "But the City Council awarded the job to the Mages' Guild since you weren't around, and they'll be ticked if you embarass them..."

The kind of AI that can do that puts game designers in the position of building the world rather than needing to write a story.

By the way, a magazine recently announced details on Bethesda's upcoming sequel to "Morrowind": "Oblivion." In this sequel, NPCs are expected to have goals and be able to execute them in several ways, with the example of a bum who might get food by hunting, by buying, or by robbing the PC depending on which is easiest. That's pretty good. I hope they don't all stand around waiting for you to talk to them, though.

Re: my own tinkering: C# is taking too much time to learn, considering that I'd have to scrap all my existing code to use it and that the main benefit is getting a Windows interface. (The hassle that finally stopped me: evaluating a string containing a variable name to get the variable's value. Threed, you don't need to provide the answer.) For the moment I've gone back to Python and quickly gotten window and button code working. It's still interface work but is closer to letting me work on the actual AI again.

My present goal is to produce a partly graphical online game kind of like "Furcadia," for the sake of having many AIs walking around interacting with humans. The AI is the most important part, so I have to balance my effort between that and making something playable (which means deciphering multi-user network code). Maybe it's vaporware, but it gives me something to shoot for beyond "Do something with AI."

Screenshot (110KB) here: 2K4 Fall Screenshot (Oct 13) (http://www.xepher.net/~kschnee/2k4fall-big.jpg)


Title: Game Concept: Technical
Post by: Calbeck on October 25, 2004, 04:46:45 AM
I think that, insofar as ItE combat is concerned, AI should follow a comparitive progression:

1) Self-Preservation.  Anyone who takes 25% damage will have this kick in, forcing them to Retreat In Good Order, meaning they back away from their foe(s) towards a known "safe point" at a speed somewhere between a walk and a jog.  If allowed to get far enough away, they will turn and run for the "safe point" (could be home, could be a nearby guardshack, the main body of the army, etcetera).  50% damage induces Rout, whereby they IMMEDIATELY turn and run away (this opens them up to a back shot which could be lethal, though).

They will do these things UNLESS there is an overriding factor involved.  Overriding factors would include not being ABLE to retreat --- backed into a corner or trapped partly beneath a cart, whenever the pathfinder can't find a safe path to a safe point the AI.  When this is the case, the AI will either fight to the bitter end or (if the Hero's reputation is Good and well-known) surrender outright.  

Overrides also appear on the battlefield, where Officers keep command of the rank and file.  A packed formation has little option but to do as ordered, both as a matter of pride and fear --- pride in terms of what the other men in the company think of you, and fear in terms of what you'll be branded as if you run.  Assuming the Captain's sword doesn't put an end to your cowardice before the enemy does!

This is the kind of "enforced courage" which allowed such things as the Charge of the Light Brigade and Pickett's Charge to occur --- neither had a realistic chance of victory, but the dishonor of not giving your best was considered worse than death.  Conversely, if a unit's Officer fell, it was not considered untoward for that unit to take defensive measures --- such as taking cover, dropping back, or even returning to the baggage trains --- in absence of "trained leadership".

Thus, I suggest that military units have their morale slaved to the Officer in charge --- if HE runs, it must be okay to follow suit, right? -:)

2) Objective.  The thief wants your pocketbook.  The gypsy wants you to toss him some gold.  The Boar Noble wants you to apologize for not groveling properly as you pass him in the street.  The Major wants you to take your company and seize that hill from the unit of enemy pike.

All of these are Objectives.  Any AI will try to achieve its Objective, but not at the cost of Self-Preservation (note Overrides).  The thief will slip back into the crowd and look for another target if you look directly at him and unsheath your sword.  The gypsy relents from his begging when you snarl at him.  The Boar, being a Boar, has to take 50% damage in the ensuing battle before he realizes you just MIGHT WELL KILL HIM.  Run away, run away!  Squuuuueeeeeee! -:D  And the Major?  Well, just come back with your shield or on it, lad...

Thus, no battles should really be "to the death" except in rare dueling or common military circumstances.  

I also suggest that access to weapons be a limited affair --- they are NOT generally tolerated in the hands of common folk!  You only have one since as a courier you are expected to protect your messages and packages, many of which will naturally go to Nobility.  Weapons among the peasantry are essentially whatever they have handy, mostly clubs or sharpened farm implements.  More advanced weapons are the prerogative of official military forces, or might rarely be found amongst brigands.

Therefore, weaponry descriptions should be limited to "this is better than that" --- no need to belabor the fine points --- and should only wind up in the Hero's possession via military issue or taking off the body of a dead criminal.  Note that this means most weapons will only be salable to actual Houses, unless the Hero wants to engage in black marketing.  In which case he's selling either to criminals or rebels and should hope he's not caught doing so!

I think that by keeping it fairly simple, this will prevent the game turning into a tactical simulation and keep the goal of immersion on track.


Title: Game Concept: Technical
Post by: Kay on October 25, 2004, 04:03:06 PM
What I've got at the moment is a nearly-working text-based game with the potential to send non-text data like images. There's a server program running the world and AIs, and a client program sending/receiving data. I think it would work online.

But that's a far cry from a real game. I'm still at a loss between focusing on the AI and focusing on making something playable. Next programming binge, I expect to firm up the client/server code so you'll be able to connect via client and walk around in a tiny text-based world, basically a crude MUCK. Then I have to decide where to go from there.


Title: Game Concept: Technical
Post by: Threed on October 26, 2004, 02:24:46 PM
Quote
But that's a far cry from a real game. I'm still at a loss between focusing on the AI and focusing on making something playable. Next programming binge, I expect to firm up the client/server code so you'll be able to connect via client and walk around in a tiny text-based world, basically a crude MUCK. Then I have to decide where to go from there.
Playable! What good is a technology if nobody uses it?


Title: Game Concept: Technical
Post by: Threed on October 26, 2004, 02:51:25 PM
Oh, and, uh, google for "Model View Controller pattern" to save yourself a serious headache down the road.


Title: Game Concept: Technical
Post by: Threed on October 28, 2004, 11:19:44 AM
(Talking to himself, don't mind the crazy)

Why," what's the 'Model View Controller pattern'?" you might ask?

Its a method of abstracting Data (Model) from Rendering (View) and Input (Controller).

In this case its a cheap and easy way of taking care of business with regards to making a game AND an AI: the AI is the Model, the presentation is the View (you can ahve multiple views if you architect it right!), and the Input can be the game logic!

Wow. Amazing. Utterly amazing.

 


Title: Game Concept: Technical
Post by: Kay on October 28, 2004, 12:37:30 PM
I've posted the version 4 demo from months ago, here (http://www.xepher.net/~kschnee/aboutniss.htm). (It was a version I had lying around as a prepackaged EXE with built-in help screens.)

I plan to make and release a new version Real Soon Now based on the new text-based code. The main problem seems to be that I don't know what I want. The MVC Pattern sounds like good theory compared the mess of code I have. Considering that I don't really want to become a MUCK administrator, maybe I'll reorganize everything so that:
-The server program has a View class.
-A View has a flag indicating Local or Online. Local Views have a graphical window; Online Views have a net connection. (Not sure how to handle the storage of messages to be sent to/from these Views.)
-Program starts with a Local View, not connected to a character... not sure how this should be linked to the Controller, as my code has Windows-like controls that are both input and output.

Will have to look at the article again. The server program still gives you control over a Player character; I guess the main thing is to reorganize that so it uses the new I/O, and change the world-sim a bit, and not mess with the online code.

Another issue is that the AIs are supposed to be in the world-sim, so which one's the Model? As much as possible I'd like to treat them like human players (the Player is really a lobotomized AI instance), using the same kind of code to interact with the world-sim except that they're constantly pinging the sim to sense their surroundings. It'd be cool if a human could possess an NPC for a while and have the NPC still learning from its experiences, so that one day your friend will go offline and you won't notice for a while.

"I see you've switched characters... Mister Anderson."

Quick update Thursday night: Good progress. Implemented a controller/view system that looks sane, but haven't tried hooking an AI up to it. Next: make the world-sim presentable and have a demo of walking around in the world with a brain-dead AI.
(http://www.xepher.net/~kschnee/ayb.jpg)
(Screenshot from an interface test)


Title: Game Concept: Technical
Post by: Threed on October 28, 2004, 02:45:04 PM
"The model is the who is the what?!" you say? Well, its O-K-DO-KAY.

Controllers invoke methods in models; thus, you can implement the AI as both a model and a controller of another model (=D).

Don't cut, copy, and paste this: its insane.

//Model of AI logic.
class AI
{
//...AI logic.
public method Think();
public method EatPretzals();

}

//Model... this is one of avatar class.
class Avatar
{

public method DestroyPlanet();

}

//Controller - execution of AI logic.
class Controller
{
private MyAI of type AI;
private MyDataModel of type Avatar;

}

Controller.MyAI.Think(); / AI is done thinking about what it wants to do, so, do that.

Controller.MyDataModel.DestroyPlanet(); //AI was feeling rash.


Soemthing, something, its the medication talking, don't mind me!


Title: Game Concept: Technical
Post by: Kay on October 30, 2004, 03:56:03 PM
New demo available for download here (http://www.xepher.net/~kschnee/aboutniss.htm). Unlike in the old demo, I didn't use the actual AI much, so that they're just sitting there, but you can walk around in a text-based world using nifty model/view/controller architecture and other complicated code that doesn't actually do much. Anyway, it establishes a tolerably-coded "worldsim" and playable interface.
(http://www.xepher.net/~kschnee/2k4fall2-small.jpg) (http://www.xepher.net/~kschnee/2k4fall2-big.jpg)
Click for bigger screenshot

By the way, the AI architecture (which is just sitting there uselessly) looks more like this:

def Go():
----RunPhysicalNeeds() # Hunger, thirst, etc. generate goals.
----PickGoal() # Select highest-priority goal
----DoGoal() # Interact with the world
----AICycle() # Form associations between neurons, form episodic memories, etc.

What next? I don't know. Get the AIs moving around again, I guess. It's frustrating that the worldsim's so simple there are lots of things it can't do, but every time I rewrite it, it delays my getting back to the actual AI which was the original point of the thing. Guess I should focus on keeping it playable.

I could use opinions from anyone who's played both demos.


Title: Game Concept: Technical
Post by: Kay on November 12, 2004, 09:29:07 PM
Now I've got parts of the dialogue system reactivated/rebuilt/refurbished. An AI's default response to dialogue is to try interpreting it by some complicated guesses at the parts of speech; failing that, it uses some Morrowind-style dialogue topics. It's doing something flaky in its responses that I have yet to investigate, and of course it's really dumb, but what I've got now is:

-Graphical interface with scrollable text window; could easily create buttons etc.
-Model/View/Controller architecture
-Ability to log in as any character, even one that's normally an AI (This was a serious pain.); could keep learning functions on even while an AI is "possessed"; minimal distinction between PC and NPCs
-Text-based game world (12 rooms with a few objects)
-AIs that gather sensory input from nearby characters and objects, storing information on new ones
-A few crude dialogue responses using multiple systems for generating a response; AIs don't care whether input is coming from a human -- in fact two AIs in the same room will at this point endlessly talk at each other

I hope to release a new demo soon. Next, I don't know. Going back to graphics? Getting online connections working? Or focusing on making the AIs move again, and making the junky text-based world interactive enough to restore the "X causes Y" learning code? Or continuing to work with the dialogue?

Have you ever been unable to log out? --Tsukasa, ".hack//SIGN"


Title: Game Concept: Technical
Post by: Threed on November 13, 2004, 12:04:56 PM
Looks like you've been busy these past few weeks.

What kind of AI are you using; state-machine based?


Title: Game Concept: Technical
Post by: Kay on November 13, 2004, 01:34:49 PM
That's a set of standard "modes" with fixed behaviors for each, with the AI switching modes according to certain conditions like the chasing/fleeing ghosts in "Pac-Man," right?

Not really. The core of it is a list of goals. The main program runs a function called Go() for each AI. Go() picks a goal from its list, tries to execute it, then does other stuff like sense its environment. Goals are things like AddGoal("say","How are you?") or AddGoal("walk","n",1). They can be added by anything, so I could for instance write a system command that forcibly adds a goal to an AI to say something.

AI gets "say" goal, AI chooses "say" goal, AI executes goal by sending message "say foo" to its Controller, Controller sends message to World, World handles command by broadcasting message "foo" to the Views of all characters in the room, Views either display text on the screen or call an AI's SenseInput() function depending on whether they're NPCs, Johnson passes to Smith and... Touchdown!

My AI is like the print function, only much more complicated.

The dialogue system is kind of cheating because it always generates a Say goal. (sing old video game startup sound: "Say-goal...") As a result, if AI #1 says something and AI #2 hears it, 2 gets a SenseInput about it, recognizes it as dialogue, generates a response, talks, triggers 1 to respond, etc.. I don't know what to do about this.

Currently messing with a 2D emotion system and how to display it, using some graphics from "La Pucelle." Douglas Adams said that if a robot were given the ability to be happy or bored, it could figure out the rest itself. Good enough theory, though modern cog. sci. people favor a six-dimensional system of human emotion.
(http://www.xepher.net/~kschnee/fnz.jpg)
(Using this for unhappy, not excited/bored)


Title: Game Concept: Technical
Post by: Threed on November 13, 2004, 04:27:41 PM
I think your method is called the "reactive paradigm," wherein stimulous determines the reaction.

Finite state-machine based is based on the theory that you can only be in one state at a time; some states are transient, and once they end they fall back to the last state they were in: You might change the state of an AI currently in DefendState to MoveState, and once they have finished moving they fall back to the last state they were in provided that nothing nearby (enemies, etc) trigger a new state like AttackState or BustAGrooveState.

"Enemy sighted! Moving to intercept."
(MoveState. There are counters to determine how far the AI will go and wheither it will get bored or not).

"Enemy is within attacking range. Moving to attack!"
(AttackState. Attack while the enemy is within range.)

"Enemy is moving away! Moving to intercept!"
(Movestate, triggered by the enemy moving out of range.)

Essentially using "states" means that they control the flow of the AI by triggering other states, though if the user ever figures out what values determine a state change they can probably trigger them at will if its as easy as wielding another weapon and turning six degrees to the left.

---

How do you handle concurrency in tasks without hardcoding responses? AKA, "I need to pick up fruit: so, I need to move six feet forward, and -- oh crap, someone just attacked me!" and the issue of reactance? What happens when the AI runs out of goals to do, are new ones randomly generated or what?


Quote
As a result, if AI #1 says something and AI #2 hears it, 2 gets a SenseInput about it, recognizes it as dialogue, generates a response, talks, triggers 1 to respond, etc.. I don't know what to do about this.

Well, for one, you should probably use weighted values to determine the response to SenseInput(), the same way you'd do in a state machine - if AI chatter is causing too much of a headache, start weighting values: if AI #1 has a low-threshold for yakking, increment, say, "boredom" + 1 every time the AI says something. Then, once boredom > 5 or something similar, trigger another AI Goal (this would normally be a state change in a state machine); this could be something as simple as walking away or stop talking or just randomly attacking something. Or it could say something offensive that would hopefully make AI #2 know its role!


Title: Game Concept: Technical
Post by: Threed on November 13, 2004, 04:30:34 PM
Alternatively, you could use a random element to determine the odds of the AI doing something "else" in response to the stimulous instead of the normal response.

I think you'd need to start using abstract classes if you did either of my suggestions, though, so you could still have different AI models.


Title: Game Concept: Technical
Post by: Kay on November 13, 2004, 09:22:54 PM
bust_a_groove_state = True

Quote
How do you handle concurrency in tasks without hardcoding responses? AKA, "I need to pick up fruit: so, I need to move six feet forward, and -- oh crap, someone just attacked me!" and the issue of reactance? What happens when the AI runs out of goals to do, are new ones randomly generated or what?

By my model:
-AI has goal "pick up fruit." It's not in reach. Add goal "walk towards fruit."
-Start executing goal "walk towards fruit."
-Enemy attacks! Receive sensory inputs (self, "feels", "pain"), ("ninja","is","description").
-Next iteration of ProcessSensoryInputs: "pain" triggers a new goal with higher priority than "walk towards fruit," though I don't know what that goal would be.

Each goal has a priority, and it picks the highest one, so attacking ninjas could pre-empt fruit collection.

When there are no goals, the AI sits there until its sensory input or physical needs trigger some. Currently I have PhysNeeds calling AddGoal("wander"), so every so often the AIs consider randomly moving around. When I hooked PhysNeeds back up, I found that the program crashed because the AIs were trying to call some forgotten eating code in response to their draining energy... that was cool. I eventually got it working, so every so often they whip some Tofu (description: "evil") out of nowhere and eat it, recovering energy. If I changed their Pulse rate or had movement drain their energy faster, they'd eat more often.

Re: dialogue, yes. I'll probably have to increment boredom (decrement "alert") or something like that to make them shut up.

Will release a demo after trying another feature and figuring out why Niss keeps yakking about the "machine" topic.

The emoticon system makes me daydream about having an AI do a LiveJournal... It'd be full of entries like "I spent all day staring at an acorn!" though. I know it can write text files and make Net connections. Maybe it can send e-mails and be a true Spambot?

A productive day! Lots of coding plus actually understanding some more of Civil Procedure law!

I am, by the way, going to Midwest Furfest next weekend.
(http://www.xepher.net/~kschnee/mzn.jpg)
(Reaction to Civil Procedure and coding errors caused by indentation)


Title: Game Concept: Technical
Post by: Kay on November 14, 2004, 06:49:06 PM
New demo is up!
NISS Home Page (http://www.xepher.net/~kschnee/aboutniss.htm)

Here the AIs are moving around some, and you can talk with them and order them around... some. Still cruddy, but improving.

(http://www.xepher.net/~kschnee/mpp.jpg)


Title: Game Concept: Technical
Post by: Kay on November 16, 2004, 09:12:10 PM
AI
With the practical goal of a playable game in mind, this is the order in which I'd get game AI working if I had a specific graphics engine to work with:

-AI Level 1: Standard RPG villagers. Features: "Stand there," "wander randomly," "wander in fixed ares," "move in fixed pattern"; single-response dialogue system. Equivalent to most console RPGs even today.
-Level 2: Morrowind-type. Features: "Stand there," "wander," "chase/follow target," "avoid"; topic-based dialogue system (lets you ask about various topics linked to NPCs' race/class/etc. and PC's reputation). Have basically built this level in Python and some of Level 3. Level 2 is probably good enough for finished game, to be improved upon as time permits?
-Level 3: NISS-type. Features: The above plus "daily work schedule," "seek food/entertainment/etc.," "converse with other NPCs"; some sort of building-block dialogue system to have more complex conversations without having to parse arbitrary English sentences.
-Level 4: Insert-apocalyptic-name-type. Features: The above plus the option to parse any dialogue the PC types; link to speech recognition/synthesis software?! More advanced than we can really expect; less important than the rest of the game.

Pending the discussion about graphics engines, when I next work on my code I'll focus on using a crude graphical world again so I can make Level 1 characters. That is, I'll turn off some AI features and get the MVC architecture working with a 2D world instead of text-based rooms.

These might be obvious, but in some other departments we'd want:

Graphics
-Graphics Level 1: Placeholder graphics; sprites of some kind walking around in a 2D world.
-Level 2: Height differences, ie. buildings sticking up from the ground, characters walking up stairs and slopes. Portals linking game areas, ie. doors to interiors if they're to be separate areas.
-Level 3: Objects. Barrels, boxes, shrubs, lampposts, chests, trees. A "script" system that notifies objects when they're hit/grabbed/etc. so they can run certain actions; data on each object (like weight) so PC can try to pick up, eat, or break anything in sight! Objects act as obstructions to block paths and to walk on; you can build a staircase out of crates. Real art for characters and world.
-Level 4: Fancy camerawork, lighting effects, cool backgrounds.

Gameplay
-Gameplay Level 1: You can walk around.
-Level 2: Basic menus (save/load; use item; talk). Movement through portals (eg. to/from world map); activation of game scripts linked to stepping on certain spots (eg. stepping through the castle gate triggers a scene where someone appears and talks to you).
-Level 3: Interact with objects and characters (hit/take/use/talk/throw?/others?)
-Level 4: Customize character: name/title/race/sex/clothes/equipment. Store data on these and on PC's reputation and history.

Writing/World-Building
-Writing Level 1: Figure out the basic theme and plot! Eg. are we using the weather-control device as a central plot and gameplay mechanic?
-Level 2: Pick locations to build, start developing specific plot events. Build Spartan but playable game areas.
-Level 3: Game areas that look nice; plot events written and worked into game.
-Level 4: Subplots and side-quests; polishing.


Title: Game Concept: Technical
Post by: Suule on November 18, 2004, 03:24:45 AM
Quote
Graphics
-Graphics Level 1: Placeholder graphics; sprites of some kind walking around in a 2D world.
-Level 2: Height differences, ie. buildings sticking up from the ground, characters walking up stairs and slopes. Portals linking game areas, ie. doors to interiors if they're to be separate areas.
-Level 3: Objects. Barrels, boxes, shrubs, lampposts, chests, trees. A "script" system that notifies objects when they're hit/grabbed/etc. so they can run certain actions; data on each object (like weight) so PC can try to pick up, eat, or break anything in sight! Objects act as obstructions to block paths and to walk on; you can build a staircase out of crates. Real art for characters and world.
-Level 4: Fancy camerawork, lighting effects, cool backgrounds.
Level 1: No problem. I'm currently working on it.
Level 2: (WORKING) 2D - I think that the system used in Adventure game studio with few mods could just be it. The portals and such won't ba a problem too. (DESIGNING) 2D Isometric - Height diffrences can be a bother here since we'll have to do diffrent layers that overlap one over another (like Fallout: BOS)
Level 3: (DESIGNING) I think we should adapt something from visual programming like 'event handling'. Every object should've data fields 'On***' (give/hit/grabbed/picked up/etc.) with a pointer to a script that should be run.
Level 4: I haven't thought of any yet (except may be lightning effects or backgrounds)

Well we should do an Alpha first with let's say 'Stick Man' that walks around the screen using the mouse.

Oh and a very important question: WHAT resolution should we use?

Quote
-Gameplay Level 1: You can walk around.
-Level 2: Basic menus (save/load; use item; talk). Movement through portals (eg. to/from world map); activation of game scripts linked to stepping on certain spots (eg. stepping through the castle gate triggers a scene where someone appears and talks to you).
-Level 3: Interact with objects and characters (hit/take/use/talk/throw?/others?)
-Level 4: Customize character: name/title/race/sex/clothes/equipment. Store data on these and on PC's reputation and history.

Level 1: Working on it
Level 2: Menus: I think here we should adapt some of the joys of SCUMM-like interface. The 'hot spots' and 'transitions' should be coded in level 1 I think, while the scripting language that supports them should be done in level 2.
Level 3: As I said: do EventHandles for scripts 'On***' for example OnUse stores a number 321 which is the number of script that should be triggered when the object is used.
Level 4: That'll be the worst part. I can use take something from my Roguelike and convert it to C++

Quote
Writing/World-Building
-Writing Level 1: Figure out the basic theme and plot! Eg. are we using the weather-control device as a central plot and gameplay mechanic?
-Level 2: Pick locations to build, start developing specific plot events. Build Spartan but playable game areas.
-Level 3: Game areas that look nice; plot events written and worked into game.
-Level 4: Subplots and side-quests; polishing.
Level 1: I presented the basic plot outline in the second topic.
Level 2: I'm doing some location sketches. The problem with them will be what size should the locations be. Give some basic ideas on the size of them ( should the fixed length backgrounds be scrolled? Will the isometric areas be rather big or small?
Level 3, 4: We can discuss that after doing a workable alpha.


Title: Game Concept: Technical
Post by: Kay on November 18, 2004, 12:30:34 PM
Level 1 AI
I whipped up a demo of one this morning. It's state-based and has only "standthere" and "wander" states at the moment, but could be hooked into a graphics engine to demo characters walking around.
http://www.xepher.net/~kschnee/aidemo.txt (http://www.xepher.net/~kschnee/aidemo.txt)
(From latest main-AI dialogue demo: "Tofu is an evil thing." I'll know it's time to stop the main AI project when my diagrams of it start looking like the kabbalistic sephiroth (http://www.telp.com/tarot/tree.htm).)

Graphics
@Suule: "Adventure Game Studio" doesn't look very good; I hope you just mean in that general style (and only for some scenes) rather than actually using that engine. I think we want at least 800x600 resolution with at least 16-bit colors. We could go higher, but at that point the quality of the art matters more than the resolution. (Bad 1024x768 is slower than bad 800x600 without being prettier.)

@Threed & Suule:
It's great that you're already working on an engine, Suule, but is it going to be able to do Cool Stuff? It seems like there are some substantial things like camera tilting/rotation and automatic lighting that are at least hard with homebrew. The most obvious way I (at least) can think of to do isometrics would limit the camera angles to the four diagonal directions, and would force artists to draw wall textures in little parallelograms. And what language is that in?

:blink: I just found the SDL page's link to Python bindings. SDL + Python = Pygame! It sounds like using SDL to write an engine that works with Python would mean basically doing what I've already done poorly: make our own multi-layer tiled graphics engine. But then I guess we'd be doing that in OGRE too. For that, should we be looking at the "Yake Engine" or "Crazy Eddie's GUI" or any of the other pre-made things under OGRE? I note that PyOGRE seems to rely on .NET.

What do you think about tile size, or how many tiles "wide" the screen will be? If we've got a mobile camera we can zoom in and out, but still have to pick a texture size and a size for characters. I suggest making the 3D blocks 1/3 or even 1/4 the height of their width and length, so that a character can climb stairs that look like a plausible height. Have to think about vertical texture size, though; wouldn't want to have a wooden wall that obviously has the same texture printed on it four times per tile-sized section.

I'll have limited Net access from Fri. noon to Mon. afternoon, but will try to check in.  


Title: Game Concept: Technical
Post by: Threed on November 18, 2004, 02:24:49 PM
PyOGRE is not .NET dependent; it just requires use of the Visual Studio 2003 C++ compiler - which is a free download from Microsoft. PyGame is a Python wrapper for SDL with a few things built on top; its a bit of a higher level abstraction that deals with concepts like sprites instead of raw images, automatically handles movies, dadda dadda dadda.

Crazy Eddie's GUI is an abstract GUI system that happens to have implementations under OGRE, Axiom, and some other engines. Yake, last I checked, was C++ based with using Lua as a scripting language.


Title: Game Concept: Technical
Post by: Suule on November 18, 2004, 02:56:16 PM
Quote
Graphics
@Suule: "Adventure Game Studio" doesn't look very good; I hope you just mean in that general style (and only for some scenes) rather than actually using that engine. I think we want at least 800x600 resolution with at least 16-bit colors. We could go higher, but at that point the quality of the art matters more than the resolution. (Bad 1024x768 is slower than bad 800x600 without being prettier.)

@Threed & Suule:
It's great that you're already working on an engine, Suule, but is it going to be able to do Cool Stuff? It seems like there are some substantial things like camera tilting/rotation and automatic lighting that are at least hard with homebrew. The most obvious way I (at least) can think of to do isometrics would limit the camera angles to the four diagonal directions, and would force artists to draw wall textures in little parallelograms. And what language is that in?

Yeah it doesn''t. It has some good ideas but NASTY code optimalizations. I think of transmitting those ideas into our 2D-engine and re-writting them to make the code optimized and therefore fast. And what's more. I need the engine myself cause when I started designing an adventure game (based on my old ideas) none of the game-creator would suit my needs.

GRAPHICS:
The ONLY bitdepth I would accept would be 32-bit. Cause it's faster (instead of operating on 5-bit and 6-bit data nibbles we use full bytes and an alpha channel, so we don't have to deal with software-coded transparecny) and easier to implement on modern day cards. 800x600 is fine and I was gonna propose it myself if there wasn't an idea for it. Most of today's games use 800x600 as deafult.

In isometric mode. I though of using OpenGL instead of 2D isometric graphics, since it'll be faster... I tell you what. What if we'll SPILT the engine into various parts and linked them together? We need 2 Engines that have a similar object-handling/scripting system with diffrent views needed. Since we all be basing on SDL as the base of the project (OGRE uses SDL, right?) the only thing that would link our project would be that we would use the same data structures for objects. Threed can take care of Isometric part, while I code the indoor/flat BG part. How does that sound? And the language I would use would be of course C++ (Borland Compiler).  


Title: Game Concept: Technical
Post by: Kay on November 18, 2004, 04:47:26 PM
As far as I can tell, OGRE (http://www.ogre3d.org) isn't built atop SDL. It's written in C++, can use Direct3D and OpenGL for its drawing, and can be commanded by various languages.

800x600 32-bit graphics: Sounds fine.

Daydream: If we have code that casts dynamic light/shadows, and can poll what the light level is at the player's position, that's an easy way to add a bit of "Thief"-style stealth gameplay.

Split engine: Hmm. How are we going to coordinate code? Say you or Threed builds a playable stickman-controlled-by-player demo. How do I get my own AI code into that?

Class design
With NISS and the dumb-AI demo I posted earlier today, I made the PC and NPCs instances of the same class, with the main difference between them being that the PCs have "controlled_by_human = True" and that causes all the learning and decision-making code to be skipped over. I'd advise doing something similar: creating a generic Character class to hold the basic physical attributes like location, name, and race, so that AIs can be a subclass of that. To interact with the world, my AIs need some way to send commands to the world ("step north", "say 'Hello'", "use saxophone"), and some way to sense it. ("Can I see an object of type 'weapon?'" "What's the description of the objects in my field of view?") Currently they're using Views and Controllers that pass text messages back and forth, and when a NISS executes a walk-north command it's actually sending out the message "move north" to the world.

I'll dust off and post some of my item code, though it's not great and I don't have time at the moment to fully comment it. The Cliff's Notes version of the structure is:
-Items have names, types (possibly several), short descriptions that AIs can read, long descriptions that sound cool to humans, possibly other descriptions that come up when the object is "felt" or "tasted" etc., and an attached script #.
-The script # gets called whenever anything interacts with the object, and possibly based on a timer. The running script gets passed the calling object's identity, and the reason it was called (like time or character "Bob" performing action "eat" on it). It then does cases. ("If called because of eating, set the eater's status to "Poisoned.")
-Objects have a weight #. If characters have a Strength rating, this gives you an automatic way to rule that an Ox can throw stuff that a Mouse can't even lift.
-It'd be a good idea to have other tags like "flammable," "fragile," (or Durability, or HP) and "magnetic." Then you don't need a list of what objects can interact with what others; instead a flame spell "naturally" sets appropriate stuff on fire.

The philosophy behind that tagging is in this great interview with one of "Deus Ex"'s creators (http://www.igda.org/articles/hsmith_future.php): building everything as objects that can be interacted with in standard ways creates the possibility of players finding fun, unexpected ways to use the environment. (Ideally, if I saw a tree I'd be able to climb it by "grabbing" or "pulling" it, cut it down by attacking with a weapon, or carve initials in it.)

Quote
...I had an opportunity to see the demo for an upcoming game... [Sounds like "Morrowind." -K] The game seems to feature an extensive set of player tools and powers. However, most of them are purely related to inflicting damage. The rest of the environment is modeled in a very simple way. The game uses a traditional paper RPG-style 'spell' system, which should allow for a great number of interesting player expressions, even if you restrict your thinking to the tactical arena. So, during the demo, I inquired about types of spells that, in paper RPG's, are often exploited in interesting ways beyond toe-to-toe combat. For instance: Can the player freeze the water pool (in the cave featured as part of the demo) as a way of creating an alternate path around an enemy? Can the player levitate a lightweight enemy up off the ground and thus get by it without resorting to violence? Can the player take the form of a harmless ambient animal and sneak past the goblin? Can the player create fake sound-generating entities that distract the enemy? I believe the answer to all these questions is "no." The game was designed around pre-planned, emulated relationships between objects. Had the game been designed around a more flexible simulation, these sorts of interactions might have just worked, even if they had never occurred to the designers. (All of this still might be possible in the special case emulation model, but would run the risk of a great deal of inconsistency, would require tons of work and would not as likely produce emergent results.) Had the game been built around more thoroughly simulated game systems, creating more interesting (less combat-centric) tools would have been easier - the game's possibility space would have been greatly enlarged.

Running around a town throwing stuff, breaking stuff, climbing rooftops, etc. sounds fun even in the absence of a story!

From another interview, re: outdoor environments:
Quote
...wide, empty landscapes with little density of interest. Games like Ultima VII did an okay job of providing something interesting every few hundred yards in the Great Forest (of Yew?). But other, similar RPG's have provided all this wilderness space and allowed the player to walk forever without providing for anything interesting (and often the player has to backtrack out of some cul-de-sac). And a few clones of Sid Meier's Pirates have, for some reason, assumed that sailing endlessly through empty oceans might be fun. Powerful outdoor terrain features have to be thought through, like everything else--they affect lots of things like the optimum player movement speed, which is also tied to other aspects of the game, like the pacing of play. It's not like you can just throw a switch and generate miles of terrain...


Title: Game Concept: Technical
Post by: Kay on November 18, 2004, 08:27:09 PM
Item code posted here (http://www.xepher.net/~kschnee/itemcode.txt). The most useful parts to look at might be the definition of the Item class, and the generic script at the end. (And yeah, I was messing with in-game objects that could do things to the real computer.)

Off to the con tomorrow!

@Threed: Lua? Doesn't that require a grass skirt?


Title: Game Concept: Technical
Post by: Threed on November 19, 2004, 09:03:32 AM
Lua is a scripting language dependent mostly or in large part on a C++ engine that provides it data structures, which can then be manipulated through Lua.

Code whoring: Sule is obviously proficient in C++ (ANSI99 if he's a youngin'), Kay's forte' obviously lies with Python, and mine is typically C# or Boo (AKA, "Python for .NET."). One of these is a language, one of these is a slim language-dependent platform, and one of these is a bulky language-agonistic platform. They each favor different coding styles and conventions; templates in C++, tuples and type inference in Python, tuples, type inference, dadda dadda dadda. Kay's never going to touch C++ - I can tell by the knee-jerk reaction Kay's had to Java and C#, because in terms of complexity, it goes, (least to greatest), Python-->C#/Java-->C++. I write C++ code, but only as a complete and utter last resort - its either Python or Boo or C#, 'cuz I hate dealing with all that mundane shit like pointer arithmetic. Suule... well,  I take it he's hardcore C++ ninja fellah.

Getting Python or C++ to work together (PROPERLY) is very hard; though the Python interpretor is embeddable into C++ code, it requires careful consideration and standards on how you're going to expose C++ data to the python interpretor, and the person doing the python scripting will require YOUR SOUL -- uh, er, they'll require close communication, because in large part how the python code might be structured depends entirely on what's exposed to it by the C++ code. And then, of course, gotta deal with returning values from Python to C++, of which I have no idea how that works; never had to bother. (won't mention C#/Boo, 'cuz I'm biased. Does writing that make me more biased, or less? Maybe if I used 'drugged up on rootbeer and pizza,' would that count?).

Alternatively, it can be written entirely in Python, and thanks to Python's modular approach, speed-intensive modules can be written in C++ and invoked from Python, summoning great DEMONS FROM BEYOND TO CONSUME versatility when you wanna be that way.

*has no real comment towards either, just wanted to make sure everyone understood the issue at hand*

Temple of Elemental Evil used Python for some of its logic - the game was buggy but only because it did not go through QA enough times towards the end. Technology wise, awesome game; grab it for 9.99, download Patch2 and the Circle of Eight patches to make the game playable. Its pretty fun then. Oh, shit, is this a tangent?


Quote
-It'd be a good idea to have other tags like "flammable," "fragile," (or Durability, or HP) and "magnetic." Then you don't need a list of what objects can interact with what others; instead a flame spell "naturally" sets appropriate stuff on fire.

For example:

"All flammable GameObjects implement the IFlammable interface, which requires they expose a public method signature called "Burnination(duration as int, damage as int); thus, when you call FlameAttack(player as GameObject, damage, duration), the FlameAttack() method will check to see if player implements IFlammable; if so, call Burnination(), then the standard Attack() methods; else, just call the standard Attack() method."

That?


Title: Game Concept: Technical
Post by: Threed on November 19, 2004, 09:14:50 AM
Now, having actually read S's reply, I think I can comment some: (=D)

Quote
...We need 2 Engines that have a similar object-handling/scripting system with diffrent views needed. Since we all be basing on SDL as the base of the project (OGRE uses SDL, right?) the only thing that would link our project would be that we would use the same data structures for objects. Threed can take care of Isometric part, while I code the indoor/flat BG part. How does that sound? And the language I would use would be of course C++ (Borland Compiler).

I think he's proposing two completely seperate engines that share a common file-format and scripting language like Lua or Python or whatever. Then, whenever the scene -- no, I take that back, have no idea what he's getting at. I thought it was coding two seperate engines and just switching between them dynamically, or two seperate rendering engines that then overlay a rendered bitmap over one another.

I have no idea what I've even said.


Title: Game Concept: Technical
Post by: Kay on November 19, 2004, 09:54:57 PM
(I'm at a con... Shouldn't I be having more fun? Oh well, it's still Friday. I got so frustrated trying to dig the hotel info out of Firefox's cache that I wrote a quick Python program to search every one of those unlabeled, buried cache files -- and still didn't find it.)

Dialogue Concerning the Two Chief World Systems
I think what Suule meant was to have two systems for drawing backgrounds -- isometric or pre-rendered -- but it sounds like that might also require a different system for movement. If all we need for pre-rendered scenes is to blit a large image to the screen, that's easy in any language, I think.

What about tile-based versus pixel-accurate movement? That is, can you move a fraction of a tile? Half-tile movement could be a compromise, but I don't know how hard that'd be to program. I was thinking of the gameplay as a bit like Zelda, with a basically tile-based world but with the ability to move and throw stuff anywhere. If we have movement in strict increments of one tile, gameplay is probably limited to more of a "Final Fantasy" style and more dependant on plot. Even with strict tile increments we could still have lifting, throwing, and lighting-based stealth, though. How hard is it to do precise movement?

Languages
I'm biased towards using live snakes as the basis for the code. It sounds like we can plug in high-speed ninja C++ or assembly modules for any special needs we have, and for other purposes Pygame lets us use SDL.

Quote
"All flammable GameObjects implement the IFlammable interface, which requires they expose a public method signature called "Burnination(duration as int, damage as int); thus, when you call FlameAttack(player as GameObject, damage, duration), the FlameAttack() method will check to see if player implements IFlammable; if so, call Burnination(), then the standard Attack() methods; else, just call the standard Attack() method." That?
Uh... yes?
I thought of it as, "All flammable GameObjects have flag self.flammable = True. When you create fire, a Fire(range, temperature) message is sent to all GameObjects in range; if an object's flammable is True, it catches fire."


Title: Game Concept: Technical
Post by: Threed on November 20, 2004, 05:50:34 AM
Tile based is not necessarily bad. Using hexagonananalalal tiles, you get much more movement space and it seems more fluid. Alternatively, you can abndon the concept of "tiles" for guiding player movement and just use collision detection, little rectangles around special, impassible entites, to determine wheither a player is allowed to walk through them or not.

Quote
Uh... yes?
I thought of it as, "All flammable GameObjects have flag self.flammable = True. When you create fire, a Fire(range, temperature) message is sent to all GameObjects in range; if an object's flammable is True, it catches fire."
Alright; two means to the same end.

The problem is that you're going to have to add a self.flammable variable to every entity you create. =D Probably not that much, though, if you inherit from a base class... just toggle self.flammable whneverekrjlkjelkfjkljsdlkfjslkdfjslkdf

KAJUTA STAN.

What are you doing?! GO BACK TO THE CON RIGHT NOW.

There might be hot chicks dressed up as sexy fox vixens AND YOU'RE MISSING IT ALL RIGHT NOW.


Title: Game Concept: Technical
Post by: Kay on November 21, 2004, 02:53:23 PM
Nice digression!

It's just finishing up. I've got some head-shot sketches I can use for my raccoon AI thing, and if I can catch an artist on the way out I'll try to get some kind of concept sketch of a Rennaissance courier. Unfortunately the vixens are more likely to be men. Some fun gaming sessions, anyway; I got to see two fellow writers, bought a (clean) otter bookmark, and talked to the rep from Sanguine, which is planning to publish my RPG book Real Soon Now.

Anyway: a gridless system can be done. The distance function in 2D is just
d^2 = sqrt( (x2-x1)^2 + (y2-y1)^2 )
I think, and
d^3 = cuberoot( (x2-x1)^2 + (y2-y1)^2 + (z2-z1)^2)
for 3D? The recent RPG "Phantom Brave" uses a gridless movement system.

More later. Closing Ceremonies.


Title: Game Concept: Technical
Post by: Kay on November 21, 2004, 08:00:12 PM
No, I think the 2D distance function is:

d = sqrt( (x2-x1)^2 + (y2-y1)^2 )

"Kajuta Stan"?

I got a little sketch of a rabbit-man courier in a rainstorm; will scan and post when possible. The artist is looking for work, but that means $.


Title: Game Concept: Technical
Post by: Threed on November 22, 2004, 09:31:57 AM
Quote
No, I think the 2D distance function is:

d = sqrt( (x2-x1)^2 + (y2-y1)^2 )

"Kajuta Stan"?
 
Stan of the Kajuta, of course.

Yes, its right.


Title: Game Concept: Technical
Post by: Kay on November 29, 2004, 12:59:40 PM
I wrote some item code in lectures today. I did a Thing class with basic stats like XYZ and mass, then an Item class inheriting Thing and adding more stats like "script."

Code:
>> x = DefaultItem()
>> x.name
"Conch"
>> x.Use("look")
Response: You | see | smooth, blue, shiny thing.
>> x.Use("listen")
Response: You | hear | whoosh thing.

There's also a "Common" sentence format used for sensory input, which also makes the AIs better able to understand dialogue. It would work well with a building-block dialogue system that makes it easy for players to ask AIs reasonably complex questions. A typical command right now is "You | move | north!" (See "Level 3 AI.")

This part isn't relevent to our project, but I've got some basic journal-writing stuff going too:

Quote
2004 Nov 29, 0030:
Niss is an ai, raccan, female thing.
Kay is a lapan, male thing.
Tofu is an evil thing.
Guest is a thing.

I was daydreaming about flammability and thought it might be a good tech demo: Aqua the Fire Fox running through a burning building, blasting items with a water spell! (Or not.)

In any case, I'll keep working on the AI, objects, and world-sim on this end, trying to keep it all generic enough to work with any graphics engine that we use.


Title: Game Concept: Technical
Post by: Kay on December 03, 2004, 08:27:13 AM
What do you think of tiles versus no tiles? Threed, you suggested hexagonal tiles, but that sounds hard to do mathematically, especially with an isometric display.

If we have tiles, we can have an array of Tile structures that each store the ID of a graphic to display on each graphics layer, and also a list of Objects (interactive things) in that spot.

Code:
World
\-Tile
  \-layer_1_graphic
   -layer_2_graphic (etc)
   -objects
    \-object_1
    \-object_2 (etc)

Then the world-drawing function says, for the x/y range Player can see, draw each tile along with its objects. When the AI wants to see whether something is in range, it can just scan the appropriate tiles' object lists. (It's a simple equation to find the right tile range. Good for showing movement ranges in tactical combat too.)

But if we go tile-less, the system might be more complicated and less efficient. I think it would mean still having background tiles (how else?) but with objects stored in an un-ordered list.

Code:
World
\-Tile array
\-List of objects in world
  \-Object 1
    \-X/Y location
    \-Type of object
    \-Other data
  \-Object 2 (etc.)

Then, to find out what's in range for an AI function, spell, etc., or even to find out which objects to draw, the program has to look at every single object's coordinates. Slow.

What else could you do to make a tile-less world practical? Create a frequently-updated, area-based lookup table of objects?

By the way, my own thinking about the gameplay is muddy. I had been picturing:
-Zelda-like movement (limited to whole-tile steps?) in a tile-based world
-Lifting/throwing/jumping; I seem fixated on this
-Non-Zelda-like combat: either tactical (see "Final Fantasy Tactics," "Disgaea: Hour of Darkness") or, more likely, highly stylized and emphasizing non-lethal battle. (Battles are rare and usually end with bribery, surrender or fleeing.)

Suule, you seem to have emphasized adventure-style gameplay -- finding the right object and deciding where to use it. I support having some of that, and using it as a way to limit where the player can go rather than giving them completely free reign over the game world. Checkpoints, rockslides, and mysterious doors can block paths.

I read that the creators of "Deus Ex" spent a lot of their time figuring out what kind of game it was.

"That little * Chrono, he said Gato, give up your Silver Points
I said Chrono, I ain't fightin' you, amigo, so put down your sword and let's smoke this joint."

--"Chrono Trigger: Team Gato," www.ocremix.org


Title: Game Concept: Technical
Post by: Threed on December 03, 2004, 11:44:28 AM
The dissonace is having tile-based graphics with a freeform movement system!

@Finding nearby tiles and their items:

I think using a Binary Search would make this much more efficient, if the list of objects were sorted. But that requires sorting, resorting, and searching.

Having said that, the actual performance hit for iterating through an unsorted array is not very bad; most users wouldn't notice unless you had thousands upon thousands of objects all loaded at once.

Problem is, you're going to have to have some kind of coordinate system to lay down objects - what's the granularity? Is 1.1 similar to 1.01?

Hexagonalalalala isn't too bad; it actually adds, like, 4 more possible areas of movement - 8 potential moves, almost freeform movement, but not quite; however, what are the benefits of a freeform system like that? If this were an FPS you could argue that you might pull some "emergent behavior" like jumping between two very hard-to-get-at-rocks.

Zelda - at least on the SNES - was tiled based. It seemed like you could move in every direction, but attacking or throwing objects would only go in four directions; you had the illusion of freeform movement, but not the benefits, which I thought was weird.

You could take it to the extreme and divide everything up into bazillions of "tile" based quardinates, then each object has the potential to spawn multiple mini tiles, thus creating the illusion of freeform phatness, but I've never done that before, so its all theory. (Theoretically this allows for neat things like scrawny characters being able to fit where fatter characters wouldn't, or can't, because they occupy way more characters than the slimmer ones that just snuck between two big rocks).

Quote
Checkpoints, rockslides, and mysterious doors can block paths.

Not necessarily bad - I played Max Payne 2 three times in a row, mainly just to get the good ending, the one I so richly deserved, RIGHTEOUSLY DESERVED, but it was still a blast even on the third go round, but maybe I just liked shoot-diving into a crowd of gangstas and thugs to save the day.

Although I'd like to blow up the world some day, and leave my initals floating in outer space using the Earth-debris.


Title: Game Concept: Technical
Post by: Kay on December 03, 2004, 12:29:26 PM
Uh, hexagonal would mean six-way. You mean octagonal?

Are you and Suule currently working on anything, graphics-wise? I've been staying away from that end of it.

I'm thinking tile-based is the way to go, even if it means random thrown crates always land right-side-up along a grid. And even if it means the player can only walk in increments of one tile (though maybe in more than 4 directions). This system is simpler than using a lookup table. The main benefit of having pixel-accurate placement of objects is action-oriented gameplay, and it doesn't sound like we want even as much real-time running-around-with-a-sword as Zelda, because that'd require action-oriented combat AI.


Title: Game Concept: Technical
Post by: Threed on December 03, 2004, 01:49:33 PM
yah. that math shit boggles my cubes, mun.

Quote
Are you and Suule currently working on anything, graphics-wise? I've been staying away from that end of it.

"Not I," said the little bunny rabbit, sinking his fangs into your neck.

I'd say there's still junk to discuss, language, user interface, map file format, etc,, etc, other things deserving of kung-fu action.

Alternatively I could just start hacking away in a language I know best and then try to backport the code to whatever (trust me, it will be backporting).


Title: Game Concept: Technical
Post by: Kay on December 04, 2004, 10:21:30 PM
(Cue Tom Jones' "Kung Fu Fighting")

-I don't know about you, but I've got law exams coming up, so I'm not going to work (much) on this until the 22nd or so.

-Shouldn't you have a "vorpal bunny" graphic, then? You too, Suule!

Some rambling on other topics:

-Language: I'm going to start looking at PyOGRE to see if I can figure it out. If at all possible I'd like to use Python as the main language, and invoke whatever voodoo (or even nVidia) you like from there.

-File formats: One way to store complicated data is Python's almighty Pickle module. I've had trouble trying to store an entire big object at once (like a whole AI) but success at storing each piece in a fixed order. With a fixed format or some clever alternation between Pickled objects and XML-like tags (saying "the next 42 lines are type X"), loading and saving shouldn't be a problem.
For my old graphical NISS, I made a map editor program and was able to save/load with it. I found that it was best to pickle the individual variables rather than the objects -- eg. ten "int"s rather than an object consisting of ten "int"s -- because that format was about 1/10 the size of storing raw objects!
For the item code I've been writing, I've managed to load and save data in plain text format, so that items can be edited in Notepad. I've got support for comment lines, too. For a real game it'd be unwise to have everything in the open, though.
If you mean "What should be stored in the map files?", I think:
Code:
-Floor graphic map: tile-based
-Possible second "floor" layer: for flat decorations like small rocks
-2D height map: what's the elevation of each patch of ground? (Walls are very high patches of ground against much lower surroundings. Note that this system is like "Doom II"'s in that different floors of a building have to be different maps.)
-Texture to apply to the sides of each floor patch, if it's not the same height as its surroundings. (Easiest if all four sides are the same.)
-2D map of objects (if there's a limit of one per tile and they're assumed to be on the ground) or unordered list.
-2D obstruction map: passable/impassable/trigger script?
-Possible 2D script map: run a script when someone steps here?

-As for the interface, I'm of the "Donkey Kong Country" school: keep nothing on the screen unless it's relevant. Given that this isn't an action game, there aren't any "meters" that need constant attention, so I'd devote the screen to showing the game world and maybe have a little "what's in your hands at the moment" display. We'd need a title screen with "New Game" and "Load" options; an in-game "System" screen, an "Inventory" or "Party" screen, and a "Conversation" screen.
I was thinking keyboard control -- hold down the right arrow to go East or Northeast -- but keyboard-and-mouse movement is easy enough and is important if we're to have buttons. Important for any modern PC game, really.
I guess that starting conversation with an NPC could pause the rest of the game, so that you won't be attacked while talking, but NPCs have to talk to each other in real-time, as the player won't appreciate having _their_ end of the game pause!

-What confuses me is the idea of party members. If the player creates a fox PC and we have all this tile-based movement and item-manipulation gameplay, the player is going to expect that they can leap Mario-style across pits with their whole party, even though they've got the big tough boar NPC carrying fifty pounds of armor.
I would rather have NPCs following the PC, and limit the game to the more sedate pace of an adventure/RPG, than make the PC a loner and throw in platform-jumping gameplay. I don't know how to do good action physics or combat AI beyond "charge at the PC and run when you're hurt," but I know how to tell a story and create interesting characters.

I want to explore a graphical world meeting characters who remember me, react to the character I've created and portrayed, have thoughts beyond their scripted dialogue, and give the impression that they're alive. I want to be convinced that my sidekick is following me because he likes me, and not because the story gods ordered him to. Secondarily, I'd like to choose from multiple character races, solve puzzles, walk around interacting with objects for fun, and uncover an interesting story. Other gameplay elements are less important to me. What's your main vision for this project?

Will cross-post this last comment to "Outline."


Title: Game Concept: Technical
Post by: Kay on December 07, 2004, 08:22:34 PM
Check out the new "Combat Demo" topic. I've got a playable little text-based combat system whose code could be recycled for a real game.


Title: Game Concept: Technical
Post by: Kay on December 14, 2004, 10:07:18 PM
Two other possible resources are PyUI here (http://pyui.sourceforge.net/), a good-looking Python-based user interface package that works with various graphics engines...

...and this interesting list of RPG monsters we could use, here (http://www.somethingawful.com/DFMSDHEO7/enemies.htm). It's got raccoons.

While on the second topic, it's worth mentioning the Console RPG Cliche List (http://www.project-apollo.net/text/rpg.html).


Title: Game Concept: Technical
Post by: Kay on December 20, 2004, 09:10:17 PM
Last exam (Contracts) is on Wednesday afternoon -- more free time starting then.

I've begun setting up OGRE and PyOGRE, but the help files are less than helpful:
Quote
Implementation: pyogre use boost.python to make the binding. pyste to generate the c++ binding code (which use boost.python) from simple specification. Scons is used to build the project.
Any idea on where the OGRE and PyOGRE files need to go for me to run anything? Running TerrainDemo.py, for instance, tells me:
Quote
Traceback (most recent call last):
  File "C:\Python\pyogre\python\ogre\demo\terraindemo.py", line 1, in ?
    import localogre as ogre
  File "C:\Python\pyogre\python\ogre\demo\localogre.py", line 4, in ?
    from ogre import *
  File "../..\ogre\__init__.py", line 1, in ?
    from pyogre_ import *
ImportError: No module named pyogre_
And there's this matter of building OGRE and its third-party libraries, somehow, in Visual C++ to get it set up for PyOGRE to use it...? Suppose Visual C# would work?

On the SDL end, I know a bit about running non-isometric tiled graphics, but nothing useful about sprites.


Title: Game Concept: Technical
Post by: Kay on December 30, 2004, 12:22:52 PM
I've got free time now. Any advice on getting OGRE and PyOGRE set up, anyone?


Title: Game Concept: Technical
Post by: Threed on December 31, 2004, 12:41:48 PM
Quote
I've got free time now. Any advice on getting OGRE and PyOGRE set up, anyone?
http://www.ogre3d.org/phpBB2/viewtopic.php...ighlight=pyogre (http://www.ogre3d.org/phpBB2/viewtopic.php?t=6892&highlight=pyogre)

Precompiled binaries of OGRE3D and PyOGRE bindings.

Sorry, incommunicado, life's been hectic, consulting is fun but hard work, also, its cold.

Love,

Threed.


Title: Game Concept: Technical
Post by: Kay on January 06, 2005, 12:08:55 AM
Great! With some fumbling I got some of the PyOGRE demos working, including the robots, terrain, skydome, and smoke programs. (Others like the BSP demo summon the Blue Screen of Death, but they did with regular OGRE too, and these are features I never expect to use.) I was able to change superficial things like the # of robots or the color of lighting, easily. Can I use py2exe to build PyOGRE-based EXEs the same way as with regular Python EXEs? (Guess I'll find out.)

Meanwhile I started a journal for my AI, Niss. By this I mean that Niss gets to write the entries. See Niss' Journal (http://www.livejournal.com/users/niss_the_ai). I'm hoping to enable Niss to send e-mails soon! More importantly, I've got refined item and world structure code, and created an MVC-based version of the state-machine "DumbAI." If I had a tile-based scene manager, I could stick my AIs in it.


Title: Game Concept: Technical
Post by: Kay on February 01, 2005, 09:58:53 PM
I'm not sure anyone's still listening, but I'll post a little update anyway. I've got the following:

-Graphics engine/Interface: Pygame (SDL)-based tiled graphics engine currently displaying a big 30x25 grid of tiny 20x20 tiles, with arrow-controlled movement, a scrollable text display for entering commands, and mouse support for buttons etc.
-Worldsim (virtual world): Engine-independent; can even run as a stand-alone program using ASCII graphics. Multi-layer tile/room-based world with collision detection, interactive objects, and scripts. Can handle over 100 entities scurrying around without noticeable slowdown.
-Sound: MIDI/MP3 music. Untested WAV support.
-AI: Dumb AI (state machine) built into worldsim; advanced AI (NISS) currently wandering around eating tofu, but with much more complex code; close to having approach/food-finding behavior. Have mostly-unused "body part" code for more realistic modeling of inventory etc.
-Battle system: Stand-alone, playable furry combat game using text interface.
-Obviously missing: Animated movement; real interface; load/save world code (just needs tweaking, then a room-editor function); inventory and related details like picking stuff up; good art; story; good graphics engine.
-Possible work directions: Use OGRE; upgrade fancy AI; make basic AI suitable for a game; build real interface; set up inventory-related functions for AIs' use and incidentally for adventure-style gameplay.
(http://www.xepher.net/~kschnee/2k5feb1-small.jpg)


Title: Game Concept: Technical
Post by: FallenWolf on February 02, 2005, 03:08:54 PM
i AM listening, but still not sure how i can help ;)


Title: Game Concept: Technical
Post by: WyrmMaster on February 02, 2005, 07:35:22 PM
Maybe this thread (and its cousin "ITE Sequel Concept: Outline") should be moved to a new forum about Game Development. Or only part of the threads. And renamed something other than "ITE Sequel ..."

Would that be OK? Suggestions?

 


Title: Game Concept: Technical
Post by: Kay on February 02, 2005, 10:41:42 PM
Moving and renaming the threads would be fine with me. "Game Concept: Outline/Technical" as a new name? We're no longer thinking of trying to create a sequel, which we wouldn't have the right to do anyway; just something similar.

Thanks, Wyrmkeep folks, for letting us use this board for the topic at all.

@ FallenWolf: Do you have any thoughts on what you'd like to see in a game? If you had a game that looked vaguely like ItE, what would you want to be able to do in the game world? Would you be willing to help test a tech demo of walking around picking up and using objects? There's not much point in doing art until I have a real graphics engine -- unless you want to post cool concept art! And if you know of anyone who'd be interested in helping with any aspect of the project, please tell them about it.

I need to bang out a legal memo outline now, so I can get back to the real work.

Kris


Title: Game Concept: Technical
Post by: FallenWolf on February 03, 2005, 01:20:03 AM
Of course i want to play demos ;) just tell me what to do, my email takes up to 2gb so just send all stuff i need to fallenwolf@gmx.net

i do have alot of thougts, as i already said some time ago, i wrote a sequel myself but stopped somewhere in the middle as i was really out of ideas (and nobody showed interest that time).

as i am a story writer i think i might help you, i just need a basic idea where to start, what needs to be contained and where i shall end :)

you can contact me on ICQ (92963416) as well.

thanks

~Chris


Title: Game Concept: Technical
Post by: Kay on February 12, 2005, 01:42:52 AM
First, an update. I added save/load code, better language code, etc., so I've now got:
-Graphics engine/Interface: Pygame (SDL)-based tiled graphics engine currently displaying a big 35x25 grid of tiny 20x20 tiles, with arrow-controlled movement, a scrollable text display for entering commands, and mouse support for buttons etc.
-Worldsim (virtual world): Engine-independent; can even run as a stand-alone program using ASCII graphics. Multi-layer tile/room-based world with collision detection, interactive objects, and scripts. Can handle over 100 entities scurrying around without noticeable slowdown. Can save and load. ("Just needs tweaking," my tail.)
-Sound: MIDI/MP3/OGG music and WAV sound.
-AI: Dumb AI (state machine) built into worldsim; advanced AI (NISS) currently wandering around eating tofu, but with much more complex code; now has approach/food-finding behavior, complex "body" system for input, sensing, and inventory, and the ability to understand some simple English sentences.
-Battle system: Stand-alone, playable furry combat game using text interface.
-Missing: Real graphics engine with animated movement and good art; real interface; story.
-Possible work directions: Use OGRE; upgrade fancy AI; make basic AI suitable for a game; build real interface; set up adventure-style use of objects.

Game-wise, I think the next thing is to set up objects/scripts that can be used on each other, eg. a key that unlocks a door. The program would then be playable enough to let you move around picking up and using objects to get through a maze or something. AI-wise, the next thing might be to get the DumbAIs smart enough that you can walk up to them and engage them in Morrowind-style conversation. The program is still too ugly to be usable as a real game, but the code is getting close to where we can talk about graphics other than these tiny tiles I'm using.

If you want to play a text-based demo of the body part system (which lets you touch and manipulate virtual objects), see my site (http://www.xepher.net/~kschnee/nissbodydemo.zip). (I don't really need feedback on that.) Niss' journal is at LiveJournal (http://www.livejournal.com/users/niss_the_ai/), but it's mostly my ramblings about the code upgrades I'm doing, at the moment.

Screenshot (click to enlarge):
(http://www.xepher.net/~kschnee/2k5feb12-small.jpg) (http://www.xepher.net/~kschnee/2k5feb12-big.jpg)


Title: Game Concept: Technical
Post by: Threed on February 17, 2005, 06:36:41 PM
It looks like you've made some serious headway with NISS. ;)

Sorry I haven't been able to help at all--I am still entangled in the writhing mass called "college." It is painful and leaves me with little free time.

The NISS journal is cute.