IntuitiveScenarioEditor

Basics

Hello, you've found my SOC project proposal page. If you want to see the answers to the Wesnoth SOC student questionnaire they are here. This page is mostly a trimmed down version of that (some of it is exactly the same), with some additions to the project proposal section. If you want to know some little facts about me (such as some of my favorite NES games), or to read more in-depth answers, you'll have to go read the questionnaire. Feel free to contact me via email at cjhopman|ATTT|gmail.com

Anyway, my name is Chris Hopman-- I go by cjhopman on irc, forum, etc-- and I am in my third year of my undergraduate studies at the University of Wisconsin - Madison. I am majoring in Computer Science and Mathematics and will be graduating spring '09.

I want to participate in summer of code because it is basically a once in a lifetime opportunity. That is, it is a chance to become a much better programmer, a chance to gain experience working on a real project, a chance to be mentored by an experienced programmer, a chance to become a member of the development team of a great game, a chance to join the community of that great game, a chance to make something that improves that community and that game, a chance to spend a summer doing something I love, and on and on... I mean, it's just an amazing opportunity.

Open Source and Gaming

Sadly, I am not currently involved with any open source development projects. However, I have, for a while now, been interested in becoming involved, and my experience with the Wesnoth community in the past few weeks has lit that spark that I needed and I will continue to be involved in open source development, regardless of my involvement in Summer of Code.

Gaming experience
Well… I remember playing the first Mario Bros. on the NES when I was 5. At that same time I started playing computer games, oh were those ever fun. Ever since, I’ve been hooked. Since then, I’ve enjoyed all types of games, but primarily strategy games and role-playing games.

Do I prefer story or gameplay? That's tough, and it depends on the game. For example, the Civilization series all have basically no story, but I love the games. However, almost all RPGs that I enjoy are because of the story, not the gameplay.

What Project and Why

There were several projects that I was interested in – the scenario editor, the map editor, and the formulaAI projects. Of course AI would be fun, but I was interested in the editors as a chance to do a more user-centric project, and to design a GUI. And so, I was more interested in doing one of the editors. In the end I decided primarily on what I thought would be best for the Wesnoth community, the scenario editor. I also considered how much work could reasonably be done on each project in a summer, as I know that many students in past Summer of Code seasons have overscoped there projects and ended the summer with little to show. I think that having an intuitive and well done scenario editor will be a huge benefit to the community, especially if it is written so that it can be extended to be a full campaign editor, including map editing and such. This extension is not feasible to do over the course of the summer, but I absolutely do not plan to let that stop me from doing it afterwards.
There are so many great games that are great precisely because of the community generated content, and with the current high-barrier to entry in developing scenarios for Wesnoth, this just is not that feasible. Not only that, but Wesnoth itself is basically user-generated content, and it is only fitting to enable the community to more easily contribute.

What do you expect to gain from this project?
Primarily, I expect to become a better programmer. Courses I have taken at my university are great for learning the theory of programming, but I am just as interested in programming well, something that the classes do not teach. For this reason I have done much coding on my own, and often the projects for my classes go well beyond the scope of the assignment – simply because I enjoy programming. However, I am limited by the fact that I don’t know what I don’t know. I can study and read all I want, but the opportunity to work on a project like Wesnoth, with an experienced mentor is priceless.
To think that programming experience is all that I would gain from working on this project is so far from the truth. I will get to become a member of the Wesnoth developer community, to work on a large project with a large team, to spend a summer doing something that I love, to make an important contribution to a great game… I could go on and on.

One of the questions in the questionnaire was what would make me stay in the community after SOC is over. Well, I think a more relevant question is what could make me leave. To be honest, from my (albeit, short) experience with the Wesnoth community, I doubt that you guys will be able to get rid of me. Being a member of the Wesnoth community is such a great opportunity, the opportunity to learn to be a better programmer is primarily what brought me here, but there is much more that keeps me here, and even with the little bit of coding that I have done on the program, I already feel a bit of a responsibility to do more, a bit of an ownership and pride in the code.

Project Proposal

So I plan to write an intuitive scenario editor. In playing with campgen, I believe one of its major drawbacks was its difficulty to use. I will be writing this in C++ for various reasons, primarily because it will allow me to reuse existing, functional code. Also, as most of Wesnoth is done in C++ (as I understand it, almost everything) it just makes sense to not require more dependence on a different language.

As for technical details, I do not intend to reinvent the wheel: that is, I would like to reuse much of Wesnoth’s existing code, for map display, for WML loading and saving, for the GUI I believe that I will primarily use code that is currently being worked on. One major benefit of this (besides the fact that it doesn’t really make sense to rewrite existing functionality), is that the scenario editor will be consistent in look and feel with Wesnoth itself. This makes a huge difference in how professional it appears.

Now, as I have planned this project, it has two important parts: the GUI and the underlying WML system/generator. The plan is to have the underlying WML system to be basically independent of the GUI, and the GUI is precisely what it is meant to be, an interface to that system. This will allow for much better extensibility of the project, and the eventual goal is to have it become an all-in-one editor for campaigns.

A little more in-depth discussion...

Now, as a disclaimer, I will admit that I have not designed a scenario on my own, so I may say something that sounds dumb here... Well, that is precisely what the next couple weeks before coding begins are meant to clean up. So, please continue.

So, absolutely the most important thing about this is that it is easy to use. If it's not easy to use then there wouldn't really be much incentive to use it over just doing it by hand. However, without giveing the user access to the underlying WML it is unreasonable to expect the editor to by very powerful-- that is, there is to much power in WML to completely abstract away. Ideally this project will provide a very easy interface to do the most common things, that is it would make it very easy to make simple scenarios, and in fact should make it very easy to make even moderately more complex scenarios. Up to that stage it should not require any knowledge of WML. An example of a scenario that would be able to be created easily without knowledge of WML would be The Siege of Barag Gor in SotBE. In fact, you should be able to make something slightly more complicated than that.

