Hunger/Awakeness effects

[hwoarangmy]

Hi,

I've almost done the hatchery and added the hunger system. Now, creatures go feeding when they are hungry. But there is no real effect when it is starving.

I guess when a creature is sleepy/hungry, it will affect its moral when it will be implemented. But do we want to affect also its stats ? Is a creature really sleepy as effective as an awake one ? Same for hunger ?

[hwoarangmy]

The pull request for hatchery is done

[Danimal]

I think we should let it at a minus for morale, your perfomance idea is cool, but something tells me its no good. It would just add to micromanagement and players feeding chickens by hand to all his creatures before a battle. I dont think such realism would add to the game at all, but rather the contrary.

[Bertram]

Hi there,

The mood system is something a bit more advanced we discussed earlier with Danimal. i do think that hunger / awakeness should have an impact on mood later.
As for the hunger, awakeness, apart from bothering the creature and making it go to sleep or eat, what we discussed earlier IIRC was that it would make the creature more likely flee battles and all sort of effort.
https://github.com/OpenDungeons/OpenDungeons/issues/11

If the effect is either applied directly or we should wait for the mood system is up to discussion.

Regards,

[hwoarangmy]

Ok, I can understand that you don't want to focus the game too much on micromanagement. And, anyway, we will have time to do it if we think something should be changed.

But IMHO, the biggest problem with DK was that it was too flat. Usually, when I played a game, I started to check for wizards/dragons to search in the library. As soon as I had Cimetary, I used to kill the wizards by slapping them and after a while, I got a vampire. Then, I just add to level him as much as possible and he was so powerful that he could almost finish every level by himself. He could even beat horny in 1v1 both level 10.

That's why I believe we should find a way to make OD more different and to not have one big creature that beats all the others. I also believe we should try to add risk to the player actions. For example, we could make a bit long to recover from wounds. That way, if a player puts too much of his creatures in the arena, he will take the risk of being attacked and loose his precious leveled wounded creatures

[Bertram]

But IMHO, the biggest problem with DK was that it was too flat. Usually, when I played a game, I started to check for wizards/dragons to search in the library. As soon as I had Cimetary, I used to kill the wizards by slapping them and after a while, I got a vampire. Then, I just add to level him as much as possible and he was so powerful that he could almost finish every level by himself. He could even beat horny in 1v1 both level 10.

Eh eh. Well, I had a similar technique with black mistresses. DK was a stone breaker in itself, but the guys could handle it all at once, I guess.

That's why I believe we should find a way to make OD more different and to not have one big creature that beats all the others. I also believe we should try to add risk to the player actions. For example, we could make a bit long to recover from wounds. That way, if a player puts too much of his creatures in the arena, he will take the risk of being attacked and loose his precious leveled wounded creatures

I agree with that point. That's why I believe we should make OD the most configurable possible concerning creature stats, room effects, and even effect per turn, such as awakeness lost per turn, and the like.
This way, it will be a matter of tweaking the values until obtaining the desired effects and try many things without recompiling the game endlessly. This could also help tweaking those values for mods, or different difficulty levels, like in campaigns.

As a first step, I'd propose that stats/level configuration support should be added to creatures.def.
E.g.: hp (when spawned at lvl 1)/ hp per level / max hp (can't be higher than that whatever the level)
Repeat for every stats.
I'll work on a XP scale, and earning values and conditions sheet based on the time a lan should last also.

Also, on the whole design plan, now we have functional basic rooms thanks to a developer which name starts by a H ;], what is next is to add creature spawning conditions and maybe room build availability conditions along with streamlining creatures stats.
In short:
- Creature spawning conditions (basic): A creature only has a chance to spawn if a room R with at least X active spots exists when rolling the spawn dice.
This way, building a room the fastest possible will have a reason.

- Room build availability conditions: 2 different things:
1. A level parameter, telling which rooms can be built in this map. Note that I said 'built', not already built when starting the map. It will be useful to later create a certain challenge on certain maps, will make possible to disable certain rooms at the beginning of the campaign for tutorial purpose, and will permit to disable unfinished/useless rooms when doing a release.

2. A separate concept from 1 but has the same effect: The Keeper can only build a room if certain parameters are gathered.
E.g.:
- The (new and shiny) Hatchery becomes available once you have at least 4 creatures.
- The Library becomes available once you have at least one Wizard.
...

In both case, the corresponding room button is hidden if not available.

