Difference between revisions of "MP Server Ilor"

From The Battle for Wesnoth Wiki
(Goals)
(added progress column to timeline)
Line 1: Line 1:
 +
'''Updated''' on April 21st -- the project was accepted into GSoC 2009
 +
 
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with  
 
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with  
 
* info about what my opinion on the design considerations is
 
* info about what my opinion on the design considerations is
Line 115: Line 117:
 
! PRIORITY
 
! PRIORITY
 
! RESULT
 
! RESULT
 +
! <small>PROGRESS</small>
 
|-
 
|-
 
| 0
 
| 0
Line 120: Line 123:
 
| <p style="color:red">MANDATORY</p>
 
| <p style="color:red">MANDATORY</p>
 
| Write the minimap widget (unless someone beats me to it) and probably test it somewhere in the editor. Also loook into a tabbed control (not really mandatory since I'll be able to make do with buttons)
 
| Write the minimap widget (unless someone beats me to it) and probably test it somewhere in the editor. Also loook into a tabbed control (not really mandatory since I'll be able to make do with buttons)
 +
| none
 
|-
 
|-
 
| 1
 
| 1
Line 125: Line 129:
 
| <p style="color:red">MANDATORY</p>
 
| <p style="color:red">MANDATORY</p>
 
| Make the lobby a separate class and not a hack in the game class. Extract common functionality into a base class or a utility class. Document code along the way.
 
| Make the lobby a separate class and not a hack in the game class. Extract common functionality into a base class or a utility class. Document code along the way.
 +
| none
 
|-
 
|-
 
| 2
 
| 2
Line 130: Line 135:
 
| <p style="color:blue">OPTIONAL</p>
 
| <p style="color:blue">OPTIONAL</p>
 
| Look into being able to show gui2 widgets as tooltips (i.e. not just text). Optional, since it'd be nice to have but nothing will rely heavily on it.
 
| Look into being able to show gui2 widgets as tooltips (i.e. not just text). Optional, since it'd be nice to have but nothing will rely heavily on it.
 +
| none
 
|-
 
|-
 
| 3
 
| 3
Line 135: Line 141:
 
| <p style="color:red">MANDATORY</p>
 
| <p style="color:red">MANDATORY</p>
 
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.
 
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.
 +
| none
 
|-
 
|-
 
| -
 
| -
Line 140: Line 147:
 
| <p style="color:green">MILESTONE</p>
 
| <p style="color:green">MILESTONE</p>
 
| Would be nice, but not required, to have the above done when the program starts (May 26)
 
| Would be nice, but not required, to have the above done when the program starts (May 26)
 +
| none
 
|-
 
|-
 
| 4
 
| 4
Line 145: Line 153:
 
| <p style="color:red">MANDATORY</p>
 
| <p style="color:red">MANDATORY</p>
 
| Document how the room system will be reflected in client-server messages.
 
| Document how the room system will be reflected in client-server messages.
 +
| none
 
|-
 
|-
 
| 5
 
| 5
Line 150: Line 159:
 
| <p style="color:red">MANDATORY</p>
 
| <p style="color:red">MANDATORY</p>
 
| Implement the server part of the room system. Have a room class or equivalent, and the proper server behavior to react to "/joins", "/parts" and messages in general.
 
| Implement the server part of the room system. Have a room class or equivalent, and the proper server behavior to react to "/joins", "/parts" and messages in general.
 +
| none
 
|-
 
|-
 
| 6
 
| 6
Line 155: Line 165:
 
| <p style="color:red">MANDATORY</p>
 
| <p style="color:red">MANDATORY</p>
 
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.
 
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.
 +
| none
 
|-
 
|-
 
| 7
 
| 7
Line 160: Line 171:
 
| <p style="color:red">MANDATORY</p>
 
| <p style="color:red">MANDATORY</p>
 
| Write a simple lobby in gui2. Doesn't have to include any of the "new" ideas for the lobby look, can be just a crude imitation of the current lobby with "a" game list, "a" playerlist and "a" chat window.
 
| Write a simple lobby in gui2. Doesn't have to include any of the "new" ideas for the lobby look, can be just a crude imitation of the current lobby with "a" game list, "a" playerlist and "a" chat window.
 +
| none
 
|-
 
|-
 
| -
 
| -
Line 165: Line 177:
 
| <p style="color:green">MILESTONE</p>
 
| <p style="color:green">MILESTONE</p>
 
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.
 
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.
 +
| none
 
|-
 
|-
 
| 8
 
| 8
Line 170: Line 183:
 
| <p style="color:red">MANDATORY</p>
 
| <p style="color:red">MANDATORY</p>
 
| Write a proper tab-based (or fake tabs with buttons) interface for having many rooms open in the lobby, and interface for joining and quitting rooms.
 
| Write a proper tab-based (or fake tabs with buttons) interface for having many rooms open in the lobby, and interface for joining and quitting rooms.
 +
| none
 
|-
 
|-
 
| 9
 
| 9
Line 175: Line 189:
 
| <p style="color:red">MANDATORY</p>
 
| <p style="color:red">MANDATORY</p>
 
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.
 
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.
 +
| none
 
|-
 
|-
 
| 10
 
| 10
Line 180: Line 195:
 
| <p style="color:red">MANDATORY</p>
 
| <p style="color:red">MANDATORY</p>
 
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list
 
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list
 +
| none
 
|-
 
|-
 
| -
 
| -
Line 185: Line 201:
 
| <p style="color:green">MILESTONE</p>
 
| <p style="color:green">MILESTONE</p>
 
| Have the above done by July 12.
 
| Have the above done by July 12.
 +
| none
 
|-
 
|-
 
| 11
 
| 11
Line 190: Line 207:
 
| <p style="color:blue">OPTIONAL</p>
 
| <p style="color:blue">OPTIONAL</p>
 
| Write more game list filters like filtering by era, filtering by eras the player has, text-matching for stuff beyond the game name etc. plus a fancy interface for it.
 
| Write more game list filters like filtering by era, filtering by eras the player has, text-matching for stuff beyond the game name etc. plus a fancy interface for it.
 +
| none
 
|-
 
|-
 
| 12
 
| 12
Line 195: Line 213:
 
| <p style="color:blue">OPTIONAL</p>
 
| <p style="color:blue">OPTIONAL</p>
 
| Write the tab interface for private messages
 
| Write the tab interface for private messages
 +
| none
 
|-
 
|-
 
| 13
 
| 13
Line 200: Line 219:
 
| <p style="color:red">MANDATORY</p>
 
| <p style="color:red">MANDATORY</p>
 
| Write a rough equivalent of the current player list with some upgrades (group labels instead of just colors to distinguish player groups, ability to hide some of the groups)
 
| Write a rough equivalent of the current player list with some upgrades (group labels instead of just colors to distinguish player groups, ability to hide some of the groups)
 +
| none
 
|-
 
|-
 
| 14
 
| 14
Line 205: Line 225:
 
| <p style="color:blue">OPTIONAL</p>
 
| <p style="color:blue">OPTIONAL</p>
 
| Implement all the outlined upgrades to the player list, with icons, nice interface for hiding groups, sorting options, possibly being able to hide the player list entirely.
 
| Implement all the outlined upgrades to the player list, with icons, nice interface for hiding groups, sorting options, possibly being able to hide the player list entirely.
 +
| none
 
|-
 
|-
 
| 15
 
| 15
Line 210: Line 231:
 
| <p style="color:blue">OPTIONAL</p>
 
| <p style="color:blue">OPTIONAL</p>
 
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.
 
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.
 +
| none
 
|-
 
|-
 
| 16
 
| 16
Line 215: Line 237:
 
| <p style="color:red">MANDATORY</p>
 
| <p style="color:red">MANDATORY</p>
 
| Write a simple RNG service in wesnothd. Write a simple server-rng-using RNG in the client. Wire it up to do combats and test. If not feasible, write a descriription of the problems encountered.
 
| Write a simple RNG service in wesnothd. Write a simple server-rng-using RNG in the client. Wire it up to do combats and test. If not feasible, write a descriription of the problems encountered.
 +
| none
 
|-
 
|-
 
| -
 
| -
Line 220: Line 243:
 
| <p style="color:green">MILESTONE</p>
 
| <p style="color:green">MILESTONE</p>
 
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.
 
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.
 +
| none
 
|-
 
|-
 
| 17
 
| 17
Line 225: Line 249:
 
| <p style="color:red">MANDATORY</p>
 
| <p style="color:red">MANDATORY</p>
 
| Write "a" way of moderating wesnotd without launching the game. Could involve having to type a special password with each privmsg command to the lobby bot, but should work.
 
| Write "a" way of moderating wesnotd without launching the game. Could involve having to type a special password with each privmsg command to the lobby bot, but should work.
 +
| none
 
|-
 
|-
 
| 18
 
| 18
Line 230: Line 255:
 
| <p style="color:blue">OPTIONAL</p>
 
| <p style="color:blue">OPTIONAL</p>
 
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.
 
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.
 +
| none
 
|-
 
|-
 
| 19
 
| 19
Line 235: Line 261:
 
| <p style="color:blue">OPTIONAL</p>
 
| <p style="color:blue">OPTIONAL</p>
 
| If the prototype is successful, wire all random numbers to use it, make it robust.
 
| If the prototype is successful, wire all random numbers to use it, make it robust.
 +
| none
 
|-
 
|-
 
| 20
 
| 20
Line 240: Line 267:
 
| <p style="color:red">MANDATORY</p>
 
| <p style="color:red">MANDATORY</p>
 
| Touch up various areas of the code, especially make sure the gui behaves nicely.
 
| Touch up various areas of the code, especially make sure the gui behaves nicely.
 +
| none
 
|-
 
|-
 
| -
 
| -
Line 245: Line 273:
 
| <p style="color:green">MILESTONE</p>
 
| <p style="color:green">MILESTONE</p>
 
| Have the project in a working and polished state by August 15.
 
| Have the project in a working and polished state by August 15.
 +
| none
 
|}
 
|}
  

