Project: Step 2.1
Living Space

Disclaimer: the automatically generated English translation is provided only for convenience and it may contain wording flaws. The original French document must be taken as reference!

Introduction

In this step, we aim to create a first graphical program that allows us to visualize the simulated "environment" (class Environment) and the different entities evolving within it over time (animals, plants, etc.).

Our program will now have as its main component a class Application; the "simulation core" capable of doing graphics and handling events, provided in src/Application.[hpp/cpp].

The class Environment

The wildlife we are going to simulate will evolve in an environment. Therefore, we need to start by modeling this concept in a basic way.

A class Environment will naturally be needed here. At this stage, we will consider that an environment is characterized by:

• The wildlife inhabiting the environment (a set of animals). We don't have any yet, but they will come soon: simply create a class Animal in the directory src/Animal. This class will be empty for now! We suggest coding the collection that represents the wildlife as a set of Animal*. We will have the opportunity to discuss this choice later in the project.
• A set of resources to be targeted by the animals (for now, it's enough to record their position, Vec2d);

To model a set of animals and targets, we will anticipate a little bit of our future course on data structures. The concept of list which does not allow indexing will have the advantage of enabling potentially less costly insertions/removals of elements.

Example usage:

#include <list>
...
list<int> integers; // or list<int> integers(3) or list<int> integers(3,1)
                   // with the same meaning as for vector constructors

integers.push_back(3); // insertion at the end
integers.push_front(2); // insertion at the front
integers.pop_front(); // removal at the front
integers.pop_back();

for (auto animal: animals)

for (auto& animal: animals)

The following methods are to be expected for the class Environment  :

• a method addAnimal(Animal*) that will allow populating the environment (adding an animal to the wildlife);
• a method addTarget(const Vec2d&) that will place resources (targets) in the environment. This method will add a target's position to the list of recorded targets;
• a method void update(sf::Time dt) that will be responsible for evolving all the animals in the wildlife at each time step. For now, this method does nothing (because our animals are still somewhat in limbo...). In the body of the method, simply put a comment like:

  //evolve the animals of the wildlife here:
  

  to remind yourself of the task to code later.
• a method void draw(sf::RenderTarget& targetWindow) that for now just draws the targets of the environment (as small red circles of radius 5) in the graphical window targetWindow. This method will also later be responsible for drawing the animals of the wildlife. Also put a small comment in the method's code to remind yourself that this task is to be implemented when the animals become more concrete.
  • you will notice that the method addAnimal takes a pointer as an argument, while addTarget does not. We will have the opportunity to discuss this choice later in the project.
  • the inclusion of <SFML/Graphics.hpp> is necessary to access SFML functionalities;
  • utility functions are provided for graphics. To draw circles, you can use the function buildCircle provided in Utility/Utility.[hpp][cpp]. A circle, circle thus created, can be drawn on a sf::RenderTarget, target, as follows: target.draw(circle). You can give the color sf::Color(255, 0, 0) (red) to the targets;
• a method clean that clears the environment of all animals or targets;
• a default constructor (you can keep the default version).

You are free to add any other method you think is useful later.

[Question Q2.1] Which methods do you think it would be wise to declare as const?

[Question Q2.2] We want to prevent the copying of an Environment. What solution would you propose to satisfy this constraint ?

[Question Q2.3] Question Q2.2 suggests that each simulation will deal with a unique environment with its own wildlife. Moreover, it doesn't make much sense to let the animals live without attaching them to an environment. An Environment can therefore be considered responsible for the lifetime of the animals created in the simulation. What impact does this have on the destruction of an environment ?

Think about these questions and answer them in your RESPONSES file, and adapt your code accordingly.

Test 2: A Basic Environment

To test the work done so far, you will use the test provided in src/Tests/GraphicalTests/EnvTest.cpp. The class EnvTest inherits from Application. It therefore has an environment on which the drawing and update methods you have drafted will be invoked in a loop. The R key on the keyboard (handled by Application::handleEvent) actually triggers a call to the clean method you just programmed.

This class also overrides the onEvent method so that pressing the 'T' key results in a call to the addTarget method you just programmed.

The provided CMakeLists.txt file allows you to compile the test via the envTest target. Don't forget to uncomment this target in the CMakeLists.txt file (lines 100, 101, and lines 143, 144) and run Build > Run Cmake when you are ready to test.

The behavior of your program at this stage should resemble what is shown in this short video (restart it if necessary):

The keys that can be used by the program are documented in the small help menu that appears in the gray portion displayed to the right of the simulation window.