https://wiki.wesnoth.org/api.php?action=feedcontributions&user=Ilor&feedformat=atomThe Battle for Wesnoth Wiki - User contributions [en]2024-03-28T22:03:46ZUser contributionsMediaWiki 1.31.16https://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=32019MP Server Ilor2009-08-25T16:38:40Z<p>Ilor: /* Overview */</p>
<hr />
<div>==Overview==<br />
The "Multiplayer Improvements" Wesnoth project for Google Summer of Code has been completed. The main objectives of the project were:<br />
* to create a new lobby interface using the new widget toolkit being developed by Mordante. This new interface is functional, but still marked as experimental due to some unresolved issues. Improvements in the new lobby include:<br />
** More compact game list<br />
** More chat space with new whisper/room interface<br />
** More general flexibility -- many aspects can be changed in WML without having to rebuild<br />
* to add a room system to the Wesnoth server, similar to IRC channels. It is working, however only the experimental lobby has a convenient interface for it. See [[MultiplayerRooms]].<br />
* to offload some random number generation to the server to prevent cheating. Combats now rely on a random number provided by the server which is generated after the decision to attack has been made.<br />
* to simplify server moderation by allowing server mnods to isue commands without having the game launched. While less interesting for players, this too has been done (with a big "thanks" to Soliton) and is working fine.<br />
<br />
The results of the project can be seen in Wesnoth 1.7.3, to see the new lobby the --new-widgets command line switch must be used. Once the new lobby is declared stable, it will replace the old one and the switch will not be needed.<br />
__TOC__<br />
<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
note: .5 goal were added after the project was accepted.<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| skipped<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done (very crude)<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed by a week, done.<br />
|-<br />
| 7.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| done<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| done (two modes idea delayed for now)<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| done<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| done<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
<br />
note: Will need a "widget wrapping horizontal container" to be "fancy" and allow more filters in a neat way that works on many resolutions withouit wasting space<br />
| delayed, 40%. <br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| done<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| done<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| done<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| 0%, delayed<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| 0%, delayed<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| done<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| done<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| 20% groundwork laid, delayed<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| done as far as feasible, ready for more testing<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August <strike>15</strike> 10.<br />
| done<br />
|}<br />
<br />
==Remaining issues==<br />
[M] - Mordante, [I] - Ilor, [O] - other people<br />
===Blockers===<br />
* [M] The mouse focus dynamic cast fail (tm) discovered by Soliton. Confirmed and being worked on by Mordante [Fixed in 1.7.3]<br />
* [I/M] The log in to trunk, try logging into 1.7 server assert discovered by me, I need to get more info as it seems difficult to reproduce. [Fixed in 1.7.3]<br />
* [M] Resizing is not reliable, resizing down can result in an exception and a drop to titlescreen if there's not enough space; resizing up can create garbage in the output (at least on winxp). Mordante notified and working on fix.<br />
<br />
===Important===<br />
* [M/I] Vertical layout jumpiness (stuff changes size as more games appear and more chat lines are in the log). Alleviated somewhat, but not perfect.<br />
* [M] Tooltips don't work for icons inside a toggle panel<br />
* [I] Room system needs docs and testing [see [[MultiplayerRooms]] for the docs]<br />
===Other===<br />
* [M] A wrapping widget container would allow some nice layout effects<br />
* [I/O] Some icons desperately need changing [done in 1.7.3]<br />
* [M] Buttons working inside a toggle panel would be nice<br />
* [M] Scrollbars can appear for no particular reason<br />
* [M/I] Not everything is tweakable in WML - color/formatting for friends, game status, some icons etc<br />
<br />
===Summary===<br />
The project was completed on time, with the mandatory goals reached and most of the optional ones done as well. Notably skipped was the more chat or more games idea, mainly due to gui2 issues with getting the layout to work exactly as needed. Highlighting the current gamelist element with a more verbose item layout was not done because the "compact" layout seems to work fine. The UI part of the project in general was a major test of the GUI2 framework, and while there were and are some issues, the advantages of gui2 are very clear in many areas.<br />
<br />
Regarding non-UI parts of the project:<br />
* the room system on the server works, but might need additional tests and tweaks as it gets used<br />
* basic server side RNG works, switching all MP random number generation to the server-based method is an objective for 1.8, as is some documentationa s to how the system actually works, which is sadly missing at the time. Expect it at [[Server RNG]].<br />
* wesnothd-less moderation (lobby bot improvements) turned out to require only adapting existing code to expose more features and use more of what irc offers<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=32018MP Server Ilor2009-08-25T16:36:04Z<p>Ilor: added overview</p>
<hr />
<div>==Overview==<br />
The "Multiplayer Improvements" Wesnoth project for Google Summer of Code has been completed. The main objectives of the project were:<br />
* to create a new lobby interface using the new widget toolkit being developed by Mordante. This new interface is functional, but still marked as experimental due to some unresolved issues. Improvements in the new lobby include:<br />
** More compact game list<br />
** More chat space with new whisper/room interface<br />
** More general flexibility -- many aspects can be changed in WML without having to rebuild<br />
* to add a room system to the Wesnoth server, similar to IRC channels. It is working, however only the experimental lobby has a convenient interface for it.<br />
* to offload some random number generation to the server to prevent cheating. Combats now rely on a random number provided by the server which is generated after the decision to attack has been made.<br />
* to simplify server moderation by allowing server mnods to isue commands without having the game launched. While less interesting for players, this too has been done (with a big "thanks" to Soliton) and is working fine.<br />
<br />
The results of the project can be seen in Wesnoth 1.7.3, to see the new lobby the --new-widgets command line switch must be used. Once the new lobby is declared stable, it will replace the old one and the switch will not be needed.<br />
__TOC__<br />
<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
note: .5 goal were added after the project was accepted.<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| skipped<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done (very crude)<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed by a week, done.<br />
|-<br />
| 7.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| done<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| done (two modes idea delayed for now)<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| done<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| done<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
<br />
note: Will need a "widget wrapping horizontal container" to be "fancy" and allow more filters in a neat way that works on many resolutions withouit wasting space<br />
| delayed, 40%. <br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| done<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| done<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| done<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| 0%, delayed<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| 0%, delayed<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| done<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| done<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| 20% groundwork laid, delayed<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| done as far as feasible, ready for more testing<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August <strike>15</strike> 10.<br />
| done<br />
|}<br />
<br />
==Remaining issues==<br />
[M] - Mordante, [I] - Ilor, [O] - other people<br />
===Blockers===<br />
* [M] The mouse focus dynamic cast fail (tm) discovered by Soliton. Confirmed and being worked on by Mordante [Fixed in 1.7.3]<br />
* [I/M] The log in to trunk, try logging into 1.7 server assert discovered by me, I need to get more info as it seems difficult to reproduce. [Fixed in 1.7.3]<br />
* [M] Resizing is not reliable, resizing down can result in an exception and a drop to titlescreen if there's not enough space; resizing up can create garbage in the output (at least on winxp). Mordante notified and working on fix.<br />
<br />
===Important===<br />
* [M/I] Vertical layout jumpiness (stuff changes size as more games appear and more chat lines are in the log). Alleviated somewhat, but not perfect.<br />
* [M] Tooltips don't work for icons inside a toggle panel<br />
* [I] Room system needs docs and testing [see [[MultiplayerRooms]] for the docs]<br />
===Other===<br />
* [M] A wrapping widget container would allow some nice layout effects<br />
* [I/O] Some icons desperately need changing [done in 1.7.3]<br />
* [M] Buttons working inside a toggle panel would be nice<br />
* [M] Scrollbars can appear for no particular reason<br />
* [M/I] Not everything is tweakable in WML - color/formatting for friends, game status, some icons etc<br />
<br />
===Summary===<br />
The project was completed on time, with the mandatory goals reached and most of the optional ones done as well. Notably skipped was the more chat or more games idea, mainly due to gui2 issues with getting the layout to work exactly as needed. Highlighting the current gamelist element with a more verbose item layout was not done because the "compact" layout seems to work fine. The UI part of the project in general was a major test of the GUI2 framework, and while there were and are some issues, the advantages of gui2 are very clear in many areas.<br />
<br />
Regarding non-UI parts of the project:<br />
* the room system on the server works, but might need additional tests and tweaks as it gets used<br />
* basic server side RNG works, switching all MP random number generation to the server-based method is an objective for 1.8, as is some documentationa s to how the system actually works, which is sadly missing at the time. Expect it at [[Server RNG]].<br />
* wesnothd-less moderation (lobby bot improvements) turned out to require only adapting existing code to expose more features and use more of what irc offers<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=31956MP Server Ilor2009-08-18T16:36:59Z<p>Ilor: /* Summary */ fix wiki markup fail</p>
<hr />
<div>Note: This project was accepted into GSoC 2009.<br />
<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
note: .5 goal were added after the project was accepted.<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| skipped<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done (very crude)<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed by a week, done.<br />
|-<br />
| 7.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| done<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| done (two modes idea delayed for now)<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| done<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| done<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
<br />
note: Will need a "widget wrapping horizontal container" to be "fancy" and allow more filters in a neat way that works on many resolutions withouit wasting space<br />
| delayed, 40%. <br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| done<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| done<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| done<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| 0%, delayed<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| 0%, delayed<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| done<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| done<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| 20% groundwork laid, delayed<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| done as far as feasible, ready for more testing<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August <strike>15</strike> 10.<br />
| done<br />
|}<br />
<br />
==Remaining issues==<br />
[M] - Mordante, [I] - Ilor, [O] - other people<br />
===Blockers===<br />
* [M] The mouse focus dynamic cast fail (tm) discovered by Soliton. Confirmed and being worked on by Mordante [Fixed in 1.7.3]<br />
* [I/M] The log in to trunk, try logging into 1.7 server assert discovered by me, I need to get more info as it seems difficult to reproduce. [Fixed in 1.7.3]<br />
* [M] Resizing is not reliable, resizing down can result in an exception and a drop to titlescreen if there's not enough space; resizing up can create garbage in the output (at least on winxp). Mordante notified and working on fix.<br />
<br />
===Important===<br />
* [M/I] Vertical layout jumpiness (stuff changes size as more games appear and more chat lines are in the log). Alleviated somewhat, but not perfect.<br />
* [M] Tooltips don't work for icons inside a toggle panel<br />
* [I] Room system needs docs and testing [see [[MultiplayerRooms]] for the docs]<br />
===Other===<br />
* [M] A wrapping widget container would allow some nice layout effects<br />
* [I/O] Some icons desperately need changing [done in 1.7.3]<br />
* [M] Buttons working inside a toggle panel would be nice<br />
* [M] Scrollbars can appear for no particular reason<br />
* [M/I] Not everything is tweakable in WML - color/formatting for friends, game status, some icons etc<br />
<br />
===Summary===<br />
The project was completed on time, with the mandatory goals reached and most of the optional ones done as well. Notably skipped was the more chat or more games idea, mainly due to gui2 issues with getting the layout to work exactly as needed. Highlighting the current gamelist element with a more verbose item layout was not done because the "compact" layout seems to work fine. The UI part of the project in general was a major test of the GUI2 framework, and while there were and are some issues, the advantages of gui2 are very clear in many areas.<br />
<br />
Regarding non-UI parts of the project:<br />
* the room system on the server works, but might need additional tests and tweaks as it gets used<br />
* basic server side RNG works, switching all MP random number generation to the server-based method is an objective for 1.8, as is some documentationa s to how the system actually works, which is sadly missing at the time. Expect it at [[Server RNG]].<br />
* wesnothd-less moderation (lobby bot improvements) turned out to require only adapting existing code to expose more features and use more of what irc offers<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=31955MP Server Ilor2009-08-18T16:36:28Z<p>Ilor: end-of-project update</p>
<hr />
<div>Note: This project was accepted into GSoC 2009.<br />
<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
note: .5 goal were added after the project was accepted.<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| skipped<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done (very crude)<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed by a week, done.<br />
|-<br />
| 7.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| done<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| done (two modes idea delayed for now)<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| done<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| done<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
<br />
note: Will need a "widget wrapping horizontal container" to be "fancy" and allow more filters in a neat way that works on many resolutions withouit wasting space<br />
| delayed, 40%. <br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| done<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| done<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| done<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| 0%, delayed<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| 0%, delayed<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| done<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| done<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| 20% groundwork laid, delayed<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| done as far as feasible, ready for more testing<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August <strike>15</strike> 10.<br />
| done<br />
|}<br />
<br />
==Remaining issues==<br />
[M] - Mordante, [I] - Ilor, [O] - other people<br />
===Blockers===<br />
* [M] The mouse focus dynamic cast fail (tm) discovered by Soliton. Confirmed and being worked on by Mordante [Fixed in 1.7.3]<br />
* [I/M] The log in to trunk, try logging into 1.7 server assert discovered by me, I need to get more info as it seems difficult to reproduce. [Fixed in 1.7.3]<br />
* [M] Resizing is not reliable, resizing down can result in an exception and a drop to titlescreen if there's not enough space; resizing up can create garbage in the output (at least on winxp). Mordante notified and working on fix.<br />
<br />
===Important===<br />
* [M/I] Vertical layout jumpiness (stuff changes size as more games appear and more chat lines are in the log). Alleviated somewhat, but not perfect.<br />
* [M] Tooltips don't work for icons inside a toggle panel<br />
* [I] Room system needs docs and testing [see [[MultiplayerRooms]] for the docs]<br />
===Other===<br />
* [M] A wrapping widget container would allow some nice layout effects<br />
* [I/O] Some icons desperately need changing [done in 1.7.3]<br />
* [M] Buttons working inside a toggle panel would be nice<br />
* [M] Scrollbars can appear for no particular reason<br />
* [M/I] Not everything is tweakable in WML - color/formatting for friends, game status, some icons etc<br />
<br />
===Summary===<br />
The project was completed on time, with the mandatory goals reached and most of the optional ones done as well. Notably skipped was the more chat or more games idea, mainly due to gui2 issues with getting the layout to work exactly as needed. Highlighting the current gamelist element with a more verbose item layout was not done because the "compact" layout seems to work fine. The UI part of the project in general was a major test of the GUI2 framework, and while there were and are some issues, the advantages of gui2 are very clear in many areas.<br />
<br />
Regarding non-UI parts of the project:<br />
* the room system on the server works, but might need additional tests and tweaks as it gets used<br />
* basic server side RNG works, switching all MP random number generation to the server-based method is an objective for 1.8, as is some documentationa s to how the system actually works, which is sadly missing at the time. Expect it at [[Server RNG]].<br />
* wesnothd-less moderation (lobby bot improvements) turned out to require only adapting existing code to expose more features and use more of what irc offers<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=ReferenceWML&diff=31764ReferenceWML2009-08-07T20:59:44Z<p>Ilor: /* The Wesnoth Markup Language */ add introducion about what WML is</p>
<hr />
<div>{{WML Tags}}<br />
== The Wesnoth Markup Language ==<br />
<br />
The Wesnoth Markup Language (WML) is used to code almost everything in Wesnoth, including scenarios, units, savefiles, and the user interface layout. WML files are simple, human-readable text files, usually with the .cfg extension, with similarities to INI files and XML. A major feature in WML are macros, which are alike those found in the C language and similarily are handled by a preprocessor. Implementation-wise, WML files are handled mainly by the ''config'' class (and ''simple_wml'' in [[wesnothd]]).<br />
<br />
This page is a collection of pointers to different common WML structures. See [[AlphabeticalWML]] for a quick listing of all WML tags. The more comprehensive [[BuildingScenariosIndex]] lists tags and keys.<br />
<br />
See [[BuildingScenarios]], [[BuildingCampaigns]] and [[BuildingUnits]]<br />
for a tutorial style overview.<br />
<br />
<br />
<br />
''Note: this reference may contain slight inaccuracies, might not list all existing keys and tags or might contain some deprecated syntax. If you find that this reference doesn't give you the answer to how to implement some feature in WML, the most reliable way is to look at the WML code of existing units and campaigns that have done so.''<br />
<br />
== How WML works ==<br />
<br />
* [[SyntaxWML]] the language syntax.<br />
* [[PreprocessorRef]] the WML preprocessor syntax<br />
** [[UtilWML]] utility macros defined in utils.cfg<br />
** [[VariablesWML]] how to use WML variables<br />
<br />
== WML toplevel tags ==<br />
<br />
* [[GameConfigWML]] the top level '''[game_config]''' tag<br />
* [[UnitsWML]] the top level '''[units]''' tag<br />
** [[UnitTypeWML]] how to describe a unit type<br />
** [[AnimationWML]] how to animate units<br />
* [[CampaignWML]] the top level '''[campaign]''' tag<br />
* [[ScenarioWML]] the top level tags '''[scenario]''', '''[multiplayer]''', '''[test]''', and '''[tutorial]'''<br />
** [[EventWML]] how to describe an event<br />
** [[SideWML]] how to describe a side<br />
** [[MapGeneratorWML]] the random map generator<br />
** [[TimeWML]] how to describe a day<br />
** [[IntroWML]] how to describe the intro screen<br />
* [[SavefileWML]] a description of the format of savegames<br />
** [[ReplayWML]] a description of the format of player actions such as moving a unit<br />
** [[StatisticalScenarioWML]] used to generate statistics of a savegame<br />
* [[PblWML]] a description of the format of server-uploadable campaigns<br />
* [[EraWML]] the top level '''[era]''' tag<br />
* [[TerrainWML]] the top level '''[terrain]''' tag<br />
* [[TerrainGraphicsWML]], the top level '''[terrain_graphics]''' tag<br />
* [[ThemeWML]] the top level '''[theme]''' tag<br />
* [[LanguageWML]] the top level '''[language]''' tag<br />
* [[HelpWML]] the top level '''[help]''' tag<br />
* [[BinaryPathWML]] the top level '''[binary_path]''' tag<br />
* [[FontsWML]] the top level '''[fonts]''' tag<br />
<br />
== Other WML tags ==<br />
<br />
* [[EventWML]] how to describe an event<br />
** [[FilterWML]] the construct to filter on units, locations, and weapons<br />
** [[ConditionalActionsWML]] actions that encapsulate conditional filters and the actions to execute if the conditions are met<br />
** [[DirectActionsWML]] actions that directly affect gameplay: for example creating a unit<br />
** [[InternalActionsWML]] actions that WML uses internally: for example storing a variable<br />
** [[InterfaceActionsWML]] actions that do not affect gameplay: for example displaying a message<br />
** [[LuaWML]] how to code actions with the Lua language<br />
* [[SingleUnitWML]] how to describe a unit<br />
* [[AiWML]] how to describe parameters for AI<br />
* [[EffectWML]] the construct to modify a unit<br />
* [[AbilitiesWML]] a list of the different abilities a unit or weapon can have<br />
* [[DescriptionWML]] the structure of WML coded menus like the difficulty chooser of campaigns<br />
* [[EditorWML]] tags controllin the post-1.4 editor's behavior<br />
<br />
== Predefined macros == <br />
<br />
Wesnoth ships with a library of predefined macros you should find useful in writing your own WML. You can find a description of all such macros [http://www.wesnoth.org/macro-reference.xhtml here].<br />
<br />
== Other ==<br />
<br />
* [[ReferenceWMLSyntax]] how this wiki and the pages it links to should be formatted<br />
* [[ConventionsWML]] how to make your WML more readable<br />
* [[UsefulWMLFragments]] Various pieces of WML for various purposes. If you have some WML you're proud of that you think others can use, add it here.<br />
* [[CommandMode]] commands are not strictly speaking part of WML, these could be a little hard to find so there's a link here.<br />
* [[MultiplayerServerWML]] is used when communicating with the multiplayer server.<br />
* [[CampaignServerWML]] is used when managing contributed campaigns on the campaign server.<br />
* [[ImagePathFunctionWML]] is used when applying the team-color function to images.<br />
* [[BinaryWML]] how WML is sent over the network<br />
<br />
== See Also ==<br />
<br />
* [[BuildingMaps]] the text-based format for Wesnoth maps<br />
* [[TerrainCodesWML]] a list of all terrains<br />
* [[MultiHexTutorial]] a description of the multi-hex tiling system<br />
* [[IGNFileFormat]] a description of the ignore file format<br />
<br />
<br />
[[Category: WML Reference]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=ReferenceWML&diff=31751ReferenceWML2009-08-07T20:35:46Z<p>Ilor: /* How WML works */ reorder links to put the syntax first</p>
<hr />
<div>{{WML Tags}}<br />
== The Wesnoth Markup Language ==<br />
<br />
The Wesnoth Markup Language (WML) is used to code almost everything in Wesnoth, including scenarios, units, savefiles, and the user interface layout.<br />
<br />
This page is a collection of pointers to different common WML structures. See [[AlphabeticalWML]] for a quick listing of all WML tags. The more comprehensive [[BuildingScenariosIndex]] lists tags and keys.<br />
<br />
See [[BuildingScenarios]], [[BuildingCampaigns]] and [[BuildingUnits]]<br />
for a tutorial style overview.<br />
<br />
<br />
<br />
''Note: this reference may contain slight inaccuracies, might not list all existing keys and tags or might contain some deprecated syntax. If you find that this reference doesn't give you the answer to how to implement some feature in WML, the most reliable way is to look at the WML code of existing units and campaigns that have done so.''<br />
<br />
== How WML works ==<br />
<br />
* [[SyntaxWML]] the language syntax.<br />
* [[PreprocessorRef]] the WML preprocessor syntax<br />
** [[UtilWML]] utility macros defined in utils.cfg<br />
** [[VariablesWML]] how to use WML variables<br />
<br />
== WML toplevel tags ==<br />
<br />
* [[GameConfigWML]] the top level '''[game_config]''' tag<br />
* [[UnitsWML]] the top level '''[units]''' tag<br />
** [[UnitTypeWML]] how to describe a unit type<br />
** [[AnimationWML]] how to animate units<br />
* [[CampaignWML]] the top level '''[campaign]''' tag<br />
* [[ScenarioWML]] the top level tags '''[scenario]''', '''[multiplayer]''', '''[test]''', and '''[tutorial]'''<br />
** [[EventWML]] how to describe an event<br />
** [[SideWML]] how to describe a side<br />
** [[MapGeneratorWML]] the random map generator<br />
** [[TimeWML]] how to describe a day<br />
** [[IntroWML]] how to describe the intro screen<br />
* [[SavefileWML]] a description of the format of savegames<br />
** [[ReplayWML]] a description of the format of player actions such as moving a unit<br />
** [[StatisticalScenarioWML]] used to generate statistics of a savegame<br />
* [[PblWML]] a description of the format of server-uploadable campaigns<br />
* [[EraWML]] the top level '''[era]''' tag<br />
* [[TerrainWML]] the top level '''[terrain]''' tag<br />
* [[TerrainGraphicsWML]], the top level '''[terrain_graphics]''' tag<br />
* [[ThemeWML]] the top level '''[theme]''' tag<br />
* [[LanguageWML]] the top level '''[language]''' tag<br />
* [[HelpWML]] the top level '''[help]''' tag<br />
* [[BinaryPathWML]] the top level '''[binary_path]''' tag<br />
* [[FontsWML]] the top level '''[fonts]''' tag<br />
<br />
== Other WML tags ==<br />
<br />
* [[EventWML]] how to describe an event<br />
** [[FilterWML]] the construct to filter on units, locations, and weapons<br />
** [[ConditionalActionsWML]] actions that encapsulate conditional filters and the actions to execute if the conditions are met<br />
** [[DirectActionsWML]] actions that directly affect gameplay: for example creating a unit<br />
** [[InternalActionsWML]] actions that WML uses internally: for example storing a variable<br />
** [[InterfaceActionsWML]] actions that do not affect gameplay: for example displaying a message<br />
** [[LuaWML]] how to code actions with the Lua language<br />
* [[SingleUnitWML]] how to describe a unit<br />
* [[AiWML]] how to describe parameters for AI<br />
* [[EffectWML]] the construct to modify a unit<br />
* [[AbilitiesWML]] a list of the different abilities a unit or weapon can have<br />
* [[DescriptionWML]] the structure of WML coded menus like the difficulty chooser of campaigns<br />
* [[EditorWML]] tags controllin the post-1.4 editor's behavior<br />
<br />
== Predefined macros == <br />
<br />
Wesnoth ships with a library of predefined macros you should find useful in writing your own WML. You can find a description of all such macros [http://www.wesnoth.org/macro-reference.xhtml here].<br />
<br />
== Other ==<br />
<br />
* [[ReferenceWMLSyntax]] how this wiki and the pages it links to should be formatted<br />
* [[ConventionsWML]] how to make your WML more readable<br />
* [[UsefulWMLFragments]] Various pieces of WML for various purposes. If you have some WML you're proud of that you think others can use, add it here.<br />
* [[CommandMode]] commands are not strictly speaking part of WML, these could be a little hard to find so there's a link here.<br />
* [[MultiplayerServerWML]] is used when communicating with the multiplayer server.<br />
* [[CampaignServerWML]] is used when managing contributed campaigns on the campaign server.<br />
* [[ImagePathFunctionWML]] is used when applying the team-color function to images.<br />
* [[BinaryWML]] how WML is sent over the network<br />
<br />
== See Also ==<br />
<br />
* [[BuildingMaps]] the text-based format for Wesnoth maps<br />
* [[TerrainCodesWML]] a list of all terrains<br />
* [[MultiHexTutorial]] a description of the multi-hex tiling system<br />
* [[IGNFileFormat]] a description of the ignore file format<br />
<br />
<br />
[[Category: WML Reference]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=31748MultiplayerServerWML2009-08-07T20:33:38Z<p>Ilor: </p>
<hr />
<div>= Multiplayer Server WML =<br />
This page describes the [[WML]] used to communicate with the multiplayer server for Wesnoth, [[wesnothd]].<br />
<br />
== The login procedure ==<br />
<br />
* server request (optional)<br />
** '''[version]'''<br />
<br />
* client response<br />
** '''[version]'''<br />
*** '''version''': The client's version string.<br />
<br />
* server request<br />
** '''[mustlogin]'''<br />
<br />
* client response<br />
** '''[login]'''<br />
*** '''username''': The username the client would like to have.<br />
*** '''password_reminder''': If "yes" the client requests the server to send a password reminder for the provided username.<br />
*** '''password''': The hashed password, created from the username, the password and salt received from the server.<br />
<br />
* server response<br />
** '''[join_lobby]''' or<br />
** '''[error]'''<br />
*** '''message''': The error message.<br />
*** '''password_request''': If not empty the server asks the client to provide a password for its desired username.<br />
*** '''phpbb_encryption''': If "yes" the client will encrypt the password using phpbb's algorithm.<br />
*** '''random_salt''': Random salt sent to the client for mixing with the password hash.<br />
*** '''hash_seed''': Salt generated from the original hash that is required to recreate it.<br />
*** '''salt''': Salt generated from the original hash that is required to recreate it.<br />
*** '''force_confirmation''': Display an ok/cancel dialog with the content of the 'message' key.<br />
<br />
* server response<br />
** '''[gamelist]'''<br />
*** '''[game]''' (repeated)<br />
**** '''id''': A unique id of the game.<br />
**** '''name''': The title of the game.<br />
**** '''mp_scenario''': The id of the scenario.<br />
**** '''mp_era''': The id of the used era.<br />
**** '''mp_use_map_settings''': Does the game use the map settings specified in the scenario.<br />
**** '''mp_fog''': Does the game use fog.<br />
**** '''mp_shroud''': Does the game use shroud.<br />
**** '''mp_village_gold''': The number of gold per village.<br />
**** '''experience_modifier''': The experience setting.<br />
**** '''mp_countdown''': Does the game use a timer.<br />
**** '''mp_countdown_reservoir_time''': Upper limit of the possibly available time.<br />
**** '''mp_countdown_init_time''': Initial time.<br />
**** '''mp_countdown_action_bonus''': Time bonus per action.<br />
**** '''mp_countdown_turn_bonus''': Time bonus per turn.<br />
**** '''map_data''': The map data. ''Notice: not sent to lobby if the game uses shroud''<br />
**** '''hash''': The hash value of the map_data.<br />
**** '''observer''': Are observers allowed or not.<br />
**** '''human_sides''': The number of sides played by humans.<br />
**** '''slots''': The number of vacant/max slots.<br />
**** '''turn''': The current turn/max turn.<br />
** '''[user]''' (repeated)<br />
*** '''name''': The username of the player.<br />
*** '''game_id''': The ID of the game the player is in (version 1.3.7+svn).<br />
*** '''location''': The name of the game the player is in.<br />
*** '''available''': "yes" if the player is in the lobby; "no" if in a game.<br />
Many of the keys under [game] are described more indepth on the [[ScenarioWML]] page.<br />
<br />
== Error messages ==<br />
<br />
* '''[error]'''<br />
** '''message''': The error message.<br />
<br />
== Chat (lobby and in-game) ==<br />
<br />
* '''[message]'''<br />
** '''sender''': (optional - filled by the server) The sender of the message.<br />
** '''message''': The message itself.<br />
** '''room''': The room the message is from/to {{DevFeature}}<br />
* '''[whisper]'''<br />
** '''receiver''': The receiver of the whisper<br />
** '''sender''': (optional - filled by the server) The sender of the whisper.<br />
** '''message''': The message itself.<br />
<br />
== Room commands ==<br />
Note: the room commands are in general {{DevFeature}} and are subject to change.<br />
* '''[room_join]'''<br />
** '''room''': The room name to join<br />
** '''player''': (filled by server in response message sent to all room members) the player that joins the room<br />
** '''[members]''': member list sent to the player that joined<br />
*** '''[member]''': (repeated) members<br />
**** '''name''': This member's name<br />
* '''[room_part]'''<br />
** '''room''': The room name to part (leave). Leaving the lobby is not allowed.<br />
** '''player''': (filled by server in response message sent to all room members) the player that leaves the room<br />
* '''[room_query]''': specific room-related queries.<br />
** '''[rooms]''': List rooms created on the server, or<br />
** '''[names]''': List members of a given room<br />
*** '''room''': The room name (if applicable)<br />
** '''[persist]''': Check or set room persistance<br />
*** '''value''': (optional) set room persistance to this value (yes/no)<br />
* '''[room_query_response]''': contains specific response to a room_query.<br />
** '''message''': optional text message response<br />
** '''room''': room name (if applicable)<br />
** '''[rooms]''': room list<br />
*** '''[room]''': (repeated) rooms<br />
**** '''name''': This room's name<br />
** '''[members]''': member list<br />
*** '''[member]''': (repeated) members<br />
**** '''name''': This member's name<br />
<br />
== Nick registration related commands (lobby and in-game) ==<br />
<br />
* '''[nickserv]'''<br />
** '''[register]'''<br />
*** '''password''': The password for the nick.<br />
*** '''mail''': The email address for the nick.<br />
** '''[drop]''': Drop this username.<br />
** '''[set]''': Set a detail (e.g. email address) for this nick.<br />
*** '''detail''': The detail, e.g. "mail".<br />
*** '''value''': The new value for this detail, e.g. "user@edomain"<br />
** '''[info]''': Request info about another username.<br />
*** '''name''': The username.<br />
<br />
== Updating the lobby state ==<br />
<br />
* '''[gamelist_diff]''': server message - basically a diff from two [gamelist]s; the keys listed are the ones that actually occure in practice<br />
** '''index''': The index of a user.<br />
** '''[insert_child]''' A new user logged on.<br />
*** '''[user]'''<br />
**** '''name''': The name of the user.<br />
**** '''available''' "yes"<br />
*** '''[delete_child]''' A user logged off.<br />
** '''[change_child]'''<br />
*** '''[user]'''<br />
**** '''[insert]''': A user joined/left a game.<br />
***** '''available''': "yes" when the user left a game. "no" when the user joined a game<br />
***** '''location''': The name of the game the user joined.<br />
**** '''[delete]'''<br />
***** '''location''': "x" when a game was left.<br />
*** '''[gamelist]'''<br />
**** '''index''': Index of the game in question.<br />
**** '''[insert_child]''': A game started.<br />
***** '''[game]''' All the usual keys of [game] possible, see above.<br />
**** '''[delete_child]''': A game ended.<br />
***** '''[game]'''<br />
**** '''[change_child]''': Something changed in a game.<br />
***** '''[game]'''<br />
****** '''[insert]'''<br />
******* '''slots''': The number of free slots in the form: free/max slots<br />
******* '''turn''': The turn number in the form: current turn/max turns<br />
****** '''[delete]'''<br />
******* '''map''': "x" comes with every ''turn'' or ''slots'' change for games with shroud<br />
******* '''mp_scenario''': "x" comes with ''turn'' and ''slots'' changes for games with no scenario id<br />
<br />
* '''[observer]''' or '''[observer_quit]''': server message - players joining([observer_quit] - quitting the lobby "game")/quitting([observer] - joining the lobby "game") a game<br />
** '''name''': Username of the player/observer.<br />
<br />
== Game setup (the phase from creation to start) ==<br />
To create a game the client sends:<br />
* '''[create_game]'''<br />
** '''name''': The title of the game.<br />
<br />
followed by a message with the scenario options as under [game] (see above) plus the scenario data ([time], [era], [side], etc. see [[ScenarioWML]])<br />
<br />
* '''[join]'''<br />
** '''id''': The id of the game.<br />
** '''observe''': Join the game as an observer.<br />
<br />
* '''[scenario_diff]''': [[ScenarioWML]] diff (side changes, etc.)<br />
<br />
* '''[start_game]''': sent by the host to start a game<br />
* '''[leave_game]''': sent by the client when it leaves a game; sent by the server to make a client leave a game<br />
<br />
== In-game communication ==<br />
<br />
* '''[store_next_scenario]''': sent by the host - the scenario data (see [[ScenarioWML]]) to advance to the next scenario<br />
* '''[notify_next_scenario]''': sent by the server to tell players that the data for the next scenario is available<br />
* '''[load_next_scenario]''': sent by the client to request the data for the next scenario<br />
* '''[next_scenario]''': data for the next scenario (see [[ScenarioWML]]), sent by the server on request<br />
<br />
* '''[info]''': sent by the host on game end - info about the game state<br />
** '''type''': "termination" <br />
** '''condition''': the termination reason<br />
<br />
* '''[change_controller]''': a player (un)droids one of his sides or assigns control to someone else (The host can assign control for any side.)<br />
** '''side''': the side to change controller<br />
** '''player''': the nick of the player to take control<br />
** '''controller''': the new controller: "human" or "human_ai"<br />
** '''own_side''': "yes"<br />
<br />
If a player leaves this is sent to the host for all sides he owned.<br />
* '''side_drop''': The number of a side that dropped because a player left.<br />
* '''controller''': The controller of that side. ("ai", "network")<br />
<br />
* '''[muteall]''': the host mutes/unmutes all observers - toggles<br />
* '''[mute]''': the host mutes an observer - toggles<br />
** '''username''': the username of the observer - if not specified the servers returns a list of muted usernames<br />
* '''[kick]''' or '''[ban]''': the host kicks/bans a player/observer<br />
** '''username''': the username of the player/observer<br />
<br />
* '''[turn]'''<br />
** '''[command]''': (repeated) can contain all the tags you can find in a replay: [recruit], [move], [end_turn], etc.<br />
*** '''[speak]'''<br />
**** '''message''': text of the message<br />
**** '''id''': the sender<br />
**** '''team_name''': the name of the team the message is for - empty if it's a public message<br />
<br />
== Administrative commands ==<br />
* '''[query]'''<br />
** '''type''': The type of query. See [[ServerAdministration]] for details.<br />
<br />
[[Category:WML Reference]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=ServerAdministration&diff=31746ServerAdministration2009-08-07T20:33:12Z<p>Ilor: /* Overview */</p>
<hr />
<div>== Overview ==<br />
<br />
The Wesnoth server, [[wesnothd]] provides a simple interface for administering the server from within the game itself.<br />
<br />
To issue an administrative command to the server, you must be connected to the server using Wesnoth, and in the lobby. Any text you type into the chat box that begins with '/query ' will be considered an administrative command instead of a normal chat message. It will not be relayed to other users, but instead treated as a command by the server.<br />
<br />
Most commands are not accessible to normal users. They are only accessible once you have authenticated yourself to the server as an administrator. The way to authenticate yourself as an administrator is to use the command,<br />
<br />
'''/query admin <password>'''<br />
<br />
where <password> is the administrative password to the server. The administrative password is specified as the passwd attribute in wesnothd.cfg. Naturally the password for a server should be kept a secret. One danger is that if you forget to type '/query ' at the start of a command you may accidentally type the password in a chat message, and let all users on the server know it. If you do this, then notify an administrator who has access to the box as soon as possible, so they can reset the password in wesnothd.cfg. We may provide features to prevent this kind of accident in future versions.<br />
<br />
A message from the server should tell you that you have successfully authenticated yourself as an administrator. The server will recognize you as an administrator until the next time you log out of the server. If the server has support for accounts it may also remember and authenticate you automatically as an administrator next time.<br />
<br />
== Available commands ==<br />
<br />
'''/query adminmsg <message>''': sends a message to all administrators and also gets logged in case none is on. You can use this to report abuse, rule violations, etc. (available to non-administrators, duh)<br />
<br />
'''/query games''': shows how many games have ended in various ways. (available to non-administrators)<br />
<br />
'''/query metrics''': shows a simple metrics report of how the server has been performing. (available to non-administrators)<br />
<br />
'''/query netstats''': shows some network stats. (available to non-administrators)<br />
<br />
'''/query stats''': shows the current number of users and games. (available to non-administrators)<br />
<br />
'''/query wml''': shows stats about WML documents and their current memory consumption. (available to non-administrators)<br />
<br />
'''/query status [<nickmask>]''': this command will show you a list of users (matching the nickmask) connected to the server, with IP addresses, and how long they have been connected. Note that IP addresses of users are not available to non-administrators, and should be treated as confidential. When used as a non-administrator it just returns the entry of the user.<br />
<br />
'''/query motd [<message>]''': this command sets the message of the day that appears as the first message users get when they log on to the server. You can prefix the message with color formatting as described in [[InterfaceActionsWML#.5Bmessage.5D]]. Without argument it returns the current motd. (available to non-administrators)<br />
<br />
'''/query msg <message>''': this command will relay the message 'message' to all users on the server, even if they are in a game. The message will appear to come from 'server', so you should write your name as part of the message if it is necessary to show who it comes from. You can prefix the message with color formatting as described in [[InterfaceActionsWML#.5Bmessage.5D]].<br />
<br />
'''/query lobbymsg <message>''': this command will relay the message 'message' to all users in the lobby of the server. The message will appear to come from 'server', so you should write your name as part of the message if it is necessary to show who it comes from. You can prefix the message with color formatting as described in [[InterfaceActionsWML#.5Bmessage.5D]].<br />
<br />
'''/green <message>''': this command executes the lobbymsg command with green font (alias for '/query lobbymsg @<message>').<br />
<br />
'''/red <message>''': this command executes the lobbymsg command with red font (alias for '/query lobbymsg #<message>').<br />
<br />
'''/yellow <message>''': this command executes the lobbymsg command with yellow font (alias for '/query lobbymsg <255,255,0><message>').<br />
<br />
'''/query clones''': shows a list of all users that have the same IP address as another one.<br />
<br />
'''/query kick <mask> [<reason>]''': this command will disconnect the user matching the given nick or ip mask from the server.<br />
<br />
'''/query ban <mask> <time> <reason>''': this command will make the server refuse connections from users matching the given IP mask or the IPs of users matching the nick mask. Existing bans (and their reason!) will be overwritten so you can change the reason for a ban by adding it again.<br />
<br />
'''/query gban <mask> <group> <time> <reason>''': this command will make a ban that belongs to a group. They function just like ordinary bans but only the group name is mentioned in the ban listing.<br />
<br />
'''/query bans''': shows a list of currently banned IP masks and the reasons for the bans.<br />
<br />
'''/query kban <mask> <time> <reason>''': this command is equivalent to 'kick <mask>' 'ban <mask> <time> <reason>' -- i.e. bans the users matching the IP mask or the IPs of users matching the nick mask and disconnects them all in one go. The most common way to ban someone from the server.<br />
<br />
'''/query unban <ipmask>''': this command removes the specified IP mask from the ban list.<br />
<br />
'''/query ungban <group>''': this command removes all bans in the group.<br />
<br />
'''/query searchlog <mask>''': this returns the IP a nick matching the mask has used or the nicks that used a matching IP. Unlike status this searches the IP log.<br />
<br />
'''/query deny_unregistered_login [yes|no]''': If set to yes the server will refuse to let unregistered users log in. Without an argument the current setting is displayed. There is an alias 'dul' for convenience.<br />
<br />
<br />
Masks are arguments that can contain wildcards ('*' and '?'). '*' matches any number of characters (including none), and '?' any one character. IP masks are masks that contain at least one '.'.<br />
<br />
The time parameter is used to set the time when a ban expires. A simple example is 2D12h which means after 2 days and 12 hours the ban gets removed. Modifiers are: s=seconds, m=minutes, h=hours, D=days, M=months and Y=years (case doesn't actually matter except for minutes (m) and months (M); also you can write the modifiers (partially) out as in 2days12hours). Permanent bans can be set with 'permanent' or '0' as the time argument. We can also set shortcuts like LONG, MEDIUM and SHORT for common ban lengths but none is set yet.<br />
<br />
== Future extensions ==<br />
<br />
The current administrative interface is fairly primitive. We plan to provide some further extensions in the future, such as,<br />
<br />
'''/query mute <nick>''': makes it so that any messages sent by the user with the given nick will not be received by any other user on the server unless they share an IP address with 'nick'. Any games created by 'nick' will likewise not be seen by other users. 'nick' may observe games but will not appear in the observer list, and players of the game will not see any messages they type.<br />
<br />
[[Category:Troubleshooting and Bugs]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=Wesnothd&diff=31745Wesnothd2009-08-07T20:32:53Z<p>Ilor: create stub page about wesnothd in general</p>
<hr />
<div>'''wesnothd''' is the muliplayer server for Wesnoth, shipped as a separate executable named ''wesnothd''. Points of interest regarding the server are:<br />
* [[MultiplayerServerWML]] for the network protocol<br />
* [[ServerAdministration]] for admin commands<br />
* [[MultiplayerRooms]] for info on the new (1.7.3) room system<br />
* [[WesnothdDesign]] for some info about the design of the server</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=31674MP Server Ilor2009-08-06T21:32:07Z<p>Ilor: </p>
<hr />
<div>Note: This project was accepted into GSoC 2009.<br />
<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| skipped<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done (very crude)<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed by a week, done.<br />
|-<br />
| 7.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| done<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| done (two modes idea delayed for now)<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| done<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| done<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
<br />
note: Will need a "widget wrapping horizontal container" to be "fancy" and allow more filters in a neat way that works on many resolutions withouit wasting space<br />
| delayed, 40%. <br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| done<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| done<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| done<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| 0%, delayed<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| 0%, delayed<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| done<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| done<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| 20% groundwork laid<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| 50%<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August <strike>15</strike> 10.<br />
| looking good<br />
|}<br />
<br />
==Remaining issues==<br />
[M] - Mordante, [I] - Ilor, [O] - other people<br />
===Blockers===<br />
* [M] The mouse focus dynamic cast fail (tm) discovered by Soliton. Confirmed and being worked on by Mordante<br />
* [I/M] The log in to trunk, try logging into 1.7 server assert discovered by me, I need to get more info as it seems difficult to reproduce.<br />
* [M] Resizing is not reliable, resizing down can result in an exception and a drop to titlescreen if there's not enough space; resizing up can create garbage in the output (at least on winxp). Mordante notified and working on fix.<br />
===Important===<br />
* [M/I] Vertical layout jumpiness (stuff changes size as more games appear and more chat lines are in the log)<br />
* [M] Tooltips don't work for icons inside a toggle panel<br />
* [I] Room system needs docs and testing<br />
===Other===<br />
* [M] A wrapping widget container would allow some nice layout effects<br />
* [I/O] Some icons desperately need changing<br />
* [M] Buttons working inside a toggle panel would be nice<br />
* [M] Scrollbars can appear for no particular reason<br />
* [M/I] Not everything is tweakable in WML - color/formatting for friends, game status, some icons etc<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=31672MP Server Ilor2009-08-06T17:54:04Z<p>Ilor: </p>
<hr />
<div>Note: Theis project was accepted into GSoC 2009.<br />
<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| skipped<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done (very crude)<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed by a week, done.<br />
|-<br />
| 7.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| done<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| done (two modes idea delayed for now)<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| done<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| done<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
<br />
note: Will need a "widget wrapping horizontal container" to be "fancy" and allow more filters in a neat way that works on many resolutions withouit wasting space<br />
| delayed, 40%. <br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| done<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| done<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| done<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| 0%, delayed<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| 0%, delayed<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| done<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| done<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| 20% groundwork laid<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| 50%<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August <strike>15</strike> 10.<br />
| looking good<br />
|}<br />
<br />
==Remaining issues==<br />
===Blockers===<br />
* The mouse focus dynamic cast fail (tm) discovered by Soliton. Confirmed and being worked on by Mordante<br />
* The log in to trunk, try logging into 1.7 server assert discovered by me, I need to get more info as it seems difficult to reproduce.<br />
* Resizing is not reliable, resizing down can result in an exception and a drop to titlescreen if there's not enough space; resizing up can create garbage in the output (at least on winxp). Mordante notified and working on fix.<br />
===Important===<br />
* Vertical layout jumpiness (stuff changes size as more games appear and more chat lines are in the log)<br />
* Tooltips don't work for icons inside a toggle panel<br />
* Room system needs docs and testing<br />
===Other===<br />
* A wrapping widget container would allow some nice layout effects<br />
* Some icons desperately need changing<br />
* Buttons working inside a toggle panel would be nice<br />
* Scrollbars can appear for no particular reason<br />
* Not everything is tweakable in WML - color/formatting for friends, game status, some icons etc<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=31482MP Server Ilor2009-07-31T18:02:13Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| skipped<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done (very crude)<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed by a week, done.<br />
|-<br />
| 7.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| done<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| done<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| done<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| done<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| delayed, 20%<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| done<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| done<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| done<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| 0%, delayed<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| 0%, delayed<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| done<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| 50% (needs testing, posibly more logging)<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| 20% groundwork laid<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| 5% (made a todo list)<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| looking good<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=31435MP Server Ilor2009-07-28T22:10:23Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| skipped<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done (very crude)<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed by a week, done.<br />
|-<br />
| 7.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| done<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| done<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| done<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| done<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| delayed, 20%<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| done<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| done<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| done<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| 0%, delayed<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| 0%, delayed<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| done<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| 20% groundwork laid<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=31404MultiplayerServerWML2009-07-26T20:09:05Z<p>Ilor: /* Room commands */</p>
<hr />
<div>= Multiplayer Server WML =<br />
This page describes the WML used to communicate with the multiplayer server (wesnothd).<br />
<br />
== The login procedure ==<br />
<br />
* server request (optional)<br />
** '''[version]'''<br />
<br />
* client response<br />
** '''[version]'''<br />
*** '''version''': The client's version string.<br />
<br />
* server request<br />
** '''[mustlogin]'''<br />
<br />
* client response<br />
** '''[login]'''<br />
*** '''username''': The username the client would like to have.<br />
*** '''password_reminder''': If "yes" the client requests the server to send a password reminder for the provided username.<br />
*** '''password''': The hashed password, created from the username, the password and salt received from the server.<br />
<br />
* server response<br />
** '''[join_lobby]''' or<br />
** '''[error]'''<br />
*** '''message''': The error message.<br />
*** '''password_request''': If not empty the server asks the client to provide a password for its desired username.<br />
*** '''phpbb_encryption''': If "yes" the client will encrypt the password using phpbb's algorithm.<br />
*** '''random_salt''': Random salt sent to the client for mixing with the password hash.<br />
*** '''hash_seed''': Salt generated from the original hash that is required to recreate it.<br />
*** '''salt''': Salt generated from the original hash that is required to recreate it.<br />
*** '''force_confirmation''': Display an ok/cancel dialog with the content of the 'message' key.<br />
<br />
* server response<br />
** '''[gamelist]'''<br />
*** '''[game]''' (repeated)<br />
**** '''id''': A unique id of the game.<br />
**** '''name''': The title of the game.<br />
**** '''mp_scenario''': The id of the scenario.<br />
**** '''mp_era''': The id of the used era.<br />
**** '''mp_use_map_settings''': Does the game use the map settings specified in the scenario.<br />
**** '''mp_fog''': Does the game use fog.<br />
**** '''mp_shroud''': Does the game use shroud.<br />
**** '''mp_village_gold''': The number of gold per village.<br />
**** '''experience_modifier''': The experience setting.<br />
**** '''mp_countdown''': Does the game use a timer.<br />
**** '''mp_countdown_reservoir_time''': Upper limit of the possibly available time.<br />
**** '''mp_countdown_init_time''': Initial time.<br />
**** '''mp_countdown_action_bonus''': Time bonus per action.<br />
**** '''mp_countdown_turn_bonus''': Time bonus per turn.<br />
**** '''map_data''': The map data. ''Notice: not sent to lobby if the game uses shroud''<br />
**** '''hash''': The hash value of the map_data.<br />
**** '''observer''': Are observers allowed or not.<br />
**** '''human_sides''': The number of sides played by humans.<br />
**** '''slots''': The number of vacant/max slots.<br />
**** '''turn''': The current turn/max turn.<br />
** '''[user]''' (repeated)<br />
*** '''name''': The username of the player.<br />
*** '''game_id''': The ID of the game the player is in (version 1.3.7+svn).<br />
*** '''location''': The name of the game the player is in.<br />
*** '''available''': "yes" if the player is in the lobby; "no" if in a game.<br />
Many of the keys under [game] are described more indepth on the [[ScenarioWML]] page.<br />
<br />
== Error messages ==<br />
<br />
* '''[error]'''<br />
** '''message''': The error message.<br />
<br />
== Chat (lobby and in-game) ==<br />
<br />
* '''[message]'''<br />
** '''sender''': (optional - filled by the server) The sender of the message.<br />
** '''message''': The message itself.<br />
** '''room''': The room the message is from/to {{DevFeature}}<br />
* '''[whisper]'''<br />
** '''receiver''': The receiver of the whisper<br />
** '''sender''': (optional - filled by the server) The sender of the whisper.<br />
** '''message''': The message itself.<br />
<br />
== Room commands ==<br />
Note: the room commands are in general {{DevFeature}} and are subject to change.<br />
* '''[room_join]'''<br />
** '''room''': The room name to join<br />
** '''player''': (filled by server in response message sent to all room members) the player that joins the room<br />
** '''[members]''': member list sent to the player that joined<br />
*** '''[member]''': (repeated) members<br />
**** '''name''': This member's name<br />
* '''[room_part]'''<br />
** '''room''': The room name to part (leave). Leaving the lobby is not allowed.<br />
** '''player''': (filled by server in response message sent to all room members) the player that leaves the room<br />
* '''[room_query]''': specific room-related queries.<br />
** '''[rooms]''': List rooms created on the server, or<br />
** '''[names]''': List members of a given room<br />
*** '''room''': The room name (if applicable)<br />
** '''[persist]''': Check or set room persistance<br />
*** '''value''': (optional) set room persistance to this value (yes/no)<br />
* '''[room_query_response]''': contains specific response to a room_query.<br />
** '''message''': optional text message response<br />
** '''room''': room name (if applicable)<br />
** '''[rooms]''': room list<br />
*** '''[room]''': (repeated) rooms<br />
**** '''name''': This room's name<br />
** '''[members]''': member list<br />
*** '''[member]''': (repeated) members<br />
**** '''name''': This member's name<br />
<br />
== Nick registration related commands (lobby and in-game) ==<br />
<br />
* '''[nickserv]'''<br />
** '''[register]'''<br />
*** '''password''': The password for the nick.<br />
*** '''mail''': The email address for the nick.<br />
** '''[drop]''': Drop this username.<br />
** '''[set]''': Set a detail (e.g. email address) for this nick.<br />
*** '''detail''': The detail, e.g. "mail".<br />
*** '''value''': The new value for this detail, e.g. "user@edomain"<br />
** '''[info]''': Request info about another username.<br />
*** '''name''': The username.<br />
<br />
== Updating the lobby state ==<br />
<br />
* '''[gamelist_diff]''': server message - basically a diff from two [gamelist]s; the keys listed are the ones that actually occure in practice<br />
** '''index''': The index of a user.<br />
** '''[insert_child]''' A new user logged on.<br />
*** '''[user]'''<br />
**** '''name''': The name of the user.<br />
**** '''available''' "yes"<br />
*** '''[delete_child]''' A user logged off.<br />
** '''[change_child]'''<br />
*** '''[user]'''<br />
**** '''[insert]''': A user joined/left a game.<br />
***** '''available''': "yes" when the user left a game. "no" when the user joined a game<br />
***** '''location''': The name of the game the user joined.<br />
**** '''[delete]'''<br />
***** '''location''': "x" when a game was left.<br />
*** '''[gamelist]'''<br />
**** '''index''': Index of the game in question.<br />
**** '''[insert_child]''': A game started.<br />
***** '''[game]''' All the usual keys of [game] possible, see above.<br />
**** '''[delete_child]''': A game ended.<br />
***** '''[game]'''<br />
**** '''[change_child]''': Something changed in a game.<br />
***** '''[game]'''<br />
****** '''[insert]'''<br />
******* '''slots''': The number of free slots in the form: free/max slots<br />
******* '''turn''': The turn number in the form: current turn/max turns<br />
****** '''[delete]'''<br />
******* '''map''': "x" comes with every ''turn'' or ''slots'' change for games with shroud<br />
******* '''mp_scenario''': "x" comes with ''turn'' and ''slots'' changes for games with no scenario id<br />
<br />
* '''[observer]''' or '''[observer_quit]''': server message - players joining([observer_quit] - quitting the lobby "game")/quitting([observer] - joining the lobby "game") a game<br />
** '''name''': Username of the player/observer.<br />
<br />
== Game setup (the phase from creation to start) ==<br />
To create a game the client sends:<br />
* '''[create_game]'''<br />
** '''name''': The title of the game.<br />
<br />
followed by a message with the scenario options as under [game] (see above) plus the scenario data ([time], [era], [side], etc. see [[ScenarioWML]])<br />
<br />
* '''[join]'''<br />
** '''id''': The id of the game.<br />
** '''observe''': Join the game as an observer.<br />
<br />
* '''[scenario_diff]''': [[ScenarioWML]] diff (side changes, etc.)<br />
<br />
* '''[start_game]''': sent by the host to start a game<br />
* '''[leave_game]''': sent by the client when it leaves a game; sent by the server to make a client leave a game<br />
<br />
== In-game communication ==<br />
<br />
* '''[store_next_scenario]''': sent by the host - the scenario data (see [[ScenarioWML]]) to advance to the next scenario<br />
* '''[notify_next_scenario]''': sent by the server to tell players that the data for the next scenario is available<br />
* '''[load_next_scenario]''': sent by the client to request the data for the next scenario<br />
* '''[next_scenario]''': data for the next scenario (see [[ScenarioWML]]), sent by the server on request<br />
<br />
* '''[info]''': sent by the host on game end - info about the game state<br />
** '''type''': "termination" <br />
** '''condition''': the termination reason<br />
<br />
* '''[change_controller]''': a player (un)droids one of his sides or assigns control to someone else (The host can assign control for any side.)<br />
** '''side''': the side to change controller<br />
** '''player''': the nick of the player to take control<br />
** '''controller''': the new controller: "human" or "human_ai"<br />
** '''own_side''': "yes"<br />
<br />
If a player leaves this is sent to the host for all sides he owned.<br />
* '''side_drop''': The number of a side that dropped because a player left.<br />
* '''controller''': The controller of that side. ("ai", "network")<br />
<br />
* '''[muteall]''': the host mutes/unmutes all observers - toggles<br />
* '''[mute]''': the host mutes an observer - toggles<br />
** '''username''': the username of the observer - if not specified the servers returns a list of muted usernames<br />
* '''[kick]''' or '''[ban]''': the host kicks/bans a player/observer<br />
** '''username''': the username of the player/observer<br />
<br />
* '''[turn]'''<br />
** '''[command]''': (repeated) can contain all the tags you can find in a replay: [recruit], [move], [end_turn], etc.<br />
*** '''[speak]'''<br />
**** '''message''': text of the message<br />
**** '''id''': the sender<br />
**** '''team_name''': the name of the team the message is for - empty if it's a public message<br />
<br />
== Administrative commands ==<br />
* '''[query]'''<br />
** '''type''': The type of query. See [[ServerAdministration]] for details.<br />
<br />
[[Category:WML Reference]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=31361MP Server Ilor2009-07-23T18:24:03Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| delayed<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done (very crude)<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed by a week, done.<br />
|-<br />
| 7.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| done<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| done<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| done<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| done<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| 20%<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| done<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| done<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| done<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 80% combats wired in, needs testing<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| on track<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| 20% groundwork laid<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=31346MP Server Ilor2009-07-21T23:06:19Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| delayed<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done (very crude)<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed by a week, done.<br />
|-<br />
| 7.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| done<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 80% (UI needs tweaks and testing)<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| done<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| done<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| mostly done<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| 20%<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| 80% (UI tweaks needed)<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| 75% (needs doubleclick dialog)<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 50% combats wired in, needs more testing<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=31263MP Server Ilor2009-07-12T14:00:09Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| delayed<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done (very crude)<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed by a week, done.<br />
|-<br />
| 7.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| 80%<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 80% (UI needs tweaks and testing)<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| 50%<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| done<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| none<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| 10%<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| 80% (UI tweaks needed)<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=31214MP Server Ilor2009-07-09T23:06:42Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| delayed<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done (very crude)<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed by a week, done.<br />
|-<br />
| 7.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| 70%<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 30% (logic mostly done, only a very crude UI)<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| 20%<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| none<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| none<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| 30% (logic mosly done, no real UI)<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=31178MultiplayerServerWML2009-07-09T12:59:20Z<p>Ilor: /* Room commands */</p>
<hr />
<div>= Multiplayer Server WML =<br />
This page describes the WML used to communicate with the multiplayer server (wesnothd).<br />
<br />
== The login procedure ==<br />
<br />
* server request (optional)<br />
** '''[version]'''<br />
<br />
* client response<br />
** '''[version]'''<br />
*** '''version''': The client's version string.<br />
<br />
* server request<br />
** '''[mustlogin]'''<br />
<br />
* client response<br />
** '''[login]'''<br />
*** '''username''': The username the client would like to have.<br />
*** '''password_reminder''': If "yes" the client requests the server to send a password reminder for the provided username.<br />
*** '''password''': The hashed password, created from the username, the password and salt received from the server.<br />
<br />
* server response<br />
** '''[join_lobby]''' or<br />
** '''[error]'''<br />
*** '''message''': The error message.<br />
*** '''password_request''': If not empty the server asks the client to provide a password for its desired username.<br />
*** '''phpbb_encryption''': If "yes" the client will encrypt the password using phpbb's algorithm.<br />
*** '''random_salt''': Random salt sent to the client for mixing with the password hash.<br />
*** '''hash_seed''': Salt generated from the original hash that is required to recreate it.<br />
*** '''salt''': Salt generated from the original hash that is required to recreate it.<br />
*** '''force_confirmation''': Display an ok/cancel dialog with the content of the 'message' key.<br />
<br />
* server response<br />
** '''[gamelist]'''<br />
*** '''[game]''' (repeated)<br />
**** '''id''': A unique id of the game.<br />
**** '''name''': The title of the game.<br />
**** '''mp_scenario''': The id of the scenario.<br />
**** '''mp_era''': The id of the used era.<br />
**** '''mp_use_map_settings''': Does the game use the map settings specified in the scenario.<br />
**** '''mp_fog''': Does the game use fog.<br />
**** '''mp_shroud''': Does the game use shroud.<br />
**** '''mp_village_gold''': The number of gold per village.<br />
**** '''experience_modifier''': The experience setting.<br />
**** '''mp_countdown''': Does the game use a timer.<br />
**** '''mp_countdown_reservoir_time''': Upper limit of the possibly available time.<br />
**** '''mp_countdown_init_time''': Initial time.<br />
**** '''mp_countdown_action_bonus''': Time bonus per action.<br />
**** '''mp_countdown_turn_bonus''': Time bonus per turn.<br />
**** '''map_data''': The map data. ''Notice: not sent to lobby if the game uses shroud''<br />
**** '''hash''': The hash value of the map_data.<br />
**** '''observer''': Are observers allowed or not.<br />
**** '''human_sides''': The number of sides played by humans.<br />
**** '''slots''': The number of vacant/max slots.<br />
**** '''turn''': The current turn/max turn.<br />
** '''[user]''' (repeated)<br />
*** '''name''': The username of the player.<br />
*** '''game_id''': The ID of the game the player is in (version 1.3.7+svn).<br />
*** '''location''': The name of the game the player is in.<br />
*** '''available''': "yes" if the player is in the lobby; "no" if in a game.<br />
Many of the keys under [game] are described more indepth on the [[ScenarioWML]] page.<br />
<br />
== Error messages ==<br />
<br />
* '''[error]'''<br />
** '''message''': The error message.<br />
<br />
== Chat (lobby and in-game) ==<br />
<br />
* '''[message]'''<br />
** '''sender''': (optional - filled by the server) The sender of the message.<br />
** '''message''': The message itself.<br />
** '''room''': The room the message is from/to {{DevFeature}}<br />
* '''[whisper]'''<br />
** '''receiver''': The receiver of the whisper<br />
** '''sender''': (optional - filled by the server) The sender of the whisper.<br />
** '''message''': The message itself.<br />
<br />
== Room commands ==<br />
Note: the room commands are in general {{DevFeature}} and are subject to change.<br />
* '''[room_join]'''<br />
** '''room''': The room name to join<br />
** '''player''': (filled by server in response message sent to all room members) the player that joins the room<br />
** '''[members]''': member list sent to the player that joined<br />
*** '''[member]''': (repeated) members<br />
**** '''name''': This member's name<br />
* '''[room_part]'''<br />
** '''room''': The room name to part (leave). Leaving the lobby is not allowed.<br />
** '''player''': (filled by server in response message sent to all room members) the player that leaves the room<br />
* '''[room_query]''': specific room-related queries.<br />
** '''[rooms]''': List rooms created on the server, or<br />
** '''[names]''': List members of a given room<br />
*** '''room''': The room name<br />
* '''[room_query_response]''': contains specific response to a room_query.<br />
<br />
== Nick registration related commands (lobby and in-game) ==<br />
<br />
* '''[nickserv]'''<br />
** '''[register]'''<br />
*** '''password''': The password for the nick.<br />
*** '''mail''': The email address for the nick.<br />
** '''[drop]''': Drop this username.<br />
** '''[set]''': Set a detail (e.g. email address) for this nick.<br />
*** '''detail''': The detail, e.g. "mail".<br />
*** '''value''': The new value for this detail, e.g. "user@edomain"<br />
** '''[info]''': Request info about another username.<br />
*** '''name''': The username.<br />
<br />
== Updating the lobby state ==<br />
<br />
* '''[gamelist_diff]''': server message - basically a diff from two [gamelist]s; the keys listed are the ones that actually occure in practice<br />
** '''index''': The index of a user.<br />
** '''[insert_child]''' A new user logged on.<br />
*** '''[user]'''<br />
**** '''name''': The name of the user.<br />
**** '''available''' "yes"<br />
*** '''[delete_child]''' A user logged off.<br />
** '''[change_child]'''<br />
*** '''[user]'''<br />
**** '''[insert]''': A user joined/left a game.<br />
***** '''available''': "yes" when the user left a game. "no" when the user joined a game<br />
***** '''location''': The name of the game the user joined.<br />
**** '''[delete]'''<br />
***** '''location''': "x" when a game was left.<br />
*** '''[gamelist]'''<br />
**** '''index''': Index of the game in question.<br />
**** '''[insert_child]''': A game started.<br />
***** '''[game]''' All the usual keys of [game] possible, see above.<br />
**** '''[delete_child]''': A game ended.<br />
***** '''[game]'''<br />
**** '''[change_child]''': Something changed in a game.<br />
***** '''[game]'''<br />
****** '''[insert]'''<br />
******* '''slots''': The number of free slots in the form: free/max slots<br />
******* '''turn''': The turn number in the form: current turn/max turns<br />
****** '''[delete]'''<br />
******* '''map''': "x" comes with every ''turn'' or ''slots'' change for games with shroud<br />
******* '''mp_scenario''': "x" comes with ''turn'' and ''slots'' changes for games with no scenario id<br />
<br />
* '''[observer]''' or '''[observer_quit]''': server message - players joining([observer_quit] - quitting the lobby "game")/quitting([observer] - joining the lobby "game") a game<br />
** '''name''': Username of the player/observer.<br />
<br />
== Game setup (the phase from creation to start) ==<br />
To create a game the client sends:<br />
* '''[create_game]'''<br />
** '''name''': The title of the game.<br />
<br />
followed by a message with the scenario options as under [game] (see above) plus the scenario data ([time], [era], [side], etc. see [[ScenarioWML]])<br />
<br />
* '''[join]'''<br />
** '''id''': The id of the game.<br />
** '''observe''': Join the game as an observer.<br />
<br />
* '''[scenario_diff]''': [[ScenarioWML]] diff (side changes, etc.)<br />
<br />
* '''[start_game]''': sent by the host to start a game<br />
* '''[leave_game]''': sent by the client when it leaves a game; sent by the server to make a client leave a game<br />
<br />
== In-game communication ==<br />
<br />
* '''[store_next_scenario]''': sent by the host - the scenario data (see [[ScenarioWML]]) to advance to the next scenario<br />
* '''[notify_next_scenario]''': sent by the server to tell players that the data for the next scenario is available<br />
* '''[load_next_scenario]''': sent by the client to request the data for the next scenario<br />
* '''[next_scenario]''': data for the next scenario (see [[ScenarioWML]]), sent by the server on request<br />
<br />
* '''[info]''': sent by the host on game end - info about the game state<br />
** '''type''': "termination" <br />
** '''condition''': the termination reason<br />
<br />
* '''[change_controller]''': a player (un)droids one of his sides or assigns control to someone else (The host can assign control for any side.)<br />
** '''side''': the side to change controller<br />
** '''player''': the nick of the player to take control<br />
** '''controller''': the new controller: "human" or "human_ai"<br />
** '''own_side''': "yes"<br />
<br />
If a player leaves this is sent to the host for all sides he owned.<br />
* '''side_drop''': The number of a side that dropped because a player left.<br />
* '''controller''': The controller of that side. ("ai", "network")<br />
<br />
* '''[muteall]''': the host mutes/unmutes all observers - toggles<br />
* '''[mute]''': the host mutes an observer - toggles<br />
** '''username''': the username of the observer - if not specified the servers returns a list of muted usernames<br />
* '''[kick]''' or '''[ban]''': the host kicks/bans a player/observer<br />
** '''username''': the username of the player/observer<br />
<br />
* '''[turn]'''<br />
** '''[command]''': (repeated) can contain all the tags you can find in a replay: [recruit], [move], [end_turn], etc.<br />
*** '''[speak]'''<br />
**** '''message''': text of the message<br />
**** '''id''': the sender<br />
**** '''team_name''': the name of the team the message is for - empty if it's a public message<br />
<br />
== Administrative commands ==<br />
* '''[query]'''<br />
** '''type''': The type of query. See [[ServerAdministration]] for details.<br />
<br />
[[Category:WML Reference]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=31177MultiplayerServerWML2009-07-09T12:59:02Z<p>Ilor: /* Room commands */</p>
<hr />
<div>= Multiplayer Server WML =<br />
This page describes the WML used to communicate with the multiplayer server (wesnothd).<br />
<br />
== The login procedure ==<br />
<br />
* server request (optional)<br />
** '''[version]'''<br />
<br />
* client response<br />
** '''[version]'''<br />
*** '''version''': The client's version string.<br />
<br />
* server request<br />
** '''[mustlogin]'''<br />
<br />
* client response<br />
** '''[login]'''<br />
*** '''username''': The username the client would like to have.<br />
*** '''password_reminder''': If "yes" the client requests the server to send a password reminder for the provided username.<br />
*** '''password''': The hashed password, created from the username, the password and salt received from the server.<br />
<br />
* server response<br />
** '''[join_lobby]''' or<br />
** '''[error]'''<br />
*** '''message''': The error message.<br />
*** '''password_request''': If not empty the server asks the client to provide a password for its desired username.<br />
*** '''phpbb_encryption''': If "yes" the client will encrypt the password using phpbb's algorithm.<br />
*** '''random_salt''': Random salt sent to the client for mixing with the password hash.<br />
*** '''hash_seed''': Salt generated from the original hash that is required to recreate it.<br />
*** '''salt''': Salt generated from the original hash that is required to recreate it.<br />
*** '''force_confirmation''': Display an ok/cancel dialog with the content of the 'message' key.<br />
<br />
* server response<br />
** '''[gamelist]'''<br />
*** '''[game]''' (repeated)<br />
**** '''id''': A unique id of the game.<br />
**** '''name''': The title of the game.<br />
**** '''mp_scenario''': The id of the scenario.<br />
**** '''mp_era''': The id of the used era.<br />
**** '''mp_use_map_settings''': Does the game use the map settings specified in the scenario.<br />
**** '''mp_fog''': Does the game use fog.<br />
**** '''mp_shroud''': Does the game use shroud.<br />
**** '''mp_village_gold''': The number of gold per village.<br />
**** '''experience_modifier''': The experience setting.<br />
**** '''mp_countdown''': Does the game use a timer.<br />
**** '''mp_countdown_reservoir_time''': Upper limit of the possibly available time.<br />
**** '''mp_countdown_init_time''': Initial time.<br />
**** '''mp_countdown_action_bonus''': Time bonus per action.<br />
**** '''mp_countdown_turn_bonus''': Time bonus per turn.<br />
**** '''map_data''': The map data. ''Notice: not sent to lobby if the game uses shroud''<br />
**** '''hash''': The hash value of the map_data.<br />
**** '''observer''': Are observers allowed or not.<br />
**** '''human_sides''': The number of sides played by humans.<br />
**** '''slots''': The number of vacant/max slots.<br />
**** '''turn''': The current turn/max turn.<br />
** '''[user]''' (repeated)<br />
*** '''name''': The username of the player.<br />
*** '''game_id''': The ID of the game the player is in (version 1.3.7+svn).<br />
*** '''location''': The name of the game the player is in.<br />
*** '''available''': "yes" if the player is in the lobby; "no" if in a game.<br />
Many of the keys under [game] are described more indepth on the [[ScenarioWML]] page.<br />
<br />
== Error messages ==<br />
<br />
* '''[error]'''<br />
** '''message''': The error message.<br />
<br />
== Chat (lobby and in-game) ==<br />
<br />
* '''[message]'''<br />
** '''sender''': (optional - filled by the server) The sender of the message.<br />
** '''message''': The message itself.<br />
** '''room''': The room the message is from/to {{DevFeature}}<br />
* '''[whisper]'''<br />
** '''receiver''': The receiver of the whisper<br />
** '''sender''': (optional - filled by the server) The sender of the whisper.<br />
** '''message''': The message itself.<br />
<br />
== Room commands ==<br />
Note: the room commands are in general {{DevFeature}} and are subject to change.<br />
* '''[room_join]'''<br />
** '''room''': The room name to join<br />
** '''player''': (filled by server in response message sent to all room members) the player that joins the room<br />
** '''[members]''': member list sent to the player that joined<br />
*** '''[member]''': (repeated) members<br />
**** '''name''': This player's name<br />
* '''[room_part]'''<br />
** '''room''': The room name to part (leave). Leaving the lobby is not allowed.<br />
** '''player''': (filled by server in response message sent to all room members) the player that leaves the room<br />
* '''[room_query]''': specific room-related queries.<br />
** '''[rooms]''': List rooms created on the server, or<br />
** '''[names]''': List members of a given room<br />
*** '''room''': The room name<br />
* '''[room_query_response]''': contains specific response to a room_query.<br />
<br />
== Nick registration related commands (lobby and in-game) ==<br />
<br />
* '''[nickserv]'''<br />
** '''[register]'''<br />
*** '''password''': The password for the nick.<br />
*** '''mail''': The email address for the nick.<br />
** '''[drop]''': Drop this username.<br />
** '''[set]''': Set a detail (e.g. email address) for this nick.<br />
*** '''detail''': The detail, e.g. "mail".<br />
*** '''value''': The new value for this detail, e.g. "user@edomain"<br />
** '''[info]''': Request info about another username.<br />
*** '''name''': The username.<br />
<br />
== Updating the lobby state ==<br />
<br />
* '''[gamelist_diff]''': server message - basically a diff from two [gamelist]s; the keys listed are the ones that actually occure in practice<br />
** '''index''': The index of a user.<br />
** '''[insert_child]''' A new user logged on.<br />
*** '''[user]'''<br />
**** '''name''': The name of the user.<br />
**** '''available''' "yes"<br />
*** '''[delete_child]''' A user logged off.<br />
** '''[change_child]'''<br />
*** '''[user]'''<br />
**** '''[insert]''': A user joined/left a game.<br />
***** '''available''': "yes" when the user left a game. "no" when the user joined a game<br />
***** '''location''': The name of the game the user joined.<br />
**** '''[delete]'''<br />
***** '''location''': "x" when a game was left.<br />
*** '''[gamelist]'''<br />
**** '''index''': Index of the game in question.<br />
**** '''[insert_child]''': A game started.<br />
***** '''[game]''' All the usual keys of [game] possible, see above.<br />
**** '''[delete_child]''': A game ended.<br />
***** '''[game]'''<br />
**** '''[change_child]''': Something changed in a game.<br />
***** '''[game]'''<br />
****** '''[insert]'''<br />
******* '''slots''': The number of free slots in the form: free/max slots<br />
******* '''turn''': The turn number in the form: current turn/max turns<br />
****** '''[delete]'''<br />
******* '''map''': "x" comes with every ''turn'' or ''slots'' change for games with shroud<br />
******* '''mp_scenario''': "x" comes with ''turn'' and ''slots'' changes for games with no scenario id<br />
<br />
* '''[observer]''' or '''[observer_quit]''': server message - players joining([observer_quit] - quitting the lobby "game")/quitting([observer] - joining the lobby "game") a game<br />
** '''name''': Username of the player/observer.<br />
<br />
== Game setup (the phase from creation to start) ==<br />
To create a game the client sends:<br />
* '''[create_game]'''<br />
** '''name''': The title of the game.<br />
<br />
followed by a message with the scenario options as under [game] (see above) plus the scenario data ([time], [era], [side], etc. see [[ScenarioWML]])<br />
<br />
* '''[join]'''<br />
** '''id''': The id of the game.<br />
** '''observe''': Join the game as an observer.<br />
<br />
* '''[scenario_diff]''': [[ScenarioWML]] diff (side changes, etc.)<br />
<br />
* '''[start_game]''': sent by the host to start a game<br />
* '''[leave_game]''': sent by the client when it leaves a game; sent by the server to make a client leave a game<br />
<br />
== In-game communication ==<br />
<br />
* '''[store_next_scenario]''': sent by the host - the scenario data (see [[ScenarioWML]]) to advance to the next scenario<br />
* '''[notify_next_scenario]''': sent by the server to tell players that the data for the next scenario is available<br />
* '''[load_next_scenario]''': sent by the client to request the data for the next scenario<br />
* '''[next_scenario]''': data for the next scenario (see [[ScenarioWML]]), sent by the server on request<br />
<br />
* '''[info]''': sent by the host on game end - info about the game state<br />
** '''type''': "termination" <br />
** '''condition''': the termination reason<br />
<br />
* '''[change_controller]''': a player (un)droids one of his sides or assigns control to someone else (The host can assign control for any side.)<br />
** '''side''': the side to change controller<br />
** '''player''': the nick of the player to take control<br />
** '''controller''': the new controller: "human" or "human_ai"<br />
** '''own_side''': "yes"<br />
<br />
If a player leaves this is sent to the host for all sides he owned.<br />
* '''side_drop''': The number of a side that dropped because a player left.<br />
* '''controller''': The controller of that side. ("ai", "network")<br />
<br />
* '''[muteall]''': the host mutes/unmutes all observers - toggles<br />
* '''[mute]''': the host mutes an observer - toggles<br />
** '''username''': the username of the observer - if not specified the servers returns a list of muted usernames<br />
* '''[kick]''' or '''[ban]''': the host kicks/bans a player/observer<br />
** '''username''': the username of the player/observer<br />
<br />
* '''[turn]'''<br />
** '''[command]''': (repeated) can contain all the tags you can find in a replay: [recruit], [move], [end_turn], etc.<br />
*** '''[speak]'''<br />
**** '''message''': text of the message<br />
**** '''id''': the sender<br />
**** '''team_name''': the name of the team the message is for - empty if it's a public message<br />
<br />
== Administrative commands ==<br />
* '''[query]'''<br />
** '''type''': The type of query. See [[ServerAdministration]] for details.<br />
<br />
[[Category:WML Reference]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=31130MP Server Ilor2009-07-07T19:28:21Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| delayed<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done (very crude)<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed by a week, done.<br />
|-<br />
| 7.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| 50%<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| 20%<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| none<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| none<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| none<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=31105MultiplayerServerWML2009-07-07T09:01:36Z<p>Ilor: /* The login procedure */</p>
<hr />
<div>= Multiplayer Server WML =<br />
This page describes the WML used to communicate with the multiplayer server (wesnothd).<br />
<br />
== The login procedure ==<br />
<br />
* server request (optional)<br />
** '''[version]'''<br />
<br />
* client response<br />
** '''[version]'''<br />
*** '''version''': The client's version string.<br />
<br />
* server request<br />
** '''[mustlogin]'''<br />
<br />
* client response<br />
** '''[login]'''<br />
*** '''username''': The username the client would like to have.<br />
*** '''password_reminder''': If "yes" the client requests the server to send a password reminder for the provided username.<br />
*** '''password''': The hashed password, created from the username, the password and salt received from the server.<br />
<br />
* server response<br />
** '''[join_lobby]''' or<br />
** '''[error]'''<br />
*** '''message''': The error message.<br />
*** '''password_request''': If not empty the server asks the client to provide a password for its desired username.<br />
*** '''phpbb_encryption''': If "yes" the client will encrypt the password using phpbb's algorithm.<br />
*** '''random_salt''': Random salt sent to the client for mixing with the password hash.<br />
*** '''hash_seed''': Salt generated from the original hash that is required to recreate it.<br />
*** '''salt''': Salt generated from the original hash that is required to recreate it.<br />
*** '''force_confirmation''': Display an ok/cancel dialog with the content of the 'message' key.<br />
<br />
* server response<br />
** '''[gamelist]'''<br />
*** '''[game]''' (repeated)<br />
**** '''id''': A unique id of the game.<br />
**** '''name''': The title of the game.<br />
**** '''mp_scenario''': The id of the scenario.<br />
**** '''mp_era''': The id of the used era.<br />
**** '''mp_use_map_settings''': Does the game use the map settings specified in the scenario.<br />
**** '''mp_fog''': Does the game use fog.<br />
**** '''mp_shroud''': Does the game use shroud.<br />
**** '''mp_village_gold''': The number of gold per village.<br />
**** '''experience_modifier''': The experience setting.<br />
**** '''mp_countdown''': Does the game use a timer.<br />
**** '''mp_countdown_reservoir_time''': Upper limit of the possibly available time.<br />
**** '''mp_countdown_init_time''': Initial time.<br />
**** '''mp_countdown_action_bonus''': Time bonus per action.<br />
**** '''mp_countdown_turn_bonus''': Time bonus per turn.<br />
**** '''map_data''': The map data. ''Notice: not sent to lobby if the game uses shroud''<br />
**** '''hash''': The hash value of the map_data.<br />
**** '''observer''': Are observers allowed or not.<br />
**** '''human_sides''': The number of sides played by humans.<br />
**** '''slots''': The number of vacant/max slots.<br />
**** '''turn''': The current turn/max turn.<br />
** '''[user]''' (repeated)<br />
*** '''name''': The username of the player.<br />
*** '''game_id''': The ID of the game the player is in (version 1.3.7+svn).<br />
*** '''location''': The name of the game the player is in.<br />
*** '''available''': "yes" if the player is in the lobby; "no" if in a game.<br />
Many of the keys under [game] are described more indepth on the [[ScenarioWML]] page.<br />
<br />
== Error messages ==<br />
<br />
* '''[error]'''<br />
** '''message''': The error message.<br />
<br />
== Chat (lobby and in-game) ==<br />
<br />
* '''[message]'''<br />
** '''sender''': (optional - filled by the server) The sender of the message.<br />
** '''message''': The message itself.<br />
** '''room''': The room the message is from/to {{DevFeature}}<br />
* '''[whisper]'''<br />
** '''receiver''': The receiver of the whisper<br />
** '''sender''': (optional - filled by the server) The sender of the whisper.<br />
** '''message''': The message itself.<br />
<br />
== Room commands ==<br />
Note: the room commands are in general {{DevFeature}} and are subject to change.<br />
* '''[room_join]'''<br />
** '''room''': The room name to join<br />
* '''[room_part]'''<br />
** '''room''': The room name to part (leave). Leaving the lobby is not allowed.<br />
* '''[room_query]''': specific room-related queries.<br />
** '''[rooms]''': List rooms created on the server, or<br />
** '''[names]''': List members of a given room<br />
*** '''room''': The room name<br />
* '''[room_query_response]''': contains specific response to a room_query.<br />
<br />
<br />
== Nick registration related commands (lobby and in-game) ==<br />
<br />
* '''[nickserv]'''<br />
** '''[register]'''<br />
*** '''password''': The password for the nick.<br />
*** '''mail''': The email address for the nick.<br />
** '''[drop]''': Drop this username.<br />
** '''[set]''': Set a detail (e.g. email address) for this nick.<br />
*** '''detail''': The detail, e.g. "mail".<br />
*** '''value''': The new value for this detail, e.g. "user@edomain"<br />
** '''[info]''': Request info about another username.<br />
*** '''name''': The username.<br />
<br />
== Updating the lobby state ==<br />
<br />
* '''[gamelist_diff]''': server message - basically a diff from two [gamelist]s; the keys listed are the ones that actually occure in practice<br />
** '''index''': The index of a user.<br />
** '''[insert_child]''' A new user logged on.<br />
*** '''[user]'''<br />
**** '''name''': The name of the user.<br />
**** '''available''' "yes"<br />
*** '''[delete_child]''' A user logged off.<br />
** '''[change_child]'''<br />
*** '''[user]'''<br />
**** '''[insert]''': A user joined/left a game.<br />
***** '''available''': "yes" when the user left a game. "no" when the user joined a game<br />
***** '''location''': The name of the game the user joined.<br />
**** '''[delete]'''<br />
***** '''location''': "x" when a game was left.<br />
*** '''[gamelist]'''<br />
**** '''index''': Index of the game in question.<br />
**** '''[insert_child]''': A game started.<br />
***** '''[game]''' All the usual keys of [game] possible, see above.<br />
**** '''[delete_child]''': A game ended.<br />
***** '''[game]'''<br />
**** '''[change_child]''': Something changed in a game.<br />
***** '''[game]'''<br />
****** '''[insert]'''<br />
******* '''slots''': The number of free slots in the form: free/max slots<br />
******* '''turn''': The turn number in the form: current turn/max turns<br />
****** '''[delete]'''<br />
******* '''map''': "x" comes with every ''turn'' or ''slots'' change for games with shroud<br />
******* '''mp_scenario''': "x" comes with ''turn'' and ''slots'' changes for games with no scenario id<br />
<br />
* '''[observer]''' or '''[observer_quit]''': server message - players joining([observer_quit] - quitting the lobby "game")/quitting([observer] - joining the lobby "game") a game<br />
** '''name''': Username of the player/observer.<br />
<br />
== Game setup (the phase from creation to start) ==<br />
To create a game the client sends:<br />
* '''[create_game]'''<br />
** '''name''': The title of the game.<br />
<br />
followed by a message with the scenario options as under [game] (see above) plus the scenario data ([time], [era], [side], etc. see [[ScenarioWML]])<br />
<br />
* '''[join]'''<br />
** '''id''': The id of the game.<br />
** '''observe''': Join the game as an observer.<br />
<br />
* '''[scenario_diff]''': [[ScenarioWML]] diff (side changes, etc.)<br />
<br />
* '''[start_game]''': sent by the host to start a game<br />
* '''[leave_game]''': sent by the client when it leaves a game; sent by the server to make a client leave a game<br />
<br />
== In-game communication ==<br />
<br />
* '''[store_next_scenario]''': sent by the host - the scenario data (see [[ScenarioWML]]) to advance to the next scenario<br />
* '''[notify_next_scenario]''': sent by the server to tell players that the data for the next scenario is available<br />
* '''[load_next_scenario]''': sent by the client to request the data for the next scenario<br />
* '''[next_scenario]''': data for the next scenario (see [[ScenarioWML]]), sent by the server on request<br />
<br />
* '''[info]''': sent by the host on game end - info about the game state<br />
** '''type''': "termination" <br />
** '''condition''': the termination reason<br />
<br />
* '''[change_controller]''': a player (un)droids one of his sides or assigns control to someone else (The host can assign control for any side.)<br />
** '''side''': the side to change controller<br />
** '''player''': the nick of the player to take control<br />
** '''controller''': the new controller: "human" or "human_ai"<br />
** '''own_side''': "yes"<br />
<br />
If a player leaves this is sent to the host for all sides he owned.<br />
* '''side_drop''': The number of a side that dropped because a player left.<br />
* '''controller''': The controller of that side. ("ai", "network")<br />
<br />
* '''[muteall]''': the host mutes/unmutes all observers - toggles<br />
* '''[mute]''': the host mutes an observer - toggles<br />
** '''username''': the username of the observer - if not specified the servers returns a list of muted usernames<br />
* '''[kick]''' or '''[ban]''': the host kicks/bans a player/observer<br />
** '''username''': the username of the player/observer<br />
<br />
* '''[turn]'''<br />
** '''[command]''': (repeated) can contain all the tags you can find in a replay: [recruit], [move], [end_turn], etc.<br />
*** '''[speak]'''<br />
**** '''message''': text of the message<br />
**** '''id''': the sender<br />
**** '''team_name''': the name of the team the message is for - empty if it's a public message<br />
<br />
== Administrative commands ==<br />
* '''[query]'''<br />
** '''type''': The type of query. See [[ServerAdministration]] for details.<br />
<br />
[[Category:WML Reference]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=31067MP Server Ilor2009-07-06T06:24:36Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| delayed<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 6.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| 50%<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done (very crude)<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| none<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| none<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| none<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| none<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=31055MP Server Ilor2009-07-05T12:50:20Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| delayed<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| done<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| done. Updates to be done if protocol is expanded.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| done<br />
|-<br />
| 6.5<br />
| Client-side rooms logic and logging<br />
| <p style="color:red">MANDATORY</p><br />
| Write the non-gui parts of lobby room logic (keeping info about the rooms the player is in, what players arein what rooms, what games are on the server etc)<br />
| 50%<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 30%<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| Delayed<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| none<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| none<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| none<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| none<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 16.5<br />
| MP protocol cleanups<br />
| <p style="color:blue">OPTIONAL</p><br />
| Clean up what the server sends to the client esp. in regard to game info to avoid some pointless tricks<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=30880MP Server Ilor2009-06-29T10:00:14Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| delayed<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| 80%<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| 50%<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 80%<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| 50%<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 1%<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| none<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| none<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| none<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| none<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| none<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=30796MP Server Ilor2009-06-25T07:52:22Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| delayed<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| 80%<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| 40%<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 70%<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| 40%<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 1%<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| none<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| none<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| none<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| none<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| none<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=30795MP Server Ilor2009-06-25T07:52:01Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| delayed<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| 80%<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages ([[MultiplayerServerWML]])<br />
| 10%<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 70%<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| 40%<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 1%<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| none<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| none<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| none<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| none<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| none<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=30794MultiplayerServerWML2009-06-25T07:50:51Z<p>Ilor: /* Multiplayer Server WML */</p>
<hr />
<div>= Multiplayer Server WML =<br />
This page describes the WML used to communicate with the multiplayer server (wesnothd).<br />
<br />
== The login procedure ==<br />
<br />
* server request (optional)<br />
** '''[version]'''<br />
<br />
* client response<br />
** '''[version]'''<br />
*** '''version''': The client's version string.<br />
<br />
* server request<br />
** '''[mustlogin]'''<br />
<br />
* client response<br />
** '''[login]'''<br />
*** '''username''': The username the client would like to have.<br />
*** '''password_reminder''': If "yes" the client requests the server to send a password reminder for the provided username.<br />
*** '''password''': The hashed password, created from the username, the password and salt received from the server.<br />
<br />
* server response<br />
** '''[join_lobby]''' or<br />
** '''[error]'''<br />
*** '''message''': The error message.<br />
*** '''password_request''': If not empty the server asks the client to provide a password for its desired username.<br />
*** '''phpbb_encryption''': If "yes" the client will encrypt the password using phpbb's algorithm.<br />
*** '''random_salt''': Random salt sent to the client for mixing with the password hash.<br />
*** '''hash_seed''': Salt generated from the original hash that is required to recreate it.<br />
*** '''salt''': Salt generated from the original hash that is required to recreate it.<br />
*** '''force_confirmation''': Display an ok/cancel dialog with the content of the 'message' key.<br />
<br />
* server response<br />
** '''[gamelist]'''<br />
*** '''[game]''' (repeated)<br />
**** '''id''': A unique id of the game.<br />
**** '''name''': The title of the game.<br />
**** '''mp_scenario''': The id of the scenario.<br />
**** '''mp_era''': The id of the used era.<br />
**** '''mp_use_map_settings''': Does the game use the map settings specified in the scenario.<br />
**** '''mp_fog''': Does the game use fog.<br />
**** '''mp_shroud''': Does the game use shroud.<br />
**** '''mp_village_gold''': The number of gold per village.<br />
**** '''experience_modifier''': The experience setting.<br />
**** '''mp_countdown''': Does the game use a timer.<br />
**** '''mp_countdown_reservoir_time''': Upper limit of the possibly available time.<br />
**** '''mp_countdown_init_time''': Initial time.<br />
**** '''mp_countdown_action_bonus''': Time bonus per action.<br />
**** '''mp_countdown_turn_bonus''': Time bonus per turn.<br />
**** '''map_data''': The map data.<br />
**** '''hash''': The hash value of the map_data.<br />
**** '''observer''': Are observers allowed or not.<br />
**** '''human_sides''': The number of sides played by humans.<br />
**** '''slots''': The number of vacant/max slots.<br />
**** '''turn''': The current turn/max turn.<br />
** '''[user]''' (repeated)<br />
*** '''name''': The username of the player.<br />
*** '''game_id''': The ID of the game the player is in (version 1.3.7+svn).<br />
*** '''location''': The name of the game the player is in.<br />
*** '''available''': "yes" if the player is in the lobby; "no" if in a game.<br />
Many of the keys under [game] are described more indepth on the [[ScenarioWML]] page.<br />
<br />
== Error messages ==<br />
<br />
* '''[error]'''<br />
** '''message''': The error message.<br />
<br />
== Chat (lobby and in-game) ==<br />
<br />
* '''[message]'''<br />
** '''sender''': (optional - filled by the server) The sender of the message.<br />
** '''message''': The message itself.<br />
** '''room''': The room the message is from/to {{DevFeature}}<br />
* '''[whisper]'''<br />
** '''receiver''': The receiver of the whisper<br />
** '''sender''': (optional - filled by the server) The sender of the whisper.<br />
** '''message''': The message itself.<br />
<br />
== Room commands ==<br />
Note: the room commands are in general {{DevFeature}} and are subject to change.<br />
* '''[room_join]'''<br />
** '''room''': The room name to join<br />
* '''[room_part]'''<br />
** '''room''': The room name to part (leave). Leaving the lobby is not allowed.<br />
* '''[room_query]''': specific room-related queries.<br />
** '''[rooms]''': List rooms created on the server, or<br />
** '''[names]''': List members of a given room<br />
*** '''room''': The room name<br />
* '''[room_query_response]''': contains specific response to a room_query.<br />
<br />
<br />
== Nick registration related commands (lobby and in-game) ==<br />
<br />
* '''[nickserv]'''<br />
** '''[register]'''<br />
*** '''password''': The password for the nick.<br />
*** '''mail''': The email address for the nick.<br />
** '''[drop]''': Drop this username.<br />
** '''[set]''': Set a detail (e.g. email address) for this nick.<br />
*** '''detail''': The detail, e.g. "mail".<br />
*** '''value''': The new value for this detail, e.g. "user@edomain"<br />
** '''[info]''': Request info about another username.<br />
*** '''name''': The username.<br />
<br />
== Updating the lobby state ==<br />
<br />
* '''[gamelist_diff]''': server message - basically a diff from two [gamelist]s; the keys listed are the ones that actually occure in practice<br />
** '''index''': The index of a user.<br />
** '''[insert_child]''' A new user logged on.<br />
*** '''[user]'''<br />
**** '''name''': The name of the user.<br />
**** '''available''' "yes"<br />
*** '''[delete_child]''' A user logged off.<br />
** '''[change_child]'''<br />
*** '''[user]'''<br />
**** '''[insert]''': A user joined/left a game.<br />
***** '''available''': "yes" when the user left a game. "no" when the user joined a game<br />
***** '''location''': The name of the game the user joined.<br />
**** '''[delete]'''<br />
***** '''location''': "x" when a game was left.<br />
*** '''[gamelist]'''<br />
**** '''index''': Index of the game in question.<br />
**** '''[insert_child]''': A game started.<br />
***** '''[game]''' All the usual keys of [game] possible, see above.<br />
**** '''[delete_child]''': A game ended.<br />
***** '''[game]'''<br />
**** '''[change_child]''': Something changed in a game.<br />
***** '''[game]'''<br />
****** '''[insert]'''<br />
******* '''slots''': The number of free slots in the form: free/max slots<br />
******* '''turn''': The turn number in the form: current turn/max turns<br />
****** '''[delete]'''<br />
******* '''map''': "x" comes with every ''turn'' or ''slots'' change for games with shroud<br />
******* '''mp_scenario''': "x" comes with ''turn'' and ''slots'' changes for games with no scenario id<br />
<br />
* '''[observer]''' or '''[observer_quit]''': server message - players joining([observer_quit] - quitting the lobby "game")/quitting([observer] - joining the lobby "game") a game<br />
** '''name''': Username of the player/observer.<br />
<br />
== Game setup (the phase from creation to start) ==<br />
To create a game the client sends:<br />
* '''[create_game]'''<br />
** '''name''': The title of the game.<br />
<br />
followed by a message with the scenario options as under [game] (see above) plus the scenario data ([time], [era], [side], etc. see [[ScenarioWML]])<br />
<br />
* '''[join]'''<br />
** '''id''': The id of the game.<br />
** '''observe''': Join the game as an observer.<br />
<br />
* '''[scenario_diff]''': [[ScenarioWML]] diff (side changes, etc.)<br />
<br />
* '''[start_game]''': sent by the host to start a game<br />
* '''[leave_game]''': sent by the client when it leaves a game; sent by the server to make a client leave a game<br />
<br />
== In-game communication ==<br />
<br />
* '''[store_next_scenario]''': sent by the host - the scenario data (see [[ScenarioWML]]) to advance to the next scenario<br />
* '''[notify_next_scenario]''': sent by the server to tell players that the data for the next scenario is available<br />
* '''[load_next_scenario]''': sent by the client to request the data for the next scenario<br />
* '''[next_scenario]''': data for the next scenario (see [[ScenarioWML]]), sent by the server on request<br />
<br />
* '''[info]''': sent by the host on game end - info about the game state<br />
** '''type''': "termination" <br />
** '''condition''': the termination reason<br />
<br />
* '''[change_controller]''': a player (un)droids one of his sides or assigns control to someone else (The host can assign control for any side.)<br />
** '''side''': the side to change controller<br />
** '''player''': the nick of the player to take control<br />
** '''controller''': the new controller: "human" or "human_ai"<br />
** '''own_side''': "yes"<br />
<br />
If a player leaves this is sent to the host for all sides he owned.<br />
* '''side_drop''': The number of a side that dropped because a player left.<br />
* '''controller''': The controller of that side. ("ai", "network")<br />
<br />
* '''[muteall]''': the host mutes/unmutes all observers - toggles<br />
* '''[mute]''': the host mutes an observer - toggles<br />
** '''username''': the username of the observer - if not specified the servers returns a list of muted usernames<br />
* '''[kick]''' or '''[ban]''': the host kicks/bans a player/observer<br />
** '''username''': the username of the player/observer<br />
<br />
* '''[turn]'''<br />
** '''[command]''': (repeated) can contain all the tags you can find in a replay: [recruit], [move], [end_turn], etc.<br />
*** '''[speak]'''<br />
**** '''message''': text of the message<br />
**** '''id''': the sender<br />
**** '''team_name''': the name of the team the message is for - empty if it's a public message<br />
<br />
== Administrative commands ==<br />
* '''[query]'''<br />
** '''type''': The type of query. See [[ServerAdministration]] for details.<br />
<br />
[[Category:WML Reference]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MultiplayerServerWML&diff=30793MultiplayerServerWML2009-06-25T07:44:09Z<p>Ilor: /* Chat (lobby and in-game) */</p>
<hr />
<div>= Multiplayer Server WML =<br />
This page describes the WML used to communicate with the multiplayer server (wesnothd).<br />
<br />
== The login procedure ==<br />
<br />
* server request (optional)<br />
** '''[version]'''<br />
<br />
* client response<br />
** '''[version]'''<br />
*** '''version''': The client's version string.<br />
<br />
* server request<br />
** '''[mustlogin]'''<br />
<br />
* client response<br />
** '''[login]'''<br />
*** '''username''': The username the client would like to have.<br />
*** '''password_reminder''': If "yes" the client requests the server to send a password reminder for the provided username.<br />
*** '''password''': The hashed password, created from the username, the password and salt received from the server.<br />
<br />
* server response<br />
** '''[join_lobby]''' or<br />
** '''[error]'''<br />
*** '''message''': The error message.<br />
*** '''password_request''': If not empty the server asks the client to provide a password for its desired username.<br />
*** '''phpbb_encryption''': If "yes" the client will encrypt the password using phpbb's algorithm.<br />
*** '''random_salt''': Random salt sent to the client for mixing with the password hash.<br />
*** '''hash_seed''': Salt generated from the original hash that is required to recreate it.<br />
*** '''salt''': Salt generated from the original hash that is required to recreate it.<br />
*** '''force_confirmation''': Display an ok/cancel dialog with the content of the 'message' key.<br />
<br />
* server response<br />
** '''[gamelist]'''<br />
*** '''[game]''' (repeated)<br />
**** '''id''': A unique id of the game.<br />
**** '''name''': The title of the game.<br />
**** '''mp_scenario''': The id of the scenario.<br />
**** '''mp_era''': The id of the used era.<br />
**** '''mp_use_map_settings''': Does the game use the map settings specified in the scenario.<br />
**** '''mp_fog''': Does the game use fog.<br />
**** '''mp_shroud''': Does the game use shroud.<br />
**** '''mp_village_gold''': The number of gold per village.<br />
**** '''experience_modifier''': The experience setting.<br />
**** '''mp_countdown''': Does the game use a timer.<br />
**** '''mp_countdown_reservoir_time''': Upper limit of the possibly available time.<br />
**** '''mp_countdown_init_time''': Initial time.<br />
**** '''mp_countdown_action_bonus''': Time bonus per action.<br />
**** '''mp_countdown_turn_bonus''': Time bonus per turn.<br />
**** '''map_data''': The map data.<br />
**** '''hash''': The hash value of the map_data.<br />
**** '''observer''': Are observers allowed or not.<br />
**** '''human_sides''': The number of sides played by humans.<br />
**** '''slots''': The number of vacant/max slots.<br />
**** '''turn''': The current turn/max turn.<br />
** '''[user]''' (repeated)<br />
*** '''name''': The username of the player.<br />
*** '''game_id''': The ID of the game the player is in (version 1.3.7+svn).<br />
*** '''location''': The name of the game the player is in.<br />
*** '''available''': "yes" if the player is in the lobby; "no" if in a game.<br />
Many of the keys under [game] are described more indepth on the [[ScenarioWML]] page.<br />
<br />
== Error messages ==<br />
<br />
* '''[error]'''<br />
** '''message''': The error message.<br />
<br />
== Chat (lobby and in-game) ==<br />
<br />
* '''[message]'''<br />
** '''sender''': (optional - filled by the server) The sender of the message.<br />
** '''message''': The message itself.<br />
** '''room''': The room the message is from/to {{DevFeature}}<br />
* '''[whisper]'''<br />
** '''receiver''': The receiver of the whisper<br />
** '''sender''': (optional - filled by the server) The sender of the whisper.<br />
** '''message''': The message itself.<br />
<br />
== Nick registration related commands (lobby and in-game) ==<br />
<br />
* '''[nickserv]'''<br />
** '''[register]'''<br />
*** '''password''': The password for the nick.<br />
*** '''mail''': The email address for the nick.<br />
** '''[drop]''': Drop this username.<br />
** '''[set]''': Set a detail (e.g. email address) for this nick.<br />
*** '''detail''': The detail, e.g. "mail".<br />
*** '''value''': The new value for this detail, e.g. "user@edomain"<br />
** '''[info]''': Request info about another username.<br />
*** '''name''': The username.<br />
<br />
== Updating the lobby state ==<br />
<br />
* '''[gamelist_diff]''': server message - basically a diff from two [gamelist]s; the keys listed are the ones that actually occure in practice<br />
** '''index''': The index of a user.<br />
** '''[insert_child]''' A new user logged on.<br />
*** '''[user]'''<br />
**** '''name''': The name of the user.<br />
**** '''available''' "yes"<br />
*** '''[delete_child]''' A user logged off.<br />
** '''[change_child]'''<br />
*** '''[user]'''<br />
**** '''[insert]''': A user joined/left a game.<br />
***** '''available''': "yes" when the user left a game. "no" when the user joined a game<br />
***** '''location''': The name of the game the user joined.<br />
**** '''[delete]'''<br />
***** '''location''': "x" when a game was left.<br />
*** '''[gamelist]'''<br />
**** '''index''': Index of the game in question.<br />
**** '''[insert_child]''': A game started.<br />
***** '''[game]''' All the usual keys of [game] possible, see above.<br />
**** '''[delete_child]''': A game ended.<br />
***** '''[game]'''<br />
**** '''[change_child]''': Something changed in a game.<br />
***** '''[game]'''<br />
****** '''[insert]'''<br />
******* '''slots''': The number of free slots in the form: free/max slots<br />
******* '''turn''': The turn number in the form: current turn/max turns<br />
****** '''[delete]'''<br />
******* '''map''': "x" comes with every ''turn'' or ''slots'' change for games with shroud<br />
******* '''mp_scenario''': "x" comes with ''turn'' and ''slots'' changes for games with no scenario id<br />
<br />
* '''[observer]''' or '''[observer_quit]''': server message - players joining([observer_quit] - quitting the lobby "game")/quitting([observer] - joining the lobby "game") a game<br />
** '''name''': Username of the player/observer.<br />
<br />
== Game setup (the phase from creation to start) ==<br />
To create a game the client sends:<br />
* '''[create_game]'''<br />
** '''name''': The title of the game.<br />
<br />
followed by a message with the scenario options as under [game] (see above) plus the scenario data ([time], [era], [side], etc. see [[ScenarioWML]])<br />
<br />
* '''[join]'''<br />
** '''id''': The id of the game.<br />
** '''observe''': Join the game as an observer.<br />
<br />
* '''[scenario_diff]''': [[ScenarioWML]] diff (side changes, etc.)<br />
<br />
* '''[start_game]''': sent by the host to start a game<br />
* '''[leave_game]''': sent by the client when it leaves a game; sent by the server to make a client leave a game<br />
<br />
== In-game communication ==<br />
<br />
* '''[store_next_scenario]''': sent by the host - the scenario data (see [[ScenarioWML]]) to advance to the next scenario<br />
* '''[notify_next_scenario]''': sent by the server to tell players that the data for the next scenario is available<br />
* '''[load_next_scenario]''': sent by the client to request the data for the next scenario<br />
* '''[next_scenario]''': data for the next scenario (see [[ScenarioWML]]), sent by the server on request<br />
<br />
* '''[info]''': sent by the host on game end - info about the game state<br />
** '''type''': "termination" <br />
** '''condition''': the termination reason<br />
<br />
* '''[change_controller]''': a player (un)droids one of his sides or assigns control to someone else (The host can assign control for any side.)<br />
** '''side''': the side to change controller<br />
** '''player''': the nick of the player to take control<br />
** '''controller''': the new controller: "human" or "human_ai"<br />
** '''own_side''': "yes"<br />
<br />
If a player leaves this is sent to the host for all sides he owned.<br />
* '''side_drop''': The number of a side that dropped because a player left.<br />
* '''controller''': The controller of that side. ("ai", "network")<br />
<br />
* '''[muteall]''': the host mutes/unmutes all observers - toggles<br />
* '''[mute]''': the host mutes an observer - toggles<br />
** '''username''': the username of the observer - if not specified the servers returns a list of muted usernames<br />
* '''[kick]''' or '''[ban]''': the host kicks/bans a player/observer<br />
** '''username''': the username of the player/observer<br />
<br />
* '''[turn]'''<br />
** '''[command]''': (repeated) can contain all the tags you can find in a replay: [recruit], [move], [end_turn], etc.<br />
*** '''[speak]'''<br />
**** '''message''': text of the message<br />
**** '''id''': the sender<br />
**** '''team_name''': the name of the team the message is for - empty if it's a public message<br />
<br />
== Administrative commands ==<br />
* '''[query]'''<br />
** '''type''': The type of query. See [[ServerAdministration]] for details.<br />
<br />
[[Category:WML Reference]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=30792MP Server Ilor2009-06-25T07:41:20Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| delayed<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| 80%<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages.<br />
| 10%<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 70%<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| 40%<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 1%<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| none<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| none<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| none<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| none<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| none<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=30782MP Server Ilor2009-06-23T19:52:06Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| done (by others)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| done<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| delayed<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| 80%<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| n/a<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages.<br />
| 10%<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 50%<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| 10%<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 1%<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| none<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| none<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| none<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| none<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| none<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=30571MP Server Ilor2009-05-21T14:38:33Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| Write the minimap widget (unless someone beats me to it [1]) 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)<br />
| 50% due to [1]<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 75%<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| 30%<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| none<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages.<br />
| none<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| none<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| none<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| none<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| none<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| none<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| none<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=30567MP Server Ilor2009-05-19T09:02:30Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 60%<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| 30%<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| none<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages.<br />
| none<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| none<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| none<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| none<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| none<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| none<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| none<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=30553MP Server Ilor2009-05-18T17:36:11Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| 30%<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| 30%<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| none<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages.<br />
| none<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| none<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| none<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| none<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| none<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| none<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| none<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=30222MP Server Ilor2009-04-21T20:02:56Z<p>Ilor: added progress column to timeline</p>
<hr />
<div>'''Updated''' on April 21st -- the project was accepted into GSoC 2009<br />
<br />
'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
! <small>PROGRESS</small><br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
| none<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
| none<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages.<br />
| none<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
| none<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
| none<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
| none<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
| none<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
| none<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
| none<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
| none<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
| none<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
| none<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
| none<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
| none<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
| none<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
| none<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
| none<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
| none<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=29934MP Server Ilor2009-04-05T18:23:48Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
|-<br />
| -<br />
| <b>0th milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Would be nice, but not required, to have the above done when the program starts (May 26)<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
|-<br />
| 8<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| 9<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
|-<br />
| 10<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
|-<br />
| -<br />
| <b>2nd milestone (midterm)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
|-<br />
| 11<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
|-<br />
| 12<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
|-<br />
| 16<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
|-<br />
| 17<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| 18<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=29933MP Server Ilor2009-04-05T17:51:34Z<p>Ilor: /* Goals */</p>
<hr />
<div>'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 28, with the exception of the lobby gui which might be non-functional yet.<br />
|-<br />
| 8<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| 9<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| 10<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
|-<br />
| 11<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
|-<br />
| -<br />
| <b>2nd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
|-<br />
| 12<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
|-<br />
| 13<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
|-<br />
| 16<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| 17<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=29932MP Server Ilor2009-04-05T17:48:42Z<p>Ilor: /* Milestones */</p>
<hr />
<div>'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
====Goals====<br />
{| border="1"<br />
! ID<br />
! NAME<br />
! PRIORITY<br />
! RESULT<br />
|-<br />
| 0<br />
| Missing gui2 widgets<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
|-<br />
| 1<br />
| Initial wesnothd refactor<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| 2<br />
| Gui2 tooltips<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
|-<br />
| 3<br />
| Understand the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Figure out how the chat and games work now. Optionally this could result in writing some documentation.<br />
|-<br />
| 4<br />
| Update to the MP protocol<br />
| <p style="color:red">MANDATORY</p><br />
| Document how the room system will be reflected in client-server messages.<br />
|-<br />
| 5<br />
| Server-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| 6<br />
| Client-side rooms<br />
| <p style="color:red">MANDATORY</p><br />
| Write a crude, possibly not very functional and heavy /command-based interface for rooms in the game client. Test the server implementation.<br />
|-<br />
| 7<br />
| Simple gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| -<br />
| <b>1st milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by June 26, with the exception of the lobby gui which might be non-functional yet.<br />
|-<br />
| 8<br />
| Server RNG prototype<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| 9<br />
| Proper rooms in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| 10<br />
| Proper game list in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| Write the new game list as outlined in the proposal, with emphasis on being more space-efficient. No filters here.<br />
|-<br />
| 11<br />
| Game list filters<br />
| <p style="color:red">MANDATORY</p><br />
| Decide in the interface and implement some simple filters (text matching, free slots, with friends) for the new game list<br />
|-<br />
| -<br />
| <b>2nd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 12.<br />
|-<br />
| 12<br />
| Advanced game list filters<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
|-<br />
| 13<br />
| Tab interface for whispers<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write the tab interface for private messages<br />
|-<br />
| 13<br />
| Proper userlist in gui2 lobby<br />
| <p style="color:red">MANDATORY</p><br />
| 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)<br />
|-<br />
| 14<br />
| Advanced userlist<br />
| <p style="color:blue">OPTIONAL</p><br />
| 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.<br />
|-<br />
| 15<br />
| Lobby mode switching<br />
| <p style="color:blue">OPTIONAL</p><br />
| Implement the swicthing between "more games, less chat" and "less games, more chat" idea.<br />
|-<br />
| -<br />
| <b>3rd milestone</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the above done by July 26. There are a lot of "optional" features there -- at least one of those should be finished.<br />
|-<br />
| 16<br />
| Simple wesnoth-less moderation<br />
| <p style="color:red">MANDATORY</p><br />
| 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.<br />
|-<br />
| 17<br />
| Advanced wesnoth-less moderation<br />
| <p style="color:blue">OPTIONAL</p><br />
| Write a proper bot or bot-like feature that will recognize moderators on IRC and allow them to moderate easily.<br />
|-<br />
| 19<br />
| Full server RNG<br />
| <p style="color:blue">OPTIONAL</p><br />
| If the prototype is successful, wire all random numbers to use it, make it robust.<br />
|-<br />
| 20<br />
| General polishing<br />
| <p style="color:red">MANDATORY</p><br />
| Touch up various areas of the code, especially make sure the gui behaves nicely.<br />
|-<br />
| -<br />
| <b>4th milestone (final)</b><br />
| <p style="color:green">MILESTONE</p><br />
| Have the project in a working and polished state by August 15.<br />
|}<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=29914MP Server Ilor2009-04-05T11:48:18Z<p>Ilor: /* Server-side RNG */</p>
<hr />
<div>'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=29907MP Server Ilor2009-04-05T00:16:15Z<p>Ilor: /* Milestones */</p>
<hr />
<div>'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
The WML side of this is a bit tricky, it might be required to add another method of RNG generaation 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 (crucial) 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.<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. <br />
====Decisions====<br />
As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=29906MP Server Ilor2009-04-05T00:15:43Z<p>Ilor: </p>
<hr />
<div>'''Updated''' on April 5th or 4th depending on your timezone (around midnight GMT) with <br />
* info about what my opinion on the design considerations is<br />
* server-side RNG info<br />
* updated timeline<br />
==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
===Wesnoth===<br />
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. <br />
<br />
===General===<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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.<br />
<br />
==== Server-side RNG ==== <br />
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.<br />
<br />
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. <br />
<br />
The WML side of this is a bit tricky, it might be required to add another method of RNG generaation 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 (crucial) 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.<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
====Server-side RNG====<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
==== Server-side RNG ====<br />
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.<br />
===Milestones===<br />
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. As for the design decisions, my take is:<br />
<br />
* Ranking is out, as a conscious design choice that I understand and kind of agree with.<br />
<br />
* 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.<br />
<br />
* 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*)<br />
<br />
* 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.<br />
<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Server-side RNG<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* July 5 have a prototype of the server-side RNG done, test how it works<br />
* 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.<br />
* 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.<br />
* August 3 - have the server-side RNG working (if it's decided worthy of more work after the prototype<br />
* August 15 (before final evaluations) - have a polished new lobby plus the game-less moderation feature.<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=29863MP Server Ilor2009-04-03T22:03:12Z<p>Ilor: </p>
<hr />
<div>==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
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. <br />
<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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. Ditto for a surrender feature (as opposed to quit), which is possibly complicated and not really in the scope of the project.<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
===Milestones===<br />
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.<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* 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).<br />
* 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.<br />
* August 15 (before final evaluations) - have a polished new lobby plus the moderation feature.<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
==Info added on April 3rd==<br />
The main uncertain points about the project as of now are:<br />
* rooms. 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.<br />
<br />
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*)<br />
<br />
* 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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=29851MP Server Ilor2009-04-03T21:52:42Z<p>Ilor: /* Options are not necessarily bad */</p>
<hr />
<div>==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
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. <br />
<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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. Ditto for a surrender feature (as opposed to quit), which is possibly complicated and not really in the scope of the project.<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
<br />
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.<br />
<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
===Milestones===<br />
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.<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* 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).<br />
* 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.<br />
* August 15 (before final evaluations) - have a polished new lobby plus the moderation feature.<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=29512MP Server Ilor2009-03-31T21:48:38Z<p>Ilor: </p>
<hr />
<div>==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
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. <br />
<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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. Ditto for a surrender feature (as opposed to quit), which is possibly complicated and not really in the scope of the project.<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
===Milestones===<br />
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.<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* 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).<br />
* 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.<br />
* August 15 (before final evaluations) - have a polished new lobby plus the moderation feature.<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=29510MP Server Ilor2009-03-31T21:41:27Z<p>Ilor: </p>
<hr />
<div>==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
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. <br />
<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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. Ditto for a surrender feature (as opposed to quit), which is possibly complicated and not really in the scope of the project.<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
===Milestones===<br />
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.<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* 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).<br />
* 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.<br />
* August 15 (before final evaluations) - have a polished new lobby plus the moderation feature.<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=29509MP Server Ilor2009-03-31T21:40:23Z<p>Ilor: </p>
<hr />
<div>==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
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. <br />
<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
==== Ranking ====<br />
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. Ditto for a surrender feature (as opposed to quit), which is possibly complicated and not really in the scope of the project.<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
===Milestones===<br />
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.<br />
====Feature short list====<br />
# A gui2 lobby<br />
## New gamelist<br />
## New userlist<br />
## "More chat" and "more games" modes<br />
## Private messages tabs<br />
# Game filters<br />
# Configurable room system<br />
# Some method of wesnoth-less moderation<br />
====Things to do before the program starts====<br />
* preliminary wesnothd refactoring (e.g. split lobby and game classes)<br />
* writing missing gui2 widgets (minimap, tabs)<br />
* <del>investigate</del> bug Mordante about gui2 tooltips<br />
* understand the current client-server protocol<br />
====Timeline====<br />
* May 26 (official program start) - have most of the initial stuff above done<br />
* 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<br />
* 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).<br />
* 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.<br />
* August 15 (before final evaluations) - have a polished new lobby plus the moderation feature.<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=29434MP Server Ilor2009-03-30T19:09:41Z<p>Ilor: /* Concept sketch */</p>
<hr />
<div>==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
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. <br />
<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
I can code better than I can sketch, but anyway: [http://img216.imageshack.us/img216/7122/sk1.png]<br />
<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
===Milestones===<br />
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:<br />
* preliminary wesnothd refactoring<br />
* writing missing gui2 widgets<br />
* (optionally) gui2 tooltips<br />
* game filtering (I think there aren't many doubts about that feature)<br />
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:<br />
* May 26 (official program start) - have informally discussed issues with devs, mp mods, players<br />
* June 26 - have the possible approaches summarised and start the decision process<br />
* 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.<br />
* August 1 - have a crude working new lobby<br />
* August 15 (before final evaluations) - have a polished new lobby<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=29393MP Server Ilor2009-03-29T16:03:30Z<p>Ilor: </p>
<hr />
<div>==About me==<br />
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 <br />
<br />
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.<br />
<br />
==Experience==<br />
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. <br />
<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
<br />
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.<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
Todo; will be here soon.<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== More chat space ====<br />
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.<br />
==== Private chat tab ====<br />
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.<br />
==== Player list improvements ====<br />
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.<br />
===Milestones===<br />
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:<br />
* preliminary wesnothd refactoring<br />
* writing missing gui2 widgets<br />
* (optionally) gui2 tooltips<br />
* game filtering (I think there aren't many doubts about that feature)<br />
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:<br />
* May 26 (official program start) - have informally discussed issues with devs, mp mods, players<br />
* June 26 - have the possible approaches summarised and start the decision process<br />
* 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.<br />
* August 1 - have a crude working new lobby<br />
* August 15 (before final evaluations) - have a polished new lobby<br />
<br />
==Practical considerations==<br />
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. <br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=SummerOfCodeIdeas&diff=29392SummerOfCodeIdeas2009-03-29T15:57:30Z<p>Ilor: /* Extending the Multiplayer server */</p>
<hr />
<div>This is a compilation of ideas from ML. Needs to be refined (more detailed description, deliverables, workload estimation?):<br />
<br />
== I want to be one of your Google Summer of Code students, what should I do... ==<br />
<br />
Here is a quick list of things to do to get you started<br />
* Create an account on gna.org<br />
* Create an account on the wesnoth forum, and tell an admin on the IRC channel to mark is as a GSoC Student account (Admins are boucman, Ivanovic, mordante, Shadow_Master, Sirp and Turuk)<br />
* Join the irc channel (#wesnoth-dev on irc.freenode.net) and introduce yourself. We will not give formal interviews, but we will clearly favor people we have learned to know during the selection process (basically communication via IRC is mandatory for our project! it is the main way of "every day communication" for Wesnoth. For the same reason, it's also a good idea to regularly read the [http://wesnoth.debian.net/?C=M;O=A IRC logs].).<br />
<br />
* Start a wiki page about your idea, add a link on the bottom of this page and add this information on it:<br />
** List your account names (gna, forum, irc nick) so that we can recognize you<br />
** Fill the questionnaire on this page: [[SoC_Information_for_Google#Does_your_organization_have_an_application_template_you_would_like_to_see_students_use.3F_If_so.2C_please_provide_it_now.| List of questions to answer]]<br />
** Detail your idea as much as possible, look at other students pages, and please give milestones and studies you've done<br />
** Add a link to the page at the bottom of this page<br />
<br />
* Though not mandatory, it is highly advisable to go to the [[EasyCoding]] and [[NotSoEasyCoding]] pages and implement one of these ideas (or any idea of similar scope) so we have an idea how you work. Be sure to use your gna account when submitting these patches so we know who it is coming from. You can also implement some features from our feature request database at gna. When you implement something, also list it on your own page with a reference to the patch.<br />
<br />
* For working on Wesnoth you have to be able to compile trunk. To do so you should have a look at the [[WesnothSVN|page about svn]] and afterwards [[CompilingWesnoth|compile Wesnoth svn]].<br />
<br />
* Once you have everything done here and think your idea is okay, go to [http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants page at google] to submit your application. You have to submit it before '''Date to be supplied later''' or you have no chance to get in!<br />
<br />
== List of Ideas for the Project (Suggestions from the wesnoth developers) ==<br />
<br />
Here is only a short description of possible Ideas we have, each has a page of its own with a more detailed version on it.<br />
<br />
=== Optimize implementation of WML for memory usage ===<br />
<br />
Based on this idea: [http://dave.wesnoth.org/?p=9] optimize WML to minimize its memory usage. High memory usage has been a problem for Wesnoth, and this project will aim to reduce it.<br />
<br />
=== Implement campaign statistics reports on stats.wesnoth.org ===<br />
<br />
Wesnoth has an infrastructure which records details of campaigns that players play into a centralized MySQL database. However, we only have rudimentary reports based on this MySQL database available at this time, at [http://stats.wesnoth.org].<br />
<br />
This project would involve writing a stats reporting web site which would take the data from the MySQL database and produce reports in chart and table form. Campaign designers would be able to use these reports to gather feedback on their campaigns and get ideas for improvements.<br />
<br />
A student could largely make their choice of infrastructure for creating the Website -- whether they prefer Python, Perl, Ruby, PHP, etc. This is a great opportunity for someone who doesn't want to dive into hardcore C++ to make a valuable contribution to Wesnoth.<br />
<br />
[[SoC Ideas Stats Server]] - Full Version of the idea, with detailed information<br />
<br />
=== Extending the Multiplayer server ===<br />
<br />
Our multiplayer community is generally strong and healthy, but we believe its growth is limited by some problems in the interface of the multiplayer lobby.<br />
<br />
[[SoC Ideas Multiplayer server]] - Full version of the idea, with detailed information<br />
<br />
=== Addon server ===<br />
Wesnoth has an addon server which offers users to upload user <br />
made content (UMC). This allows all other users of Wesnoth<br />
to easily download and install this content. The server was <br />
originally written for user-made campaigns but contains a lot<br />
more types of addons nowadays. Both the server side and the <br />
client side need to be improved.<br />
<br />
[[SoC Ideas Addon Server]] - Full version of the idea, with detailed information<br />
<br />
=== WML validation schemes ===<br />
Wesnoth uses WML as basic data structure. Over the years<br />
this language has evolved and got more complex. At the<br />
moment the WML is validated at runtime and in case of a<br />
problem the engine stops. With schemes these problems can<br />
be validated when loading the WML, making it easier to find<br />
problems before running into them.<br />
<br />
[[SoC Ideas Schemes]] - Full version of the idea, with detailed information<br />
<br />
=== Write a primitive library for Formula AI ===<br />
<br />
Wesnoth has always had a simple C++ based AI. David (our lead developer) has been working on a simple language to write AI in Wesnoth: [[FormulaAI]]<br />
<br />
The Wesnoth AI is used as an opponent in most campaigns, and as such is an important piece of code for the Wesnoth project. Unfortunately, because the skills required to understand and modify it are rather arcane, it is also one of the most neglected parts of the Wesnoth code. This is a place where a lot of research and useful work could be done. But keep in mind that [[WhyWritingAWesnothAIIsHard|writing an AI for Wesnoth is difficult]].<br />
<br />
Writing a whole AI is so complicated that we believe it can't be done in a single Summer of code. All proposals should keep that in mind and try to identify an interesting subset that would be workable in the limited time of a summer of code<br />
<br />
<br />
[[SoC Ideas FormulaAI]] - Full version of the idea, with detailed information<br />
<br />
=== Savegame reorganization ===<br />
The savegame formats of Wesnoth for single player campaigns<br />
and multiplayer differ from each other. And they are processed<br />
differently as well. Now there is an additional request coming<br />
up: Multiplayer campaigns. The task will be to unify the savegames<br />
for all types of scenarios in order to provide a maintainable code<br />
again.<br />
<br />
[[SoC Ideas Savegame]] - Full version of the idea, with detailed information<br />
<br />
<br />
=== Other possible ideas to be fleshed out ===<br />
A MapGenerator rewrite - better scalable for outdoor maps, plus the possibility to define areas (similar to the caverns in the cave generator) etc.<br />
<br />
=== Make your own ideas ===<br />
If you have your own idea the best thing is to join IRC wesnoth-dev at irc.freenode.net and discuss the idea with the developers there. If the developers think your idea is interesting and like the feature you can start to turn it into a full proposal. Once done discuss it again on IRC so the developers can accept your idea.<br />
<br />
== Information about our Project ==<br />
The information we provided google with about our project can be looked up at the site [[SoC Information for Google]].<br />
<br />
Also see the [[DeveloperResources]] link (from the [[Project]] page).<br />
<br />
== People to bug on IRC ==<br />
We have prepared a list of people with their "area of competence". This is to give you an idea on which areas those people can be of help for you. Of course you should always just ask in the IRC chan, but those are the most likely ones to answer questions in the respective area. And here is the list:<br />
<br />
[[SoC People to bug on IRC]]<br />
<br />
== GSoC Student pages ==<br />
<br />
Please add a link to your wiki page below<br />
<br />
==== AI ====<br />
<br />
[[SummerOfCodeProposal_Velory| Velory - SoC Proposal]]<br />
<br />
[[SummerOfCodeProposal_AI_Improvement_Crab| Crab - SoC Proposal - AI Improvement]]<br />
<br />
[[SummerOfCodeProposal_Sparksteel | Sparksteel - Improving the AI engine design]]<br />
<br />
==== Savegame reorganization ====<br />
<br />
[[SummerOfCodeProposal_Euschn | Euschn - Savegame reorganization]]<br />
<br />
[[SummerOfCodeProposal_lmg| lmg - Savegame reorganization]]<br />
<br />
[[SummerOfCodeProposal_grantwu| grantwu - Savegame reorganization]]<br />
<br />
==== Extending the Multiplayer server ====<br />
<br />
[[SummerOfCodeProposal_rubend | rubend - Extending the Multiplayer server]]<br />
<br />
[[SummerOfCodeProposal_IneQuation | IneQuation - Extending the Multiplayer server]]<br />
<br />
[[MP Server Ilor | Ilor - Extending the Multiplayer server]]<br />
<br />
==== Addon server ====<br />
<br />
[[SummerOfCodeProposal_Ryochan7| Ryochan7 - Addon server]]<br />
<br />
[[SummerOfCodeProposal_iyonius| iyonius - Addon server]]<br />
<br />
==== Optimize implementation of WML for memory usage ====<br />
<br />
[[SummerOfCodeProposal_res| res - Optimize implementation of WML for memory usage ]]<br />
<br />
[[SummerOfCodeProposal_jdmunro| jdmunro - Optimize implementation of WML for memory usage ]]<br />
<br />
==== WML validation schemes ====<br />
<br />
[[SummerOfCodeProposal_orian| orian - WML validation schemes ]]<br />
<br />
==== Implement campaign statistics reports on stats.wesnoth.org ====<br />
<br />
[[SummerOfCodeProposal_Elbin| Elbin - New campaign statistics page]]<br />
<br />
[[SummerOfCodeProposal_Munk| Munk - New campaign stats page]]<br />
<br />
[[SummerOfCodeProposal_carlestyle| carlestyle - New campaign stats page]]<br />
<br />
[[SummerOfCodeProposal_nerwa| NeRwa - New campaign stats page]]<br />
<br />
[[SummerOfCodeProposal_mrfinch| mrfinch - New Campaign Statistics Page]]<br />
<br />
[[SummerOfCodeProposal_corn| corn - New Campaign Statistics Page]]<br />
<br />
[[SummerOfCodeProposal_csaunders | csaunders - SoC Proposal - Stats Server]]<br />
<br />
[[Category:Summer of Code|*]]</div>Ilorhttps://wiki.wesnoth.org/index.php?title=MP_Server_Ilor&diff=29391MP Server Ilor2009-03-29T15:55:14Z<p>Ilor: </p>
<hr />
<div>==About me==<br />
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 <br />
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.<br />
<br />
==Experience==<br />
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. <br />
<br />
A few years back I wrote a (now defunct, but useful for a long time) helper utility for a browser based strategy game ([http://reddragon.pl]) 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 ([http://idarionis.com]). 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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
==Gaming==<br />
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.<br />
<br />
==Communication skills==<br />
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.<br />
<br />
==Project==<br />
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.<br />
===Design considerations===<br />
==== Lobby channels/rooms/filters ====<br />
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.<br />
==== Wesnoth-less wesnothd chat / moderation ====<br />
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.<br />
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.<br />
===Server-side details===<br />
====Maintenance work====<br />
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.<br />
====Options are not necessarily bad====<br />
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).<br />
===Client details===<br />
==== Redo the interface in gui2 ====<br />
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.<br />
==== Concept sketch ====<br />
Todo; will be here soon.<br />
==== More games shown at a time ====<br />
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.<br />
==== Powerful game filters ====<br />
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.<br />
==== Switchable mode for more chat space====<br />
A button to expand the chat window so more text fits, at the expense of the game list.<br />
==== Player list improvements ====<br />
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.<br />
===Milestones===<br />
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:<br />
* preliminary wesnothd refactoring<br />
* writing missing gui2 widgets<br />
* (optionally) gui2 tooltips<br />
* game filtering (I think there aren't many doubts about that feature)<br />
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:<br />
* May 26 (official program start) - have informally discussed issues with devs, mp mods, players<br />
* June 26 - have the possible approaches summarised and start the decision process<br />
* 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.<br />
* August 1 - have a crude working new lobby<br />
* August 15 (before final evaluations) - have a polished new lobby<br />
<br />
==Practical considerations==<br />
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. <br />
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.<br />
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.<br />
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.<br />
<br />
[[Category:Summer of Code]]</div>Ilor