Revision as of 20:02, 21 April 2009

Updated on April 21st -- the project was accepted into GSoC 2009

Updated on April 5th or 4th depending on your timezone (around midnight GMT) with

  • info about what my opinion on the design considerations is
  • server-side RNG info
  • updated timeline

About me

My name is Tomasz Śniatowski, ilor on irc/gna/forums/wiki, I'm a third year software engineering student in the Wroclaw University of Technology in Poland. My preferred e-mail adress is kailoran(at]gmail.com

I chose to participate again to allow myself to focus on Wesnoth development during the summer i.e. earn summer money while doing something fun. Wesnoth was my default choice for an organization as I feel that being already familiar with the code will allow me to be much more productive.

Experience

Wesnoth

Last year I successfully participated in Summer of Code, completing the Editor2 project. I am currently maintaining the new map editor and sometimes doing some small random fixes or features around the code.

General

A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([1]) that automated some tedious tasks. Some time later I got involved for a while in another browser based game, a local text MMORPG under construction ([2]). I wrote several helpful Greasemonkey scripts, such as a simple ajax-ification of part of the game, that I hope will be integrated into that game someday. I also had some chats with the game developer and helped him with some PHP and database stuff. I'm not more involved there because the developer wants to keep it a one man job for now, and it's a closed project which makes it appeal to me less and less.