Feel free to complete me would I be wrong. We should also try to complete the list of conditions for 2. so we can think of a configuration that handles it.
Note that 1. would be great for the release, if certain rooms are useless. 2. would be for after the next release, unless someone holds on it fast.

If we can come to an agreement here, I'll open corresponding issues on github.

Best regards,

[hwoarangmy]

I agree with that point. That's why I believe we should make OD the most configurable possible concerning creature stats, room effects, and even effect per turn, such as awakeness lost per turn, and the like.
This way, it will be a matter of tweaking the values until obtaining the desired effects and try many things without recompiling the game endlessly. This could also help tweaking those values for mods, or different difficulty levels, like in campaigns.

I agree. When we will have a playable game, most of the players will not be coders. That's why we should make it as easy as possible to change that. Even if we need to keep in mind the consequences on multiplayer (as always, the server will be the reference so we should find a way to use the server def file without erasing the client's)

As a first step, I'd propose that stats/level configuration support should be added to creatures.def.
E.g.: hp (when spawned at lvl 1)/ hp per level / max hp (can't be higher than that whatever the level)
Repeat for every stats.
I'll work on a XP scale, and earning values and conditions sheet based on the time a lan should last also.

IMHO, you should put some "logical" values but do not spend too much time as it will be something that will probably change a lot. I remember that for Starcraft 2, the beta lasted for something like 6 to 12 months. So do not expect to find the perfect values at first

Also, on the whole design plan, now we have functional basic rooms thanks to a developer which name starts by a H ;]

I'm gonna make some searches to find who it is

what is next is to add creature spawning conditions and maybe room build availability conditions along with streamlining creatures stats.
In short:
- Creature spawning conditions (basic): A creature only has a chance to spawn if a room R with at least X active spots exists when rolling the spawn dice.
This way, building a room the fastest possible will have a reason.

I've had a look at the GitHub issue concerning mood and it seems quite similar to what is needed for spawning conditions...

This way, building a room the fastest possible will have a reason.

I believe that's a key point. Like in strategy game, you should have the choice between upgrading low level units and rushing your opponent or to not use at all low level units and try to go for the strong ones. But if you go too far in one if theses, you should be exposed. That would prevent everybody to close the dungeon, train until his creatures reaches max level during 1 hour and start to do something only after that.

1. A level parameter, telling which rooms can be built in this map. Note that I said 'built', not already built when starting the map. It will be useful to later create a certain challenge on certain maps, will make possible to disable certain rooms at the beginning of the campaign for tutorial purpose, and will permit to disable unfinished/useless rooms when doing a release.

That seems good.

2. A separate concept from 1 but has the same effect: The Keeper can only build a room if certain parameters are gathered.
E.g.:
- The (new and shiny) Hatchery becomes available once you have at least 4 creatures.
- The Library becomes available once you have at least one Wizard.

On that point, I'm not sure it is the best way. Firstly, because it doesn't seem logical to me to have something that becomes magically available after some random time (the hatchery). That may even look like a bug. Secondly, because I would have expected library to make wizards come. If no library, no wizard. And if we need a wizard for library...
Of course, I'm only talking about basic rooms (dormitory, treasure, hatchery, library and maybe training hall and forge). The others being available through research.

[Danimal]

Of course, I'm only talking about basic rooms (dormitory, treasure, hatchery, library and maybe training hall and forge). The others being available through research.

Disabling them for a tutorial and later enabling them after an explanation sounds good, and maybe disabling a certain room for a whole level; or only recovering it under some condition (like enabling the Farm on the very first level after the first creature enters the dungeon).
But normally, the basic rooms should be available from the start of the level (i dont consider forge a basic room) and the other need to be researched.

[Bertram]

I agree. When we will have a playable game, most of the players will not be coders. That's why we should make it as easy as possible to change that. Even if we need to keep in mind the consequences on multiplayer (as always, the server will be the reference so we should find a way to use the server def file without erasing the client's)

Ok, then the server should send such values to the client at start time, I guess.

