fabio-t / alone-rl Goto Github PK

change pom to use the newest AsciiPanel commit, since it has a few bug fixes and some interesting minor features.

• crafting info must be added to README (how to do, what recipes are available) and put up near the controls

• Also in README, reduce the size of the GIF and show the starting screen, opening craft screen, viewing recipe, then throwing a stone or something (related to this: always put a worn stone in the player to speed up testing..)

The smart way would be to implement a yaml serialiser/deserialiser for artemis-odb itself, so as to have component mappings.

But we'll go the easy way first: parse the yaml file and manually check a list of possible keys, then convert them to components as appropriate.

We are already doing it for primary attributes (and then we create secondary attributes), but stuff is still missing:

• Game configuration (height and width of terminal, tileset, hour-seconds..)
• Map generation information (seed, "biomes", distributions for placement..); this might probably be "distributed" in another files
• Creature, trees, boulders etc placement.. (probably linked to above)
• Map thresholds for terrain (colours, character, elevation) #18
• Creature templates #30
• Item templates
• Crafting recipes #14

• Cell becomes a class with character data, height threshold, movement cost, name, (a property to know if it's water?), etc
• all available Cells are loaded via a terrain.yml file; they must be pooled and set to the terrain array (see #12)
• in the rest of the code, we still get a Cell from the map but obviously we can't use EnumSet like we do, so we must think about how to solve this (#17 in general should solve it because we would just pass a lambda selecting for the terrain "types", eg names, that we care about - or those having some specific properties, etc)

This must be supported:

• ai check intervals should be shorter than actions

• some behaviours should be able to interrupt others, but usually the selected behaviour should be let running

One way to achieve this is to keep the best behaviour score of the previous check in memory, then at every check we run all behaviours evaluations again but only select a new one if the score if higher than the previously selected score - or if the cooldown has expired.

This does not account for the case when a behaviour should be interrupted, because it's an action that is active, not a behaviour. But if the checks are often enough (even twice per second is plenty), it should work pretty fine. Say that a fleebehaviour makes me move somewhere, but then I'm attacked from another direction. At the next check the fleebehaviour should pop out a score high enough that I will activated this new flee. If not, I only lose a single movement action.

(it should always pause when changed, if in real-time mode)

• Start: new game, continue, save?, options, credits..
• Play: the actual game
• Inventory: it's actually multiple inventory-like screens: drop/throw/equip/eat
• Look: shows entity/items at current target position (necessary? might just be an enhancement on PlayScreen)

1. StartScreen should see map and bootstrap essentially doing nothing yet
2. If new game, load map generation; only process MapSystem when map is chosen (make the "init" a method that must be called, so we manually call it either in MapScreen or in StartScreen if player chooses Continue); only process "bootstrap" when player stats are chosen (again, should not actually process but just present an API to place creatures and trees), then enter playscreen

• item

• crafting recipe (needs a corpse and a sharp instrument)

• it needs to inherit the creature skin protection values. Also, it should possibly have a bonus to blunt, a malus to point and average to slash.

In map-generation, we should only write to file when one map is selected with ENTER. The quick & dirty way I did it now it's only a placeholder.

• allow chaining of screens? Eg, if you [t]hrow, but don't have a wielded weapon, we should open the inventory screen and after a weapon is selected go forward with the Look screen. If ESC is pushed we go back to play screen. Instead of keeping a single field with the next screen, we should instead have a list. If we don't go through with that, the list is purged.

• subscreens should not cover the whole screen, but adapt to the size of their content

• they should also have a nice border, possibly not just white (a nice purple maybe?)

Some of the settings/classpath etc sneaked into being tracked.

FastUtil works great.. but it makes my jar 20MB in size. It's too much. Must evaluate some other option.

Having to work with RGB is quite annoying. I think a palette like libtcod's works much better.

A private-constructor class Col should do the job. In code, I should only use something like Col.red.lightest(), that finds the right colour in that cell. Colours would all be flyweights of course.

Then at rendering stage awt.Color is wrapped around the chosen colour.

• light a fire - crafting recipe or dedicated mechanic?

• put out a fire - do we need it at all?

• fire spreading - how fast and under what conditions? Should we skip it for now?

• making and using torches

• wielding a torch should increase FOV range at night and reduce darkness.

• a fire at a distance should be visible is within maximum sight but beyond current sight at night. How to handle FOV increase when we are very close to such fire?

I've inverted them by mistake in terrain.yml. Also I should look if the colours used in the terrain-generator are the same or if I've tweaked them (they looked nice).

Something like this:

https://github.com/Emmsii/roguelikedev-does-the-complete-roguelike-tutorial/blob/master/src/com/mac/rltut/game/screen/game/GameScreen.java

Which one to use (ASCII or sprites) should be choosable with a Function key or via config (depending if I can make it work on the fly).

Initially it should be purely 2d top down square tiles, but we might try to play with rectangular overlapping tiles to make depth.

• Graze: restricted to herbivores. For now, the utility it's simply proportional to hunger. Later, it might be logarithmic if we are on a grass cell already, and exponential if we are away from grass.
• Flock: keep track of your "companions". If the creature is far away from the group, moves toward its center of mass. To think over: how does the "leader" decides a direction? A different behaviour, maybe.
• Call:
• AnswerCall:
• Wander: just move randomly, as a fallback if nothing else gets selected

For carnivores I was thinking of something along the lines of "Search", where it's not only about randomly walking around but also giving a (fake) sense of purpose. How can that be achieved? Possibly, through fixing a far-away direction somewhere and keeping at it over time (I need a Path component, pathfinding function and support from MovementSystem to achieve this. I'll open an issue for them).

How to harvest it? Action to de-bark tree (must then mark the tree as "de-barked" so you can't do it again), or as side product of falling a tree?

• item

• crafting recipe (consumes one trunk)

For the use we do, IntSet is much better than the IntList to store the IDs of the entities within a certain grid.

We both iterate over the elements often, but also add/remove. O(1) add and remove are gold.

If I need to keep the order of the inserted elements (I'm pretty sure I don't, but IF), I can use the implementation IntLinkedOpenHashSet.

If there's no GRASS cell around the herbivore, we should follow the gradient: go up if we are lower than grass (eg water, sand). Go down if we are higher than grass (mountain, hill).

This should make for interesting movement patterns.

• convert all colours to HSB (hue, saturation, brightness). This must also encompass the templates, palettes etc. This should make the below easy, otherwise it's a headache. This also implies one important thing: we store (we'll probably need a ColHSB class with three float fields) and modify HSB float values, and only convert to Color class when absolutely needed, eg when rendering.

• there should be two thresholds: the "hard" one, over which we cannot see anything, and a "soft" one, where we tweak the above-mentioned v value proportionally to distance and hour of the day. To decide: beyond the hard threshold we either show pure black, or it's a "shadow" like now.

• evaluate if the following makes sense: hour of the day adds a cap to "sight", black colour is for beyond-sight, shadow-view is for what is shaded by obstacles but within our sight radius, proportional darkness (but with items and creatures visible) is applied during low-sun hours inside our view radius to both the visible and shadowed cells.

Test and integrate the following library: http://rlforj.sourceforge.net/index.html

• make a CraftScreen that opens by pressing c and shows the available recipes. When a recipe it opens a CraftItemScreen with more detailed information on that specific recipe (eg, what it does require, do we have all that, what will it produce). ESC goes back as usual, and ENTER produces the item.

• recipes should be loadable from a single file, crafting.yml. All involved items (the output item and the sources/tools) must be specified into items.yml (see #12).

• failure to craft, and success in crafting, must both produce a Message otherwise the user doesn't have a feedback.

• item types (one per body part? Or allow multi-part?)

• crafting recipes

• must inherit protection values from material

• shadowView can be simplified by simply assuming that every "obstacle" is visible outside the Fov

• Crushable and Cuttable can be joined into a Destructible component that takes the WeaponType (if null, it can't be destroyed) and minimum damage needed. This can be simplified further by using the Obstacle component (renaming it Destructible).

First, of course, must release it :) it will change a bit the API and it's a good thing to keep AloneRL and rlforj-alt in sync.

• bow and arrow items and crafting recipes

• shooting mechanic

• screen support

Title and bars look strange with the map behind. It would probably be better to leave, eg 3 or 4 lines black and put the title and bars there.

Must specify:

• how to download, possibly with direct link (tricky for release version but must figure out a way)

• requirements, eg Java 8 (direct link to installation? Write howto in Wiki?)

• how to run: must provide a run.sh and run.bat for respectively Linux/Mac and Windows. Internally these should run java -jar alone-rl-XXX.jar

• bonus points: actually release the game with launch4j or IzPack to make the process simpler to the user

Must investigate whether I should pass a lambda to map functions, or even better how to make it a Stream so that I can use functional-style filter/fold/map functions.

To properly implement the Character Creation (#20) I must handle the creature templates just like items and terrains. This implies a bit of refactoring into BootstrapSystem, or the creation of a CreatureSystem that allows instantiating creatures of a specific "type" at runtime.

It will probably be better if we define all creatures in a single file.

It remains the question or where to put player specific configuration, then. Some things shouldn't be modifiable, eg primary attributes are chosen at creation, not via a file. However, stuff like Sight should be configurable, unless I make Sight another primary attribute (that consumes attribute points at creation).

When thrown, an object doesn't stop on its path - even if there's a bump action raised.

Right now, at every AI tick (variable for each entity, to avoid clogging the system) we evaluate all possible behaviours and choose the best one. Depending on the circumstances, the scores might be so that we could be in a situation where behaviour A is selected, then behaviour B, then behaviour A, every tick.. thus doing close to no work.

One solution is to add a behaviour cooldown, optional and to be used sparingly. Important, substained behaviours (like Chase and Flee) should have a cooldown lasting twice or thrice a a single movement time. This allows for the same behaviour to be evaluated at each tick, unless its score goes to 0 or the cooldown expires; then the other behaviours would be evaluated again and the best executed.

One problem is of course reactivity: if I put a cooldown to non-essential behaviours, or too long a cooldown in general, the creature will be complitely oblivious to things unrelated to the active behaviour.

With some discipline in cooldown configuration, it should be fine though: behaviours related to escaping death/danger should have the highest cooldown (we don't care about anything else); behaviours related to nutrition should have a cooldown (it's important we don't starve) but proportional to hunger, so for a light hunger we'd eat, but we'd still be highly reactive to the environment; other behaviours don't need a cooldown.

EntityGrid (and probably future other classes) return groups of entities by creating a new list and add elements, than returning it. This is safe, as the caller can either keep, or discard, the result list: it's new.

Some of the functions however, either return the ACTUAL internal list, or they make a copy that is technically unnecessary.

In this case, we should return an Immutable version of the collection. With one caveat: I don't want the elements to be copied!.

The solution should simple: use a wrapping class/interface to the collection, one that doesn't expose set/remove/add etc. I should first dig into fastUtil and see if it's available, otherwise ImmutableBag of artemis-odb, or else I'll craft something up.

Each behaviour has a list of "necessary components". We should either make an initial if condition checking all necessary requirements, or (if possible) create an Aspect with the right composition and use it for quicker testing.

Also, I need to remove some component mappers from AISystem (they are not needed anymore).

• make entity creation data driven: look into artemis-odb json serialiser
• linked to above: need to save/load the game, even for testing, as it speeds things up
• for debug, make some more world/entity creation commands for the player, so that I can test various things without re-running the game

Only a python script right now. Makes decent rivers but no lakes.

Must be tweaked to produce decent rivers and lakes.

• animal sight should get the same penalty as the player's

• nocturnal animals should have the opposite problem, maybe. Or just a much reduced penalty at night.

Right now, the player's view is limited by the FOV algorithm. The creatures should use the same (the distance check is already in place, but it doesn't consider walls).

That would allow, for example, the player to sneak past dangerous creatures by standing next to a wall, and for preys to get cover from predators.

• MapGenerationScreen: after choosing New, map generation should be prompted (with possibility to re-run, but no configuration for now)

• CharacterCreationScreen: after the map generation, there should be a screen to modify the character's strength/agility/constitution