Difference between revisions of "User:Elfy/SoC Questionnaire"

From The Battle for Wesnoth Wiki
(Description)
(Features)
 
(5 intermediate revisions by the same user not shown)
Line 4: Line 4:
 
= Basics =
 
= Basics =
 
== Introduction ==
 
== Introduction ==
My name is Protas Oleksiy. I come from Southern Ukraine, Crimea more precisely. At the present moment I am a biology student and freelance programmer. Speaking of global goals I set in my life I would like to find a cure for cancer and aging one day as well as help open and alternative software gain worldwide acknowledge and break the chains of stereotype and monopoly regarding software market. My hobbies include solving math problems, wrtiting poems, fishkeeping beadcrafting and more. I am not employed at the moment but I am occupying head software engineer position in our [http://usic.org.ua university student internet center] and also do computer work at the [http://imbg.org.ua biological lab].
+
My name is Protas Oleksiy. I come from Southern Ukraine, Crimea more precisely. At the present moment I am a biology student and freelance programmer. Speaking of global goals I set in my life I would like to find a cure for cancer and aging one day as well as help open and alternative software gain worldwide acknowledge and break the chains of stereotype and monopoly regarding software market. My hobbies include solving math problems, wrtiting poems, fishkeeping beadcrafting and more. I am not employed at the moment but I am occupying head software engineer position in our [http://usic.org.ua university student internet center] and also do some computer work at the [http://imbg.org.ua biological lab].
 
== Email ==
 
== Email ==
 
My main e-mail is: http://img217.imageshack.us/img217/5192/emailky4.png
 
My main e-mail is: http://img217.imageshack.us/img217/5192/emailky4.png
Line 28: Line 28:
 
I came up with the idea of project long before and I was just happy finding it in the list given by deleloppers. The project of my choice is '''Map/Scenario Editor'''.
 
I came up with the idea of project long before and I was just happy finding it in the list given by deleloppers. The project of my choice is '''Map/Scenario Editor'''.
 
== Reasoning ==
 
== Reasoning ==
I've chosen the project because scripted map-editing is my passion in all strategy games I come across. Also having a userfriendly scenario editor greatly speeds up the mapmaking process as stated in an interview with Blizzard employee speaking of difficulties making maps for '''Warcraft I''' (TODO: link here). MORE HERE
+
I've chosen the project because scripted map-editing is my passion in all strategy games I come across. Also having a userfriendly scenario editor greatly speeds up the mapmaking process as stated in an interview with Blizzard employee speaking of difficulties making maps for '''Warcraft I''' (TODO: link here).
 +
 
 
== Timeline ==
 
== Timeline ==
TODO
+
The timeline estimation for the project is following. Basically the project consists of two parts loosely connected with each other: '''WML editor''' and '''Terrain Editor'''. Though they will form a unite application by the end of development they need distinct methods employed in order to be written.
 +
=== Phase 1: WML generator ===
 +
This will be the very base of the project. The goal is to provide simple GUI application capable of creating all common WML structures via a graphical interaction and export them as WML files.
 +
'''Time estimation''': End of may
 +
=== Phase 2: WML importer ===
 +
The second step is allowing WML import. By this point it will just load the script into internal editor structures and then let edit it and generate the output. At this phase the editor is going to be '''WML-destructive'''.
 +
'''Time estimation''': End of june
 +
=== Phase 3: Markup keeper ===
 +
At this phase the internal representation of WML is going to be sharpened, allowing the formatting of input to be saved. Also as an optional feature, program will try to guess the author's style and stylize its generated output.
 +
'''Time estimation''': Middle of july
 +
=== Phase 4: Map editor ===
 +
This phase involves rewritting terrain&unit rendering code to use with Arthur, Qt4's rendering engine. Also paining tools will be implemented and map loading/editing allowed. The code then is going to be merged with WML editor. Easiest part, ever ;-)
 +
'''Time estimation''': End of july
 +
=== Phase 5: Map editor features ===
 +
The most pushed part contains more optional features that are not very critical to implement and also are relatively easy to do. At this phase advanced terrain editor features such as vector shape rasterization and symmetry generator are going to be impemented. If vector technique proves to be usefull --- a separate format for saving unrasterized vector shapes is going to be made.
 +
'''Time estimation''': End of august
 +
 
 +
Note: this is a SoC-only timeline and will be expanded as soon as SoC goals are accomplished.
 +
 
 
== Description ==
 
== Description ==
 
The project I've chosen is the rewrite of wesnoth map editor.  
 
The project I've chosen is the rewrite of wesnoth map editor.  
Line 58: Line 77:
 
In short - most designers do not care of individual hexagons(however this is a matter of faction balance) but tend imagine the general overview of the things they are about to draw. Adding such functionality will allow them to quickly generate the thing that is on mind needing only some retouch after the generation.  
 
In short - most designers do not care of individual hexagons(however this is a matter of faction balance) but tend imagine the general overview of the things they are about to draw. Adding such functionality will allow them to quickly generate the thing that is on mind needing only some retouch after the generation.  
  
As to details IMHO Beziers curves are ideal to fill the role of a tool for defining areas as they provide intuitive and easy to code 'drag-n-bend' feature which most computer users are very familliar with.  
+
As to details IMHO Beziers curves are ideal to fill the role of a tool for defining areas as they provide intuitive and easy to code 'drag-n-bend' feature which most computer users are very familliar with.
 +
==== Non-destructive WML editor ====
 +
Last but not the least, the feature which was immediately pointed to by developpers on IRC to anyone willing to write GUI WML editor --- editor must not be destructive existing handwritten files it edits. In other words it must modify a spot in a file but not regenerate it from the scratch. This concerns keeping comments, author's style to identication, paragraph separation, choice of equivalent structures, macros etc.
 +
 
 +
The whole thing reminds of the traditional argue over HTML editors and is in many ways similar, because of visual likeness of WML to XML. Some editors import the code and regenerate using their own algorithms. The most well know example: '''Microsoft Word''' enlarging the page ten fold when the page is just opened in it and saved to another file. One can speculate that any of editor capable of generating human-readable script is script-destructive. However the guess is false as there are HTML editors capable of keeping author's style. The famous '''Dreamweaver''':
 +
 
 +
http://www.alanwood.net/unicode/dreamweaver.gif
 +
 
 +
Dreamweaver was in many ways a compomise between a notepad and fully visual editor, because it allowed to preview the code one writes manually and to edit it visually previewing the code generated. So the program gained popularity among novice web designers as well as among experts because of two way editing it provided. Also the code it generated was much cleaner than that of Word.
 +
 
 +
Wesnoth editor can have such a feature as well. Though it concerns more a scenario than a webpage, still its WML data can be represented graphically so that it can be visually edited and understood. So the editor will host a feature similar to dreamviewer capable --- the two way editing. Even if one dislikes visual editing and sticks to handwritten code the feature nevertheless will be usefull as it will provide a visually incorrect scheme if one makes a typo or mistake in the code.
 +
 
 
=== Technology ===
 
=== Technology ===
 
==== GUI toolkit ====
 
==== GUI toolkit ====
This is the point to discuss with the developpers so I am presenting this in a form of pro-contras
+
The editor will use Qt4 library for UI operations. Advantages:
===== Native Wesnoth UI =====
+
* Arthur engine provides fast and efficient drawing capabilities.
Pro:
+
* Qt allows a complex nonmodal dialog structure to be rapidly developped.
* Gives an original '''Look-n-Feel''' of the game.
+
* No need to code specialized widgets.
* Can be easily embedded into the main executable.
+
The Qt4 is present in virtually every Linux distribution. As to Windows binary release - Qt dlls can be shipped within the package with ease providing seameless installation for end-user.
Contra:
+
 
* UI is not flexible enough. Some ideas (e.g. vectoral shape definition) would need extensive UI engine rewrite or at least a whole complex of things unsupported at the moment.
+
==== User Interface ====
* As I've read [[EasyCoding#GUI_related_features | here]] UI structure is about to be rewritten so it is rather a volatile ground to base the whole new project on.
+
The new editor will feature a vectoral 'select'-like tool including some subvariants similar to the '''Photoshop''' or '''Gimp''' selection mechanics while keeping them as most simple and trivial to use as possible. The selection then can be filled with terrain based on some predefined generation rules (akin to '''gradients''' in raster image editors but more demostrative to use) or cloned to achieve symmetrical formations.
===== External UI =====
+
 
Pro:
+
The other thing new is a unit and trigger editor allowing dialog-driven customization of units and map script. The unit editor will be a '''property-value''' scheme based editor in a way like '''Delphi-style''' property editor used in countless visual GUI design IDE's.
* Will save time designing specialized widgets which are absent in Wesnoth UI.
+
 
* Will keep Wesnoth UI codebase clean of things that are solely used in editor.
+
The trigger editor will feature tools to create map triggers as well as adjust AI behaviour. In short it will allow to design all the ''dynamic'' map properties while unit editor is more to work with ''static'' ones. As stated above the core element will be a '''gap-filling''' control to compose a logical human-readable sentence. Parameters will be picked from lists or the map itself. For instance to indicate which unit is to be affected one could just click it on the map as opposed to assigning identifiers and writing textual names('f course if the unit is present on the initial map layout).  
Contra:
+
==== WML import/export ====
* Can't be trully embedded into the main game program.
+
Also a must-have feature for the editor is the ability to ''modularize'' the map. In other words the user will be given a way to export some units/scripts he created as separate WML files for use in other maps. This will allow a GUI-driven editor to benefit from textual nature of the WML script freeing the user from any repeated actions while maintaining a user-friendly GUI interface.  
* Will have very different visual style.
+
==== Non-map based WML ====
 +
Also the editor will be capable of generic WML generation such as graphical design of themes, units etc. without any map open.
  
 
== Gains ==
 
== Gains ==

Latest revision as of 11:24, 12 April 2008


This page has Google Summer of Code proposal questionnaire filled by Elfy 13:24, 29 March 2008 (EDT)

Basics

Introduction

My name is Protas Oleksiy. I come from Southern Ukraine, Crimea more precisely. At the present moment I am a biology student and freelance programmer. Speaking of global goals I set in my life I would like to find a cure for cancer and aging one day as well as help open and alternative software gain worldwide acknowledge and break the chains of stereotype and monopoly regarding software market. My hobbies include solving math problems, wrtiting poems, fishkeeping beadcrafting and more. I am not employed at the moment but I am occupying head software engineer position in our university student internet center and also do some computer work at the biological lab.

Email

My main e-mail is: emailky4.png

Nickname

My nick is elfy almost everywhere however on Freenode it's been already taken when I first connected to it so I often use JarisSeagull instead. Things like Elf-Eluna-Alina, Jaris and Chantale can probably represent my identity on other resources.

Summer o' Code

I decided to take part in summer of code because I've long heard about the project and it allows you to code for an opensource project while having a stipenid which is not a last concern for a student ;-) Moreover it's a good stimuli to finally joing opensource programmer community.

Study

I study at National University "Kievo-Mohylanska Akademia" majoring in biology and attending extra courses of math, physics, chemistry and computer science. I am currently freshman because of reenrolling on biology from physics department.

Experience

Programming

At the very beginning of my career I've written program for Lesser Academy of Sciences contests which is an annual contest for scholars in different fields of science including computing. I've made four attempts with a graphical editor(...in pascal ;-) ), a distributed database, a security program and finally an infusoria shape reconstructor from a photograph. Later on I've been writing small programs to use on my own. I've wanted to write a real time strategy for ages, I even began doing 2 or 3 engines but all the projects failed due to lack of artists. However from this immature games the simple fully functional 3D model editor and the OpenGL GUI library were left. Now I basically stick to website writing(which I dislike :( ) and freelance programming for profit. I am eager to engage to a big project such as Wesnoth and that's one point for applying to GSoC.

Teamwork

I've found a small team for freelance writing and I've faced the challenges teamwork offers to a developper. We've done a lot of programs together so I am getting more and more used to program in a team as opposed to being a 'lone wolf'.

Summer o' Code

I've never participated in Summer of Code before. Neither have I ever applied.

Open Source

Though I use open source solutions for 5 years now I've never participated in an opensource project unfortunately. Though I've taken part in coding based on opensource involving program alteration for iternal tools of the internet center I work in.

Gaming

Well, I can't consider myself truly a gamer but I've always been fond of computer games. I prefer fantasy strategies and roleplaying, puzzle, stealth action games. My top-list of games includes: all warcrafts, thief, doom. Speaking of type I am more hacker than a gamer - I always seek to exploit the game, carry on experiments with engine and so on. Most of the times just for fun as oposed to find cheat-like exploits. Also the story and multiplayer is critical for the game to please me. I often dig hard into a storyline and analyze the game atmosphere, live in it. I've discovered Wesnoth roughly a year and a half ago while browsing portage and immediately fell in love with it. I mostly lean towards multiplayer but not just a meelee scirmish but a more scripted and fun action.

Project

Selection

I came up with the idea of project long before and I was just happy finding it in the list given by deleloppers. The project of my choice is Map/Scenario Editor.

Reasoning

I've chosen the project because scripted map-editing is my passion in all strategy games I come across. Also having a userfriendly scenario editor greatly speeds up the mapmaking process as stated in an interview with Blizzard employee speaking of difficulties making maps for Warcraft I (TODO: link here).

Timeline

The timeline estimation for the project is following. Basically the project consists of two parts loosely connected with each other: WML editor and Terrain Editor. Though they will form a unite application by the end of development they need distinct methods employed in order to be written.

Phase 1: WML generator

This will be the very base of the project. The goal is to provide simple GUI application capable of creating all common WML structures via a graphical interaction and export them as WML files. Time estimation: End of may

Phase 2: WML importer

The second step is allowing WML import. By this point it will just load the script into internal editor structures and then let edit it and generate the output. At this phase the editor is going to be WML-destructive. Time estimation: End of june

Phase 3: Markup keeper

At this phase the internal representation of WML is going to be sharpened, allowing the formatting of input to be saved. Also as an optional feature, program will try to guess the author's style and stylize its generated output. Time estimation: Middle of july

Phase 4: Map editor

This phase involves rewritting terrain&unit rendering code to use with Arthur, Qt4's rendering engine. Also paining tools will be implemented and map loading/editing allowed. The code then is going to be merged with WML editor. Easiest part, ever ;-) Time estimation: End of july

Phase 5: Map editor features

The most pushed part contains more optional features that are not very critical to implement and also are relatively easy to do. At this phase advanced terrain editor features such as vector shape rasterization and symmetry generator are going to be impemented. If vector technique proves to be usefull --- a separate format for saving unrasterized vector shapes is going to be made. Time estimation: End of august

Note: this is a SoC-only timeline and will be expanded as soon as SoC goals are accomplished.

Description

The project I've chosen is the rewrite of wesnoth map editor.

Features

Easy to use dialog-driven system to write WML

Since WML controls every aspect of the game it should be given for a user to manipulate in a transparent manner. The IMHO perfect example of such mechanic is Warcraft III Map Editor(WorldEdit). The users uses a graphical tool to write scenarios and customize units, spells etc. This data is then converted into a JASS script which acts like WML. However the WorldEdit is not that much flexible the Wesnoth editor will be because JASS is more a programming language and not all JASS expressions can be loaded into the Editor. Moreover Blizzard did leave some perks available only to hackers for usage. In the Wesnoth case WML can be easily represented in a graphical way, due to it's structure.

While units are trivial to implement map triggers do cause a bit of challenge in the way of displaying data. Here again my proposal is not to reinvent the wheel and use the time proven Blizzard scheme as displayed on this StarEdit screenshot:

screnshotkf4.png

The idea is to give the user a tool to create triggers using event-conditions-actions combo, basically as it is done in map script. For each 'class' of event, condition and action there is a textual template with gaps for user to fill. Filling the gaps involves extensive use of lists, comboboxes etc. to free the user of any writing at all.

Symmetry generator

Symmetry is a critical point when designing melee maps. While some asymmetrical melee maps are known to exist in most strategies they are considered the state of art and are very fragile in terms of modification without breaking balance. A famous example - contest-winning (2)Two Rivers for WCIII:

tworiverzof6.png

The idea is to let the user select a portion of map(probably radial) and let the editor clone it to generate a symmetrical map. The advantages of such technique are:

  • User is freed from calculating how the portion would look like if rotated. Though Wesnoth uses hexagonal map grid it is a real challenge for people not gifted enough artisticaly to imagine how a region would look like from the other point of view.
  • The user is also freed from routine work repeating basically the same thing he did. Also modifying a thing would need all the copies modified manually which is a potential source of mistakes and a mundane in first place.
  • It provides a editing layer in-between manual map editing and autogeneration taking benefits of both.

Vector-orieded shape editor

Last but not the least there is one more idea on autogeneration tools involved in mapmaking process. Though the idea is very rough and needs severe critics from developpers it's basic is to provide the users a tool to design a vector shape which is then 'rasterized' to hexagons according to the rasterization rules. This includes optional 'gradients' between different terrain types e.g. a line of hills for a transition from rocks to plains. The aims of the idea are:

  • Once again save the user from mundade and requiring tasks when drawing large portions of similar terrain.
  • Let the generator make the terrain more lifelike for example adding occasional forest tiles on plains etc.
  • Make transitions between different terrains more smooth, again freeing the designer from picking each tile by hand.

In short - most designers do not care of individual hexagons(however this is a matter of faction balance) but tend imagine the general overview of the things they are about to draw. Adding such functionality will allow them to quickly generate the thing that is on mind needing only some retouch after the generation.

As to details IMHO Beziers curves are ideal to fill the role of a tool for defining areas as they provide intuitive and easy to code 'drag-n-bend' feature which most computer users are very familliar with.

Non-destructive WML editor

Last but not the least, the feature which was immediately pointed to by developpers on IRC to anyone willing to write GUI WML editor --- editor must not be destructive existing handwritten files it edits. In other words it must modify a spot in a file but not regenerate it from the scratch. This concerns keeping comments, author's style to identication, paragraph separation, choice of equivalent structures, macros etc.

The whole thing reminds of the traditional argue over HTML editors and is in many ways similar, because of visual likeness of WML to XML. Some editors import the code and regenerate using their own algorithms. The most well know example: Microsoft Word enlarging the page ten fold when the page is just opened in it and saved to another file. One can speculate that any of editor capable of generating human-readable script is script-destructive. However the guess is false as there are HTML editors capable of keeping author's style. The famous Dreamweaver:

dreamweaver.gif

Dreamweaver was in many ways a compomise between a notepad and fully visual editor, because it allowed to preview the code one writes manually and to edit it visually previewing the code generated. So the program gained popularity among novice web designers as well as among experts because of two way editing it provided. Also the code it generated was much cleaner than that of Word.

Wesnoth editor can have such a feature as well. Though it concerns more a scenario than a webpage, still its WML data can be represented graphically so that it can be visually edited and understood. So the editor will host a feature similar to dreamviewer capable --- the two way editing. Even if one dislikes visual editing and sticks to handwritten code the feature nevertheless will be usefull as it will provide a visually incorrect scheme if one makes a typo or mistake in the code.

Technology

GUI toolkit

The editor will use Qt4 library for UI operations. Advantages:

  • Arthur engine provides fast and efficient drawing capabilities.
  • Qt allows a complex nonmodal dialog structure to be rapidly developped.
  • No need to code specialized widgets.

The Qt4 is present in virtually every Linux distribution. As to Windows binary release - Qt dlls can be shipped within the package with ease providing seameless installation for end-user.

User Interface

The new editor will feature a vectoral 'select'-like tool including some subvariants similar to the Photoshop or Gimp selection mechanics while keeping them as most simple and trivial to use as possible. The selection then can be filled with terrain based on some predefined generation rules (akin to gradients in raster image editors but more demostrative to use) or cloned to achieve symmetrical formations.

The other thing new is a unit and trigger editor allowing dialog-driven customization of units and map script. The unit editor will be a property-value scheme based editor in a way like Delphi-style property editor used in countless visual GUI design IDE's.

The trigger editor will feature tools to create map triggers as well as adjust AI behaviour. In short it will allow to design all the dynamic map properties while unit editor is more to work with static ones. As stated above the core element will be a gap-filling control to compose a logical human-readable sentence. Parameters will be picked from lists or the map itself. For instance to indicate which unit is to be affected one could just click it on the map as opposed to assigning identifiers and writing textual names('f course if the unit is present on the initial map layout).

WML import/export

Also a must-have feature for the editor is the ability to modularize the map. In other words the user will be given a way to export some units/scripts he created as separate WML files for use in other maps. This will allow a GUI-driven editor to benefit from textual nature of the WML script freeing the user from any repeated actions while maintaining a user-friendly GUI interface.

Non-map based WML

Also the editor will be capable of generic WML generation such as graphical design of themes, units etc. without any map open.

Gains

The first thing to gain from the project is to give birth to a brand-new scenario editor for wesnoth allowing the map base to grow more intensively. At least I would like also to use the thing after it is done ;-) The other thing to gain is the experience working on massive and opersource project which is on my point of view invaluable.

Wesnoth Community

I hope to ;-) Wesnoth is a great thing to code for.

Practical considerations

English

I consider my English level good enough to be able to communicate with other speakers. I've spent years reading English text because of programming a lot so I even have some little 'language sense' speaking of written English. I think the whole page can better present my skills in English than theese three sentences. ;-)

SVN/C++/Python

C++ along with plain C are my languages of preference so I dare to claim knowing them almost perfectly. I've been using C/C++ for roughly 7 years now. Subversion is the thing I've only discovered recently, but I think I've played enough with it to be able to use it as a confident user. Python is unfortunately Terra Incognita for me. However it is on the my 'to-learn' list on highest positions along with Perl.

Development tools

At present moment I mostly use Kate+GCC+GDB combo for development plus SVN+CMake for distributed projects. IDE's seem to complicated for me and moreover they do not provide enough freedom and flexibility generating lots of unneeded stuff. On the other hand when working on bigger projects I favour KDevelop for its usability and the option to cut down as much autogenerated code as possible. When using CMake my KDevelop basically transforms in a bigger Kate while I write all code by hand.

Languages

Programming

I can code confidently in:

  • C
  • C++
  • Pascal
  • PHP
  • BASH

More slowly and having an access to documentation:

  • JavaScript
  • BASIC/VBA
  • JASS (WCIII scripting language)

Spoken

I speak natively:

  • Russian
  • Ukrainian

Also I am proficient in:

  • English
  • French (it was my major in school but I am loosing grasp due to lack of practice now)
  • German (very elementary level mostly for understanding written text and not without a dictionary)

Timing

I am generally awake 6:00 AM - 11:00 PM UTC

Phone

I like phone calls but written communication with mentor is way better providing a logback and natural 'antinoise' and 'misunderstanding' protection :-)

Essay

TODO

This page was last edited on 12 April 2008, at 11:24.