MP Server Ilor

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

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.

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 srating 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. Details to follow.

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. Assumung 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 e 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.

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).

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.

Concept sketch

Todo; will be here soon.

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.

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.

Switchable mode for more chat space

A button to expand the chat window so more text fits, at the expense of the game list.

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.

Milestones

The idea page indicates that the first milestone should be a summary of studies and proposed interface changes. I generally agree, but I think there is a lot of initial work that can be done in the meantime, for example:

• preliminary wesnothd refactoring
• writing missing gui2 widgets
• (optionally) gui2 tooltips
• game filtering (I think there aren't many doubts about that feature)

Also, I think by the time the midterm evaluations happen, we should have a clear vision of the design we want already to allow more time for the actual implementation. Therefore, I suggest the following timeline:

• May 26 (official program start) - have informally discussed issues with devs, mp mods, players
• June 26 - have the possible approaches summarised and start the decision process
• July 12 (midterm evaluations deadline - 1 day) - have a clear view of the desired approach. Also, have at least half of the "initial-work" code done.
• August 1 - have a crude working new lobby
• August 15 (before final evaluations) - have a polished new lobby

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 :). The fact that the first milestone is more about idea-gathering and less about raw code output should be helpful.