I also have some intermediate-level database knowledge, mostly MySQL for webapps and MSSQL for a proprietary accounting application I helped deploy and maintain in a small company. Right now I'm in the middle of a database design course at my uni but I'd rather not talk about it. It's in MS Access and that should be enough.

I have also coded some websites as a kind of part-time job. This included using an established framework (Zend) and adapting and maintainng open-source software installations (oscommerce).

I have mostly worked on my own, though once or twice I coded something with 2 or 3 friends. A notable example from this school year was writing a simple raytracer from scratch (in C++), which later became the basis for a distributed systems project. This was a very interesting experience, especially since eventually it all worked fine. The raytracer I wrote on my own, the distributed bit was in cooperation with a friend. We ended up modularizing the project which allowed us to work efficiently, and the project was well-received by the profs.

Gaming

I played lots of various games, from strategies both real-time and turn-based to shooters and RPGs. I tend to play mostly singleplayer, and like a good story in a game, though some games, like racing sims, don't really need one. I also think that bad gameplay can kill a game regardless of story. I also really prefer solid gameplay to stunning visuals, possibly because I could never justify buying a high-end gaming rig. I have played some Wesnoth campaigns, enjoyed them, but generally find myself not having time for a lot of games lately, including Wesnoth.

Communication skills

English is my second language -- my first is Polish. I have no trouble communicating in English in any way. I consider myself fairly good at interacting with other players and developers. I try to give advice when I can and when I am fairly confident it will be correct. I don't really like people who keep giving "advice" despite not knowing much. I'm perfectly fine with receiving advice, I generally prefer having someone look over my ideas especially when starting on something new. Sometimes I ask for help, sometimes I make it a point to figure out stuff by myself.

