Add a base class for animated 2D objects (aka Sprites). All steps have the same duration, specified on construction. Drawing a Sprite requires setting the right SDL_Rect to show the right step AND the right state.

Implement a management class, to reopen conversations when a new message arrives and start new ones if necessary. No messages will be recorded server-side: if you try to reach a player who is not connected, the messages are lost.

Although the file in its present form has 3 lines, only the first one can be seen in the GUI.

It would be useful to keep the previous contexts, so we can get back to them without necessarily losing the state. To do this, instead of the current state of a single pointer, using a stack would be beneficial. The only edge case here is when you want to leave a room while playing, which should move you back to the room list instead of the lobby.

Factor the parts in classes representing objects shared between the client side and the server side which are needed on both sides.
Such classes include:

• player
• room
• server

Obviously the most important one. Should feature a scrolling background, with possibilities to move by putting the pointer at the edges of the screen.

Store a game map. On construction, parse the whole XML description file, but only load the preview. Offer a method to load the rest. Be able to destroy terrain (SDL2_gfx filledCircleColor will be useful, but we will have to use internal textures and probably a dedicated renderer to a texture to make this work).

Once #1 is completed, set the project to use Appveyor for Windows CI.

New UI component: chat balloon. Make the text appear character by character, lines of 20 characters max, 10 char/sec. Once fully displayed, must be kept visible in full for 5 seconds. At most 1 balloon per player at a time: if a new one arrives, destroy the previous one.

Manage the different requests sent, check timeouts, repeat timed out requests and create listeners for the various message types (chat, user shots...). Be the interface between the network and classes inside the software which need to send/receive messages.

From the server view, it should be possible to create a new room. Required info is:

• name
• password (can be left empty)
• map
• sudden death type
• sudden death delay
• size

At the server side, it may be necessary to have a database in order to store user data, avatar item list and manage rooms currently being played.
Because the traffic and update requests are likely to be quite low, and to keep software requirements low too, I plan to include SQLite.

GUI improvement for #11, may be better in guisan.
In #11, there could be a filtering option to select which types of rooms you want to see. Implementing this with checkboxes would be possible, but less elegant.

On some machines, the colorkey is not taken into account. This is especially visible with the mouse cursor.

Be able to load the avatarlist.xml into the system, so we can fetch an item when needed. Key is a unique identifier (Uint16), attributed in sequence. As with game maps #12, only load the actual image data when requested.

Before envisioning packaging for Linux (RPM, DEB...), an installation target needs to be set for Linux in CMakeLists.txt. Related to #1.

Use CMake instead of autotools to ease multiplatform compilation.

This is where you land when clicking on #16.

On some machines, the colorkey is not taken into account. This is especially visible with the mouse cursor.

Write the view for the list of servers.
A quick note:

• for the LAN operation mode, a broadcast message should be sent on startup so that local servers can announce their presence
• for the WEB operation mode, we should rely on a hardcoded list of servers (or on a configuration file).

In both cases, it should be possible for the user to specify manually the IPv4 of a server to connect to.
The LOCAL operation mode directly jumps from the menu to a room, hiding the fact that it actually connects to a server running locally and creates a new room in it, then joins this room.

Useful for #11, the Room button should be able to feature basic data about a game room prior to entering it:

• number
• title
• show if password-protected
• current status
• current map being played
• number of players in it / capacity.

If possible, right-clicking on it should toggle an extended view showing who is actually inside.

Shows the different rooms, buddy list, communication channel, list of connected players. Allows access to the item shop. Allows to create a new room.

When a match is over, this dialog should pop up with the gained money and experience for each of the players. For simplicity, no order is implemented, the only requirement is that winners and losers show up in two different columns.

• Add an extra mode in RoomView for when this window is displayed
• Auto click on OK (only button) after a short delay closes the window and transitions back to the lobby
• The PlayerResults struct should be used here.