superfola / pataro

A generic and modular Roguelike game on top of libtcod - I'll be back soon, just need a break!

Pataro

A C++ 17 Rogue Like library built on top of lib TCOD.

Pataro means Walker Male in Quenya.

Read ARCHITECTURE.md before diving in.

Deps

• CMake >= 3.8

Building

First, clone the repository and refresh the submodules to get vcpkg, then bootstrap vcpkg and install it.

Then you can compile using CMake, don't forget to point to vcpkg toolchain cmake file.

git clone https://github.com/SuperFola/Pataro.git
cd Pataro
git submodule update --init --recursive
(cd ./vcpkg && ./bootstrap-vcpkg && ./vcpkg integrate install)
cmake -Bbuild -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE=./vcpkg/scripts/buildsystems/vcpkg.cmake
cmake --build build --config Debug

Controls

• Move/attack with the arrows (up, down, left, right)
• Take a screenshot with F3
• Collect objects with g
• Open the inventory with i

Code structure

Roadmap

• generation of the world map (rooms + corridors)
• field of view handling
• explored tiles handling
• the player can move and attack
• monsters spawn, can follow the player (if they are in their field of view) and attack them
• everyone has health points, attack power, and AI
• transitionning from libtcod event system to SDL event system
• the world map moves with the player
• GUI about the player, events...
• inventory GUI
• items handling, generation and spawn
• spells and ranged combat
• travelling between levels / floors
• saving player progress on a given map + level
• loading preconfigured maps/levels (eg the overworld with shops...)
• add a game menu
• dungeons and character progression
• (generic?) scripting engine to configure Pataro's engine

Screenshot

pataro's Issues

Write a GUI inspired by libtcod/gui

Add action(s) interacting with the environment

The why is pretty simple: being able to cast a fireball, burning ennemies and wood, is pretty cool

The how is more complex, since this will need to add (at least)

• new type of tile
• ability to query the type of a tile
• enhancements to the Fireball action to search for wood tiles where it hits
  • the propagation of the fire could be achieved through new actions being spawned for each tile to burn?

Move away from TCOD::waitEvent and use SDL event system

Fix CI

The CI is downloading the 1.16 libtcod release and building it with scons on Ubuntu, and the CMakeLists includes tcod/include (which should be a symlink to tcod/src), thus it should find the include libtcod.hpp, but when building, it doesn't.

On Windows, the release isn't downloaded because wget and unzip are not present.

On macOS, libsdl is downloaded but the libtcod release isn't.

Factorizing "Use" components code

The Use components are practically just wrappers to launch an action:

• HealUse -> HealAction
• LightningBoltUse -> LightningBoltAction

Thus I've started to write a OneTimeUse templated component, so that it can return any type of Action.

The problem arise when the creation of an Action needs more than one argument, currently I've settled on a

template <typename A, typename T>
class OneTimeUse
{
public:
    OneTimeUse(T data): m_data(data)
    {
        m_function = [this](Entity* source, Entity* owner) -> std::unique_ptr<Action> {
            return std::make_unique<A>(source, owner, m_data);
        };
    }

private:
    T m_data;
    std::function<std::unique_ptr<Action>(Entity* source, Entity* owner)> m_function;
};

later on, m_function is called in the .use() method of the component, given the source and owner, and returns the action. I've succeeded in using variadic template and constructing a "capture all + perfect forwarding" lambda, so that we can create functions returning an action with more than a single argument. The problem arise when we need to clone the component.

template <typename A, typename... Args>
class OneTimeUse
{
public:
    OneTimeUse(Args&&... args): m_data(std::make_tuple(std::forward<Args>(args)...))
    {
        m_function = [this](Entity* source, Entity* owner) -> std::unique_ptr<Action> {
            return std::apply([source, owner](auto&&... args) {
                return std::make_unique<A>(source, owner, std::forward<Args>(args)...);
            }, m_data);
        };
    }

protected:
        OneTimeUse<A, Args...>* clone_impl() const override
        {
            // typing problem here, most likely because our m_data didn't keep the type correctly according to Args
            return std::apply([this](auto&&... args) {
                return new OneTimeUse<A, Args...>(std::forward<Args>(args)...);
            }, m_data);
        }

private:
    std::tuple<Args...> m_data;
    std::function<std::unique_ptr<Action>(Entity* source, Entity* owner)> m_function;
};

The question is: should we specialize OneTimeUse to take 0 to 5 templated arguments, or find a work around with variadic templates? In the first sample I copied data because I assumed I was using POD, if we assume we're also receiving POD in the variadic template, no more need for perfect forwarding, thus no more errors. But is it viable to assume that we'll only deal with POD?

Revamped energy system

Currently, the player gains 1 energy ever turn, and can use it for anything: walking, attacking, picking up an object, using an object... The same (at least it should, iirc) applies to monsters which can see the player (if they are in the player field of view, they can gain energy ; this is a small optimization to avoid updating things you can't see).

It could be interesting

• to have actions that don't need energy to be used
• to be able to gather energy to cast bigger fireball (by not moving for a couple turns for example)
• to display the energy level
• to find other interesting uses of the energy

Container and pickable

I'm currently implementing containers and pickable components for the actor class, but encountering a problem:

• the pickable component should remove the owning actor from the current level where it is, thus destroy it
• the container should copy the new actor to hold it and ensures that it can continue to exist (pointer lifetime)
• the remove() method of the container should be able to discard an entity, currently working with an internal identifier per actor

This leads to a problem, actors should be copiable, will keeping their id in some cases.

I think the best thing to do would be to copy actors inside the container, in a vector<Actor>, and then search for them by, because storing vector<Actor*> would be very yanky as we would need to "remove" the actor from the map while not removing it to keep it alive (the map has a vector<shared_ptr<Actor>> actors collection but we can't access the shared pointer to copy it into the container).

I'm open to suggestions, currently I'm leaving this as is (an id() method), even though this includes the need to be able to clone in a polymorphic way the actor's components (doable, but need to have a virtual clone() method in every class).

Add serialization to be able to save/load games

I'm currently trying something on this branch, but before going further, maybe one should consider trying a premade library for this, like cereal

The goal is to be able to serialize:

• the player
• the player attributes: attack, defense, bags and the objects in it, its position, health and such
• the objects we picked up, so that they aren't regenerated when the game starts again
• the terrain modifications (if any, currently we don't support it), if the player destroyed a wall or whatever (can be skipped for now)
• the seed of the random number generator (we should use the same seed everywhere or the same RNG, to generate the same map)

Migrating to the new tcod API

Starting from tcod 1.19, a bunch of objects and methods are now marked as deprecated, and we need to move away from them.