What to contribute
FreedroidRPG is entirely free software and free artwork. It is developed exclusively by volunteers in their leisure time. FreedroidRPG depends on these contributions to become a better game.
There are many things you can help with, being a programmer or not does not matter! (A game is not developed entirely by programmers.)
Testing and bug reporting
We need people to try out the game and report anything that does not work correctly or seems to be unstable. The task of testing is growing with the size of FreedroidRPG. We need your help. This may look like something of low importance, but a game without quality assurance is likely to be more frustrating than entertaining.
Small or large projects
We have many project ideas that can be tackled, for example by Google Summer of Code applicants. See below for the project ideas.
Creating new maps
The overall duration of FreedroidRPG is strongly tied to the amount and the size of levels that the player will go through. The current world is quite small, and we need more levels to extend the game. The random dungeon generator can help us, but only to a certain extent.
The leveleditor is accessible from the main menu of the game. Its documentation is scarce, but the developers will happily assist anyone playing with the editor!
The biggest flaw of FreedroidRPG as of this writing is its almost complete lack of decent sound effects, which breaks the immersion of the players. If you can create sound effects, or have time to browse existing free (as in free speech) sound databases, your help is required!
More music, more dialogs, more items, improvements on the gameplay rules (for example rethinking the player stats) are always welcome.
How to contribute
Our advice, based on years of experience working with people making their first contribution to FreedroidRPG or to free software in general, is to start small. Take your idea, and cut it in the smallest pieces that make sense, then do the first piece and submit it. Starting small is the best way of becoming a successful free software contributor - because oversized projects tend to be motivation killers in the long run.
Our tools and workflow
IRC is our primary communication means in the team. Many of our contributors do not join the IRC channel and communicate by e-mail or using our ReviewBoard (see below). Google Summer of Code students and applicants are however required to maintain some presence on IRC.
We have a FreedroidRPG Reviewboard (abbreviated RB) instance that is used for all incoming changes that affect the game's code (source code, but also maps and dialogs). This is where you will most likely submit the changes you make.
You need to create an account on Reviewboard before you can start submitting tickets or reviewing other people's code (this is strongly encouraged even if you aren't an active FreedroidRPG developer).
We rely on our bug tracker to list all the bugs that are found, and the requests from people who have a nice idea but are not able to implement it at the moment.
Please report the issues you encounter with the game!
http://buildbot.freedroid.org/ makes sure that we do not break the build, and automatically cross-compiles Microsoft Windows binaries for the less lucky of us who are stuck to this platform.
http://wiki.freedroid.org/ is a wiki (not publically editable) that we use to store some ideas and documentation. Reading it is advised, but what is written there is not authoritative.
Open jobs (project ideas)
We have a list of open jobs for outsiders. It notably contains Google Summer of Code project ideas. Note that you can also pick from the trackers or make your own choice! In any case, discussing your idea with the team before formally submitting is a requirement.
Check our application requirements.
In addition, we would like applicants to submit one or more patches to the game, in order to gauge coding ability and motivation. These patches can be related to your chosen project, an item from the bug tracker or feature request tracker, or an improvement in our current code.
FreedroidRPG, despite being in an advanced stage (and moving closer to 1.0), gets a significant number of bug reports, and an incredible number of feature requests. There are quite a few hairy issues that require a good knowledge of the codebase, but most of the issues are accessible to a newcomer who has time on his hands. See our bug tracker. Fixing bugs and implementing requested features could make a decent project, and be appropriate for people with various skill levels. Many small flaws do not require experience writing software, only a basic understanding of C and Lua, and a strong willingness to learn.
Difficulty ranges anywhere from easy to hard, depending on what bugs are picked.
FreedroidRPG uses the Lua language to provide scripting support, in dialogs and as ingame events. You will have to increase FreedroidRPG scriptability to match the needs of the people writing dialogs.
The project requires an interest in game design, an ability to read documentation, knowledge - or ability to learn quickly - of Lua, and, depending on the subtasks, a moderate to significant experience with C. Being a C expert or having extensive Lua experience is a plus but by no means required.
You will have to:
- support spawning of enemies from scripts
- add the ability for the engine to specify large zones as event triggers instead of a 1x1 square only
- add a "enter level" event hook
- improve animated obstacles support
- improve interaction of the player with the environment (breakable walls, etc.)
- add support for player scripted actions/movement ("ingame" cutscenes)
- review submitted patches to spot "patterns" in Lua script usage and provide improvements
- improve the savegame mechanism to be able to save Lua global variables, making it possible to use such persistent variables in dialogs
- bonus: add support for cinematics ("real video" cutscenes)
Floor tiles improvement: multilayer and animation
FreedroidRPG uses floor tiles to represent the floor. There are several elements such as water and grass, that exist in many variants due to the existence of corners and borders. The single layer of floor tiles introduces a painful limitation because it is impossible to represent both "grass over road" and "grass over sand" without rendering those two in blender. We would like to have the ability to have (semi) transparent floor tiles, that can be layered on top of others.
Additionally, floor tiles are static, so it is not possible to animate water or grass. It would greatly improve immersion of the player to be able to animate those tiles.
This project is moderately easy. It requires familiarity with Blender (ability to create some basic models and render existing ones). Experience in C and animated computer graphics is appreciated. You will have to:
- add support for rendering multilayer floor
- modify level file format to handle multiple layers of floor tiles
- design and implement a user interface in the editor to be able to work on multiple layers of tiles instead of just one at the moment
- add support for animated floor tiles
- animate water and grass, with help from graphics contributors if required
- meet performance and memory space constraints when designing and implementing the technical solution
- optional: implement "beautify water" in the leveleditor similar to the existing "beautify grass" feature
FreedroidRPG features an integrated graphical level editor. It works quite well, but needs some more work to increase the productivity of people making levels, and attract more contributors. Editors from other games such as The Sims could be an inspiration.
This moderately easy project requires a bit of experience with C, as you will have to work on the existing leveleditor which is a large piece of software (integrated into the game). You do not need to know C very well, nor have strong SDL and OpenGL experience. You need to have the ability and the will to learn C and be able to interact with FreedroidRPG's graphics layer (SDL, OpenGL).
If you have experience designing or implementing graphical user interfaces, or working with isometric 3D level editors, this is a plus. Don't hesitate to play with our level editor as it is right now, it will help you understand the tasks. Various ideas of things to do are :
- handle placement of random and special enemies on the map
- handle placement and basic editing of event triggers
- improve leveleditor minimap
- implement new tests in the ingame level validator to enforce design rules
- anything you feel is important for the interface (you can work based on your own impressions or other people's who report to us what they would like to see regularly)
Do also look at open items on the Bug and especially the Feature Request tracker. Most relevant tickets are tagged with Editor: or lvled: but some might not be.
FreedroidRPG performance is acceptable, but the game is not able to run on as many machines as we would like. This is mostly due to insufficient OpenGL performance, which can be improved with a few changes, for example by reducing the amount of texture changes, and the overhead of vertex emission. Your job is to increase the performance of the game, with a focus on the graphics rendering part. FreedroidRPG is slower than it could be, and this is impairing our players who have low end graphics hardware (most of integrated Intel cards). The problem got bigger with the apparition of "netbooks" which usually have such limited hardware.
This project requires fairly good knowledge of C and a bit of OpenGL experience, as you will be required to implement things that are not trivial, in an existing codebase that you must not break (unless you fix it afterwards). You will need to do a lot of profiling (on the CPU *and* on the GPU) to make sure what you implemented actually improves performance.
You will need to have a "slow" test machine available - and your project might be to make FreedroidRPG run on it. There are still plenty of < 1GHz processors in use, and FreedroidRPG is intended to be playable by everyone!
Some ideas are:
- try to use Nvidia's profiling tools (available for MS Windows only), and see if they give useful results, act accordingly
- investigate use of Intel's gputop
- do anything that appears necessary to you to improve GL performance Bonus task (for fun)
- if you have time and interest, play with disable-able additional effects such as GLSL explosions/flames
Improve assets (binary data) handling
FreedroidRPG uses a custom format to store animations of robots and players. This format is poorly documented, not very efficient, and technically unjustified. It would be good to replace it with something that is future-proof and easy to work with, in order to help FreedroidRPG's graphics army be more efficient.
This project requires a good understanding of C, basic knowledge of Blender or similar tools. Previous experience working on open source software is appreciated for this project. The difficulty is moderate to high, because some of the code to be modified is at the core of the engine and therefore must not be broken. Tasks may include:
- replace existing uses of "tux_image_archive" (the aforementioned custom format) by a PNG texture atlas similar to what is already used for fonts or floor tiles
- browse the feature request tracker and interview the graphics contributors to understand their needs and suggest ways of catering to them
- provide a way for the game to reload part of its graphics without having to be restarted, as an attempt to speed up the testing process for graphics contributors
- understand, unify, document, and integrate the existing FreedroidRPG texture atlas tools
- provide reference Blender python scripts for rendering
- modify the obstacle, enemy, items, floor, or tux graphics loading code to make the graphics creation process easier, perhaps based on actual small contributions you could try to make in order to get a feeling of what should be done
More minigames for takeover game
The takeover feature of FreedroidRPG, which enables the player to turn enemy bots to his side, relies on a minigame that was in the original Paradroid on C64. This minigame is fairly interesting, but introducing more variety would be appreciated from many players.
This project is easy if you have experience writing minigames, or slightly challenging if you've never written games in the past and want to learn. You need to be extremely creative to be able to imagine several games, but if you have got no previous C or game writing experience this project is suitable for you.
- understand the original takeover game
- write 2+ minigames that can be finished in less than one to two minutes of playing (those games must have a "difficulty" parameter similar to the "number of connectors of enemy" variable in the original takeover game)
- provide graphics and sound effects for your games if possible
- test the difficulty levels and do the balancing
- (optional) improve the artificial intelligence of the original takeover game
Multi-resolution support for the user interface
The user interface of FreedroidRPG was designed at a single resolution (640x480). Practically everyone plays at a higher resolution than this. To accomodate for higher resolution, the game simply scales (zooms) the HUD parts. This is suboptimal for two reasons :
- non 4:3 resolutions will end up distorting the HUD, which looks ugly
- high resolutions will enlarge the HUD disproportionately, yielding an ugly interface again.
In order to improve the general look & feel of the game, especially at high resolution on those "wide" screens, the user interface code has to be improved. Instead of zooming the user interface elements, the game should use (properly splitted) parts of those elements, only zooming the borders, so as not to enlarge decorations and to maximize the useful screen space.
This project requires an interest in human-computer interaction, and a minimal experience of user interface design. Experience with multi-resolution interface design for e.g. websites is a plus. Some knowledge of C will be required, as well as knowledge of one image editing tool such as Gimp.
You will have to:
- design a resolution-independent system for the FreedroidRPG user interface
- split up the various user interface elements (HUD, dialog background, shop interface, ...) in individual elements to be either scaled or displayed without scaling
- implement the system that makes use of the splitting user interface elements to create a true resolution-independant system
- make the HUD use this system
- move all other user interface elements of the game so that they use the new system
The leveleditor is already resolution independent, but the rest of the game isn't.