Difference between revisions of "SoC Ideas Sprite Sheets2011 ArthurWulf"

From The Battle for Wesnoth Wiki
(More information)
(1. Implementing spritesheet support)
Line 26: Line 26:
 
I will introduce a new flexible spritesheet system with two goals:
 
I will introduce a new flexible spritesheet system with two goals:
  
- Making the artists work more convenient.
+
<ul>
  
- Improving the loading time and memory useage of the game.
+
<li>- Making the artists work more convenient.</li>
 +
 
 +
<li>- Improving the loading time and memory useage of the game.</li>
 +
 
 +
</ul>
  
 
The process will start by adding spritesheet support so the artist can test it and provide feedback.
 
The process will start by adding spritesheet support so the artist can test it and provide feedback.

Revision as of 19:52, 22 March 2011


This page is related to Summer of Code 2011
See the list of Summer of Code 2011 Ideas



This is a Summer of Code 2011 student page
Project: SoC_Ideas_Sprite_Sheets2011



Description

ArthurWulf - spritesheets - proposal summary

I wish to reorganize the sprite system for units & terrain:
Creating an artist friendly workflow & implementing extensile spritesheet functionality.
Doing this I'm planning to accomplish two goals:

  1. Allow artists to make tweaks in animation more quickly and easily.
  2. Improve installation time and loading time of the game. It could also be of benefit to perforamance on ports to mobile devices.

It will simplify the process of adding new content by allowing artists to work with one single large image rather than many seperate files.
After receiving artists feedback we may also want to consider adding an in-game option to refresh sprites w/o exiting the game and restarting.
(In order to test tweaks more quickly)

In addition to working on the spritesheet system I will complete the transition to this new system by creating a tool that merges frames in seperate .png files into an organized spritesheet and creates a new .cfg files that is adjusted to use a spritesheet.
This will have the additional benefit of leaving the choice between the new and existing workflow in the hands of the artist.

Design Plan

My proposal is consisted of three parts:

1. Implementing spritesheet support

I will introduce a new flexible spritesheet system with two goals:

  • - Making the artists work more convenient.
  • - Improving the loading time and memory useage of the game.

The process will start by adding spritesheet support so the artist can test it and provide feedback. I suggest implementing a system where the artist 'marks' the corenrs of the frame with a unique color. This way, we can have flexible frame sizes and with do not limit ourselves to 'even' blocks.

The code will identify the sprite sheet and have it act as a virtual "2d array" of frames. So where we had "archer-idle-1.png" we'd have "archer[idle, 1]"; To help keep the meaningful names I'll create a user friendly too that automates the process of creating a WML file that contains descriptions of the frame blocks inside the png.

2. Making a visual cfg unit editor

Adding spritesheet support is helpful and if we want to make the best out of it, making an easy to use tool with user friendly GUI that automates the creation of unit CFG files is the next step.

I'll create a tool that allows looking at the spritesheet and assigning frames to custom actions.

This will also allow testing of tweaks on the spot.

And hopefully the improved loading times from step 1 will make testing in game quicker and easier.

TODO - add more details

3. converting existing content

TODO

IRC

TODO: put ONLY your irc nickname in there. in case of alternate nicks, separate by ,

Example content of this section: "user" "user1, user2"

Questionnaire

1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

1.4) Why do you want to participate in summer of code?

1.5) What are you studying, subject, level and school?

1.6) What country are you from, at what time are you most likely to be able to join IRC?

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.


2) Experience

2.1) What programs/software have you worked on before?

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or gameplay?

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our SVN (during the evaluation period or earlier) please state so.


3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

3.2) What spoken languages are you fluent in?


3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

3.6) Are you good at sorting useful criticisms from useless ones?

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want


4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

4.5) Include as much technical detail about your implementation as you can

4.6) What do you expect to gain from this project?

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?


5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?

  • Subversion (used for all commits)
  • C++ (language used for all the normal source code)
  • STL, Boost, Sdl (C++ libraries used by Wesnoth)
  • Python (optional, mainly used for tools)
  • build environments (eg cmake/scons)
  • WML (the wesnoth specific scenario language)
  • Lua (used in combination with WML to create scenarios)

5.2) Which tools do you normally use for development? Why do you use them?

5.3) What programming languages are you fluent in?

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!