SoC Ideas Sprite Sheets2011 ArthurWulf

From The Battle for Wesnoth Wiki


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

Arthur Wulf - Spritesheets

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

Experience

Recently I completed a RPG adventure game for a TV reality show.
To make the code resuable and modular I wrote an engine for that game.
That engine includes amongst other features an easy to use, flexible spritesheet support.
(All the characters are in a spritesheet and so are the character's speach animations) Currently the game is not released to the public, however I'd be happy to provide a private link.

Arthur Wulf

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 corners of the frame with a unique color. This way, we can have flexible frame sizes w/o limiting ourselves to 'even' blocks.

The code will identify the frames inside the spritesheet and have it act as a virtual "2d array" of frames that is accessible via the unit's.cfg just as file names are in the existing system.

The frames will be accessed with the following syntax: "<unit_name>[<animation_name> , <frame#>]".
So where we had "archer-idle-1.png" we'd have "archer[idle, 1]"
To allow the game to know where [idle, 1] or [bowAttack, 2] points to, the code will generate a dictionary in WML with 'meaningful names' as keys and x1,y1,x2,y2 positions as values. For the purpose of generating the dictionary I'll make a user friendly tool that allows the artist to name the frames in his/her units spritesheet and saves the needed data into WML for use.(more on that ahead)

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'd want to see the system accessible to new artists as well as veterans.

For this purpose I'll create a spritesheet manager that helps generate a .cfg and assign frames with meaningful names.

To ease the process of testing new units I think we should consider adding an 'advanced option' that reloads the sprite data. 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.

3. converting existing content

Once the new system is in place and gets devs and artists approval I'll begin to concentrate efforts on a new tool that will automate the merging of seperate .png files of each unit in the existing system into one spritesheet and adjusting units .cfg files to support the resulting spritesheets.

This will require some manual work and testing. Once the tool is ready I'll start working on converting the existing content to support the system.

Timeline

+ Apr 25 - May 7 Familiarize myself with important parts of current Wesnoth Bliting system code and artist needs.
+ May 8 - May 23 Discuss my ideas and plan how to implement them.
+ May 24 - Jun 21 Implement a new Spritesheet system and test it get artist and dev feedback and implement suggestions.
+ Jun 22 - Jul 7 Create a tool with user friendly GUI that assists artists in managing and editing unit .cfg files that work with spritesheets.
+ Jun 8 - Aug 7 Work on converting the existing content into the newly implemented and tested sprite system.
+ Aug 8 - Aug 20 Two weeks to polish the code and add through documentation and answer faq."
  • I don't have holidays or days that I cannot be available

Feedback

(see feedback at the application page in google melange)

IRC

elbowroom

SoC Application

SoC Application

Questionnaire

1) Basics

1.1) Write a small introduction to yourself.
My name is Arthur Wulf and I'm a Computer Science student at the Tel-aviv university.

1.2) State your preferred email address.
aturlevy at hotmail dot com

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

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

  • Learning experience.
  • Contributing to a game I enjoy playing.
  • Challange.


1.5) What are you studying, subject, level and school?
I'm a level two Computer Science student (2nd year) in Tel-Aviv uni

1.6) What country are you from, at what time are you most likely to be able to join IRC?
I live in Israel. I can join at any time.(I'm used to night shifts)

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.
I have two tests in July but I don't cram for tests, I study in advance.
I work at a software company part time, about 12h per week during the summer.

2) Experience

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

  • I've worked with Visual C++/C#, Eclipse, FlashDevelop, PHP, mySQL, apache server, Python and Scheme.
  • I've made visual content for games with 3dsMax, Maya3d and PaintShop Pro.
  • And I created game music with Acid Music and sound effects with sfxr.


2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)
Well yeah, most of serios projects require a team, even if I do all the code I like to get constructive criticism and suggestions from another person. I can work independent but I still get more results when I have weekly feedback from someone.

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?
no

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.
not really
Side note: I recently completed an Adventure game engine, I'd like to release it as open source but I am not yet familiar with the legal aspects of releasing code.


2.5) Gaming experience - Are you a gamer?
Yes.

2.5.1) What type of gamer are you?
Oldskul / casual

2.5.2) What type of games?
I like 8-bit / 16-bit console games, I like pixel art.
As a teenager I liked startegy games like Dune, X-Com, Heroes, Warcraft(1,2), C&C and Syndicate.

2.5.3) What type of opponents do you prefer?
I like a mixture opponents depending on my mood, both superior and equal.
I learn more from ones that are more skilled than myself, and enjoy a hard earned victory. Playing against someone of the same skill level, I still get a decent thrill.

2.5.4) Are you more interested in story or gameplay?
Stories bring me back to games I haven't played in awhile. However, gameplay is what gets me hooked in the first place. I enjoy balanced gameplay and challange.

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.
Ever since I recently heard of this game, I've been playing it often.

MP vs. SP:
Multiplayer is more thrilling but single player is more relaxing.
I really like the stories in single player.


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 S­­V­­N (during the evaluation period or earlier) please state so.
nope.

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.
English is my native language.
3.2) What spoken languages are you fluent in?
English and I am also able to understand and express ideas in Hebrew at a native level.
3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.
Well, tbh I feel that way, some may strongly disagree on certain aspects of a game but I keep my discussion respectful and thoroughly explained. I'd much rather play the game than argue on why things are a certain way.
3.4) Do you give constructive advice?
Yes, I'd like to think that I offer assistance more than advice.

Meaning, rather than recommending what I think is best, I try to explain the pros and cons of different decisions and let people decide for themselves.
3.5) Do you receive advice well?
Yeah, I'd to think that I'm an easy going broad-minded man.
3.6) Are you good at sorting useful criticisms from useless ones?
Yeah, I have to cause I work with people on most projects and you can't please everyone all the time. I still use 90% of the critcism cause I normally work with logical reasonable people.
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
Well, I work very intensively and if I know I can complete something in two-three hours and than get feedback on the actual code I'd start writing code. People are not always available for discussion or they may lack the time.
I personally like to plan and spend my time efficiently when I work so I would prefer to talk things through and get clear idea of what the dev team wants before I start.

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?
I selected the spritesheet project. I want to concentrate on two things: Simplifying the process of adding new content & improving performance.
4.2) If you have invented your own project, please describe the project and the scope.
-
4.3) Why did you choose this project?
Because I have wrote similar features for engines previously. Also I think it could improve the games exposure in the mobile market and greatly improve artist quality of life. I feel that in order to maximize my contribution it is best to concentrate my efforts in a field that I am experienced with.
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".
#Timeline
4.5) Include as much technical detail about your implementation as you can
*******
4.6) What do you expect to gain from this project?
Learning experience and also I find writing code for games satisfying.
4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?
Well, I enjoy the game and that is my reason to stay.

5) Practical considerations

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

  • Sub­­version (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!
*******

6) recommendations

This page was last edited on 21 March 2013, at 01:21.