Project

The project is to extend the wesnoth multiplayer server and the client-side lobby interface, as outlined in SoC_Ideas_Multiplayer_server. There are essentially two parts to the project, an UI ovarhaul in the client and some modifications to the server, with choices to be made in both cases.

Design considerations

Lobby channels/rooms/filters

Channels are probably the most common way of handling larger audiences, but there are concerns that it'd split the community, and make moderation more difficult. One other idea was a "chat filters" thing, but I'm not entirely convinced it'd work well. Regardless of the choice, I think all users should start in the general lobby by default and only move elsewhere if they really need to. Assuming channels, I'd make it so everyone's in the lobby always, but can join a different room if they want to. A tab-like interface would allow switching rooms, as is common in chat apps, irc etc.

Wesnoth-less wesnothd chat / moderation

In general starting up Wesnoth takes a while and keeping it on is a bit of a hassle. An irc-server-like interface to allow moderation would be very welcome, but I think might be too difficult. If we'd want to mirror the room structure into a server, I think the best approach would be to extend an existing modular ircd with a wesnoth interface.

Extending the lobby bot would be another option esp. if we don't do channels. The bot is in perl which I don't know well but I probably could manage if the scope of the canges required there would be small enough.

Ranking

It seems well established that ranking should not be a part of the server. If anything, a method of veryfing that a game has been played (by e.g. the server publishing replays) could be desirable to help ladder efforts, but this has been determined to be fairly low priority. Also Soliton seems to have taken matters into his own hands and worked on that. Ditto for a surrender feature (as opposed to quit), which is possibly complicated and not really in the scope of the project.

Server-side RNG

It came up that it would be useful to delegate the random number generation to wesnothd to alleviate some potential cheating (predicting next RNG rolls since the client knows the seed). It would involve the client asking the server for a bunch of random numbers to be used as a seed whenever it needs to do some dice-rolling. This can potentially bring some unwanted lag, but the added security might just make it bearable.

After some discussion it seems that a reasonable idea would be to have a new delegating RNG in the game that would have a special state variable (validity). The RNG would become invalid after every action that involves user interaction (like unit movement, attack selection, deciding to recruit, answering a WML dialog question, etc). When a random number is required and the generator is invalid, it will ask the server for a new random seed. If the RNG is valid, it'll just generate another number. This way there are no changes to be done in WML and the random numbers become safe.

The WML side of this is a bit tricky, it might be required to add another method of RNG generation to split "private" and "shared" random numbers. This will also require in-depth investigation of how the data about what's happening ingame is sent around. It is much simpler in the (far more crucial imo) case of combat -- when the final decision to attack is made (attack type is selected) the game will ask the server for a seed to be usd in this combat only, making combats unpredictable and cheat-proof. This should be enough to test the validity of the entire approach.

Server-side details

Maintenance work

The server looks like it needs some maintenance. Having the lobby be a special game works, but isn't really logical and leads to hacks and workarounds. I'd extract the common actions for games and the lobby into a superclass and derive Lobby (or Room) and Game from that class. Documenting along the way would be helpul, too.

Options are not necessarily bad

I think that regardless of what we decide to implement, there should be a way of disabling it (other than reverting all the changes). For instance, if we implement rooms, there should be a simple "one_lobby=yes" value to set in order to revert to a behavior similar to the old one. Even if we decide not to do a feature, I'd rather have the code written in a way that would allow adding it later without having to redesign half the server (or client).

Server-side RNG

The server bit of the server RNG looks rather simple. The server just needs to maintain a RNG and send random numbers to clients when asked to.

Client details

Redo the interface in gui2

There's little point in trying to expand the old widgets lobby when there's a new toolkit around. Some new widgets will have to be created first, notably the minimap and a tab control. Tabs could be simulated by buttons though.

Concept sketch

I can code better than I can sketch, but anyway: [3]

More games shown at a time

The current UI shows only 4 or 5 games and wastes a lot of screen space. My idea would be to collapse all games except for the selected one into much smaller bars with a smaller minimap and less information, possibly by using icons and/or skipping some redundant text. The selected game would have a similar look to what's there now, with the notable addtion of the join and observe buttons which I think would work better near the game as opposed to somewhere on top. This would also help save some vertical space which is usually at a premium.

