GSoC-2011-ideas.textile

   1 h1. GSoC 2011 ideas
   2
   3 This page lists a number of ideas given by the developers, which can serve as the bases for a proposal. The ideas are quite short on purpose, you are encouraged to talk to (one of) the prospective mentors about the project to find out more about a certain subject. We can also point you in the right direction regarding documentation or code you may find useful when writing your proposal.
   4
   5 You may obviously come up with your own ideas, but please discuss them with us before writing your proposal. Many ideas are likely to have implications that need to be taken into account, and we may be able to point you to previous attempts of implementing certain features.
   6
   7 h2. Getting in touch
   8
   9 We frequently hang out in our main irc channel: #xonotic on Freenode. There are also many other people there who may be able to help you in your quest for information, don't hesitate to ask!
  10
  11 Alternatively you may contact us using the forums or email. Generally the mentors can be reached by their nickname [at] xonotic.org, if you don't know who can mentor you please address the emails to admin [at] xonotic [you-know-what-comes-here] org, and we will find someone who can assist you.
  12
  13 h2. FAQ
  14
  15 To give you a basic idea of how the game works internally, this is a short summary of the pieces involved. We use the DarkPlaces engine to run the game, the engine is written entirely in C and provides all the features for rendering and integration. The engine is based on the GPL sources of Quake 1, and is still fully compatible with it. The engine spawns a sort of VM that executes the gamecode, this is written in the C-derived language QuakeC. QuakeC is actually a subset of the C language, and is quite easy to learn (if you know a little C you can pick it up in a few hours). The gamecode is compiled using fteqcc, which produces a progs.dat (server code), csprogs.dat (client code) and menu.dat (guess). Maps are created using some form of Radiant, mostly NetRadiant.
  16
  17 Everything that ships with the game is licensed under the GPLv2. This means that all your contributions must also be licensed under this license, but you maintain all the rights to the code you write.
  18
  19 h2. Ideas
  20
  21 h3. Round-Based Gametype
  22
  23 This is required for games like arena, clan arena, and freezetag. A proper round-based system which allows for two types of spectators: one for each team and one for a player that just joined. Also proper scoring system for this. This includes rewriting some of our current gamemodes to use the round-based system.
  24 Prospective mentors: Samual, Dib, tZork, FruitieX
  25 Effort Level: Medium to High
  26 Knowledge required: QuakeC / C
  27
  28 h3. Allowing CSQC to control entities (and maybe also ragdolls and animation blending)
  29
  30 Currently tasks such as ragdolls and animation blending cannot be accomplished from the client side, and it would be too harsh on network traffic if we were to do this server side, so essentially the idea is to allow CSQC to manipulate the SSQC entities specifically for this purpose.
  31 Prospective mentors: divVerent, tZork
  32 Effort level: medium
  33 Knowledge required: C
  34
  35 h3. Loadable mutators
  36
  37 Basically, a dynamic linking system for progs. Additionally to the regular game code, additional game code can be loaded from extra files. These link to the main game code by field/function names, and also have a special initialization function the engine calls at load time. This, with our existing "mutator system", will provide a full equivalent to Unreal Engine's "mutators".
  38 Prospective mentors: divVerent
  39 Effort level: medium
  40 Knowledge required: C
  41
  42 h3. Implementing a statistics system for Xonotic
  43
  44 We would like to be able to let players keep track of their scores, progress and achievements using a website. We can already generate a lot of output from the game and store that in a centralized way, so this would mainly involve creating a web frontend that ties in with our other webpages and databases.
  45 Prospective mentors: merlijn, detrate, Antibody
  46 Effort level: medium to high
  47 Knowledge required: Databases and some web language like PHP / Python
  48
  49 h3. Soft Particles and (real) Cel Shading for the engine
  50
  51 Simple effects which need a *real* (defered shadow one won't work) depth buffer to work properly, they're also generally light on resources and wouldn't be very harmful to real time performance.
  52 Prospective mentors: Samual, divVerent, perhaps LordHavoc
  53 Effort level: medium
  54 Knowledge required: C, OpenGL experience, GLSL
  55
  56 h3. Better player and movement prediction with physics
  57
  58 Right now our player prediction really isn't all that good, it mismatches a lot and doesn't account for a lot of things which it needs to. If we could expand upon it and improve it for things such as ladders/hook etc then it would be really fantastic.
  59 Prospective mentors: divVerent, LordHavoc
  60 Effort level: Medium to high
  61 Knowledge required: C and probably some networking knowledge
  62
  63 h3. Scoreboard re-write/rebase upon new hud code
  64
  65 The current scoreboard code is quite outdated and simply doesn't fit the new panelhud very well. Remaking a lot of its structure and incorporate it as a separate "page" for the HUD will integrate it better. That in and of itself would open up new possibilities for the HUD, and allow easier extending of the scoreboard for gamemode specific tweaks.
  66 Prospective mentors: Samual, FruitieX
  67 Effort level: Low to medium
  68 Knowledge required: C and some 2D rendering
  69
  70 h3. Dynamic menu rendering and controls
  71
  72 Improve the current menu system by allowing controls on the menu to be changed in real time (such as strings for buttons or even hiding/showing controls dynamically), so that dialogs can be created and changed dynamically from the code for use in game. The biggest use for this would be to have CSQC menus for things like voting or hud_setup, which allows a cleaner a way of implementing these with better extendibility.
  73 Prospective mentors: Samual, divVerent
  74 Effort level: Medium
  75 Knowledge required: C
  76
  77 h3. BOCC
  78
  79 We currently use the FTEQCC project to compile our gamecode, which has quite a few problems. Mainly it lacks ways of implementing more complex optimizations and it doesn't have very good support for some basic functions like arrays. We have a new project which in its current state cannot yet compile all the gamecode, but allows for better ways of implementing the DP1 assembler and more optimizations. This project would mainly focus on making BOCC work for all of our gamecode, and if possible some minor optimizations.
  80 Prospective mentors: Blub\0, divVerent
  81 Effort Level: Probably high
  82 Knowledge required: C / C++
  83
  84 h3. g_warmup_allguns 2:
  85
  86 Currently warmup mode gives you every normal weapon, and we would like it to only give the weapons which are available on that map. Right now the weapons are set up for warmup before it is known which weapons are available, so it would probably involve  some alternative or work around. This would mainly be useful for competitive play, where warmup mode is pretty default before starting a match.
  87 Prospective mentors: Samual, divVerent
  88 Effort level: low to medium
  89 Knowledge required: QuakeC / C
  90
  91 h3. Blender for Mappers
  92
  93 Basically, various tools/scripts (or, code changes in Blender) for mappers to efficiently work in Blender that can be easily called from the Blender user interface. Possibilities include: first person shooter-like camera movement (like Radiant has, with forward, backward, strafe left, strafe right, and mouse turning); "brush objects" (quick tools to make a cube, and deform it to put in the appropriate place); texture alignment (mappers typically prefer XY/YZ/ZX axis projections of the texture, Blender can currently do this, but it is quite complex to set up); q3 shader to Blender material import; but also: using Blender to generate lightmaps for an existing .bsp file (possibly done using q3map2's export-to-obj feature).
  94 Prospective mentors: divVerent
  95 Effort level: low to high, depending on subtask
  96 Knowledge required: Blender, Python, possibly C++
  97
  98 h3. New bot AI
  99
 100 Our current bots are not very smart, and mappers have to add many waypoints in order to make them move around a map at all. It would be good if the AI could be simplified and be more fun to play against bots. The AI should also be easily extendible for new gamemodes where different objectives can be defined.
 101 Propective mentors: tZork, divVerent
 102 Effort level: medium to high
 103 Knowledge required: AI, QuakeC / C