crankycyclops / trogdor Goto Github PK

event() should return some value that will determine whether or not the normal behavior should be suppressed. For example, if we drop an object and that triggers an event that stops us from being able to complete the action, this would be required.

Add a static int timerActive to determine whether or not the clock is running. destroyTimer() will then set this to 0, and the while loop will exit and the threaded timer() function will return, killing the timer thread.

This should be called by destroyGame().

If I type "look at ," the output should include information about the object's weight (if a finite weight is defined for the player's inventory.) If object is weightless, make a comment about that.

For example, in a room definition in game.xml, if I say squiggle, but room squiggle doesn't exist, I should get an error. Instead, parsing happens anyway. Wtf?

Second iteration involves adding support for parsing mention of scripts in XML. I think that this should be handled by specifying a <script file=""> tag inside of a basic game structure (room, object or creature.) Then, in the game, whenever an event happens on that object, we check the script file to see if there's a function that matches a certain naming convention, and if so, we call it during the execution of that event. Not sure how all of this is going to be handled yet (and this will probably depend on the scripting language used.)

We don't need a C API yet. This will be taken care of in step 3.

Need to be able to add support for triggers. Not sure how this will work, yet. First iteration will NOT include any kind of scripting support, only support for pre-defined types of triggers that take arguments.

Right now, object names are unique, but one object's synonym could be another object's name. This leads to a possible unresolved ambiguity, where two objects, one with a name and no synonyms and another with a synonym matching the other object's name, both exist in the same place. The easiest way to resolve this is to ensure that a synonym cannot equal the name of any unique object name.

Add support for creatures, which are attached to a room. Creatures won't do anything in the first iteration, only be there and be described to the user.

Add support for object weights (default is 1, but can also be set to 0 if you don't want the object to "weigh" anything), and add support for a storyteller-defined weight limit to the inventory (default is unlimited.)

When a creature is killed, it should drop all of its objects.

Add neutral game objects (examples: rope, candle, etc.) -- nouns, which can be placed in a room. We don't have to add support picking up yet.

There's a bug in the data destruction routine in data.c. Find and fix it. It seems to have something to do with the destruction of the objectByName hash table inside a room (backtrace lead me to destroyRoom().)

Filler words like articles (such as the and a), of, etc. should be filtered out so that the user can feel more natural by typing them without actually changing what we detect to be direct and indirect objects.

Just to separate things and keep them organized :)

Right now, the flow of the logic is such that objects only get instantiated if they belong to a room. Now that we're adding support for scripting and such, we should change this. Being in a room is no longer required. All objects should be instantiated, regardless of whether or not they are initialized to be in any particular place.

Related to #44: we should store some kind of list mechanism in a player's state to grant the player the ability to take "untakable" objects and to drop "undroppable" objects. The same should go in reverse, so we should be able to prevent a user from dropping an object that they could usually drop and from taking one that they could ordinarily take.

Not sure how I'm going to implement this yet. We'll see.

Should display object weights in terms of percentage (i.e. inventory is 80% filled, object 1 takes up 10% of inventory, object 2 takes up 55% of inventory, etc.) Use floats (we don't need the precision of double, and we're only going to display up to one decimal place.)

When a creature is killed, the game developer should be able to decide whether or not it will respawn.

Add extensible support for synonyms. Don't know yet how to handle synonyms for verbs vs. prepositions, nouns, etc. Thinking that it should JUST be synonyms for verbs, nothing else. I think noun synonyms will be defined in the game file itself.

We should be able to say in the game.xml file that certain objects and state variables are to be assigned to a player at game start.

Some examples are "text (book, scroll, etc.)", "key," etc. Each class will probably have certain properties set by default (for example text, by default, will have a readable block of text for the player to see when they issue a "read" command.) Objects should then, in addition to names and synonyms, be identifiable by class.

The hierarchy for recognizing objects by class name should be as follows:

First, recognize objects with name/synonym. If these are found, ignore class. If no objects are found by name/synonym, then see if there's an object of the specified class, and if so, you can interact with it. This will be an enhancement to the static function getObject(), most likely.

Pre-defined object classes might have special tags that can go in the section of game.xml. For example, if it's a text, instead of:

[object name="book"]
...
[/object]

It would be something like:

[text name="book"]
...
[/text]

The text block would automatically imply certain attributes that would otherwise have to be explicitly stated in a generic block.

In the future, I may want to create a mechanism to allow the game developer to specify extra custom classes (probably want to put in another ticket for that! :)

There should be two new fields in the room structure:
. shortDescription: what to print by default when the user has already seen the room
. seen: an integer that's set to 0 when initialized and to 1 when the user visits the room

This will effect the struct definition, XML parser and displayRoom().

We should add a new command (look, look around, show, etc.) that will make the game display the long description when the user wishes to read it again.

Because we're going to be picking up and dropping objects, we need a linked list, not an array. Fix this. I am a f***ing idiot :)

Extra attributes should be specifiable (by default, generic object class makes objects takeable by player and creatures) that allow the game developer to say that certain objects can't be taken by the player and also that they can't be taken by creatures (this behavior can always be overridden by a script.)

