Archive: Open jobs (project ideas)
WARNING: Most from tasks here have already been addressed long ago, and this page was archived (instead of being deleted) because it may be useful, shall we ever run for GSoC again. Only a few minor tasks are still relevant (eg. beautiful water, cutscene stuff which was already partly added, random tiles functions, minigames). Most, if not everything else written here is legacy.
You have been warned.
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. Also note, some changes were already done at our Review Board.
WARNING: Outdated. This page was almost ten years old, by the time this warning was written. You have been warned.
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
Visual effects additions:
- if you have 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 accommodate 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.