SoC Ideas Sprite Sheets2011 Npepinpe

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

Note: This is a work in progress.

Description

Nicolas Pépin-Perreault - Spritesheet Implementation

The idea is to implement support for a flexible sprite sheet mechanism within the Wesnoth code base; flexible implies the capacity to deal with variable-sized frames within the same sheet. The project would focus on implementing a 2D array interface to individual sprite sheets, allowing easy and efficient access to single sprites within the sheet with minimal change to the rest of the code base. Other goals would be the creation of a command-line tool to batch convert series of PNG images into a sprite sheet, and a GUI tool to allow artists to easily tweak the visual aspects of unit and terrain sheets.

IRC

npepinpe

SoC Application

SoC Application

Basic Idea

The sprite sheet on disk would be a large PNG image containing individual sprites arranged in individual, variable sized rectangular cells. Configuration files would be modified so that coordinate (x,y) attributes would be added to individual frame tags. A sprite sheet could be defined for a given unit/terrain, with the possibility to override the image in the frame tag. Some macros would have to be changed to take as parameters the coordinates within a given base image.

Details

There are some details I am unsure of at the moment, which would need me to learn more about the current code base. What would be the logical classification of sprites into sheet?

Tools

I would propose two sort of tools: a command line tool to batch process existing images into sprite sheets, and a GUI tool which would allow for easy specification of frames in unit/terrain configuration files.

Command Line

Considering there already exists a large amount of single files, processing each sprite/configuration file by hand will be ridiculously long and tedious, and prone to errors. The basic idea would be to put together a simple program which could read in a list of single images and produce a single sprite sheet out of these. The sophistication of the tool would depend on the needs of the community, and how much control over the format we want.

I'm unsure as to how automated this process could be: could the sprites list be read off single configuration files? Or are there images shared between different image files? Would it be more efficient to pack one sheet for each unit, or perhaps one sheet for unit types (i.e.: single bat-sheet.png or bat-sheet.png, bloodbat-sheet.png, etc.)? What algorithm should be used to efficiently pack sprites together into sheet (packing, tesselation)?

Ultimately the sprite sheet would be a PNG image, so it can be optimized by the current toolset as any other image would.

GUI

The GUI tool would allow artists and contributors to define frames within a sheet for a given unit/terrain configuration file. My first idea (although this would be changed to fit the needs of contributors) would be to have the sprite sheet visible, open a configuration file and have, say, a list of the frames in a different window. Selecting a frame would highlight a rectangular portion of the sprite sheet, which can be resized, moved or removed. New frames could be defined as well.

I'm unsure yet as to which tools are most used by contributors: if artists mostly use GIMP, then a GIMP plugin could be created. I don't think attempting to create a GUI tool from scratch is such a good idea, integration within a pre-existing tool seems more feasible.

Questionnaire

1) Basics My name is Nicolas Pépin-Perreault (not French, but French Canadian). Apart from computer science/math related things, I sing (classical) and read extensively (mostly for studies, but still). I'm a final year undergraduate student at McGill University in Montreal, Quebec, Canada. I will be graduating next semester, with a major in Computer Science and a minor in English Literature. I've been following Google Summer of Code for some time now, and have always wanted to participate, but until now I was either working full-time or travelling. This year I have no plans on doing either yet, although GSoC would count as a full-time job. As for why I want to participate...primarily to learn in a non-competitive atmosphere. Jobs are a wonderful opportunity to learn, but from experience, my boss were rarely interested in the how, and more in results. If it doesn't work, make it work, no, don't take the time to do it properly, there is no time, etc. I think I will prefer by far the atmosphere of an open source project, and it will be an even greater opportunity to learn.

My main email is n.pepinpe@gmail.com. On the forums and IRC, I use the nickname "npepinpe" (no quotes). I have no major commitments for the summer, but I will not be living in Montreal. I will not be traveling, however, as if I am doing GSoC then I expect to be working full-time. As such, in the summer, I expect to be joining IRC during most days (i.e.: from 11-12am to 16-17pm Central European Time, outside this range if need be).

The only time I will not be available is from May 29th to June 10th, where I will be touring in France, Switzerland and Germany (singing).

2) Experience I have no worked on many open source projects before: most of my experience is with student projects, with a few patches here and there in some open source program I wanted to use that was broken (DeSMuMe and freedroidRPG, for example).