To make it so that it is easy to do more advanced things with knowledge of WML, I plan to have a text box for most dialogs that shows the WML that would be generated for the relevant thing (i.e. Event, Unit, etc.) and allow the user to directly edit it in the editor. If the user edits something that the editor recognizes, it should update its own corresponding fields... i.e. if the user changes a location it should update where they would normally have the location. This text box would be optional, in that only people who want to see the underlying WML, need to. Ideally, the text box would also have syntax highlighting, but I don't know how realistic that is, it is something that I would discuss with the mentor, maybe integrating some other project into the editor...

The main part of the user interface would be a map of the scenario. It should be very obvious and very easy for the user to add the most common things to the map... that is units, villages, events(occuring at a particular location), etc. Selection of these items should bring up a dialog-- not so much a popup, think more like how when you select a unit in game it shows the information in the bar, but with a wider bar and with options on it-- that would then have the common options right there, for example a unit's name, traits, side, etc. As I hinted just now, I would like to not only reuse a lot of the existing display code (the map display code, etc...) I would also like to reuse the basic ui layout. Not only would these keep the project consistent with the main game, but it would also be easier for users to learn.

The importation of WML would be a very useful feature, at least the importation of WML that the editor recognizes -- and then the ability to save changes without breaking things that the editor doesn't recognize. Considering the fact that I intend to allow editing of the WML directly through the editor, I don't believe that this will be too difficult. Also, the existing code will provide a lot of the functionality needed to handle importation. The most difficult consideration will be importing things that the editor doesn't recognize, making various changes, and then saving without it breaking the WML, but this will not be an insurmountable challenge.

Exporting WML should be very easy with the design that I envision. Since we will already be basically generating WML for various things on the fly, it will be a matter of combining these together correctly, and a lot of what is needed for that is already present in the current Wesnoth code, I believe.

The final, and definitely not least part, of the project is documentation. Now, I intend for a user to be able to use the scenario editor with absolutely no need for external documentation. I believe that if presented correctly it will be intuitive enough how to build a scenario. However, even if I believe that what I build is very easy to figure out, that doesn't really mean much because I know exactly how the thing works. So, for the user, there should be helpful, but non-intrusive documentation in the editor, for example little tooltips that appear in the bottom right as you mouse over things. Also, it will be important to have a detailed online documentation and tutorial, likely walking a user through the creation of a scenario from start to finish.

Extensibility

The eventual goal of my project is to be basically an all-in-one campaign editor. That is it would be able to take you from designing units and maps to build entire campaigns. With this goal in mind from the outset, I will be making design decisions that allow for easily extending the functionality of the editor. In fact, since I see myself likely to be working on extending the project myself, I will be very careful to make that easy to do (then I get to look like a hero when I do it quickly and well).

Preliminary Timeline

March 26 Submit Application and build wiki page on www.wesnoth.org
March 26 – April 11 Continue minor coding tasks on wesnoth, mostly in areas dealing with WML to get an intimate knowledge of the WML processing.
Also, provide further proposal details as requested.
April 14 Accepted to work on Wesnoth for Summer of Code :)
April 14 – May 26 Three goals for this period:

1. Become very familiar with WML, and the design of scenarios. Use this research to refine and improve the project plan.

2. Do some coding work on the Wesnoth GUI, likely assisting Mordante by implement various features.

3. Become more familiar with Python. This will mostly be done in class, though I will also be studying it outside of class. Also, this is not as important as the other two as it is not directly required for the scenario editor. It will, however, allow me to become more familiar with other parts of the Wesnoth code.

Basically, by the end of this period I should be very well-prepared to begin the project. I will also in this period have started some of the groundwork for the project.

May 26 Google Summer of Code begins.

   Begin coding.

Tentative coding schedule: I’ve put some specific functionality goals here, though these are highly likely to change based on input from developers, scenario designers, and Wesnoth players gathered in the weeks prior. Also, I have tried hard to under-scope each iteration, as again, over-scoping is a common mistake for Summer of Code students. My project proposal, however, is very extensible, and so nothing is lost by this under-scoping as there are many more features that can be added. It is very important that at the end of the summer there is a well-done, completed project. I expect that at each of these dates there will be significantly more done than is on the timeline, and communication will be important as the summer goes on.

June 9 Iteration 1: Editor is fairly simple at this point, but can display map, add units to different sides, and change different attributes of those units.

June 23 Iteration 2:

   Can Add events triggered at particular locations, or by particular units (either 
       that unit does something, or something is done to it… i.e. unit dies).
   Can edit side info
   Can Edit objectives
   Can place villages

July 7 Iteration 3:

   Can save to WML.
   Can load from WML, those features that the editor supports.
   Added a WML editing box for most dialogs (i.e. can write your own WML for events.)
   Maintains WML output that can be edited within editor.
   At this point should be able to fully create basic scenarios.

July 21 Iteration 4:

   Continue to improve functionality
   Make common tasks easy to do, for example, conversations.
   Add more functionality as determined by discussions with users/ designers
   Add story editing

August 4 Iteration 5:

   Add support for more advanced WML
   If ahead of schedule, add advanced unit editing.
   Add more functionality as determined by discussions with users/ designers
   Thorough re-testing of all code has begun.

August 4 Tentative feature lock.

August 4 – 11

   Test and clean code.
   Improve usability and polish in-game documentation.
   Improve code documentation.
   Improve online documentation.

August 11 – 18 Final Week.

   Finalize code.
   Finish code documentation.
   Finish online documentation.

August 18 - ? Continue working on Wesnoth, both extending the finished project and working on other areas of interest.