Powerful game filters

There should be a method of filtering to search for games with a particular era, games that allow obervers or not, game names, creator names etc. I think this should be accomplished by a combination of filtering and sorting the game list. To avoid confusion, I think the game list should display "Games: showing NNN of MMM" to indicate that a filter is active.

More chat space

A button to expand the chat window so more text fits, at the expense of the game list. The userlist could also be hidden, but I'm not sure what could reasonably be done with that space as there's usually enough space horizontally.

Private chat tab

We already allow private messaging via the /whisper command, but it's not very convenient. I think a query-like separate window for private chats could be useful, similar to what irc clients do. I also think that such windows should display a reminder on how to use the ignore list and how to restrict private messages to friends only to make it easy for people to avoid abusers.

Player list improvements

The colors and fonts used to signify players in the current gamel, nick registered status etc are not immediatelly obvious to me. I'd add small textual info to separate the groups, and avatar-like status icons to indicate different types of users (unregistered, registered, moderator etc.). If we consider adding a ranking system, the "rank" could also be indicated by a different icon. I'd rather not allow custom icons. Since there will be no ranking in the project, this bit is moot.

Server-side RNG

Implementing that in the client might require some engine changes but mostly will need lots of engine *understanding*. This is quite orthogonal to the rest of the project and also it's not yet certain how much of an impact the added delay would have. Therefore I think it'd be good to implement a prototype of this early (e.g. with combat only, disregarding WML random numbers) just to see how it works in practice. Then it should be decided whether or not to proceed and whether or not this feature should be optional so players can disable it if they can't stand the lag.

Milestones

The idea page indicates that the first milestone should be a summary of studies and proposed interface changes, but disucssion revealed that a concrete list of features and milestones would be preferable now, and this is the approach I'm taking.

Decisions

As for the design decisions, my take is:

  • Ranking is out, as a conscious design choice that I understand and kind of agree with.
  • I think that in general rooms are the way to go, but if another idea solidifies before the project begins, I can imagine adjusting the design and milestones accordingly if it is generally agreed to be better. Right now I think a flexible room system is the best option.
  • In particular, I think the room system should be flexible enough to allow limiting users to a predefined set of rooms, for example consisting of the main lobby and language-based channels only. (note that *allow limiting* is not the same as just *limit*)
  • regarding wesnoth-less moderation, after some thought I think that upgrading the lobby bot to accept mod commands is the most reasonable choice. It should be fairly simple to implement, unlike the irc server module idea, and just as useful unless we'd want to moderate dozens of channels which probably wouldn't work anyway.

Feature short list

  1. A gui2 lobby
    1. New gamelist
    2. New userlist
    3. "More chat" and "more games" modes
    4. Private messages tabs
  2. Game filters
  3. Configurable room system
  4. Server-side RNG
  5. Some method of wesnoth-less moderation

Things to do before the program starts

  • preliminary wesnothd refactoring (e.g. split lobby and game classes)
  • writing missing gui2 widgets (minimap, tabs)
  • investigate bug Mordante about gui2 tooltips
  • understand the current client-server protocol

Timeline

  • May 26 (official program start) - have most of the initial stuff above done
  • June 28 have the server-side rooms in a working state, a protocol update with (possibly interface-less) support in the client, plus a (non-functional) prototype of the new lobby gui
  • July 5 have a prototype of the server-side RNG done, test how it works
  • July 12 (midterm evaluations deadline - 1 day) - have a working "new lobby" with basic room support, simple filters, user list. Possibly without mode switching (1.3). Decide on what to do with the server-side RNG.
  • July 26 - have the planned features roughly done. Start polishing and work on the wesnoth-less moderation. Have a decision on whether it's a lobby bot upgrade or something more.
  • August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype
  • August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.

Goals

ID NAME PRIORITY RESULT PROGRESS
0 Missing gui2 widgets

MANDATORY

