explain autobuilds
[xonotic/xonotic.wiki.git] / GSoC-2011-ideas.md
1 GSoC 2011 ideas
2 ===============
3
4 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.
5
6 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.
7
8 Getting in touch
9 ----------------
10
11 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!
12
13 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.
14
15 FAQ
16 ---
17
18 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.
19
20 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.
21
22 Ideas
23 -----
24
25 ### Round-Based Gametype
26
27 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.
28 Prospective mentors: Samual, Dib, tZork, FruitieX
29 Effort Level: Medium to High
30 Knowledge required: QuakeC / C
31
32 ### Allowing CSQC to control entities (and maybe also ragdolls and animation blending)
33
34 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.
35 Prospective mentors: divVerent, tZork
36 Effort level: medium
37 Knowledge required: C
38
39 ### Loadable mutators
40
41 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”.
42 Prospective mentors: divVerent
43 Effort level: medium
44 Knowledge required: C
45
46 ### Implementing a statistics system for Xonotic
47
48 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.
49 Prospective mentors: merlijn, detrate, Antibody
50 Effort level: medium to high
51 Knowledge required: Databases and some web language like PHP / Python
52
53 ### Soft Particles and (real) Cel Shading for the engine
54
55 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.
56 Prospective mentors: Samual, divVerent, perhaps LordHavoc
57 Effort level: medium
58 Knowledge required: C, OpenGL experience, GLSL
59
60 ### Better player and movement prediction with physics
61
62 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.
63 Prospective mentors: divVerent, LordHavoc
64 Effort level: Medium to high
65 Knowledge required: C and probably some networking knowledge
66
67 ### Scoreboard re-write/rebase upon new hud code
68
69 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.
70 Prospective mentors: Samual, FruitieX
71 Effort level: Low to medium
72 Knowledge required: C and some 2D rendering
73
74 ### Dynamic menu rendering and controls
75
76 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.
77 Prospective mentors: Samual, divVerent
78 Effort level: Medium
79 Knowledge required: C
80
81 ### BOCC
82
83 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.
84 Prospective mentors: Blub\\0, divVerent
85 Effort Level: Probably high
86 Knowledge required: C / C++
87
88 ### g\_warmup\_allguns 2:
89
90 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.
91 Prospective mentors: Samual, divVerent
92 Effort level: low to medium
93 Knowledge required: QuakeC / C
94
95 ### Blender for Mappers
96
97 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).
98 Prospective mentors: divVerent
99 Effort level: low to high, depending on subtask
100 Knowledge required: Blender, Python, possibly C++
101
102 ### New bot AI
103
104 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.
105 Propective mentors: tZork, divVerent
106 Effort level: medium to high
107 Knowledge required: AI, QuakeC / C
108