metabolix/putkarts

PutkaRTS is a real-time strategy game that is being developed by a group of Finnish programmers as a hobby and as a means of learning C++, good coding practices, documentation, team work, and VCS usage.

putkarts's Issues

Task: Map loading

The game should load some kind of map. The initial version could use an ASCII format like this:

WWWWWWW
WGGGGGW
WGGLGGW
WSGGGGW
WWWWWWW

G 1 0 tiles/ground.png
W 0 1 tiles/water.png
S 1 1 tiles/shallow.png
L 0 0 tiles/lava.png

Here we have first the map, then an empty line to indicate that the map ends, then lines containing information about the tiles (tile character, ok for land units, ok for sea units, image).

Task: Message class

The Message class is not finished yet. Here are some missing things:

• Player
• ObjectAction
• List of target objects

Task: Objects, object types, object actions and tech tree

Simple. Design the classes ObjectType, ObjectAction and Object. All types and actions should be dynamically loadable from data files. The only and sole exception is movement, which requires special algorithms anyway.

ObjectType class may represent practically anything:

• Unit
• Building
• Resource (tree or something)
• Static object (stones or something), if they are not made from tiles

Object actions include:

• Harvesting resources
• Attacks (this may be merged below)
• Producing other objects, such as:
  • Units from buildings
  • Grenades and the like, they can be objects as well
• Changing technology tree, that is, changing other object actions
  • Researching new technologies like new unit types to produce
  • Upgrading weapons to better ones
    • A single upgrade may affect multiple object types, like better armour for all tanks

Task: Object graphics

We will need animations from multiple directions, and the object size may vary. Different actions (such as shooting) will also require animations. If needed, modify the World::ObjectType and World::ObjectAction classes to neatly support these.

Decide a format for the animation. Either create a separate index file or code it in a single image using some nice color such as 0xff00ff for separating the frames. Animations for different actions will be stored separately, "objects/<type>/<action>.png" or something.

Create a class that handles a single animation. Use something similar to GUI::ImageCache (but a lot simpler) for the animations to avoid duplicates and reloading. The cache should be organised by object type and action (strings). Use some special strings like "begin", "default", "move" and "end" for states that do not have a real action associated.

Update GUI::GameObject so that it uses the graphics.

Update GUI::GameHandler so that it keeps a GUI::GameObject for each visible object. Handle dead objects nicely: display death animation and then remove from the list. For optimization, drop GUI::GameObject instances after some time if the object isn't visible anymore.

Game::Game: getPlayers() and getObjects() give non-const pointers

The functions Game::Game::getPlayers() and Game::Game::getObjects() should return boost::shared_ptr<const X> so that the caller can't modify the players and objects.

However, it isn't very efficient to duplicate all object pointers. This will probably be fixed when we implement some better way to traverse the objects (e.g. by location, such as getObjectsNearSomething()).

Task: Network infrastructure

The game client and server should be implemented.

The server creates the Game object and any AI players and assigns an id number for each client.

During the game, all clients (including AI clients) send their messages to the server. The server checks that the player is allowed to issue the commands. If everything is fine, the server queues the message (resets message time stamp) and sends it to all clients (also the one who originally sent it).

The client receives the messages in order, feeds them to the local game and always waits until there is a newer message waiting before handling the older ones.

Task: Player class

The Player class should contain information about things like player's resources and map exploration.

Task: Find out some system-specific paths

We need the following paths:

• Global data directory (devel: ./data/, release: $dir/PutkaRTS, where $dir is in $XDG_DATA_DIRS)
• Local config file path (devel: ./local/client.conf, release: $XDG_CONFIG_HOME/PutkaRTS.conf)
• Local data directory (devel: ./local/, release: $XDG_DATA_HOME/PutkaRTS)

The problem is that the paths depend on the operating system and vary even between different Linux distributions. The examples above are fit for a typical Arch Linux installation. For other distributions, we will probably need something more to try. Mac OS X will store at least the global data somewhere near the executable (within PutkaRTS.app). Windows has its own paths for everything.

So, we will need a list of the possible paths, in order of preference. Their existence should be checked on startup, and some might even be created automatically. Then we will need a system that automatically generates the possible search paths for a file; for example, x.png could be searched in local/x.png and global/x.png.

