crankycyclops / trogdor-pp Goto Github PK

Similar to global synonyms for creatures, you should be able to say something like "take item" or "take object" and have it automatically refer to whatever item (or items, if more than one) is in a room. Not sure how to do this yet, though, or if it's a good idea...

Right now, whether or not Item is a weapon is a boolean flag in Item. Should I instead extend Object with a new type, Weapon? This would require fundamental changes to Parser, and in game.xml, would have to declare object with instead of .

Hmm...

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

Game objects support global meta data. We should also be able to set meta data for entities, which could be useful for scripting, when a script needs to keep track of non-game-standard variables. Just a simple string-only key-value pair.

Some things I might want to do will involve both a command timeout event (if user doesn't enter a command in a given number of seconds, a commandTimeout event will be triggered) and knowing how many clock ticks have elapsed since user entered the last command. Investigate this.

Add extensible support for synonyms. Don't know yet how to handle synonyms for verbs vs. prepositions, etc. Note that nouns are already handled via aliases.

I need an input stream and an err stream (err will be pretty much the same as an ordinary output stream.)

Allow Creatures to wander. For now, there's no AI, just random wandering. This can be configured regardless of a Creature's status as neutral, friend or enemy.

Related to #23.

Instead of having a fixed list of attributes, this should be implemented internally as an unordered_map (like connections in Room) so that we can easily extend the engine later.

I was doing global -> player -> entity, but you know what? I actually think it should go the other way, from inside out. That way, local event triggers can override and halt global event triggers.

At some point, when trogdor-pp is up to speed with legacy trogdor...

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!

NOTE 1:

Should be API functions to create and modify rooms and that take in as arguments name of the room and a table with properties to be set. Also should be function to retrieve room and all its properties in a table, which can then be changed and then passed to modifying function.

Something like:
room/boolean getRoom(string name);
boolean updateRoom(string name, table roomProperties);
boolean createRoom(string name, table roomProperties);

getRoom will return boolean false if the room with that name doesn't exist. updateRoom will return true if update was successful and false if room doesn't exist. createRoom will return true if the room was created and false if arguments were invalid or room with that name already exists.

NOTE 2:

Should disable io library.

NOTE 3:

Also, not quite related to this exact iteration, but we also need to be able to pass the object in question to the script function (or the room in question, or the creature, etc.)

Investigate commerce: money, trade, giving things, accepting things, etc. How should all of this work? This is a BIG task!

There should be possible custom messages for combat and health issues.

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.

NOTE: these notes are related to the old Trogdor project, which was written in C. The same basic principles should remain the same, though.

If input is invalid, throw an exception. Investigate how this will impact things. Might alleviate some validation in the Parser (maybe?) Investigate!

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

Certain objects should be cloneable (optional feature in game.xml using cloneable = true tags). Cloneable means that if an object appears inside a room more than once, it should automatically have an instantiated copy.

Not sure how this will work yet. I can't have duplicate names, and I don't like the idea of using iterated names (i.e. candle-1, candle-2, etc...) Related to an issue brought up in crankycyclops/trogdor#61

Per a note in crankycyclops/trogdor#59, "During combat, creature will pick with certain probability the weapon in its inventory that deals the highest amount of damage. This probability will be influenced by the creature's attributes." This attribute will probably be intelligence. DO EET!

Class something like this:

class Parser {

public construct(filename="game.xml") {
open file;
parse (call private methods);
}
...
}

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

So, when I put together the Entity -> lua table code, I didn't know much about Lua. Now, I know enough to realize that I can actually create wrappers for my classes. So, do this. Check this article out:

https://gist.github.com/kizzx2/1594905

That has some good code to get started.

http://cfc.kizzx2.com/index.php/binding-c-classes-to-lua-a-step-by-step-example-for-beginners/

That's the Lua 5.2 version of the other (which is 5.1, my current version.)

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.

I wrote clone constructors far enough down the chain of inheritance that I can clone Players, but I still have to do this for all other entity types.

Should support meta info about game, such as title, author, etc. Title and author (if set) should be displayed at the beginning, when the game is first run.

Section would look something like this:

< meta>
< title>Game name < /title>
< author>Author name < /author>
< /meta>

Damage done by players and creatures without a weapon should be configurable option in game.xml (for both player section and in creature definitions.)

Some creatures should be able to be configured to automatically attack a player when they share the same room. This will be implemented as a native event handler.

Add functions to pause/restart timer.

Right now, all creatures will fight back by default when they're attacked. Make it so that only enemy creatures attack back by default. Not sure how neutrals should respond by default, but friendly creatures should definitely NOT attack by default.

Do this when there's some time. It will be useful for debugging.

Global synonyms like "object," "thing," etc. or "creature," "being", etc. should refer to all objects/creatures in a room.

It would be cool to have a graphical tool that can generate game.xml. I'll probably never consider this important enough to actually implement, but I'll go ahead and throw it on the backlog anyway!

Right now, Creatures are using StreamIn instantiated with cin, which is stupid. Instead, we should use a NullIn for non-player entities.

Related to crankycyclops/trogdor#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.

Right now, in and out are prepositions (and they need to be.) Unfortunately, because of this, typing "go in" or "go out" won't work, because in and out are seen as prepositions to the command parser. We need to add an exception for when there's a preposition without an indirect object and it's equal to either in or out (in this case, it should be saved as direct object.)

Three settings:

1. visible - Entity shows up during room descriptions and everything else
2. hidden - Entity only shows when you look at it directly with a command or when it interacts with the observer. Hidden from room description.
3. invisible - Entity never shows. You can't look at it with a direct command, either.

Something like this in game.xml:

visible (etc.)

Should be easy to implement.

This could be an interesting idea. Investigate it.

There should be a Lua interface to set and get meta data for a Game.

In the parser, first check manifest. If an object has the same name (of any type), throw error. This should resolve all naming errors, as an object with a name that isn't in manifest (since manifest is good) that matches another object's name would be rejected simply because it wasn't in the manifest.

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

Creatures now have an inventory just like players. Thus, we need to add configuration options to game.xml for this inventory on a per creature basis.

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.

If an entity is declared in the manifest but is not defined later, it's an error. If an entity is defined in the XML file, but is not declared first in the manifest, that's also an error. GGG!

Back in the day, when I started, I didn't realize that iterators could be implicitly cast to const_iterators, which I mistakenly thought was C++11 only. Now that I know better, there are places in the code where I'm returning non-const iterators to data inside private members of Entities that needs to be fixed to be const instead (and make sure to make those functions const as well!)

GGG!

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! :)