The very first values we could soft-code for a start (but not a priority for the next release, we're already ahead of the scope. :]) are IMHO the rooms cost per tile.
This could be defined in the future 'config/game.cfg' file where such generic values would belong.
There are a lot of values that could be added there after the base is done.
What do you guys think?

IMHO, you should put some "logical" values but do not spend too much time as it will be something that will probably change a lot. I remember that for Starcraft 2, the beta lasted for something like 6 to 12 months. So do not expect to find the perfect values at first

True.

I've had a look at the GitHub issue concerning mood and it seems quite similar to what is needed for spawning conditions...

It is. All concepts are linked IMHO, but we have to start somewhere.

I believe that's a key point. Like in strategy game, you should have the choice between upgrading low level units and rushing your opponent or to not use at all low level units and try to go for the strong ones. But if you go too far in one if theses, you should be exposed. That would prevent everybody to close the dungeon, train until his creatures reaches max level during 1 hour and start to do something only after that.

Yep, agreed.

1. That seems good.

I'll open an issue for the 0.4.9 milestone.

On that point, I'm not sure it is the best way. Firstly, because it doesn't seem logical to me to have something that becomes magically available after some random time (the hatchery). That may even look like a bug. Secondly, because I would have expected library to make wizards come. If no library, no wizard. And if we need a wizard for library...
Of course, I'm only talking about basic rooms (dormitory, treasure, hatchery, library and maybe training hall and forge). The others being available through research.

Eh eh, you're completely right. By adding such configuration, we'll have the risk of setting "race conditions".
IMO, that's a risk we have to take while choosing the best configuration. Of course, rooms don't need to forcefully have availability conditions. And maybe my examples were bad.
But when a room becomes available, the game should make it clear it's an event, not a bug.

Note that advanced rooms could be seen as things obtained through research in the library & forge for instance, true, but also when choosing a faction specialization.
My point is also that not every room should be available at a 'standard' game start, while it should be nice to get them right away on test maps.

Research is one key feature, btw:
-> This leads me to think we'll later have to create a 'Research' or 'Skill' window with the available skill/feature to research and their costs.
'Build Cemetery' could be one skill, for instance.
'Fire spell' could be another.
'Spawn stronger worker'
'Choose X specialization', ...

[Akien]

1. That seems good.

I'll open an issue for the 0.4.9 milestone.

Depending on how much work is involved, maybe we should think about setting it for the 0.5.0 milestone?
OD is now starting to be in a pretty solid state, it's playable and the multiplayer works. I think we should aim for a 0.4.9 release in the coming week, and then works towards a 0.5.0 maybe one or two months later? "Release early, release often".
Particularly now that OD is not included (yet) in major distros, it doesn't do much harm to issue releases often even if it breaks multiplayer compatibility between versions.

FYI, I will probably import OD officially in Mageia in a couple of months (by the end of October). Mageia 5 is due for Christmas, and the "versions freeze" (i.e. no new version of existing packages can be imported, but for exceptions) is in two weeks. Luckily it will still be possible to import new packages until the end of October, that's why I'm waiting a bit to package OD :-)

[Bertram]

FYI, I will probably import OD officially in Mageia in a couple of months (by the end of October). Mageia 5 is due for Christmas, and the "versions freeze" (i.e. no new version of existing packages can be imported, but for exceptions) is in two weeks. Luckily it will still be possible to import new packages until the end of October, that's why I'm waiting a bit to package OD :-)

Cool to hear Akien.

Depending on how much work is involved, maybe we should think about setting it for the 0.5.0 milestone?
OD is now starting to be in a pretty solid state, it's playable and the multiplayer works. I think we should aim for a 0.4.9 release in the coming week, and then works towards a 0.5.0 maybe one or two months later? "Release early, release often".
Particularly now that OD is not included (yet) in major distros, it doesn't do much harm to issue releases often even if it breaks multiplayer compatibility between versions.

Note that I was planning a win32 binary release this week, just in case.
I'd rather ask this question to everyone involved in the project: (Please all answer it!!)
--> What is the feature/bugfix you would absolutely want to see (in a reasonnable fashion) before the 0.4.9 release to happen and why?

Depending on the answers, we'll adapt(read reduce) the scope.

Regards,

[Akien]

I'd rather ask this question to everyone involved in the project: (Please all answer it!!)
--> What is the feature/bugfix you would absolutely want to see (in a reasonnable fashion) before the 0.4.9 release to happen and why?

Depending on the answers, we'll adapt(read reduce) the scope.

Let's start this discussion in another topic then, I'll create one.

[hwoarangmy]

Disabling them for a tutorial and later enabling them after an explanation sounds good, and maybe disabling a certain room for a whole level

Of course, theses are case we should handle for tutorial. Actually, in a tutorial, we could even do something when you meet a wizard (already in the map), you get a popup saying that you have met a wizard and where he explains how research works. That would allow using the library. But in normal games, I'm not fond of these behaviour.

like enabling the Farm on the very first level after the first creature enters the dungeon.

I cannot think of an interest in such a thing, except for tutorial purposes.

[Danimal]

Yes, as a tutorial, to explain what each room does one by one