RujasuScenarioEditor

This page is obsolete. It should not be relied upon as a source of information. If you are willing and able to update this page, please do so. If it cannot be brought up to date it may be removed.

Reason: It's an GSoC application, and the ideas from it are now either implemented or logged in the issues database.

Basics

My name is Jacob Rudolph. I'm twenty years old and currently reside in Pennsylvania. I'm hoping for a career in software development, though I have not decided my exact ambitions yet. My hobbies include acting, and, well, open source game development.

Email: rujasu@yahoo.com

My nick is "rujasu" on IRC and forums. Generally, if you see "rujasu," it's probably me.

I am hoping that Summer of Code will give me enough income to dedicate more of my time to working on one of my favorite open source games, and less time working at a job that may not relate to my ultimate career path.

I'm a junior (third-year) undergraduate student at York College of Pennsylvania, majoring in Computer Science. I've taken nearly every programming-related course possible.

Experience

I have been a developer for Hero of Allacrost (www.allacrost.org) for about a year now, and was recently named lead of the programming team. Hero of Allacrost is an open source project for a single player RPG with 2D graphics; it draws inspiration from games such as Final Fantasy and Chrono Trigger. This would be my first Summer of Code experience.

I believe in using a general agile development model. It is clear that the waterfall model does not work in open source development. Documentation is important, but more important is producing readable and flexible code. Creating full prototypes is unnecessary for this project, but it will be helpful to create some interface mockups. For this project, the best method of testing is having people try using the software; I don't feel that automated testing will be useful for this project.

For the Allacrost project, I have worked on bugfixing and extending the functionality of the game's shopping and game menu interfaces. I have also contributed ideas, tested for bugs, and worked with scripting in Lua. More recently, I have been mentoring new contributing programmers for the project and working on battle mode.

I consider myself a pretty serious strategy/RPG gamer, though I haven't been playing as many games as I'd like lately. I play single-player games almost exclusively. I like games that challenge me; great gameplay is always the important factor, but a fantasy game needs a great story to be a true classic. I first learned of Wesnoth from a friend, a little over a year ago. I play single-player campaigns and have not tried multiplayer.

Communication skills

I am a native English speaker. I am an effective communicator and have taken academic writing classes through college. I do my best to help anyone who has questions or problems. I am very patient, and I should be able to interact with players easily. Whenever possible, I give constructive advice. I do not give negative or demeaning feedback. I am always willing to listen to advice and constructive criticisms. I am able to recognize when a criticism is accurate and useful.

Project

I chose the scenario editor project from the list. I chose this project because I would like to create an editor that is more usable and flexible than the out-of-date campgen, and one that will ultimately be more powerful. The editor will be written in C++. This is my most proficient language, and it allows better integration with other aspects of Wesnoth.

The editor will be using Wesnoth's own GUI toolkit (currently in development), with any necessary extensions being added as needed. I plan to use this toolkit because it would allow the editor to be distributed with Wesnoth, without any added dependencies. Since it is supposed to be easy-to-use, we don't want the user to have to install additional libraries. It would also keep the general feel of the game. Map viewing code from the map editor and/or main game could be re-used.

The interface will allow:

- Modification of basic scenario infomation - Modification of sides/unit types - Adding/removing/editing WML events by clicking on specific units, locations, or list of turns - Saving to WML, loading from WML

On the back end, the editor will work using a simple process:

- Load and parse the scenario's CFG file. - Modify the components of the WML as directed by the user/interface. - Output the WML components to a CFG file.

This will also allow significant re-use and coordination with the main game's code. Much of the WML parser will be re-used, or at least used as a guide. Other things to worry about on the WML side:

Events will have to be dealt with. The system will have to be able to create events, remove events, and modify existing events. Removing events will be simple enough; just delete the event code. My plan to deal with creating events is to use small templates for common types of events. For modifying events, the editor can essentially list everything that happens as a part of that event, allowing the user to add to the event, remove from the event, or change parts of the event. To change the condition for an event, the user will probably have to create new events in most cases.

Preferably, comments written in WML would be preserved, though exact formatting will not be. This is a feature that may be difficult to implement during a summer project. However, comments could be preserved by keeping a record of all comments loaded from a data file and the information directly below them.

Macros would be very possible to deal with, however it would require a fundamental change to the editor's internal representation, so it would probably not be a feasible goal for this project to preserve macros.

Practical considerations

I am very familiar with SVN, mainly from my work on Allacrost. Also, I have been using C++ for about six years. Though I have no experience with Python, I am confident in my ability to learn programming languages quickly when needed.

As a Linux user, my work is mostly done on KDE development tools such as KWrite and KDevelop. I believe these are the most easily usable and visually appealing tools available for Linux. I am fluent in C++, Java, and C, with a working knowledge in Lua and a few others. Unfortunately, I am also fluent in BASIC, though I haven't touched it in years.

My only fluent language is English. My knowledge of Spanish is passable at best. Generally, I am awake from 14:00 to 6:00 UTC. I am able to talk over the phone; haven't really done anything with VOIP before.

Tenative Timeline

Now - May 25:

Learn more about Wesnoth: read documentation, talk to developers, etc. Play through as many currently-available campaigns as possible. Refine ideas. Talk to scenario developers and get an idea of most requested features, etc.

May 26 - June 8:

Begin coding Implement loading from WML, using (derivative of) current Wesnoth parser Begin implementing the interface

June 9 - June 22:

Implement saving to WML Implement basic modification support: static scenario information

June 23 - July 6:

Implement support for creating events Implement support for modifying events Implement support for creating new scenarios (default CFG files)

July 7 - July 20:

Clean up loose ends Continue to work on implementing more events Implement "export to WML" and test basic scenario

July 21 - August 3:

Put out version to community for testing/feedback Implement an interface that will allow the user to tie scenarios together into a full campaign Continue to work on implementing more events Begin implementing additional features, such as: - preserving comments - events that affect AI?

August 4 - August 18:

Respond to feedback/bug reports Finish anything not already completed Work on additional features/events