The same system could be generalized for map loading so that image x.png of map y would be looked for in local/maps/y/x.png, local/images/x.png, global/maps/y/x.png and global/images/x.png.

Units move when dragging the view

Units get move commands when dragging the view.

Proposed fix as pseudocode:

mouse pressed:
    mousePressedPosition = current position (in game coordinates)
    mouseAction = true / "move"
mouse move:
    if mousePressedPosition is far from current position:
        mouseAction = false / null
mouse released:
    if mouseAction:
        command units

Task: Classes for user interface objects

There should be a handler that keeps track of the objects and handles things such as tab stops and event passing. Menu and other UIs will be derived from this class.

class UserInterface {
    std::list<UserInterfaceObject*> objects;
protected:
    virtual bool handleEvent(const sf::Event& e) {
        if (e is tab press) {
            move to next tab stop;
            return true;
        }
        // other events: pass to some button
        for (auto i = objects.begin(); i != objects.end(); ++i) {
            if (i->handleEvent(e)) {
                return true;
            }
        }
        return false;
    }
    virtual bool draw(sf::RenderWindow& window) {
        for (loop objects) {
            object->draw(window);
        }
    }
public:
    virtual ~UserInterface();
};

The interface for one object should be like this:

class UserInterfaceObject {
    friend class UserInterface;
protected:
    virtual bool handleEvent(const sf::Event& e) {
        // By default, don't handle events.
        return false;
    }
    virtual void draw(sf::RenderWindow& window) = 0;
    UserInterfaceObject(UserInterface& ui);
    virtual ~UserInterfaceObject();
};

There should be implementations for different types of objects. For example, buttons could work like this:

#include <boost/function.hpp>

class UserInterfaceButton: protected UserInterfaceObject {
    boost::function<void()> callback;
protected:
    virtual bool handleEvent(const sf::Event& e) {
        if (e is mouse click on this button) {
            callback();
            return true;
        }
        return false;
    }
    virtual void drawNormal(sf::RenderWindow& window) {
        // Draw it
    }
    virtual void drawHover(sf::RenderWindow& window) {
        drawNormal(window);
    }
    virtual void draw(sf::RenderWindow& window) {
        if (mouse over button) {
            drawHover(window);
        } else {
            drawNormal(window);
        }
    }
public:
    UserInterfaceButton(UserInterface& ui, position, size, text, boost::function<void()> _callback);
};

The system could be used like this:

#include <boost/bind.hpp>

class MainMenu: public UserInterface {
public:
    void run(sf::RenderWindow& window) {
        UserInterfaceButton newGame(*this, position, size, text, boost::bind(&MainMenuHandler::onNewGame, this));
        UserInterfaceButton exitProgram(*this, position, size, text, boost::bind(&RenderWindow::Close, &window));

        while (window.IsOpen()) {
            sf::Event e;
            while (window.GetEvent(&e)) {
                if (handleEvent(e)) {
                    continue;
                }
                // else check if something else should be done?
            }
        }
    }
}

Implement chat messages

Add chat messages to the network protocol. A message should have a sender and a list of receivers.

Task: Path finding & tile collisions

First make objects move directly to a given location. There isn't any GUI control system yet, so make the locations random.

Next, implement path finding. Remember to check tile types so that a land object doesn't move through water.

Task: Menus

Here is a draft:

• New game
  • List of maps (initially a dummy list)
  • Settings, if any.
  • Provide a way to choose either local game or a network game. Some possibilities:
    • Microsoft style: select single player or multiplayer from the main menu; people can join even before the map and settings are set and discuss things.
    • Blizzard style: first make the game, then wait for people; while waiting, show only minimal settings like teams and races.
    • Something else, what?
• Join game
  • Either enter an address or select from a list of known servers.
• Settings
  • Widget::TabPanel or something.
  • Some possible tabs:
    • Graphics (resolution, fullscreen)
    • Sound (music, unit sounds)
    • Gameplay (scrolling speed)
  • Make this good so that it can be used during the game as well!
• Credits
  • Make it look good. ;)
• Exit

Implement Widget::TextField

Implement a text field widget. Try to reuse Label where possible.

Task: Configuration file

The game should have some kind of configuration file for storing game settings like resolution and player name.