Ideas for v0.0.8

[bernardosulzbach]

• [x] After a creature dies, its corpse will lay on the ground and all the items it had in its inventory will be dropped.
• [x] Milk command to get milk from cows. MILKABLE tag.
• [x] Readable items with actual text (letters, journals etc). READABLE tag.

[ghost]

Re 1: What about non-creature non-item world objects? Furniture comes to mind, though there are no 'civilized' areas yet, so more appropriately... pond, lake, tree(s), boulders, bushes... in the desert or wasteland, bones or boneyards... basically features in the world that are listed (descriptively) in the location's description, such that when it's put together it just sounds like a paragraph describing the local area, but is more fluid because, say, the order/content can vary.

This would be in addition to each location having a little base sentence that the other features build on. This then opens the door for, say, chopping down trees (CHOPPABLE tag?), fishing in lakes/ponds (or gathering water? WATER_FRESH tag?)

Also also this raises the question of an "examine " command. Instead of having a wiki with creature descriptions, have those descriptions be something that comes up when you examine an actual entity in the world. Then the location features can have more in depth descriptions, so that they can also be examined. I've played a lot of text adventures (for some reason) and, at least for me, running around examining literally everything was like 80% of the fun. I like to read, especially good writing.

[bernardosulzbach]

I agree in some parts. Examining sounds OK and believable (if you look at the weather issue - that adds more realism itself - you'll see that trees are a plan). So you can get cherries from a bush and not always magically from the ground. But wiki entries will provide even more lore about stuff, such as mating habits, even though that is useless in the game as it is now.

Sure chopping, fishing and water gathering are interesting features. All should use tags, I believe.

Agriculture and construction could also be implemented in the future. Buildings with multiple levels, etc.

I don't know if I already wrote it here, but I want some hardcoded starting scenario, such as a Dungeon (guess why) where the character wakes and fights his or hers way out to the open randomly-generated world.

[ghost]

Yeah that's a good idea for wiki entries, more general lore/information, where examine just gives you a visual description of the thing.

Honestly I think the Dungeon idea should be a priority because it can give the game more of a sense of cohesion. Also if you're going to implement the one dungeon it would probably make sense to just implement 'Dungeons' in general--i.e. randomly placed randomly configured locations in the world that you fight through for loot. Currently there's not really any incentive to fight creatures, they don't threaten the player or stand in the way of gathering items. Probably need to implement creatures dropping items, too.

[ghost]

Have you any intention of broadening the combat to include multiple combatants? Dungeons where you only fight one enemy at a time (and the others, presumably, stand waiting for their turn) probably wouldn't feel right.

[bernardosulzbach]

Yes, I have already thought about all this, but we need to move slow and play safe.

The dropping mechanism (with bodies and butchering also) is closer to reality than the multiple combatants, however.

Maybe some 2x3 or 3x4 hardcoded dungeons placed underground will be made soon. How to store them, though? Randomly decide where there will be a dungeon entrance and write than dungeon below it?

[ghost]

Yeah I'll start looking at a drop mechanism. For corpses I'm thinking a type of item that is generated from a given creature, so creature resources will need to have weight values to be transferred to the corpse item upon generation. In the future, perhaps the corpse item could maintain a reference to the creature that produced it, in order to implement resurrections or an animate corpse type spell.

Also in the future, I think it would be ideal if corpses functioned along the lines of being an inventory, so that instead of dying creatures being pinatas of loot where everything suddenly falls out onto the floor, you actually have to search the body and pull items from it. Actually, scratch that. It would be annoying if, say, you wanted to collect a corpse but not the items the creature was carrying, and you had to loot/drop the items to get them off the corpse. Perhaps instead, creatures drop anything they're holding in their hands, and they need a backpack or other inventory item in order to hold more things, and they drop that backpack separately from the corpse item.

Anyways, I'm rambling. First things first, dying creatures vomit their inventories onto the floor!

[bernardosulzbach]

I really do like to see someone else thinking about what the game should do at a stage such as v1.0.0, but I also do love baby steps.

"Yeah I'll start looking at a drop mechanism. For corpses I'm thinking a type of item that is generated from a given creature, so creature resources will need to have weight values to be transferred to the corpse item upon generation." - Feel free to open an issue for this.

"In the future, perhaps the corpse item could maintain a reference to the creature that produced it, in order to implement resurrections or an animate corpse type spell."

"Also in the future, I think it would be ideal if corpses functioned along the lines of being an inventory, so that instead of dying creatures being pinatas of loot where everything suddenly falls out onto the floor (LOL), you actually have to search the body and pull items from it." Absolutely. See this. If an elf scout were carrying a lot of elvish trinkets, he or she would likely be using a purse or something to store those.

"Actually, scratch that. It would be annoying if, say, you wanted to collect a corpse but not the items the creature was carrying, and you had to loot/drop the items to get them off the corpse." No. If a corpse had many items I think that the bags/backpacks would fall beside the corpse, not attached with it.

"Perhaps instead, creatures drop anything they're holding in their hands, and they need a backpack or other inventory item in order to hold more things, and they drop that backpack separately from the corpse item." - I was commenting as I was reading, now I see that I just repeated your words.

"Anyways, I'm rambling. First things first, dying creatures vomit their inventories onto the floor!" Would love to see that. You do know that before we must provide items to the creatures, right? Give the wolf some pelt and the orc an orcish sword. BTW, an orcish sword as something that could only be obtained from orcs would make killing foes less pointless. (While I am at this, have you ever checked the achievement command and the whole achievement system?) Would also make a nice weapon for an achievement, right?

[ghost]

I was just going over the creature code, actually. I had to switch to my laptop which means I'm installing IDEA and Git all over again. It looked like they have inventories, yeah? Are you saying there's just nothing actually in them currently?

[bernardosulzbach]

Yes. If I were you I would write a simple useless (for now) item such as Wolf Pelt in items.txt and assign it to the wolf in creatures.txt. Creatures don't get items at creation now.

Too bad that you need to re-install this stuff =(. Look at the bright side, you already know one stuff or another about configuring Git and can import my wonderful IDEA configurations to speed up the process.

[ghost]

I see. Another thought: though a dummy item like "Wolf Pelt" is fine for this purpose, in the future I think it would be better to have a sort of 'body parts tag' list assigned to the creature, and no hard-coded "Wolf Pelt" at all, but instead have it work like the corpse works--generate the item from the creature. That way you don't have to go through writing out a Pelt resource for every single animal with a pelt, and also you don't have to link to a specific item in the creature resource.

[bernardosulzbach]

Yes, but some specifics will be linked (such as which weapon a monster uses).

As we are starting with a simple drop system, anything should do the trick (for now).

[ghost]

Right on.

[bernardosulzbach]

Anyway, in the end, it is really up to you (supposing that you will implement this). I'm just saying that you don't need to implement something more advanced than necessary.

[ghost]

Definitely, I'm just spitballing ideas.

[ghost]

In order to give creatures inherent inventories, I need to be able to clone the items from the prototype creature. Creatures can't carry item blueprints (right now), so I either have to create a CreatureBlueprint class from which creatures are created and have that carry item blueprints, or create a clone constructor for Items so that the prototype's items can just be cloned. Doing the clone constructor seems simpler but it sort of seems to invalidate the itemblueprint premise. Is there any particular reason why Item prototypes exist as a separate class (ItemBlueprint) but Creature prototypes are just cloned from a regular Creature? It seems here like it would be best to pick one and do it for both.

Also, I'm not sure... it looks like the ID class doesn't look for String equality, but object equality? Does that mean I can't do itemBlueprints.get(new ID("SWORD")); (just an example since the actual string would be an ID from the text resource) and have it work because it's looking for the specific Id object?

[bernardosulzbach]

  @Override
  public boolean equals(Object o) {
    if (this == o) {
      return true;
    }
    if (o == null || getClass() != o.getClass()) {
      return false;
    }

    ID oid = (ID) o;

    return id.equals(oid.id);

  }

(new ID("Something")).equals(new ID("Something")) evaluates to true. Always. At least on my VM and if in yours it doesn't, it is bugged.

[bernardosulzbach]

Have a look at line 35 of CreatureFactory. Create a creature from a model and then items to it there. Seems the best way to do it.

Maybe ItemBlueprint should not exist.

[ghost]

Right, but either the Creature's inventory has to serve as the model--meaning Items need a clone constructor (or they have to carry their own blueprints, which seems convoluted)--or the creature model needs to change somehow to incorporate a list of itemBlueprints.

My thinking is that ItemBlueprint should be axed and items should just be cloned from prototypes the way Creatures are. Then, I can easily duplicate the Creature's inventory by using it's inventory items as the prototypes.

[ghost]

As for the ID.equals() -- looking over it AGAIN I finally calculated that "id" is the reference to the value that my brain was failing to see. It's getting late here, I was just reading it as ID, I think.

[bernardosulzbach]

I will get rid of ItemBP myself, if you don't mind. Do you plan to do something related to it right now or my time window is a bit larger?

[ghost]

As you prefer. I will probably go to bed soon, but I'm off tomorrow and would like to finish the creature drops and perhaps even the corpse and butchery stuff.

[bernardosulzbach]

If you wrote something such as an ITEMS or INVENTORY (without probabilities, just a plain list of items) for all creatures and these items in the items.txt file I would do the rest gratefully. You don't need to create 3 different items for each creature, obviously. Some may not even get any item, it is fine for now.