Write the minimap widget (unless someone beats me to it) and probably test it somewhere in the editor. Also loook into a tabbed control (not really mandatory since I'll be able to make do with buttons) none
1 Initial wesnothd refactor

MANDATORY

Make the lobby a separate class and not a hack in the game class. Extract common functionality into a base class or a utility class. Document code along the way. none
2 Gui2 tooltips

OPTIONAL

Look into being able to show gui2 widgets as tooltips (i.e. not just text). Optional, since it'd be nice to have but nothing will rely heavily on it. none
3 Understand the MP protocol

MANDATORY

Figure out how the chat and games work now. Optionally this could result in writing some documentation. none
- 0th milestone

MILESTONE

Would be nice, but not required, to have the above done when the program starts (May 26) none
4 Update to the MP protocol

MANDATORY

Document how the room system will be reflected in client-server messages. none
5 Server-side rooms

MANDATORY

Implement the server part of the room system. Have a room class or equivalent, and the proper server behavior to react to "/joins", "/parts" and messages in general. none
6 Client-side rooms

MANDATORY

Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation. none
7 Simple gui2 lobby

MANDATORY

Write a simple lobby in gui2. Doesn't have to include any of the "new" ideas for the lobby look, can be just a crude imitation of the current lobby with "a" game list, "a" playerlist and "a" chat window. none
- 1st milestone

MILESTONE

Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet. none
8 Proper rooms in gui2 lobby

MANDATORY

Write a proper tab-based (or fake tabs with buttons) interface for having many rooms open in the lobby, and interface for joining and quitting rooms. none
9 Proper game list in gui2 lobby

MANDATORY

Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here. none
10 Game list filters

MANDATORY

Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list none
- 2nd milestone (midterm)

MILESTONE

Have the above done by July 12. none
11 Advanced game list filters

OPTIONAL

Write more game list filters like filtering by era, filtering by eras the player has, text-matching for stuff beyond the game name etc. plus a fancy interface for it. none
12 Tab interface for whispers

OPTIONAL

Write the tab interface for private messages none
13 Proper userlist in gui2 lobby

MANDATORY

Write a rough equivalent of the current player list with some upgrades (group labels instead of just colors to distinguish player groups, ability to hide some of the groups) none
14 Advanced userlist

OPTIONAL

Implement all the outlined upgrades to the player list, with icons, nice interface for hiding groups, sorting options, possibly being able to hide the player list entirely. none
15 Lobby mode switching

OPTIONAL

Implement the swicthing between "more games, less chat" and "less games, more chat" idea. none
16 Server RNG prototype

MANDATORY

Write a simple RNG service in wesnothd. Write a simple server-rng-using RNG in the client. Wire it up to do combats and test. If not feasible, write a descriription of the problems encountered. none
- 3rd milestone

MILESTONE

Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished. none
17 Simple wesnoth-less moderation

MANDATORY

Write "a" way of moderating wesnotd without launching the game. Could involve having to type a special password with each privmsg command to the lobby bot, but should work. none
18 Advanced wesnoth-less moderation

OPTIONAL

Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily. none
19 Full server RNG

OPTIONAL

If the prototype is successful, wire all random numbers to use it, make it robust. none
20 General polishing

MANDATORY

Touch up various areas of the code, especially make sure the gui behaves nicely. none
- 4th milestone (final)

MILESTONE

Have the project in a working and polished state by August 15. none

Practical considerations

I have good knowledge of C++ (and STL), I'm moderately familiar with the Wesnoth codebase and I started to look into wesnothd sources. I learned C++ pretty much on my own, first by coding small problems for some local programming/algorithm contests. I even got to the country finals once, though I'm not a huge fan of 5-hour "reimplement the appropriate algorithm in each of the problems" events. At least this made me pay attention to computational etc. complexity issues. Later I got some more useful knowledge from various books and experimenting. I'm comfortable with Subversion and intent on finally trying git-svn. I develop mainly on windows on MSVC but can switch to linux if it turns out toying with wesnothd is problematic on windows.

I use MSVC mainly because it's a powerful and helpful tool, though not without defects. I also use a lightweight smart text editor (notepad++) for general editing. Cygwin, putty, wireshark are some useful tools I use quite often. I am awake between around 0900 UTC and 0100 UTC, and online for an hour or two in the mornings and for most of the evening/night. I can sometimes be reached during the day on IRC if the campus wifi works good enough and I have my laptop with me. No objections towards talking on thephone, voip on whatnot, in English or Polish.

As I'm a student in Europe, I will have a lot of exams at the end of May and in the first half of June, and will not be able to do much work during that time. I will be generally available, just busy. I plan to offset this by doing some work during the "community bonding" period and, well, working hard in general :). This is also why I give myself quite a lot of time between the program start and the first item on the timeline.