Add support for mobile creatures (whether or not mobile is a game file configurable option), so that on each tick of the game (a tick will probably be defined as each time the user types a command, or at least certain kinds of commands), the creature will randomly move around.

At some point, I might want to have some sort of AI to game (particularly if the creature is an enemy, so we can have him chase the user), but not yet :)

We need another field in the room structure, a title. This will affect the struct definition, XML parser and displayRoom().

For max portability, change jobID and gameTime to explicit longs instead of just ints.

Allow the user to give an object to a creature. Game developer should be able to define whether or not creatures accept objects. Game developer should also be able to decide what objects can be given to creatures and what objects cannot.

Also, allow the creature to give objects to the user during certain kinds of interactions.

"room" should be an illegal object name. If it's detected in game.xml during parsing, the parser should error out.

We need support for custom messages for actions. So, when player does "take rock," we can either do default "You have taken the rock" if no message is specified or print out what the developer said in game.xml instead.

Add support for a user being able to pick up and drop objects. We don't need an inventory yet.

Add support for creatures to own objects. They can't yet pick anything up, and can only own objects. Ownership can only happen during initialization of game at this point.

Right now, we're iterating through an array of verbs, when instead we should be using a hash table. It will be faster. GGG!

Right now, this defaults to 0 for unlimited weight. Now that object and inventory weight support has been implemented, we need a way to set a different max weight in game.xml.

When a creature is killed, the game developer should be able to decide which objects are dropped and which objects simply "disappear."

Allow creatures to be defined as friends or enemies. If a creature is an enemy, the user can attack it. If the creature is a friend, the user cannot attack it. No object drops should occur during this phase.

An event handling mechanism needs to exist. Events should be triggered, for example, whenever we enter or leave a room, when pickup, drop or look at an object, etc. This will be useful mostly for when we start implementing scripting.

Should support custom verbs via scripts. Not sure how this will work yet, but somehow, we'll register the verb along with a pointer to a function that will execute a scripted function (all verbs go in some game script file?) with a name like verbVerbname. Also, we'll probably want to pull verbs array out of getVerbs function and make it a global in vocabulary.c.

Iteration 1 of embedded scripting support: include should JUST be including investigating a language (current propositions are Python and Lua) and then integrating that library with Trogdor. We don't yet need to be able to setup actual scripts via XML or create a C API for the scripting language to call. These will come in steps 2 and 3.

Add functions to pause/restart timer.

In parsexml.c, these functions do EXACTLY the same thing. The only difference is the section tag name. This should be condensed into a single function that takes as an additional parameter the name of a section.

State for objects should be defined in special state structs, and a pointer to one of each should be included in the Room, Object and Creature structs. We also need an API to read/write state.

Might want to add a timer thread that runs in the background and executes certain events every x seconds (ticks of the timer.) Timer could be used to control creature movement, what happens to certain objects (objects, rooms, creatures, etc. could maybe register events with the timer?)

This could be a very interesting feature to implement. Will have to think about how I might do this...

Right now, core is functioning as a library that an application (like standalone) wraps around. Since this is the case, core should not call exit() unless there's an unrecoverable error (like memory allocation failure), which means that destroyGame() should not call exit(). Should alter the main game loop in standalone/main.c so that it says something like:

while (inGame()) {
...
}

And then implement inGame() so that it returns TRUE if the game is running and FALSE if the game has ended. Then, initGame() will set the variable this function returns to TRUE and destroyGame(), when we're done tearing down, will set this value to FALSE.

DO EET!

All objects should be hashed in a global hash table so that we can easily find them (will be particularly important when we add support for an embedded scripting language.)

Right now, we define scripts like this:

[script]filename.lua[/script]

But, what if we want to define script inline without referring to a file? Syntax should be like this instead:

[script src="filename.lua"][/script]

OR

[script]Code goes here[/script]

Having both types in the same tag should trigger an error. Doing this will require us to change the way we initialize Lua state variable. Should have a way to differentiate during parse between filename and inline script so that we'll know what to do in parse.c when we're ready to initialize the Lua state variable.

Allow enemy creatures to move around in pursuit of players. Could implement a shortest path algorithm to determine which direction to take from current room, then allow it to choose that direction with some percentage determined by how "smart" the creatures is defined to be.

Creatures might also be able to pickup objects (especially objects like weapons, shields, etc.)

Not sure if I would want a creature to move each time the player enters a command or if I would want there to be a thread running in the background that moves the creature every x seconds. Having timed events in the game might make it more interesting (in fact, will put in another ticket for this!)

Add a listable inventory to keep track of objects the user owns.

If we, for example, type "take rock," and there are two objects identified by rock, we'll ask which object was meant. It will continue asking until you provide it with a suitable answer. Now, if the user types "nevermind" or "never mind", the clarification operation and whatever called it should be canceled, so that the user won't have to follow through if he decides not to.

Step 3 involves writing a C-to-scripting language API that will allow scripts to actually change the state of the game. This should complete basic scripting support!