| Version 5 (modified by , 9 years ago) ( diff ) |
|---|
Table of Contents
Idea List for Google Summer of Code 2014
This list has mostly been culled from GameplayFeatureStatus, GraphicsFeatureStatus, and GamePerformance.
Project Shortlist
| Feature | Relevant link(s) | Difficulty |
|---|---|---|
| Short / Vertex Pathfinder Rewrite | Detail #1942 | Hard |
| Potential AI architecture improvement | Detail | Hard |
| Different Game Modes | Detail | Easy |
| Improved Threading | Detail | Medium |
| NAT Transversal | Detail #2305 | Medium |
| Realistic Naval Warfare | Detail #940 #305 | Medium |
| OpenGL ES 2.0 Support | Detail | Easy |
| Renderer improvements | Detail #2337 | Medium |
Projects
Short / Vertex Pathfinder Rewrite
Details
The current short-range pathfinder in 0 A.D. is one of our greatest bottlenecks and needs to be re-written to work with the new long range pathfinder and our formation system.
This potentially means finding novel ways of short-term pathfinding, such as crowd movements. Work is already ongoing in that direction, so this area is subject to a lot of cross-team talk.
Expected Result
New short-range pathfinder which fits with 0 A.D.'s gameplay and is at least 4 times faster.
Required Prerequisites
Fluency in C++, familiarity with pathfinding systems, and experience in C++ optimization.
Helpful Links
Ticket #1942
Potential improvements to the AI architecture
Details
The current AI in 0 A.D. runs a lot of very complex calculations all in JavaScript which can become very slow. We have discussed moving intensive calculations to C++, or relying more on the C++ (for pathfinding for example), but this has never proved 100% satisfactory (it is assumed converting data from JS to C++ and vice-versa is too slow). New ideas could be brought to the table, and actual extensive testing is required anyhow.
Expected Result
Improvements in AI efficiency, to which extent is currently hard to tell (this will have to be determined too).
Required Prerequisites
Fluency in C++ and JavaScript. Experience with SpiderMonkey and optimization is a definite plus, having worked with AI and threading could be useful too.
Helpful Links
This forum thread might be helpful.
Different Game Modes
Details
Currently 0 A.D. has only two game mode - conquest or wonder - obliterate your enemies or build a wonder to win. This lacking number is atypical to an RTS and should be expanded upon with game modes like "Regicide", "Deathmatch", "King of the Hill" and, "Treaty". The details of each game mode would be worked out with the project manager, but an example of how the "Regicide" game mode would work should give you an idea of what this would entail. A game started as a Regicide game would initially be identical to a normal game, excepting the fact that each player starts with a powerful "regent" unit. The goal of a Regicide game would also be different. Your opponent's sole goal would be to eliminate your regent at which point you would immediately lose.
Expected Result
At least one new game mode.
Required Prerequisites
Experience in C++ and JavaScript. Experience with game (any, not only computer game) development is a plus.
Helpful Links
?
Better Threading
Details
Right now 0 A.D. has a number of minor threads, but all the major calculations are run in the main thread. We would like to see some of the more intensive loads split into their own threads so as to take better advantage of modern multicore processors. Potential processes to be split out would be the Range Manager, Renderer, or AI (it would be awesome if each AI could get its own thread).
Expected Result
At least one major computational load being isolated into its own thread.
Required Prerequisites
Fluency in C++ and experience using pthreads. (Familiarity with SpiderMonkey and JavaScript may also be required depending on the component)
Helpful Links
?
NAT Transversal
Details
Right now in 0 A.D. we use a primitive UPnP system to implement NAT transversal but this system is unreliable. We'd like to see a better method using UDP Hole Punching instead. The solution would most likely involve interacting with the lobby server to get transversal information.
Expected Result
Enabling 0 A.D. clients to connect to a host behind any type of NAT.
Required Prerequisites
Fluency in C++ and understanding of NAT transversal. JavaScript knowledge would also be recommended. (Ability to learn/familiarity with erlang would also be required when dealing with the lobby server)
Helpful Links
#2305 Incomplete/failed try at implementation
Realistic Naval Warfare
Details
As of now, navel battles in 0 A.D. are at best confusion because naval units generally try to behave exactly like land units. Some things which could help with this would be,
- Smart/realistic boat movement (so that the boat obstruction sizes can be increased to actually match the model size without horrible movement behavior)
- Better battle animation (like make the ram attack actually visible)
This area is open to suggestions, so any good idea goes.
Expected Result
Improved gameplay experience in naval combat.
Required Prerequisites
Fluency in JavaScript and at least basic C++ experience. Experience with game (any, not only computer game) development is a plus.
Helpful Links
Improved Model Culling
Details
0 A.D.'s renderer is suboptimal in several areas. The GUI system does no batching at all, which is very slow, and could be reworked a lot. The Model renderer does batching, but uses naive and non-persistent culling which slows it down. Using some existing groundwork (such as a central component for culling), extensive improvements could be obtained (examples including support of several lights, batching by merging similar meshes together dynamically, automatic texture combining…).
Expected Result
Rendering should be sped up significantly for maps with many slightly different models, such as maps with many trees, of which there are many.
Required Prerequisites
Experience with C++, OpenGL, and graphics programming in general.
Helpful Links
OpenGL ES 2.0 Support
Details
This is sort of a subset of the rendering improvement. Right now we have just enough support of OpenGL ES 2.0 to launch an error-ridden game on Android. We would like to be able to transparently support OpenGL ES 2.0. Firstly, everything available in 0 A.D. on normal OpenGL 2.0 hardware should be available in the ES version. Secondly, we should support using OpenGL ES 2.0 in a typical environment with X-windows (might require fighting SDL).
Expected Result
Ability to play the game in GLSL mode on an OpenGL ES 2.0 system running X-windows.
Required Prerequisites
Experience with C++ and OpenGL. SDL experience could also be helpful.
Helpful Links
AMD OpenGL ES SDK Git branch of historicbruno's work towards better GLES support
Improve Terrain texture blending
Details
This is sort of a subset of the rendering improvement. The terrain texture blending in 0 A.D. is imperfect: it can only blend two textures together, using alpha maps, over one tile only; this leads to uglyness, notably in random maps. Rewriting this system could lay groundwork for other improvements and could significantly improve the look of the game.
Expected Result
Terrain blending should probably support an arbitrary number of textures (or at least several), and should look prettier and be more customizable (both for smoother or less smooth transitions).
Required Prerequisites
Experience with C++, OpenGL, and graphics programming in general would help.
Helpful Links
None really so far.
