This page lists open jobs for outsiders. It notably contains Google Summer of Code project ideas.
Note that you can also pick from
ToDo and send a patch, or simply implement something of your choice !
You are advised to download FreedroidRPG from our svn repository
(svn co https://freedroid.svn.sourceforge.net/svnroot/freedroid freedroid) in order to see the current state of things and be able to fully understand the projects described here.
Random dungeon generation
This project aims at bringing random levels to FreedroidRPG, in order to increase the gameplay
value by adding content that does not require careful hand editing. This would represent a significant improvement for our players.
You will have to write a generator that is able to build fully playable levels, such as what the game Diablo does.
This project requires a bit of interaction with existing FreedroidRPG source code in order to
integrate the generator into the engine, but the first steps of it are fairly independant from the
game.
You probably need to have a decent math/theorical computer science level to properly design the system (you might be using some notions such as automata).
Ability to understand and write C is required, as your project must be implemented in C and then integrated into the FreedroidRPG codebase.
The coding part of this project is moderately difficult, the design of a proper dungeon generator is a rather tough problem that we think can be very interesting to work on for the summer. It does require some background though.
The tasks are :
- see what dungeon/labyrinths generators exist, and how they could be adapted to FreedroidRPG
- design a random dungeon generator that can make completely playable levels including floor
tiles, walls, enemies, objects on the ground and chests
- change the engine for it to allow "random" levels to be generated on level loading (at runtime)
- plug your system in the engine and tweak it until the results are satisfying from a gameplay
point of view (balancing, etc.)
Leveleditor overhaul
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 relatively 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.
Many features exist but are very basic, for example copy/pasting only works for walls and not for floor.
Various ideas of things to do are :
- improve placing of walls as lines instead of tile by tile
- improve copy/paste functionnality
- improve autoscrolling system
- 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)
- handle placement of random and special enemies on the map
- handle placement and basic editing of event triggers
Difficulty levels
FreedroidRPG does not currently support difficulty levels. Those could be implemented by selectively tweaking certain multiplying factors like "bot maximal energy factor", "bot damage factor", etc.
This project is one of the easiest we have to propose, since most of the backend to do difficulty levelling is already here. It is therefore ideal for a beginner with C or open source.
You have to :
- think about (and implement) how to implement difficulty levels in terms of interface (ie. how does the user change the difficulty level)
- think about (and implement) what values to change when changing a difficulty level (do you give more health points to the character, reduce damage of enemies, reduce armor of enemies, or all at once..)
- work on balancing your changes so that "easy" is easy to play but not too much, "normal" gives a challenge but does not kill the player every five minutes, and "hard" represents a serious challenge so one can brag about having finished FreedroidRPG in "hard" mode
-
Scripting improvements
FreedroidRPG recently started using the Lua language to provide scripting support. The Lua API was designed to reproduce the previously existing functionnality, but it has the ability to provide many more features. You will have to increase FreedroidRPG scriptability.
The project requires an interest in game design, an ability to read documentation, and, depending on the subtasks, a small to moderate experience with C. Being a C or Lua expert is a plus but by no means required.
You have to:
- add a takeover() Lua function that starts our takeover minigame and returns the win/lose information, in order to impement hackable doors/lockers/etc.
- add support for "user clicked there" event triggers (we currently have location based triggers among other things, but no "user clicked" based trigger)
- support spawning of enemies
- add a function open_log("Quest name", "Log message") to update the quest log directly from within scripts
- add support for player scripted actions/movement ("ingame" cutscenes)
[1] [
http://en.wikipedia.org/wiki/Cutscene]
- add support for cinematics ("real video" cutscenes)
OpenGL performance improvements
FreedroidRPG OpenGL performance is acceptable but 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.
Some ideas are:
- evaluate the relevance of using a texture atlas for obstacles, characters, inventory item images, fonts, etc. and implement it if necessary
- use vertex buffers whenever possible (doable for floor tiles)
- do anything that appears necessary to you to improve GL performance (we are not experts at OpenGL?)
Bonus task (for fun)
- if you have time and interest, play with disable-able additional effects such as GLSL
explosions/flames
Obstacles specification format improvements
FreedroidRPG defines as "obstacles" the elements of the map that do not interact with the player, and possibly blocks his way. Basically, "obstacles" designates walls, tables, chairs, shelves,... anything but items (which can be picked up) and robots/humans.
Our obstacles have collision rectangles, that describe the area they occupy on the map - the area the player/enemies cannot go into. Those rectangles are currently specified in a very limited way : they are hardcoded into the blocks.c source file. This makes them difficult to change, and forces a recompilation every time.
Your job will be to clean this up and make obstacles easier to modify and add, by moving the specification to an external data file, and possibly writing it in Lua so we have several ways of describing the collision rectangle (X1 Y1 X2 Y2, X Y W H, offset relative to the center of the rectangle).
If you have extra time, modify the engine so people can easily change those rectangles when adding a new obstacle (without reloading the game etc.)
Magic items naming
FreedroidRPG features items with special abilities ("magic items"). Currently it uses a system similar to the one found in the commercial game Diablo 1 : each item can have up to one prefix and up to one suffix, each prefix/suffix gives certain special attributes. The name of the item is built as follows : "prefix basename suffix", e.g. "Massive bow of the heavens".
This is practically impossible to translate due to genre problems in all western european languages but english, therefore we need another approach.
You will look at how other games solved the problem of naming special items, find and implement a solution.
One possibility is to generate a unique, more or less pronouncable name based on the abilities of the item.
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
- improve the artificial intelligence of the original takeover game