Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[qwertyuiopas]

How about the possibility of a person standing in a doorway to block it temporarily? Great way to corner someone...

[Outcast Orange]

The blocking the doorway idea is gold.

Those items will not be displayed until the container is opened.
That is a tech demo, where all items in existence are asked to declare their status.

EDIT: The keys are not concealed because they aren't in a container.
The concealed tag is more of a "can be concealed" tag.
Like papers, keys, credit cards, change and other small loose things.

[Outcast Orange]

Here is the new item text I'm implementing tomorrow:

Spoiler (click to show/hide)

Code: [Select]

[>][1][love seat] [INROOM:2][FURNITURE]
[>][2][cushions] [ON:1][FURNITURE]
[>][3][throw pillow] [ON:2]
[>][4][paper scrap] [UNDER:2][TINY][IMPORTANT]
[>][5][strange rug] [INROOM:2][FURNITURE]
[>][6][grandfather clock] [INROOM:2][FURNITURE]
[>][7][maintenance hatch] [PART:6][SEALED]
[>][8][oil canister] [IN:7][IMPORTANT]
[>][9][oil] [IN:8][IMPORTANT]
[>][10][dead potted plant] [INROOM:2][FURNITURE]
[>][11][sailor painting] [INROOM:2][FURNITURE]
[>][12][wagon painting] [INROOM:2][FURNITURE]
[>][13][chandelier] [INROOM:2][FURNITURE]
[>][14][red key] [INROOM:11][TINY][IMPORTANT]
[>][15][blue key] [INROOM:12][TINY][IMPORTANT]
[>][16][pizza] [INROOM:14]
[E]

===========================================================================
Tag descriptions:
===========================================================================
[>] - REQUIRED

Starts a new item declaration.
Doesn't have to be on a new line.

[#] - REQUIRED

This is the item ID number.
This MUST come after the [>] tag.

[RELATION:#] - REQUIRED

The # is the id of the parent item.
The RELATION could be IN, ON, or UNDER.
If the item is a part of the related item, use PART.
If the item has no parent, use INROOM and the room ID for #.
This MUST come after the [#] tag.

[E] - REQUIRED

Use this after the final item.
Anything after this will be ignored.
Feel free to edit this help text or remove it.

[FURNITURE]

Use for anything large and bulky, or difficult to move.
Do NOT use it for small things stuck in place.

[TINY]

Use this for anything that can fit in a pocket.

[SEALED]

Use for anything containing a sealed space that can be accessed,
 like boxes, drawers, cabinets, and bags with zippers and buttons.
Sealed things are presumed to be closed.

[IMPORTANT]

Items marked with this tag will get special text effects whenever mentioned.


Any item can be a key, no tag is required.
The key item ID will be stored by the lock.
I'll be adding new tags as I progress.
Those are the basic ones that will test the item tracking/interacting of the characters.

I'm thinking about merging the house text file with this one,
 and spacing it so that the rooms are separated.

[Armok]

One use for multiple doors is if one is loked, and the other is hidden, and a peron in the room think they are safe because they have locked the only door they know abaut, but the murderer knows abaut the secret door...

[Outcast Orange]

I've decided on items storing a list of bools that describe them,
 and the tags activating those bools.

The final text file I have right now is just about finished.
I had to put a : in most tags, due to technical laziness.
So you have tags like [IMPORTANT:] and [SEALED:], with no second variable,
 but it can also support tags it more than two variables.
The key part is that when it searches for the tag, it takes the text before the colon.
If I had it looking for tag types between the brackets, tags with parameters wouldn't read right.
So I just chose to add an empty parameter to simple tags.

I'm going to get the characters storing items in their memory now,
 and perhaps deciding which items are useful to them, and picking them up.

This way they can snag the keys to their bedrooms,
 and if they're villainous, they can snag the other keys too.

I'll be overhauling the character states,
 making them more logic based and less spaghetti coded.

Here's a sample:

Code: [Select]

[>:6:grandfather clock] [INROOM:2][FURNITURE:]
[>:7:maintenance hatch] [PART:6][SEALED:]


EDIT:

I'm adding in character item memory,
 so they can remember items, and their locations.

[Outcast Orange]

Eureka! It works!

Characters can now spot all items and related items in a room, store them in memory,
 and update memory for all items they see.

If they find the same item twice in a new room, they will add the item to the new room in memory,
 remove it from the old one in memory, and update facts about the object in memory,
 in case it has been altered.

[timmeh]

That is epic!  Can't wait to mess around with this now!

[Hippoman]

What if one of them gets a SEAL CLUB TO THE HEAD!!!!!! and can't remember things all to well?

[timmeh]

Actually, that's an interesting idea Hippoman, particularly with the joking about inebriation earlier   Drunk people might not remember some of the stuff they did/saw when approaching blood-alcohol levels close to those of an average dwarf   Then again, they might just die at that point

[Outcast Orange]

Once again, perception, assumptions, and memory recall will all be dependent on stats,
 so even temporary status effects will cause havoc.
Now that all that stuff has been properly implemented, I can start focusing on character functions.
The first two I want to deal with are locking doors, and food consumption.
I think this game is going to have a finite amount of food lying around,
 forcing an end game eventually.
Of course I'll make a [MAGIC FRIDGE:] tag, so you can modify your game to have infinite food.

[SolarShado]

[MAGIC FRIDGE:]

Anyone know where I can get one of these IRL?

[Outcast Orange]

Okay, so I've been thinking a lot, and I'm starting to piece things together.

I'm pretty sure I will have a goals class, and each player will start with the default ones,
 but can craft more goals as they go.
Instead of having hard code decide the actions they perform,
 I will associate actions with certain goals, and they will perform actions to fulfill or further those goals.
The actions will also have a level of success associated, which can change as the player experiences things.

For instance, the most important goal is to escape the island.
It is also important to sleep, but not nearly as important.
Since sleep has a very high chance of furthering one goal,
 and exploring has a relatively small chance of helping them escape (though this goal is far more important)
 they will choose to sleep.

If a player gets very little sleep, and has trouble sleeping every day,
 they might give up sleeping altogether, and continue down the path towards insanity.

I'm going to associate a familiarity value with everything,
 so characters will be less willing to do things they are unfamiliar with, like sleep in a room.
Once they've reluctantly slept in the same room a few times, they should become familiar with it,
 and have a smaller inclination to avoid it.

Does that all sound good?

[timmeh]

It sounds incredible!  I don't know if you ever watched any of the pre-release trailers for TES4: Oblivion, but this is very, very similar concept to the AI Oblivion was supposed to have.

[Armok]

If you're going to have goals and actiaons having varius probabilities of leading to goals, you shuld read this: http://yudkowsky.net/rational/bayes

[Outcast Orange]

There will be no predicted probability, just a moving variable,
 guided higher or lower whenever an action succeeds or fails.

The thing I find humorous, is that this system will let me know if the actions I program in are actually useful or not.
So if having conversations never helps any goals, they will probably stop having them.
Then I will reconsider it all, and try balancing it back out.

These characters  are going to be able to decide which actions are useful, and which ones are not.
These characters  will judge the usefulness of the code I give them.

That sort of creeps me out, but also excites me!