 |
 |
 |
|
Project navigation
Documents
Old stuff
|
|
 |
 |
 |
|
|
|
|
|
ToDo.OpenJobs History
Hide minor edits - Show changes to markup
May 04, 2009, at 09:03 AM
by 127.0.0.1 --
Added lines 97-103:
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.
April 03, 2009, at 01:43 PM
by ahuillet --
Deleted line 6:
March 27, 2009, at 06:42 AM
by ahuillet --
Added lines 7-10:
March 18, 2009, at 08:27 PM
by ahuillet --
Deleted line 6:
March 18, 2009, at 06:17 PM
by ahuillet --
Changed lines 7-9 from:
to:
March 18, 2009, at 06:17 PM
by ahuillet --
Added lines 7-9:
March 09, 2009, at 08:44 PM
by ahuillet --
Deleted line 6:
March 08, 2009, at 10:58 AM
by ahuillet --
Changed line 9 from:
Large projects
Random dungeon generation
to:
Random dungeon generation
Changed line 32 from:
Leveleditor overhaul
to:
Leveleditor overhaul
Changed line 50 from:
Difficulty levels
to:
Difficulty levels
Changed line 62 from:
Scripting improvements
to:
Scripting improvements
Changed line 77 from:
OpenGL performance improvements
to:
OpenGL performance improvements
Changed line 92 from:
Obstacles specification format improvements
to:
Obstacles specification format improvements
Changed line 99 from:
More minigames for takeover game
to:
More minigames for takeover game
March 08, 2009, at 10:56 AM
by ahuillet --
Added lines 94-100:
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.)
March 08, 2009, at 10:10 AM
by ahuillet -- another update for GSoC 2009
Changed lines 54-62 from:
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.
You have to think about how to implement difficulty levels in terms of interface (ie. how does the user change the difficulty level), think about 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..), and 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.
to:
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
-
March 08, 2009, at 10:07 AM
by ahuillet --
Deleted line 10:
Leveleditor overhaul
FreedroidRPG features an integrated graphical level editor. It works quite well, but needs some
more work to increase the productivity of people doing levels, and attract more contributors.
Editors from other games such as The Sims could be an inspiration.
This relatively easy project requires a bit of experience with C, as you will have to work on the existing leveleditor which is a bit dirty due to non careful design. 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 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 things to do are :
- DONEimplement placing of walls as lines instead of tile by tile
- support selection of elements on the map, provide copy/paste functionnality
- DONEadd a undo feature
- DONEremember "favorite" wall tiles in a specific menu
- DONEadd a system that allows testing the level without altering the world state (save the map, test
level, reload the map)
- improve autoscrolling system
- anything you feel is important for the interface
- (if time permits) handle placement of random and special enemies on the map
Changed lines 14-16 from:
value by adding content.
You will write a generator that is able to build fully playable levels, such as what the game Diablo does.
This project requires a bit of interference with existing FreedroidRPG code source in order to
to:
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
Changed line 23 from:
The coding part of this project is only 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. Due to lack of time we have not been able to assess existing GPL solutions, so this would be part of the project.
to:
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.
Changed line 25 from:
Your tasks are :
to:
The tasks are :
Changed lines 32-70 from:
point of view
to:
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.
You have to think about how to implement difficulty levels in terms of interface (ie. how does the user change the difficulty level), think about 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..), and 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]
- add support for cinematics ("real video" cutscenes)
Changed line 74 from:
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 (optimization of collision detection and pathfinding algorithms is part of another project).
to:
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.
Changed line 76 from:
This project requires good knowledge of C and 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 to make sure what you implemented
actually improves performance.
to:
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.
Deleted line 79:
- DONE - great increase in perfs evaluate the relevance of using a texture atlas for floor tiles
Changed lines 81-82 from:
- DONEfind an open source program that can generate our atlases, or write one
- use vertex buffers whenever possible (definitely doable for floor tiles)
- do anything that appears necessary to improve GL performance
to:
- 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?)
Deleted line 85:
- if you have time and interest, write an additional flame effect and implement a flamethrower
Artificial intelligence
FreedroidRPG's artificial intelligence of non playing characters is not very good. The NPCs tend to fire on allies, bump into walls, etc. You will have to design a new AI system by yourself, and actually implement it. A few minutes of playing in the game should suffice for you to notice the current status: the AI mostly works, but is limited to basic combat ("see player, attack player"). It could for example retreat, warn friends, hide, etc.
This project is difficult because you will need to dive into the large AI codebase that wasn't very well designed (due to lack of care in the planning of evolution of the game), understand its limitations and propose something that fixes them. You need to be comfortable with the C programming language, and have an interest in artificial intelligence for isometric 3D video games. We believe the problem is interesting to solve, and makes a good GSoC project.
The steps are:
- understand the existing AI system and its limitations
- propose a better design for AI
- write the new AI for enemy and allied bots, and for humans (moving and fighting behaviors)
- have your AI playtested and refine it
Changed line 95 from:
- write 4+ minigames that can be finished in less than one to two minutes of playing
to:
- write 2+ minigames that can be finished in less than one to two minutes of playing
Added line 100:
- improve the artificial intelligence of the original takeover game
December 02, 2008, at 10:35 AM
by ahuillet --
Changed line 25 from:
- add a system that allows testing the level without altering the world state (save the map, test
to:
- DONEadd a system that allows testing the level without altering the world state (save the map, test
April 22, 2008, at 02:16 PM
by 195.221.228.9 --
Deleted line 87:
Pathfinding and collision detection
Considered done and/or not relevant anymore.
For historical purposes you can find the test at PathfindAndColldetOld?.
This project has a few links with AI rewrite project - you will have to communicate with the person taking care of AI in order to agree on certain things.
The pathfinding and collision system of FreedroidRPG turns out not to work well enough, and is a weak point in the game.
Collision detection has two problems: performance and actual results - the system is terribly slow (because it uses unefficient O(n^2) collision testing) and it doesn't even always return the right values.
Pathfinding is practically not implemented, which makes the bot behavior on the map sometimes unexpected and greatly hurts gameplay value.
You will have to provide a new collision detection system, and a pathfinding module that yields a satisfying behavior of the various actors on the map. This project requires an interest in pathfinding algorithms applied to an isometric 3D RPG and experience with C.
The two tasks here are open questions that have been solved by other games in the past, and solutions probably exist on the Internet. You are encouraged to look up those solutions and see how they could apply to FreedroidRPG.
- try to understand the existing system and its limitations
- design and implement a faster, better collision detection system
- design and implement a suitable pathfinding algorithm
- integrate your new code in the engine and check how well it works, improve if necessary
April 22, 2008, at 02:15 PM
by 195.221.228.9 --
Changed lines 66-67 from:
- evaluate the relevance of using a texture atlas for obstacles, floor tiles, characters, inventory item images, fonts, etc. and implement it if necessary
to:
- DONE - great increase in perfs evaluate the relevance of using a texture atlas for floor tiles
- evaluate the relevance of using a texture atlas for obstacles, characters, inventory item images, fonts, etc. and implement it if necessary
Added lines 90-92:
Considered done and/or not relevant anymore.
For historical purposes you can find the test at PathfindAndColldetOld?.
April 21, 2008, at 09:01 PM
by Cygal --
Changed line 24 from:
- remember "favorite" wall tiles in a specific menu
to:
- DONEremember "favorite" wall tiles in a specific menu
April 17, 2008, at 10:11 PM
by 80.170.69.97 --
Changed line 21 from:
- implement placing of walls as lines instead of tile by tile
to:
- DONEimplement placing of walls as lines instead of tile by tile
Changed line 23 from:
to:
Changed line 67 from:
- find an open source program that can generate our atlases, or write one
to:
- DONEfind an open source program that can generate our atlases, or write one
March 21, 2008, at 08:34 PM
by ah --
Changed lines 111-112 from:
those games must have a "difficulty" parameter similar to the "number of connectors of
enemy" variable in the original takeover game
to:
those games must have a "difficulty" parameter similar to the "number of connectors of
enemy" variable in the original takeover game
March 19, 2008, at 09:51 AM
by ah --
Changed line 7 from:
to:
March 19, 2008, at 09:50 AM
by ah --
Added lines 7-8:
March 03, 2008, at 08:04 PM
by ah --
Changed lines 33-34 from:
value by adding content. You will write a generator that is able to build fully playable levels, such as what the game Diablo does.
to:
value by adding content.
You will write a generator that is able to build fully playable levels, such as what the game Diablo does.
Changed lines 38-41 from:
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.
to:
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.
Changed lines 75-76 from:
FreedroidRPG's artificial intelligence of non playing characters is not very good. The NPCs tend to fire on allies, bump into walls, etc. You will have to design a new AI system by yourself, and actually implement it. A few minutes of playing in the game should suffice for you to notice the current status: the AI mostly works, but is limited to basic combat ("see player, attack player").
It could for example retreat, warn friends, hide, etc.
to:
FreedroidRPG's artificial intelligence of non playing characters is not very good. The NPCs tend to fire on allies, bump into walls, etc. You will have to design a new AI system by yourself, and actually implement it. A few minutes of playing in the game should suffice for you to notice the current status: the AI mostly works, but is limited to basic combat ("see player, attack player"). It could for example retreat, warn friends, hide, etc.
Changed line 88 from:
The pathfinding and collision system of FreedroidRPG turns out not to work well enough, and is a
weak point in the game.
to:
The pathfinding and collision system of FreedroidRPG turns out not to work well enough, and is a weak point in the game.
March 03, 2008, at 08:00 PM
by ah --
Changed line 5 from:
to:
(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.
March 03, 2008, at 08:00 PM
by ah --
Changed line 71 from:
FreedroidRPG's artificial intelligence of non playing characters is not very good. The NPCs? tend
to fire on allies, bump into walls, etc. You will have to design a new AI system by yourself, and actually implement it. A few minutes of playing in the game should suffice for you to notice the current status: the AI mostly works, but is limited to basic combat ("see player, attack player").
to:
FreedroidRPG's artificial intelligence of non playing characters is not very good. The NPCs tend to fire on allies, bump into walls, etc. You will have to design a new AI system by yourself, and actually implement it. A few minutes of playing in the game should suffice for you to notice the current status: the AI mostly works, but is limited to basic combat ("see player, attack player").
Changed line 73 from:
This project is difficult because you will need to dive into the large AI codebase that wasn't very well designed (due to lack of care in the planning of evolution of the game), understand its limitations and propose something that fixes them. You need to be comfortable with the C programming language, and have an interest in artificial intelligence for isometric 3D video games. We believe the problem is interesting to solve, and makes a good GSoC? project.
to:
This project is difficult because you will need to dive into the large AI codebase that wasn't very well designed (due to lack of care in the planning of evolution of the game), understand its limitations and propose something that fixes them. You need to be comfortable with the C programming language, and have an interest in artificial intelligence for isometric 3D video games. We believe the problem is interesting to solve, and makes a good GSoC project.
March 03, 2008, at 07:59 PM
by ah --
Changed line 14 from:
This relatively easy project requires a bit of experience with C, as you will have to work on the existing leveleditor which is a bit dirty due to non careful design. 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).
to:
This relatively easy project requires a bit of experience with C, as you will have to work on the existing leveleditor which is a bit dirty due to non careful design. 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).
Changed line 71 from:
FreedroidRPG?'s artificial intelligence of non playing characters is not very good. The NPCs? tend
to:
FreedroidRPG's artificial intelligence of non playing characters is not very good. The NPCs? tend
Changed line 85 from:
The pathfinding and collision system of FreedroidRPG? turns out not to work well enough, and is a
to:
The pathfinding and collision system of FreedroidRPG turns out not to work well enough, and is a
Changed line 91 from:
The two tasks here are open questions that have been solved by other games in the past, and solutions probably exist on the Internet. You are encouraged to look up those solutions and see how they could apply to FreedroidRPG?.
to:
The two tasks here are open questions that have been solved by other games in the past, and solutions probably exist on the Internet. You are encouraged to look up those solutions and see how they could apply to FreedroidRPG.
Changed line 100 from:
The takeover feature of FreedroidRPG?, which enables the player to turn enemy bots to his
to:
The takeover feature of FreedroidRPG, which enables the player to turn enemy bots to his
March 03, 2008, at 07:58 PM
by ah --
Changed line 4 from:
You are advised to download FreedroidRPG? from our svn repository
to:
You are advised to download FreedroidRPG from our svn repository
Changed line 10 from:
FreedroidRPG? features an integrated graphical level editor. It works quite well, but needs some
to:
FreedroidRPG features an integrated graphical level editor. It works quite well, but needs some
Changed line 14 from:
This relatively easy project requires a bit of experience with C, as you will have to work on the existing leveleditor which is a bit dirty due to non careful design. 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?).
to:
This relatively easy project requires a bit of experience with C, as you will have to work on the existing leveleditor which is a bit dirty due to non careful design. 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).
Changed line 32 from:
This project aims at bringing random levels to FreedroidRPG?, in order to increase the gameplay
to:
This project aims at bringing random levels to FreedroidRPG, in order to increase the gameplay
Changed line 34 from:
This project requires a bit of interference with existing FreedroidRPG? code source in order to
to:
This project requires a bit of interference with existing FreedroidRPG code source in order to
Changed line 37 from:
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.
to:
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.
Changed line 42 from:
- see what dungeon/labyrinths generators exist, and how they could be adapted to FreedroidRPG?
to:
- see what dungeon/labyrinths generators exist, and how they could be adapted to FreedroidRPG
Changed line 49 from:
OpenGL? performance improvements
to:
OpenGL performance improvements
Changed line 51 from:
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 (optimization of collision detection and pathfinding algorithms is part of another project).
to:
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 (optimization of collision detection and pathfinding algorithms is part of another project).
Changed line 53 from:
This project requires good knowledge of C and OpenGL? experience, as you will be required to
to:
This project requires good knowledge of C and OpenGL experience, as you will be required to
March 03, 2008, at 06:58 PM
by ah --
Changed line 82 from:
Pathfinding
to:
Pathfinding and collision detection
March 03, 2008, at 06:57 PM
by ah --
Changed lines 63-64 from:
to:
- do anything that appears necessary to improve GL performance
Bonus task (for fun)
Changed lines 72-73 from:
to fire on allies, bump into walls, etc. You will have to design a new AI system by yourself, and actually implement it. A few minutes of playing in the game should suffice for you to notice the current status: the AI mostly works, but is limited to very basic combat ("see player, attack player").
to:
to fire on allies, bump into walls, etc. You will have to design a new AI system by yourself, and actually implement it. A few minutes of playing in the game should suffice for you to notice the current status: the AI mostly works, but is limited to basic combat ("see player, attack player").
It could for example retreat, warn friends, hide, etc.
Changed line 87 from:
Collision detection has two problems: performance and actual results - the system is terribly slow (because it uses unefficient O(n
) collision testing) and it doesn't even always return the right values.
to:
Collision detection has two problems: performance and actual results - the system is terribly slow (because it uses unefficient O(n^2) collision testing) and it doesn't even always return the right values.
March 03, 2008, at 06:50 PM
by ah --
Changed line 14 from:
This relatively easy project requires a bit of experience with C, as you will have to work on the existing leveleditor which is a bit dirty due to non careful design. 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?).
to:
This relatively easy project requires a bit of experience with C, as you will have to work on the existing leveleditor which is a bit dirty due to non careful design. 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?).
March 03, 2008, at 06:45 PM
by ah --
Changed line 38 from:
The coding part of this project is only 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. Due to lack of time we have not been able to assess existing GPL solutions, so this would be part of the project.
to:
The coding part of this project is only 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. Due to lack of time we have not been able to assess existing GPL solutions, so this would be part of the project.
Changed lines 51-53 from:
This project requires knowledge of C and previous OpenGL? experience, as you will be required to
to:
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 (optimization of collision detection and pathfinding algorithms is part of another project).
This project requires good knowledge of C and OpenGL? experience, as you will be required to
Changed line 56 from:
actually improves performance.
FreedroidRPG? OpenGL? performance is acceptable but can be improved with a few changes, notably by
reducing the amount of texture changes, and the overhead of vertex emission.
to:
actually improves performance.
Changed line 58 from:
The ideas are:
to:
Some ideas are:
Changed lines 60-61 from:
- use a texture atlas for floor tiles (you will have to write the program for making atlases or
provide a free software one)
- evaluate the relevance of using a texture atlas for obstacles (walls etc.) and implement it if
necessary
- use a texture atlas for every character (tux, bots, etc.)
- texture atlas for inventory item images
- use texture atlas for the characters of a font
to:
- evaluate the relevance of using a texture atlas for obstacles, floor tiles, characters, inventory item images, fonts, etc. and implement it if necessary
- find an open source program that can generate our atlases, or write one
Added lines 63-64:
Changed lines 72-74 from:
to fire on allies, bump into walls, etc. This project is difficult because you will have to design
a new AI system by yourself, and actually implement it.
to:
to fire on allies, bump into walls, etc. You will have to design a new AI system by yourself, and actually implement it. A few minutes of playing in the game should suffice for you to notice the current status: the AI mostly works, but is limited to very basic combat ("see player, attack player").
This project is difficult because you will need to dive into the large AI codebase that wasn't very well designed (due to lack of care in the planning of evolution of the game), understand its limitations and propose something that fixes them. You need to be comfortable with the C programming language, and have an interest in artificial intelligence for isometric 3D video games. We believe the problem is interesting to solve, and makes a good GSoC? project.
Changed lines 77-79 from:
- propose a better state machine design for AI
- write the new AI for both enemy and allied bots (moving and fighting behaviors)
- write the new AI for humans (moving and fighting behaviors)
- have your AI playtested
to:
- propose a better design for AI
- write the new AI for enemy and allied bots, and for humans (moving and fighting behaviors)
- have your AI playtested and refine it
Added line 83:
This project has a few links with AI rewrite project - you will have to communicate with the person taking care of AI in order to agree on certain things.
Changed lines 85-90 from:
to:
weak point in the game.
Collision detection has two problems: performance and actual results - the system is terribly slow (because it uses unefficient O(n
Added line 93:
- design and implement a faster, better collision detection system
Added line 95:
- integrate your new code in the engine and check how well it works, improve if necessary
Added line 102:
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.
Changed line 105 from:
- design 5 to 20 minigames that can be finished in less than one to two minutes of playing
to:
- write 4+ minigames that can be finished in less than one to two minutes of playing
Changed lines 108-110 from:
- implement those games, test the difficulty levels and do the balancing
- make it such that FreedroidRPG? choses a minigame randomly when the player attempts a
takeover. don't throw away the original game
to:
- provide graphics and sound effects for your games if possible
- test the difficulty levels and do the balancing
March 03, 2008, at 06:04 PM
by ah --
Changed line 1 from:
This page lists open jobs for outsiders.
to:
This page lists open jobs for outsiders. It notably contains Google Summer of Code project ideas.
Changed lines 4-5 from:
Large projects (Google Summer of Code ideas)
to:
Added line 7:
Large projects
Changed lines 14-15 from:
This relatively easy project requires a bit of experience with C, as you will have to work on the existing leveleditor which is a bit dirty due to non careful design. You do not need to know C very well, nor have strong SDL and OpenGL? experience. If you have experience designing graphical user interfaces, or working with isometric 3D level editors, this is a plus.
to:
This relatively easy project requires a bit of experience with C, as you will have to work on the existing leveleditor which is a bit dirty due to non careful design. 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 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.
Changed line 27 from:
- (if time permits) handle placement of random and special enemies on the map (this has to be
done by hand editing the file map/ ReturnOfTux?.droids at the moment)
to:
- (if time permits) handle placement of random and special enemies on the map
Changed line 33 from:
value by adding content. You will write a generator that is able to build fully playable levels.
to:
value by adding content. You will write a generator that is able to build fully playable levels, such as what the game Diablo does.
Added line 38:
The coding part of this project is only 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. Due to lack of time we have not been able to assess existing GPL solutions, so this would be part of the project.
Added line 42:
- see what dungeon/labyrinths generators exist, and how they could be adapted to FreedroidRPG?
March 03, 2008, at 12:17 PM
by ah --
Changed line 12 from:
This project requires experience with C, as you will have to work on a large existing codebase
that is a bit dirty due to non careful design.
to:
This relatively easy project requires a bit of experience with C, as you will have to work on the existing leveleditor which is a bit dirty due to non careful design. You do not need to know C very well, nor have strong SDL and OpenGL? experience. If you have experience designing graphical user interfaces, or working with isometric 3D level editors, this is a plus.
Added line 35:
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.
March 02, 2008, at 02:45 PM
by ah --
Added lines 92-104:
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.
- understand the original takeover game
- design 5 to 20 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
- implement those games, test the difficulty levels and do the balancing
- make it such that FreedroidRPG? choses a minigame randomly when the player attempts a
takeover. don't throw away the original game
February 29, 2008, at 10:53 AM
by 77.185.45.111 --
Changed line 83 from:
The pathfinding and collision system of FreedroidRPG? turns out not to work well enough, and is a
to:
The pathfinding and collision system of FreedroidRPG? turns out not to work well enough, and is a
February 29, 2008, at 10:53 AM
by 77.185.45.111 --
Changed line 8 from:
FreedroidRPG? features an integrated graphical level editor. It works quite well, but needs some
to:
FreedroidRPG? features an integrated graphical level editor. It works quite well, but needs some
Changed line 10 from:
Editors from other games such as The Sims could be an inspiration.
to:
Editors from other games such as The Sims could be an inspiration.
Changed line 12 from:
This project requires experience with C, as you will have to work on a large existing codebase
to:
This project requires experience with C, as you will have to work on a large existing codebase
Changed lines 15-21 from:
Various things to do are :
* implement placing of walls as lines instead of tile by tile
* support selection of elements on the map, provide copy/paste functionnality
* add a undo feature
* remember "favorite" wall tiles in a specific menu
* add a system that allows testing the level without altering the world state (save the map, test
to:
Various things to do are :
- implement placing of walls as lines instead of tile by tile
- support selection of elements on the map, provide copy/paste functionnality
- add a undo feature
- remember "favorite" wall tiles in a specific menu
- add a system that allows testing the level without altering the world state (save the map, test
Changed lines 23-25 from:
* improve autoscrolling system
* anything you feel is important for the interface
* (if time permits) handle placement of random and special enemies on the map (this has to be
to:
- improve autoscrolling system
- anything you feel is important for the interface
- (if time permits) handle placement of random and special enemies on the map (this has to be
Deleted line 26:
Deleted line 27:
Random dungeon generation
Changed lines 29-31 from:
This project aims at bringing random levels to FreedroidRPG?, in order to increase the gameplay
to:
Random dungeon generation
This project aims at bringing random levels to FreedroidRPG?, in order to increase the gameplay
Changed line 37 from:
to:
Your tasks are :
Changed line 39 from:
* design a random dungeon generator that can make completely playable levels including floor
to:
- design a random dungeon generator that can make completely playable levels including floor
Changed lines 41-42 from:
* 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
to:
- 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
Changed line 47 from:
This project requires knowledge of C and previous OpenGL? experience, as you will be required to
to:
This project requires knowledge of C and previous OpenGL? experience, as you will be required to
Changed line 52 from:
FreedroidRPG? OpenGL? performance is acceptable but can be improved with a few changes, notably by
to:
FreedroidRPG? OpenGL? performance is acceptable but can be improved with a few changes, notably by
Changed line 55 from:
to:
The ideas are:
Changed line 57 from:
* use a texture atlas for floor tiles (you will have to write the program for making atlases or
to:
- use a texture atlas for floor tiles (you will have to write the program for making atlases or
Changed line 59 from:
* evaluate the relevance of using a texture atlas for obstacles (walls etc.) and implement it if
to:
- evaluate the relevance of using a texture atlas for obstacles (walls etc.) and implement it if
Changed lines 61-65 from:
* use a texture atlas for every character (tux, bots, etc.)
* texture atlas for inventory item images
* use texture atlas for the characters of a font
* use vertex buffers whenever possible (definitely doable for floor tiles)
* if you have time and interest, play with disable-able additional effects such as GLSL
to:
- use a texture atlas for every character (tux, bots, etc.)
- texture atlas for inventory item images
- use texture atlas for the characters of a font
- use vertex buffers whenever possible (definitely doable for floor tiles)
- if you have time and interest, play with disable-able additional effects such as GLSL
Changed line 67 from:
* if you have time and interest, write an additional flame effect and implement a flamethrower
to:
- if you have time and interest, write an additional flame effect and implement a flamethrower
Changed line 71 from:
FreedroidRPG?'s artificial intelligence of non playing characters is not very good. The NPCs? tend
to:
FreedroidRPG?'s artificial intelligence of non playing characters is not very good. The NPCs? tend
Changed lines 73-79 from:
a new AI system by yourself, and actually implement it.
The steps are:
* understand the existing AI system and its limitations
* propose a better state machine design for AI
* write the new AI for both enemy and allied bots (moving and fighting behaviors)
* write the new AI for humans (moving and fighting behaviors)
* have your AI playtested
to:
a new AI system by yourself, and actually implement it.
The steps are:
- understand the existing AI system and its limitations
- propose a better state machine design for AI
- write the new AI for both enemy and allied bots (moving and fighting behaviors)
- write the new AI for humans (moving and fighting behaviors)
- have your AI playtested
Changed line 81 from:
Pathfinding
to:
Pathfinding
Changed line 83 from:
The pathfinding and collision system of FreedroidRPG? turns out not to work well enough, and is a
to:
The pathfinding and collision system of FreedroidRPG? turns out not to work well enough, and is a
Changed lines 89-90 from:
* try to understand the existing system and its limitations
* design and implement a suitable pathfinding algorithm
to:
- try to understand the existing system and its limitations
- design and implement a suitable pathfinding algorithm
February 29, 2008, at 10:10 AM
by 80.170.75.228 --
Changed line 2 from:
Note that you can also pick from ToDo/{ ToDo} and send a patch, or simply implement something of your choice !
to:
Note that you can also pick from ToDo and send a patch, or simply implement something of your choice !
February 29, 2008, at 10:09 AM
by 80.170.75.228 --
Changed lines 4-90 from:
Large projects
to:
Large projects (Google Summer of Code ideas)
Leveleditor overhaul
FreedroidRPG? features an integrated graphical level editor. It works quite well, but needs some
more work to increase the productivity of people doing levels, and attract more contributors.
Editors from other games such as The Sims could be an inspiration.
This project requires experience with C, as you will have to work on a large existing codebase
that is a bit dirty due to non careful design.
Various things to do are :
* implement placing of walls as lines instead of tile by tile
* support selection of elements on the map, provide copy/paste functionnality
* add a undo feature
* remember "favorite" wall tiles in a specific menu
* add a system that allows testing the level without altering the world state (save the map, test
level, reload the map)
* improve autoscrolling system
* anything you feel is important for the interface
* (if time permits) handle placement of random and special enemies on the map (this has to be
done by hand editing the file map/ ReturnOfTux?.droids at the moment)
Random dungeon generation
This project aims at bringing random levels to FreedroidRPG?, in order to increase the gameplay
value by adding content. You will write a generator that is able to build fully playable levels.
This project requires a bit of interference with existing FreedroidRPG? code source in order to
integrate the generator into the engine, but the first steps of it are fairly independant from the
game.
Your tasks are :
* 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
OpenGL? performance improvements
This project requires knowledge of C and previous 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 to make sure what you implemented
actually improves performance.
FreedroidRPG? OpenGL? performance is acceptable but can be improved with a few changes, notably by
reducing the amount of texture changes, and the overhead of vertex emission.
The ideas are:
* use a texture atlas for floor tiles (you will have to write the program for making atlases or
provide a free software one)
* evaluate the relevance of using a texture atlas for obstacles (walls etc.) and implement it if
necessary
* use a texture atlas for every character (tux, bots, etc.)
* texture atlas for inventory item images
* use texture atlas for the characters of a font
* use vertex buffers whenever possible (definitely doable for floor tiles)
* if you have time and interest, play with disable-able additional effects such as GLSL
explosions/flames
* if you have time and interest, write an additional flame effect and implement a flamethrower
Artificial intelligence
FreedroidRPG?'s artificial intelligence of non playing characters is not very good. The NPCs? tend
to fire on allies, bump into walls, etc. This project is difficult because you will have to design
a new AI system by yourself, and actually implement it.
The steps are:
* understand the existing AI system and its limitations
* propose a better state machine design for AI
* write the new AI for both enemy and allied bots (moving and fighting behaviors)
* write the new AI for humans (moving and fighting behaviors)
* have your AI playtested
Pathfinding
The pathfinding and collision system of FreedroidRPG? turns out not to work well enough, and is a
weak point in the game. You will have to provide a new pathfinding module that yields a satisfying
behavior of the various actors on the map. Because of the inherent weakness of collision detection
in FreedroidRPG? you may have to fix this first. This project requires an interest in pathfinding
algorithms applied to an isometric 3D RPG and understanding of C.
* try to understand the existing system and its limitations
* design and implement a suitable pathfinding algorithm
Deleted line 91:
To be written
February 29, 2008, at 10:06 AM
by 80.170.75.228 --
Changed lines 1-2 from:
Here I post some jobs that we could need help with from 'outsiders'. Not that we wouldn't need help with many other things too, but these are some especially important items, that should be mentioned explicitly.
to:
This page lists open jobs for outsiders.
Note that you can also pick from ToDo/{ ToDo} and send a patch, or simply implement something of your choice !
Changed lines 4-6 from:
All other areas of the game also need help and your contibution to that would be welcome there as well of course.
to:
Large projects
To be written
May 20, 2004, at 07:09 PM
by 62.47.25.13 --
Changed lines 1-3 from:
to:
Here I post some jobs that we could need help with from 'outsiders'. Not that we wouldn't need help with many other things too, but these are some especially important items, that should be mentioned explicitly.
All other areas of the game also need help and your contibution to that would be welcome there as well of course.
| |
|
|
|
|