The bulk of my experience comes from my last job, where I was initially hired to finish a web interface for a sensor network. I then worked on the embedded side. The company's chief product is a building automation solution. They provide sensors and a controller. I was working on the controller, integrating Lua as a scripting engine and writing extensions, integrating the http server, setting up basic Bacnet compatibility. I was then moved back to front-end for another project, where I worked mostly with JavaScript and some Groovy.

I have never participated in the Google Summer of Code before, but I've been wanting to for a while now.

I suppose I'm a gamer? I wouldn't identify as such, but I do play quite a number of games (less now, thank you University...). I play mostly RPG (from JRPGs to BioWare games), RTS games and old platformers (thank god I kept my Super Nintendo).

I would say in games I prefer opponents of my level; too easy is no fun, but too hard crushes my spirit in the long run.

As for story vs. gameplay, I would say it depends; of course I would prefer that both of them be excellent, but if I'm playing an RPG, I expect a strong focus on the story. If I'm playing an RTS, then it's mostly the gameplay that will determine if I keep playing or not.

I have played Wesnoth in the past (a year ago or so), and only the beginning of single player, but I only have dim memories of the game.

3) Communication skills I work and study in English, and spent a year living in England in 2009-2010. I would say my level of English is near native (but not quite). My primary language is French, then English. I can handle myself in Spanish and German, but not enough to write, say, this application page.

I would say I'm an easy person to get along with, so I should get along with players and developers. For this project I expect near to no interaction with players, however, but who knows.

I'm used to working in a small team, which has its advantages and disadvantages, the main one being that we tend to be rather easy-going with our criticism since we know each other so well and have to work together constantly. Or maybe it's just our famous Canadian politeness. Either way, I think I give fairly constructive advice, but perhaps am not as harsh as need be at times. Similarly, I would say I receive advice rather well, but I'm not particularly used to receiving very harsh criticism; when I do, I tend to be very skeptical of it, but if you're willing to explain to me why then I will listen and learn.

I tend to be very autonomous when developing. I will stay in my corner until I hit a wall, at which point I will come back and discuss it out with whoever's there. I guess I'm the kind who would create a proof of concept to better explain my vision to others, and then discuss it. I don't mind if it doesn't make it.

4) Project I'm especially interested in the Spritesheet project, because I see it as an opportunity to delve into the Wesnoth code base for future endeavours, as a project I am sure I can do (and do well), and one that will have a direct impact on contributors.

Timeline: well, Google puts May 24th as the date students should begin work on their projects. I finish University on the 26th of April, and of course will be taking a couple days to air out my brain. Roughly, I would be starting around May 1st or 2nd, then. If I really have to abide by Google dates, then we can move everything down by a week or two.

May 2nd - 17th: get to know the Wesnoth code base, the developer community, start discussing alternatives with contributors. Finalize details of sprite sheet format and packing algorithm. May 18th -28th: implement a proof of concept in an unobtrusive manner. May 29th - June 10th: touring in France, Germany and Switzerland. June 11th - July 2nd: work on command line tool. July 3rd - July 24th: work on GUI tool. July 25th - end: Testing, documenting, polishing, revising.

Of course, throughout this, I would be constantly seeking feedback, and the development process will most likely be iterative.

Hopefully this project will make me more familiar with the fundamentals of computer graphics (since I will be poking around in the animation code), and generally make me familiar with the Wesnoth code base so that I could keep working on it in the future. Furthermore, working on this project will give me a greater familiarity with C++, something I've been wanting to do for a while. I have been programming in C for years, and also in C++ a bit, but have never had any incentive to take the time to properly learn C++.

5) Practical considerations I am familiar with sub­­version (used at my work), C++, SDL (not STL and Boost, however, but I am a quick learner). I have some minimal experience with Python, not much with CMake/SCons, not much with WML (but it seems simple enough, and a reference is there). I have some experience using Lua, but most of it was integrating it into an existing project and writing C extensions for it.

As for tools I use in development, Sub­­version, profiling tools (depends on the language I am working with), Hudson (CI), GNU build tools. As I said before, since most of my experience comes from work, these are tools that were used there, and worked quite well. Hudson was useful for continuous integration, the autotools were used for internal tools and libraries, the profiling tools for debugging and sub­­version was used since it made more sense as multiple developers to work with some source control.

I am mostly proficient with the following programming languages: C, JavaScript, Ruby, and SML. Over time I have picked up others, but none I would consider myself truly fluent in. Some, such as C++, I have worked with quite a bit, but I still have to look up the reference from time to time about certain aspects.

I have no problem talking over the phone/Skype/Google Voice with anyone. I do have an accent when speaking English, but that's just more trouble for the other person. I will put up a phone number in my Google application.