I think it would be fun to implement "compiled game" support. This would mean that data structures are loaded from game.xml once, then compiled into data that gets injected directly into the binary at runtime to avoid future parsing.

This would be relatively simple (at least in theory.) My method would go something like this:

In Game::init():

if (game.xml exists) {
   parse it and use its data;
}

else {
   attempt to load shared object (game.so, game.dll, etc.);
   if (doesn't exist) {
      error and exit;
   }
}

There would be a separate tool that would use the Parser class to parse game.xml, create a C++ file that corresponds to it (instantiating entities, configuring them via setters, etc.) and compile it into a shared object that can then be loaded by the game at runtime.

To make shared objects as cross-platform as possible, look into this: http://boost-extension.redshoelace.com/docs/boost/extension/index.html

The output stream thing I'm doing right now is really lame and stupid, and won't work much longer. I'm going to do new and improved output streaming that takes entities and scope into account, and that will work for both console and network stuff.

Should be able to override a creature's default allegiance on a per player basis, so that a creature might be a friend to one player but an enemy to another.

Instead of hard coding values in awkward places, set default Messages for different kinds of entities in their constructors. That way, it's always just a clean access to Messages when we need to print something out after taking, attacking, etc; it's much cleaner and simpler!

Right now, due to limitations in my event handler, if you fire an event while handling an event, you segfault. This will not do. I need, for example, to setup an event handler to respawn Beings after they die, and the respawn function will itself fire beforeRespawn and afterRespawn events. I need this to work.